Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]
Задача с экзамена 1С Эксперт. (частично обсуждение было )
Текст задачи:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос select count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c."
Можете ли Вы подсказать, пожалуйста, в каком направлении мыслить/искать? Преподаватель говорит, есть порядка 12 способов решить задачу.
Коллеги отвечали преподавателю (Александру Морозову) по-разному, мы заранее придумали что можно отетить и отвечали
1) требуется выполнение всех регламентных операций, дефрагментация, реиндексация
2) требуется создание некластерного индекса или сделать регистр таким, чтобы был хотя бы один некластерный индекс, т.к. scan по нему быстрее скана по кластерному индексу
Первые два совета недостаточны.
3) Пробовали ответить, что нужно хранить заведомо где-то количество в этом регистре, типо константы и при записи наборов записей или удалении - следить за тем, сколько у нас записей (жертвуем записью ради запроса по выбору количества записей) - тоже не подходит
4) Коллеги предлагали из DMV представлений или статистики получать значение - тоже преподаватель говорит нарушение лиц.соглашения, нельзя в обход rphost подключаться к SQL базе напрямую
5) может быть нужно секционирование предложить было? Но Вы писали где-то, что его оч.сложно настроить и нужны знания сертифицированного специалиста MS SQL
6) Может быть надо MDOP = 1 выставить? Т.к. если 60 секунд выполняется сканирование - может быть происходит блокировка параллельных сканов или что-то такое.
7) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".
Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)
Спасибо!!!
Текст задачи:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос select count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c."
Можете ли Вы подсказать, пожалуйста, в каком направлении мыслить/искать? Преподаватель говорит, есть порядка 12 способов решить задачу.
Коллеги отвечали преподавателю (Александру Морозову) по-разному, мы заранее придумали что можно отетить и отвечали
1) требуется выполнение всех регламентных операций, дефрагментация, реиндексация
2) требуется создание некластерного индекса или сделать регистр таким, чтобы был хотя бы один некластерный индекс, т.к. scan по нему быстрее скана по кластерному индексу
Первые два совета недостаточны.
3) Пробовали ответить, что нужно хранить заведомо где-то количество в этом регистре, типо константы и при записи наборов записей или удалении - следить за тем, сколько у нас записей (жертвуем записью ради запроса по выбору количества записей) - тоже не подходит
4) Коллеги предлагали из DMV представлений или статистики получать значение - тоже преподаватель говорит нарушение лиц.соглашения, нельзя в обход rphost подключаться к SQL базе напрямую
5) может быть нужно секционирование предложить было? Но Вы писали где-то, что его оч.сложно настроить и нужны знания сертифицированного специалиста MS SQL
6) Может быть надо MDOP = 1 выставить? Т.к. если 60 секунд выполняется сканирование - может быть происходит блокировка параллельных сканов или что-то такое.
7) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".
Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)
Спасибо!!!
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(205)
Слава, Вы какие-то глупые вопросы задаете. С какой, интересно, целью?
а эта система после внедрения модифицироваться не будет?
Будет. И это уже стоимость владения, куда риски тоже зашиваются. Но план развития системы обычно не оценивает архитектурные решения, которые существенно влияют на производительность, предполагая, что архитекторы вменяемые, а сценарное тестирование уже написано и позволит на тестовой среде воспроизвести новый функционал и определить уровень влияния на тот же APDEX.
Слава, Вы какие-то глупые вопросы задаете. С какой, интересно, целью?
(208)
Да, и как с этим помогут бороться Ваши продукты?
или каждый раз будете покупать заново железо и другие работы по перевнедрению?
Так в крупных конторах есть и среда разработки, и тестовая среда, и продуктив. Пример приведите конкретный. Вот что такого надо сделать, чтобы при внедрении нового функционала, оттестированного на сценарии в тестовой среде, внезапно завалить продуктовый сервер, который, обычно, несколько мощнее?
Да, и как с этим помогут бороться Ваши продукты?
(209) еще раз
вменяемые архитекторы, риски зашиваются, архитектурные решения - это так на курсе теперь что ли учат?
пока единственное что я услышал - вы предлагаете максимально точно сэмитировать нагрузку пользователей, которая должна быть сразу после внедрения
но делая конкретную фиксацию нагрузки вы тут же говорите что позднее после внедрения " позволит на тестовой среде воспроизвести новый функционал и определить уровень влияния " - но сервер то вы к этому моменту уже купите, ну получите вы новый характер нагрузки, с которым сервер больше не справляется, дальше что?
куда риски тоже зашиваются. Но план развития системы обычно не оценивает архитектурные решения, которые существенно влияют на производительность, предполагая, что архитекторы вменяемые,
вменяемые архитекторы, риски зашиваются, архитектурные решения - это так на курсе теперь что ли учат?
пока единственное что я услышал - вы предлагаете максимально точно сэмитировать нагрузку пользователей, которая должна быть сразу после внедрения
но делая конкретную фиксацию нагрузки вы тут же говорите что позднее после внедрения " позволит на тестовой среде воспроизвести новый функционал и определить уровень влияния " - но сервер то вы к этому моменту уже купите, ну получите вы новый характер нагрузки, с которым сервер больше не справляется, дальше что?
(210)
золотые слова кстати...
производительность никогда расти не будет(решения вцелом), а вот деградация - с радостью. Поэтому логично мониторить в рантайме.
И хоть и есть тестовые среды, покуда бизнес работает - будут вносится изменения, а значит и расти сложность готового решения.
ну получите вы новый характер нагрузки, с которым сервер больше не справляется,
золотые слова кстати...
производительность никогда расти не будет(решения вцелом), а вот деградация - с радостью. Поэтому логично мониторить в рантайме.
И хоть и есть тестовые среды, покуда бизнес работает - будут вносится изменения, а значит и расти сложность готового решения.
(211)
Короче, диалог с вами, господа, никуда не приводит, ибо Слава, как обычно, рекламирует свои продукты, а кто-то просто фанатеет. Учите математику - и будет вам счастье...
Поэтому логично мониторить в рантайме.
А кто говорит, что мониторить никто не будет? В любом случае есть APDEX, есть ТОП запросов, есть рабочая система. Деградация скорости возникает при увеличении числа записей в таблицах. SQL как раз и реализует замедление деградации. Если бы Вы с Славой владели математикой хоть чуть-чуть, то знали бы, что скорость поиска в таблице по индексу равна логарифму по основанию два из числа записей. А логарифм - функция медленно растущая, при том чем больше числа, тем медленнее растет логарифм. Есть тут умные, кто может производную от лог2(Х) привести? Из этой циферки видно, на сколько серьезно замедляется рост этой величины со временем. И если тестовые данные отработали на количестве равном миллиону, то для того, чтобы время поиска выросло в 2 раза, необходимо увеличить количество данных в миллион раз. А вот количество таблиц по всей видимости расти будет очень медленно, а соединения с ростом количества таблиц увеличиваться не будут. Знаете, как работает nested loops? Он берет данные одной таблицы и ищет их в другой. Если есть индекс, то в другой таблице он гарантированно найдет данные за лог2(кол-во записей второй таблицы). Таким образом, для дегрдации производительности этого запроса в двое при достаточном объеме ОЗУ, необходимо увеличить количество записей в тысячу примерно раз. А если индексов нет - извини, как говорится, но на то ты и архитектор, чтобы не писать запросы, которые не будут юзать индексы.
Короче, диалог с вами, господа, никуда не приводит, ибо Слава, как обычно, рекламирует свои продукты, а кто-то просто фанатеет. Учите математику - и будет вам счастье...
(213) Сергей, обратите внимание - к слову "деградация" я не добавлял слово "скорость"( и даже слово запрос ):
- бывают ситуации когда вчерашний бизнес вырастает в 2 раза и памяти на сервере тупо не остается;
- за один месяц кол-во баз может утроится, обрасти обменами;
- кто то "решит"(прикажет) хранить на сервере большое кол-во больших файлов( макетов по 150 мегабайт штука) и место на дисках на сервере быстро исчезнет;
- а еще "по приказу" сервер должен быть резиновым, держать копии всех баз в онлайне, для "тестовых" примеров так же хранить копии (ибо ишь чего - потеряются) - и вообще сервер - "не ломается и резерв не нужен" и покупку хрен обоснуешь.
- бывают ситуации когда вчерашний бизнес вырастает в 2 раза и памяти на сервере тупо не остается;
- за один месяц кол-во баз может утроится, обрасти обменами;
- кто то "решит"(прикажет) хранить на сервере большое кол-во больших файлов( макетов по 150 мегабайт штука) и место на дисках на сервере быстро исчезнет;
- а еще "по приказу" сервер должен быть резиновым, держать копии всех баз в онлайне, для "тестовых" примеров так же хранить копии (ибо ишь чего - потеряются) - и вообще сервер - "не ломается и резерв не нужен" и покупку хрен обоснуешь.
(214) (215)
и покупку хрен обоснуешь.
Ну вот Слава предложил за 500 рублей сразу купить то, что нужно. Они там типа решают проблему вновь возникшей нагрузки в автоматическом режиме. Я так примерно представляю схему: у Вас нагрузка Х, платите 500 руб, вам автоматически подбирают самое дешевое барахло, которое Х тянет (ну а на что машину покупать, если все иначе). Дальше возрастает нагурзка. Снова платим 500 рублей и на вырученные от проданной машины деньги покупаем второй сервер для нагрузки Y. Я Славу, конечно, понимаю - "ничего личного, джаст бизнес".
(216) можешь привести примеры когда мы кому то посоветовали купить "барахло"?
поливание грязью это тоже часть тренинга?
И про бизнес, если обучение таковым считать - - мы обучаем людей подбирать оборудование, причем именно исходя из практики какие способы жизнеспособны, а какие "просто слив денег". Т.е. мы даем различные возможности - не хочешь задумываться, есть быстрый способ в автоматическом сервисе, хочешь вникать, приходи, научим.
(217) на некорректно поставленный вопрос сложно получить правильный ответ
из ниоткуда в никуда ничего не бывает
как уже была дана ссылка в исходном посте - разумные решения заключаются в том чтобы не сканировать постоянно таблицу в 100 миллионов строк,
варианты реализации тоже обсудили
разве что преподаватель знает готовый механизм платформы, который эту реализацию автоматизирует
у нас сервисах не совсем, но похожая задача есть "мы контролируем максимально приемлемый размер полтеррабайтной таблицы", чтобы сервер ее переваривал, и опрашиваем статистическое знание скулем размера таблицы, оно не точное, но для того чтобы нам принять решение о переносе в архив "лишних строк" устраивает
поливание грязью это тоже часть тренинга?
И про бизнес, если обучение таковым считать - - мы обучаем людей подбирать оборудование, причем именно исходя из практики какие способы жизнеспособны, а какие "просто слив денег". Т.е. мы даем различные возможности - не хочешь задумываться, есть быстрый способ в автоматическом сервисе, хочешь вникать, приходи, научим.
(217) на некорректно поставленный вопрос сложно получить правильный ответ
из ниоткуда в никуда ничего не бывает
как уже была дана ссылка в исходном посте - разумные решения заключаются в том чтобы не сканировать постоянно таблицу в 100 миллионов строк,
варианты реализации тоже обсудили
разве что преподаватель знает готовый механизм платформы, который эту реализацию автоматизирует
у нас сервисах не совсем, но похожая задача есть "мы контролируем максимально приемлемый размер полтеррабайтной таблицы", чтобы сервер ее переваривал, и опрашиваем статистическое знание скулем размера таблицы, оно не точное, но для того чтобы нам принять решение о переносе в архив "лишних строк" устраивает
(220)Вячеслав, я три раза перечитывал обсуждения на форуме по ссылке в исходном посте. И я понимаю что лучше не сканировать. Но я приводил в этой ветке (89-90 посты) результаты замера на своей рабочей базе, со скриншотом, у меня в регистре сведений цен номенклатуры 50+ млн записей и читает начиная от 0,3 сек (хотя разброс большой). Это наводит меня на мысль, что действительно реально просчитать и на 100 млн записей за 1сек. и без добавления констант, реквизитов в регистре и прочего, а просто запросом 1С. (хотя возможно между 50 и 100 млн происходит качественный скачок сложности для сервера). Всё это далее наводит на мысль, что действительно есть что-то, что преподаватель знает, вот это и не дает покоя. Еще смущает в формулировке, что 1000 человек одновременно пытаются то ли прочитать, то ли просто работать с регистром и мне кажется, именно этот факт приводит к задержке до 60 сек и вообще оговорка про 1000 человек не случайна.
(221) задержка в 60 секунд не обязательно может быть следствием ожиданий на блокировках, еще есть вариант что железо не справляется с 1000 одновременных запросов и возникают ожидания на дисках, или процессоре или т.п. ,
и тогда речь оптимизации опроса количества строк может быть сведена к пуллированию, например только один фоновый сеанс имеет право спрашивать количество, а остальные потребители получают это число от фонового процесса
в реальной жизни также видел ожидания связанные с некорректной отработкой платформой изменившихся доступных ресурсов виртуалки, которая коллективно с другими виртуалками туда-сюда гонят "общие ядра, память и т.п.", но думаю на экзамене 1С:Эксперт такое не спрашивают
согласен с вами, что надо у преподавателя выяснить природу задержек
и тогда речь оптимизации опроса количества строк может быть сведена к пуллированию, например только один фоновый сеанс имеет право спрашивать количество, а остальные потребители получают это число от фонового процесса
в реальной жизни также видел ожидания связанные с некорректной отработкой платформой изменившихся доступных ресурсов виртуалки, которая коллективно с другими виртуалками туда-сюда гонят "общие ядра, память и т.п.", но думаю на экзамене 1С:Эксперт такое не спрашивают
согласен с вами, что надо у преподавателя выяснить природу задержек
(220)
поливание грязью это тоже часть тренинга?
Я никого не поливаю, я просто задаюсь вопросом и фантазирую о том, как сервис может определить, с какой нагрузкой в будущем столкнется клиент. Ведь машину на что-то надо покупать, да? Ничего личного - просто попытка понять.
(222) не ради тебя а истины для. сходил на указанный сайт и ... ничегошеньки не нашел про "с какой нагрузкой в будущем столкнется клиент". нет там такого, это плод твоей фантазии, чтение межстрочное и тд. единственное косвенное упоминание это требование указать размер базы, но видима такова формула расчета. всяко лучше, чем запрашивать средний возраст младших аналитиков отдела бюджетирования :)
(225)
ничегошеньки не нашел про "с какой нагрузкой в будущем столкнется клиент"
Ну так я и говорю, что ничего такого нет. Есть только текущая нагрузка и какая-то предположительная оценка ее роста. Но вопрос был как раз о том, что делать с тем, что новые механизмы будут требовать большего от системы. Слава на это сказал, что у него есть супер-сервис, который за 500 рублей все сделает, на что я заметил, что вряд ли. И кто тут читает между строк?
(212) т.е. мы вложили деньги в достаточно точно имитирующий нагрузку пользователей тест, оценили характеристики сервера под эту нагрузку, и после этого говорим
а хрен его знает насколько мощнее нужен сервер, но мощнее?
тогда возникают вопросы: зачем делать точный тест, если в итоге мы не знаем какой точно нам нужен сервер? может нам делать не очень точный тест? может сразу покупать "помощнее" без теста?
вы говорите
т.е. вы предлагаете спустить 10% на то чтобы сказать НЕ точно как нужен сервер?!
серьезно?
да лучше за 500 руб. нашим автоматическим подбором воспользуйтесь , а на разницу купите себе новый автомобиль - бугага
Сервер, обычно, покупают лучше, чем надо
а хрен его знает насколько мощнее нужен сервер, но мощнее?
тогда возникают вопросы: зачем делать точный тест, если в итоге мы не знаем какой точно нам нужен сервер? может нам делать не очень точный тест? может сразу покупать "помощнее" без теста?
вы говорите
И если система не будет работать с заявленной производительностью, то они ее просто не купят, потратив 10% бюджета внедрения на оценку.
т.е. вы предлагаете спустить 10% на то чтобы сказать НЕ точно как нужен сервер?!
серьезно?
Да, и как с этим помогут бороться Ваши продукты?
да лучше за 500 руб. нашим автоматическим подбором воспользуйтесь , а на разницу купите себе новый автомобиль - бугага
Наблюдаю похожую описанной в задаче с производительностью картину если пытаюсь утром обратиться к базе логов. Пытаясь первый раз за долгий промежуток времени узнать количество записей, улетаю минуты на 2. Второе и последующие чтения отрабатывают за 400 мс. В регистре около 6 млн записей. Количество меняется каждую секунду. Компьютер не особо мощный, СУБД MSSQL. Думаю вопрос в "прогреве" кэша.
Средствами разработчика решается изобретением параллельно регистра накопления и считывание итогов, но поскольку экзамен на эксперта технологиям, может просто держать кэш всегда "горячим" ?
Средствами разработчика решается изобретением параллельно регистра накопления и считывание итогов, но поскольку экзамен на эксперта технологиям, может просто держать кэш всегда "горячим" ?
К слову, насчет 1С на java переписать. Уже есть такая фигня, не помню как называется, но концепция очень интересная.
В том смысле, что в качестве внутреннего языка используется java-script Rhino от Mozilla, который за счет того, что сам реализован на java - имеет c java полностью прозрачную интеграцию. Т.е. разработчику доступна вся мощь java-script при разработке и можно из коробки юзать любые java-библиотеки.
ЗЫ. Понятно, что там тоже не сахар. В том смысле, что только толстый клиент и про штуки типа СКД остается только мечтать.
В том смысле, что в качестве внутреннего языка используется java-script Rhino от Mozilla, который за счет того, что сам реализован на java - имеет c java полностью прозрачную интеграцию. Т.е. разработчику доступна вся мощь java-script при разработке и можно из коробки юзать любые java-библиотеки.
ЗЫ. Понятно, что там тоже не сахар. В том смысле, что только толстый клиент и про штуки типа СКД остается только мечтать.
Очень странное обсуждение. Я правда не знаю 12 способов решения данной задачи. Но я знаю самый главный способ - обновить статистику таблицы регистра сведений. И всё - это вполне должно быть достаточно. В задаче не указано, что статистка актуальная или вообще хоть когда-то обновляется. Для подобных проблем оптимизации - это самое первое, что должно быть проверено и выполнено. Количество записей в таблице - хранится в статистике. И долгое выполнение выбрать Количество(*) из РегистрСведений.какойтотам лишь говорит о том, что статистика не актуальна и не используется.
Позвольте высказать своё дилетантское мнение. Может быть все ответы которые давались здесь правильные, но преподаватель видит в них один существенный минус - это тыканье пальцем в небо? Есть замечательная блок схема расследования проблем производительности в книжке по подготовке к эксперту. Может быть имеет смысл на этот вопрос не отвечать, а задавать вопросы?
А настроена ли для базы регламентное обслуживание и как давно оно выполнялось.
А есть ли проблемы загрузки оборудования
А повторяется ли данная проблема при работе одного пользователя ... и так далее пока мы не выйдем на то место где у нас будет затык? По крайней мере такой подход мне кажется более системный и показывает что вы знаете не заученные ответы а именно сам метод диагностирования проблемы?
А настроена ли для базы регламентное обслуживание и как давно оно выполнялось.
А есть ли проблемы загрузки оборудования
А повторяется ли данная проблема при работе одного пользователя ... и так далее пока мы не выйдем на то место где у нас будет затык? По крайней мере такой подход мне кажется более системный и показывает что вы знаете не заученные ответы а именно сам метод диагностирования проблемы?
(231)Да, эта книга.На первых страницах есть алгоритм поиска узкого места. Если выполнять "решенияе" задачи по нему то таки может и набереться все 12 вариантов решения проблемы начиная от замены оборудования(база работает на селероне 200-х годов) и до перестроения бизнес логики системы.
То что Морозов задавал такой вопрос совсем не значит, что на него существует односложный ответ или ответ вообще существует. Александр не преподаватель, а практик. И свои интересные мысли выплескивает на участников экзамена и смотрит "куда они плывут"
Вижу решение проблемы в установке счётчика строк в виде приёмника, который будет хранится в ИБ (например, константы или др.). Значение счётчика менять при операциях с данными целевого объекта ИБ, в описанной ситуации при операциях с данными регистра сведений (например, при проведении или отмене проведения документа). В результате считывание счётчика будет происходить моментально.
P.S. В развитие темы для автоматизации подобного рода задач можно создать план видов характеристик (ПВХ) с типами значений, для которых мы хотим моментально получать информацию, подобную количеству строк. Затем в список ПВХ добавить нужные типы значений с настройками, по которым мы будем собирать нужные сведения. Первоначальные значения сведений заполнять программно при записи нового элемента ПВХ, а потом менять эти значения при изменении данных типа объекта из списка ПВХ. Для этого можно написать глобальный модуль и прописать его вызов программно в модуле объекта ИБ. Или, например для группы документов, создать обработчики событий, подключить необходимые события и указать модуль, который будет обрабатывать изменение данных.
P.S. В развитие темы для автоматизации подобного рода задач можно создать план видов характеристик (ПВХ) с типами значений, для которых мы хотим моментально получать информацию, подобную количеству строк. Затем в список ПВХ добавить нужные типы значений с настройками, по которым мы будем собирать нужные сведения. Первоначальные значения сведений заполнять программно при записи нового элемента ПВХ, а потом менять эти значения при изменении данных типа объекта из списка ПВХ. Для этого можно написать глобальный модуль и прописать его вызов программно в модуле объекта ИБ. Или, например для группы документов, создать обработчики событий, подключить необходимые события и указать модуль, который будет обрабатывать изменение данных.
Возможно, что решение задачи в области использование СУБД опции "parametr sniffing". При первом выполнении запроса, с неким параметром, СУБД запоминает план запроса и просто подставляет в него другие параметры. Что может быть не оптимально если первое выполнение было по низкоселективным параметрам.
Соответственно решение - в коде 1с указывать параметры в тексте запроса через конкатенацию, или добавлять любой другой символ в запрос, что бы для него в СУБД строился свой план.
Соответственно решение - в коде 1с указывать параметры в тексте запроса через конкатенацию, или добавлять любой другой символ в запрос, что бы для него в СУБД строился свой план.
Можно предложить вынести запрос в серверный модуль с повторным использованием возвращаемых значений.
При таком подходе APDEX операции с целевым временем t=1 будет 0.999 (при условии, что 1000 обозначенных в задаче пользователей обращается к данному модулю в интервале актуальности возвращаемых значений).
При таком подходе APDEX операции с целевым временем t=1 будет 0.999 (при условии, что 1000 обозначенных в задаче пользователей обращается к данному модулю в интервале актуальности возвращаемых значений).
Еле дочитал... реально тема превратилась в помойку
У меня похожая ситуёвина.
ДО КОРП. 25 Гб.
Запрос на количество версий объектов выполняется 2-2.5 секунды. Очень похоже на условие задачи из топика.
Всего 25кк записей. Но видимо около 70 активных пользователей часто делают записи в неё. Хотя, вру, фоновое задание какое-то ещё дублирует версии, но это уже другое. Но смысл такой, что таблица активно используется.
Так вот, железо хорошее (xeon gold 6244, 128Гб ОЗУ, SSD), а запрос 2+ секунды и всего 25кк записей.
У меня похожая ситуёвина.
ДО КОРП. 25 Гб.
Запрос на количество версий объектов выполняется 2-2.5 секунды. Очень похоже на условие задачи из топика.
ВЫБРАТЬ
Количество(*)
ИЗ
РегистрСведений.ВерсииОбъектов
Всего 25кк записей. Но видимо около 70 активных пользователей часто делают записи в неё. Хотя, вру, фоновое задание какое-то ещё дублирует версии, но это уже другое. Но смысл такой, что таблица активно используется.
Так вот, железо хорошее (xeon gold 6244, 128Гб ОЗУ, SSD), а запрос 2+ секунды и всего 25кк записей.
Осмелюсь предположить, что ключевой фразой в условии задачи является "В базе работают 1000 пользователей". И, если допустить, что с этим регистром идет интенсивная работа (модификация), то очевидно, что будем иметь определенные проблемы при подсчете кол-ва строк в таблице. Т.е., если исключить фактор модификации данных регистра в момент выполнения запроса, то все должно быть ощутимо быстрее (само собой статистика должна быть в акт. состоянии). Т.е., если перед выполнением установить упр. блокировку на весь регистр, то тем самым и будет исключен фактор модификации данных регистра в других транзакциях.
Вроде, такое решение будет работать:
Создать новый реквизит, проиндексировать его. Тип допустим будет числовой - 1 знак, чтобы меньше весил. Этот реквизит НИКОГДА не будет заполняться.
В запросе поиска количества строк просто указать отбор по этому реквизиту:
ВЫБРАТЬ
Количество(МойРегистр.ФиктивныйИндексированныйРеквизит) КАК КоличествоСтрок
ИЗ
РегистрСведений.МойРегистр
ГДЕ
МойРегистр.ФиктивныйИндексированныйРеквизит = 0
Создать новый реквизит, проиндексировать его. Тип допустим будет числовой - 1 знак, чтобы меньше весил. Этот реквизит НИКОГДА не будет заполняться.
В запросе поиска количества строк просто указать отбор по этому реквизиту:
ВЫБРАТЬ
Количество(МойРегистр.ФиктивныйИндексированныйРеквизит) КАК КоличествоСтрок
ИЗ
РегистрСведений.МойРегистр
ГДЕ
МойРегистр.ФиктивныйИндексированныйРеквизит = 0
(244) прошу прощения, немного ошибся в решении.
Ускорения это не придаст особо, так как все равно придется сканировать все страницы нового индекса, а вес строки индекса может быть большим, так как в новый индекс будут включаться еще и все измерения регистра. Хотя, если в ресурсах регистра и других его реквизитах содержатся тяжелые данные (а это может быть, судя по времени подсчета 100 млн строк за 60 сек), то ускорение будет, так как при сканировании строк нового индекса не будет требоваться читать тяжелые листовые страницы кластерного индекса, которые содержат в себе все данные (здесь только без * нужно выбирать естественно).
Основная идея в том, чтобы создать более легкий индекс, который бы сканировался быстро для подсчета количества строк. Поэтому как решение, можно создать вспомогательные непериодический регистр сведений с одним измерением с типом уникальный идентификатор и в это регистр писать столько строк, сколько добавляется в регистр (ну и обыграть все сценарии изменения строк для согласованости данных в регистрах). Записывать можно в режиме без замещения, что будет ускорять загрузку.
Кластерный индекс у него будет легкий и как раз можно будет за 1 сек просканировать 100 млн строк (замерял на своем компе). Единственное, что индекс по ГУИДу будет сильно фрагментирован, и чтобы он работал хорошо, требуется каждый день делать реорганизацию и периодически ребилд.
понятно, что в таком варианте мы будем проигрывать на операции записи. но именно скорость подсчета количества строк ускорим, что и требуется по задаче
Ускорения это не придаст особо, так как все равно придется сканировать все страницы нового индекса, а вес строки индекса может быть большим, так как в новый индекс будут включаться еще и все измерения регистра. Хотя, если в ресурсах регистра и других его реквизитах содержатся тяжелые данные (а это может быть, судя по времени подсчета 100 млн строк за 60 сек), то ускорение будет, так как при сканировании строк нового индекса не будет требоваться читать тяжелые листовые страницы кластерного индекса, которые содержат в себе все данные (здесь только без * нужно выбирать естественно).
Основная идея в том, чтобы создать более легкий индекс, который бы сканировался быстро для подсчета количества строк. Поэтому как решение, можно создать вспомогательные непериодический регистр сведений с одним измерением с типом уникальный идентификатор и в это регистр писать столько строк, сколько добавляется в регистр (ну и обыграть все сценарии изменения строк для согласованости данных в регистрах). Записывать можно в режиме без замещения, что будет ускорять загрузку.
Кластерный индекс у него будет легкий и как раз можно будет за 1 сек просканировать 100 млн строк (замерял на своем компе). Единственное, что индекс по ГУИДу будет сильно фрагментирован, и чтобы он работал хорошо, требуется каждый день делать реорганизацию и периодически ребилд.
понятно, что в таком варианте мы будем проигрывать на операции записи. но именно скорость подсчета количества строк ускорим, что и требуется по задаче
ChatGPT предлагает просто делать sel ect count по индексу. Т.е. следуя этой логике верный ответ
Я:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос sel ect count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c"
ChatGPT:
Для того, чтобы ускорить выполнение запроса SEL ECT COUNT, можно использовать индекс.
Добавьте индекс на столбец, который вы используете в запросе SELECT COUNT. Например, если запрос выглядит так:
SELECT COUNT(*) FR OM table_name;
То необходимо добавить индекс на все столбцы таблицы:
CRE ATE INDEX idx_table_name ON table_name(*)
Если же запрос выглядит так:
SELECT COUNT(column_name) FR OM table_name;
То необходимо добавить индекс на столбец column_name:
CRE ATE INDEX idx_table_name_column_name ON table_name(column_name)
После создания индекса необходимо убедиться, что он используется при выполнении запроса. Для этого выполните запрос EXPLAIN для вашего запроса:
EXPLAIN SELECT COUNT(*) FR OM table_name;
В результате выполнения этого запроса вы должны увидеть, что ваш индекс используется.
Если после создания индекса вы все еще испытываете проблемы с производительностью, то можете рассмотреть возможность горизонтального разделения таблицы (sharding) или вертикального разделения таблицы (partitioning). При горизонтальном разделении таблицы данные разбиваются на несколько таблиц, что позволяет снизить нагрузку на каждую из них. При вертикальном разделении таблицы столбцы разбиваются на группы и размещаются в разных таблицах.
Также можно рассмотреть возможность оптимизации на уровне аппаратного обеспечения. Например, установить более производительные диски или использовать кэширование.
Применение этих методов должно помочь ускорить выполнение запроса SELECT COUNT и получить данные за 1 секунду.
ВЫБРАТЬ
КОЛИЧЕСТВО (*)
ИЗ
(ВЫБРАТЬ
Измерение1,
Измерение2,
....
ИзмерениеN
ИЗ
РегистрСведений.БольшойРегистр
) ПоказатьЯ:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос sel ect count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c"
ChatGPT:
Для того, чтобы ускорить выполнение запроса SEL ECT COUNT, можно использовать индекс.
Добавьте индекс на столбец, который вы используете в запросе SELECT COUNT. Например, если запрос выглядит так:
SELECT COUNT(*) FR OM table_name;
То необходимо добавить индекс на все столбцы таблицы:
CRE ATE INDEX idx_table_name ON table_name(*)
Если же запрос выглядит так:
SELECT COUNT(column_name) FR OM table_name;
То необходимо добавить индекс на столбец column_name:
CRE ATE INDEX idx_table_name_column_name ON table_name(column_name)
После создания индекса необходимо убедиться, что он используется при выполнении запроса. Для этого выполните запрос EXPLAIN для вашего запроса:
EXPLAIN SELECT COUNT(*) FR OM table_name;
В результате выполнения этого запроса вы должны увидеть, что ваш индекс используется.
Если после создания индекса вы все еще испытываете проблемы с производительностью, то можете рассмотреть возможность горизонтального разделения таблицы (sharding) или вертикального разделения таблицы (partitioning). При горизонтальном разделении таблицы данные разбиваются на несколько таблиц, что позволяет снизить нагрузку на каждую из них. При вертикальном разделении таблицы столбцы разбиваются на группы и размещаются в разных таблицах.
Также можно рассмотреть возможность оптимизации на уровне аппаратного обеспечения. Например, установить более производительные диски или использовать кэширование.
Применение этих методов должно помочь ускорить выполнение запроса SELECT COUNT и получить данные за 1 секунду.
(251)
Вычисление количества записей в запросах
#std787
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. При вычислении количества записей на языке запросов следует всегда использовать функцию КОЛИЧЕСТВО, а не СУММА. В противном случае, при количестве записей 10 млн. и более произойдет переполнение, что связано с разрядностью числа по умолчанию (7 разрядов), используемого в СУБД платформой 1С:Предприятие.
Правильно:
КОЛИЧЕСТВО(*)
КОЛИЧЕСТВО(<Поле>)
Неправильно:
СУММА(1)
ЕСТЬNULL(СУММА(1), 0)
Показать#std787
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. При вычислении количества записей на языке запросов следует всегда использовать функцию КОЛИЧЕСТВО, а не СУММА. В противном случае, при количестве записей 10 млн. и более произойдет переполнение, что связано с разрядностью числа по умолчанию (7 разрядов), используемого в СУБД платформой 1С:Предприятие.
Правильно:
КОЛИЧЕСТВО(*)
КОЛИЧЕСТВО(<Поле>)
Неправильно:
СУММА(1)
ЕСТЬNULL(СУММА(1), 0)
(258)Из темы:
Стандарт явно говорит, что на некоторых СУБД может быть ошибка при использовании Сумма для подсчета количества записей, если более 10млн записей в регистре.
Нет смысла в ускорении, если это в принципе не работоспособно.
Только для этого привел цитату.
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей.
Стандарт явно говорит, что на некоторых СУБД может быть ошибка при использовании Сумма для подсчета количества записей, если более 10млн записей в регистре.
Нет смысла в ускорении, если это в принципе не работоспособно.
Только для этого привел цитату.
Тема очень интересная.
Но думаю, что правильным решением будет, как уже кто-то писал, не придумать супер быстрое решение, а выяснить причины долгого выполнения запроса, задавая преподователю вопросы.
1. Начать с конфигурации оборудования:
- какие диски (может, вообще hdd);
- какая и сколько оперативная память;
- какие процессоры и какой частоты;
- какая архитектура клиент-серверного взаимодействия и какая пропускная способность сети;
- какая ОС на СУБД и СУБД;
- нет ли конкурентной борьбы за ресурсы сервера. Например, если используется несколько виртуалок на одном физическом сервере и ресурсов под виртуалки выдано больше, чем есть на физическом сервере. Или не крутиться ли с сервером СУБД еще какое-то ресурсоемкое приложение;
- есть ли антивирусы на сервере;
- план элетропитания серверов и т.д.
2. Если с железом все впорядке, то выяснить:
- не стоит ли автоматический режим работы у конфигурации;
- есть ли разница в скорости выполнения запроса в рабочее время и в техническо окно;
- есть ли разница в скорости выполнения у разных пользователей и т.д.
Т.е. объяснить преподователю как можно расследовать причины долгого выполнения запроса.
Если все-таки остановиться на "хитром" способе, то предложил бы:
1. Использовать дата акселератор 1С, т.е. по сути вынести данную таблицу в оперативную память, тогда время обращения к таблицы будет еще быстрее
2. Если мы говорим о высококонкурентной работе на сервере СУБД, то возможно использовать запрос не к основной базе, а к ее реплике на другом сервере, где ресурсы железа будут свободными
Но думаю, что правильным решением будет, как уже кто-то писал, не придумать супер быстрое решение, а выяснить причины долгого выполнения запроса, задавая преподователю вопросы.
1. Начать с конфигурации оборудования:
- какие диски (может, вообще hdd);
- какая и сколько оперативная память;
- какие процессоры и какой частоты;
- какая архитектура клиент-серверного взаимодействия и какая пропускная способность сети;
- какая ОС на СУБД и СУБД;
- нет ли конкурентной борьбы за ресурсы сервера. Например, если используется несколько виртуалок на одном физическом сервере и ресурсов под виртуалки выдано больше, чем есть на физическом сервере. Или не крутиться ли с сервером СУБД еще какое-то ресурсоемкое приложение;
- есть ли антивирусы на сервере;
- план элетропитания серверов и т.д.
2. Если с железом все впорядке, то выяснить:
- не стоит ли автоматический режим работы у конфигурации;
- есть ли разница в скорости выполнения запроса в рабочее время и в техническо окно;
- есть ли разница в скорости выполнения у разных пользователей и т.д.
Т.е. объяснить преподователю как можно расследовать причины долгого выполнения запроса.
Если все-таки остановиться на "хитром" способе, то предложил бы:
1. Использовать дата акселератор 1С, т.е. по сути вынести данную таблицу в оперативную память, тогда время обращения к таблицы будет еще быстрее
2. Если мы говорим о высококонкурентной работе на сервере СУБД, то возможно использовать запрос не к основной базе, а к ее реплике на другом сервере, где ресурсы железа будут свободными
(263)
Студент сельхоза выучил на экзамен только строение блохи. Тянет билет — там строение собаки. Он и начинает:
— Собака — животное на четырех лапах, покрыто шерстью. А в шерсти водятся блохи…И дальше про блох все что знает.
Преподаватель:
— Ладно, ладно. Расскажите нам о строении коровы.
— Ну, корова, это животное на четырех ногах, питается травой, покрыто шерстью. А вот в шерсти водятся блохи, ну и дальше по тексту.
— Ладно, хватит. Расскажите нам тогда про строение рыбы.
— Рыба живет в воде, шерсти у нее конечно нет, но вот если бы она у нее была, то в ней обязательно водились бы блохи…
Начать с конфигурации оборудования:
Студент сельхоза выучил на экзамен только строение блохи. Тянет билет — там строение собаки. Он и начинает:
— Собака — животное на четырех лапах, покрыто шерстью. А в шерсти водятся блохи…И дальше про блох все что знает.
Преподаватель:
— Ладно, ладно. Расскажите нам о строении коровы.
— Ну, корова, это животное на четырех ногах, питается травой, покрыто шерстью. А вот в шерсти водятся блохи, ну и дальше по тексту.
— Ладно, хватит. Расскажите нам тогда про строение рыбы.
— Рыба живет в воде, шерсти у нее конечно нет, но вот если бы она у нее была, то в ней обязательно водились бы блохи…
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот