Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]

1. headMade 144 01.06.17 13:35 Сейчас в теме
Задача с экзамена 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) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".


Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)

Спасибо!!!
METAL; user660224_laa; +2 Ответить
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
205. Gilev.Vyacheslav 1915 29.06.17 17:57 Сейчас в теме
(204)
И если система не будет работать с заявленной производительностью, то они ее просто не купят, потратив 10% бюджета внедрения на оценку.
а эта система после внедрения модифицироваться не будет?
206. starik-2005 3051 29.06.17 18:00 Сейчас в теме
(205)
а эта система после внедрения модифицироваться не будет?
Будет. И это уже стоимость владения, куда риски тоже зашиваются. Но план развития системы обычно не оценивает архитектурные решения, которые существенно влияют на производительность, предполагая, что архитекторы вменяемые, а сценарное тестирование уже написано и позволит на тестовой среде воспроизвести новый функционал и определить уровень влияния на тот же APDEX.

Слава, Вы какие-то глупые вопросы задаете. С какой, интересно, целью?
208. Gilev.Vyacheslav 1915 29.06.17 18:02 Сейчас в теме
(206) а как вы будете тестировать функционал не существующий на момент до внедрения, тот функционал, который будет написан только спустя три месяца после внедрения? или каждый раз будете покупать заново железо и другие работы по перевнедрению?
209. starik-2005 3051 29.06.17 18:04 Сейчас в теме
(208)
или каждый раз будете покупать заново железо и другие работы по перевнедрению?
Так в крупных конторах есть и среда разработки, и тестовая среда, и продуктив. Пример приведите конкретный. Вот что такого надо сделать, чтобы при внедрении нового функционала, оттестированного на сценарии в тестовой среде, внезапно завалить продуктовый сервер, который, обычно, несколько мощнее?

Да, и как с этим помогут бороться Ваши продукты?
210. Gilev.Vyacheslav 1915 29.06.17 18:10 Сейчас в теме
(209) еще раз

куда риски тоже зашиваются. Но план развития системы обычно не оценивает архитектурные решения, которые существенно влияют на производительность, предполагая, что архитекторы вменяемые,


вменяемые архитекторы, риски зашиваются, архитектурные решения - это так на курсе теперь что ли учат?

пока единственное что я услышал - вы предлагаете максимально точно сэмитировать нагрузку пользователей, которая должна быть сразу после внедрения

но делая конкретную фиксацию нагрузки вы тут же говорите что позднее после внедрения " позволит на тестовой среде воспроизвести новый функционал и определить уровень влияния " - но сервер то вы к этому моменту уже купите, ну получите вы новый характер нагрузки, с которым сервер больше не справляется, дальше что?
master555; Fox-trot; +2 Ответить
211. minimajack 80 29.06.17 19:10 Сейчас в теме
(210)
ну получите вы новый характер нагрузки, с которым сервер больше не справляется,

золотые слова кстати...
производительность никогда расти не будет(решения вцелом), а вот деградация - с радостью. Поэтому логично мониторить в рантайме.
И хоть и есть тестовые среды, покуда бизнес работает - будут вносится изменения, а значит и расти сложность готового решения.
Fox-trot; +1 Ответить
213. starik-2005 3051 29.06.17 20:21 Сейчас в теме
(211)
Поэтому логично мониторить в рантайме.
А кто говорит, что мониторить никто не будет? В любом случае есть APDEX, есть ТОП запросов, есть рабочая система. Деградация скорости возникает при увеличении числа записей в таблицах. SQL как раз и реализует замедление деградации. Если бы Вы с Славой владели математикой хоть чуть-чуть, то знали бы, что скорость поиска в таблице по индексу равна логарифму по основанию два из числа записей. А логарифм - функция медленно растущая, при том чем больше числа, тем медленнее растет логарифм. Есть тут умные, кто может производную от лог2(Х) привести? Из этой циферки видно, на сколько серьезно замедляется рост этой величины со временем. И если тестовые данные отработали на количестве равном миллиону, то для того, чтобы время поиска выросло в 2 раза, необходимо увеличить количество данных в миллион раз. А вот количество таблиц по всей видимости расти будет очень медленно, а соединения с ростом количества таблиц увеличиваться не будут. Знаете, как работает nested loops? Он берет данные одной таблицы и ищет их в другой. Если есть индекс, то в другой таблице он гарантированно найдет данные за лог2(кол-во записей второй таблицы). Таким образом, для дегрдации производительности этого запроса в двое при достаточном объеме ОЗУ, необходимо увеличить количество записей в тысячу примерно раз. А если индексов нет - извини, как говорится, но на то ты и архитектор, чтобы не писать запросы, которые не будут юзать индексы.

Короче, диалог с вами, господа, никуда не приводит, ибо Слава, как обычно, рекламирует свои продукты, а кто-то просто фанатеет. Учите математику - и будет вам счастье...
mickey.1cx; +1 Ответить
214. minimajack 80 29.06.17 21:57 Сейчас в теме
(213) Сергей, обратите внимание - к слову "деградация" я не добавлял слово "скорость"( и даже слово запрос ):
- бывают ситуации когда вчерашний бизнес вырастает в 2 раза и памяти на сервере тупо не остается;
- за один месяц кол-во баз может утроится, обрасти обменами;
- кто то "решит"(прикажет) хранить на сервере большое кол-во больших файлов( макетов по 150 мегабайт штука) и место на дисках на сервере быстро исчезнет;
- а еще "по приказу" сервер должен быть резиновым, держать копии всех баз в онлайне, для "тестовых" примеров так же хранить копии (ибо ишь чего - потеряются) - и вообще сервер - "не ломается и резерв не нужен" и покупку хрен обоснуешь.
216. starik-2005 3051 30.06.17 13:04 Сейчас в теме
(214) (215)
и покупку хрен обоснуешь.
Ну вот Слава предложил за 500 рублей сразу купить то, что нужно. Они там типа решают проблему вновь возникшей нагрузки в автоматическом режиме. Я так примерно представляю схему: у Вас нагрузка Х, платите 500 руб, вам автоматически подбирают самое дешевое барахло, которое Х тянет (ну а на что машину покупать, если все иначе). Дальше возрастает нагурзка. Снова платим 500 рублей и на вырученные от проданной машины деньги покупаем второй сервер для нагрузки Y. Я Славу, конечно, понимаю - "ничего личного, джаст бизнес".
220. Gilev.Vyacheslav 1915 04.07.17 10:46 Сейчас в теме
(216) можешь привести примеры когда мы кому то посоветовали купить "барахло"?
поливание грязью это тоже часть тренинга?
И про бизнес, если обучение таковым считать - http://www.gilev.ru/podbor/#l3 - мы обучаем людей подбирать оборудование, причем именно исходя из практики какие способы жизнеспособны, а какие "просто слив денег". Т.е. мы даем различные возможности - не хочешь задумываться, есть быстрый способ в автоматическом сервисе, хочешь вникать, приходи, научим.

(217) на некорректно поставленный вопрос сложно получить правильный ответ
из ниоткуда в никуда ничего не бывает
как уже была дана ссылка в исходном посте - разумные решения заключаются в том чтобы не сканировать постоянно таблицу в 100 миллионов строк,
варианты реализации тоже обсудили

разве что преподаватель знает готовый механизм платформы, который эту реализацию автоматизирует

у нас сервисах не совсем, но похожая задача есть "мы контролируем максимально приемлемый размер полтеррабайтной таблицы", чтобы сервер ее переваривал, и опрашиваем статистическое знание скулем размера таблицы, оно не точное, но для того чтобы нам принять решение о переносе в архив "лишних строк" устраивает
221. spe1c 5 04.07.17 11:17 Сейчас в теме
(220)Вячеслав, я три раза перечитывал обсуждения на форуме по ссылке в исходном посте. И я понимаю что лучше не сканировать. Но я приводил в этой ветке (89-90 посты) результаты замера на своей рабочей базе, со скриншотом, у меня в регистре сведений цен номенклатуры 50+ млн записей и читает начиная от 0,3 сек (хотя разброс большой). Это наводит меня на мысль, что действительно реально просчитать и на 100 млн записей за 1сек. и без добавления констант, реквизитов в регистре и прочего, а просто запросом 1С. (хотя возможно между 50 и 100 млн происходит качественный скачок сложности для сервера). Всё это далее наводит на мысль, что действительно есть что-то, что преподаватель знает, вот это и не дает покоя. Еще смущает в формулировке, что 1000 человек одновременно пытаются то ли прочитать, то ли просто работать с регистром и мне кажется, именно этот факт приводит к задержке до 60 сек и вообще оговорка про 1000 человек не случайна.
talych; METAL; +2 Ответить
227. Gilev.Vyacheslav 1915 04.07.17 22:24 Сейчас в теме
(221) задержка в 60 секунд не обязательно может быть следствием ожиданий на блокировках, еще есть вариант что железо не справляется с 1000 одновременных запросов и возникают ожидания на дисках, или процессоре или т.п. ,
и тогда речь оптимизации опроса количества строк может быть сведена к пуллированию, например только один фоновый сеанс имеет право спрашивать количество, а остальные потребители получают это число от фонового процесса
в реальной жизни также видел ожидания связанные с некорректной отработкой платформой изменившихся доступных ресурсов виртуалки, которая коллективно с другими виртуалками туда-сюда гонят "общие ядра, память и т.п.", но думаю на экзамене 1С:Эксперт такое не спрашивают

согласен с вами, что надо у преподавателя выяснить природу задержек
222. starik-2005 3051 04.07.17 15:26 Сейчас в теме
(220)
поливание грязью это тоже часть тренинга?
Я никого не поливаю, я просто задаюсь вопросом и фантазирую о том, как сервис может определить, с какой нагрузкой в будущем столкнется клиент. Ведь машину на что-то надо покупать, да? Ничего личного - просто попытка понять.
225. Fox-trot 158 04.07.17 16:16 Сейчас в теме
(222) не ради тебя а истины для. сходил на указанный сайт и ... ничегошеньки не нашел про "с какой нагрузкой в будущем столкнется клиент". нет там такого, это плод твоей фантазии, чтение межстрочное и тд. единственное косвенное упоминание это требование указать размер базы, но видима такова формула расчета. всяко лучше, чем запрашивать средний возраст младших аналитиков отдела бюджетирования :)
Gilev.Vyacheslav; KazanKokos; +2 Ответить
226. starik-2005 3051 04.07.17 16:38 Сейчас в теме
(225)
ничегошеньки не нашел про "с какой нагрузкой в будущем столкнется клиент"
Ну так я и говорю, что ничего такого нет. Есть только текущая нагрузка и какая-то предположительная оценка ее роста. Но вопрос был как раз о том, что делать с тем, что новые механизмы будут требовать большего от системы. Слава на это сказал, что у него есть супер-сервис, который за 500 рублей все сделает, на что я заметил, что вряд ли. И кто тут читает между строк?
223. herfis 505 04.07.17 15:40 Сейчас в теме
(220)
поливание грязью это тоже часть тренинга?

А, starik-2005 что, имеет какое-то отношение к этому тренингу?

(222)
Я никого не поливаю

Справедливости для, "попытка понять" выглядит очень некрасиво.
METAL; CSiER; KazanKokos; Gilev.Vyacheslav; Fox-trot; +5 Ответить
224. starik-2005 3051 04.07.17 15:57 Сейчас в теме
(223)
"попытка понять" выглядит очень некрасиво
Это без контекста. С контекстом все иначе, но для этого нужно прочитать не только мои и Славины комментарии. А по поводу "джаст бизнес", то только этой фразой я пока лишь могу объяснить происходящее.
212. starik-2005 3051 29.06.17 20:09 Сейчас в теме
(210)
но сервер то вы к этому моменту уже купите
Сервер, обычно, покупают лучше, чем надо, ибо экономия суммы, равной месячному окладу спеца, вообще погоды не делает.
215. Gilev.Vyacheslav 1915 30.06.17 06:18 Сейчас в теме
(212) т.е. мы вложили деньги в достаточно точно имитирующий нагрузку пользователей тест, оценили характеристики сервера под эту нагрузку, и после этого говорим
Сервер, обычно, покупают лучше, чем надо

а хрен его знает насколько мощнее нужен сервер, но мощнее?

тогда возникают вопросы: зачем делать точный тест, если в итоге мы не знаем какой точно нам нужен сервер? может нам делать не очень точный тест? может сразу покупать "помощнее" без теста?

вы говорите
И если система не будет работать с заявленной производительностью, то они ее просто не купят, потратив 10% бюджета внедрения на оценку.

т.е. вы предлагаете спустить 10% на то чтобы сказать НЕ точно как нужен сервер?!
серьезно?
Да, и как с этим помогут бороться Ваши продукты?

да лучше за 500 руб. нашим автоматическим подбором воспользуйтесь http://www.gilev.ru/podbor/ , а на разницу купите себе новый автомобиль - бугага
202. KazanKokos 11 29.06.17 17:52 Сейчас в теме
(199) А Вы ответ задачи знаете? :) или 12 ответов.
METAL; mamonth; talych; Gilev.Vyacheslav; +4 Ответить
203. Gilev.Vyacheslav 1915 29.06.17 17:53 Сейчас в теме
(202) прочтите ссылку у топикстартера пожалуйста в исходном сообщении
189. li5enok 26.06.17 19:26 Сейчас в теме
Наблюдаю похожую описанной в задаче с производительностью картину если пытаюсь утром обратиться к базе логов. Пытаясь первый раз за долгий промежуток времени узнать количество записей, улетаю минуты на 2. Второе и последующие чтения отрабатывают за 400 мс. В регистре около 6 млн записей. Количество меняется каждую секунду. Компьютер не особо мощный, СУБД MSSQL. Думаю вопрос в "прогреве" кэша.
Средствами разработчика решается изобретением параллельно регистра накопления и считывание итогов, но поскольку экзамен на эксперта технологиям, может просто держать кэш всегда "горячим" ?
корум; +1 Ответить
192. KazanKokos 11 27.06.17 09:37 Сейчас в теме
193. корум 288 27.06.17 10:00 Сейчас в теме
(192) просто держать кэш всегда "горячим".
207. herfis 505 29.06.17 18:01 Сейчас в теме
К слову, насчет 1С на java переписать. Уже есть такая фигня, не помню как называется, но концепция очень интересная.
В том смысле, что в качестве внутреннего языка используется java-script Rhino от Mozilla, который за счет того, что сам реализован на java - имеет c java полностью прозрачную интеграцию. Т.е. разработчику доступна вся мощь java-script при разработке и можно из коробки юзать любые java-библиотеки.
ЗЫ. Понятно, что там тоже не сахар. В том смысле, что только толстый клиент и про штуки типа СКД остается только мечтать.
217. spe1c 5 30.06.17 15:10 Сейчас в теме
Как жаль что тема превратилась в помойку. А так хотелось узнать ответ на поставленный автором вопрос.
Мах; Boulala; EVKash; talych; DarkUser; charushkin; akR00b; Сурикат; корум; KazanKokos; +10 Ответить
218. KazanKokos 11 30.06.17 15:16 Сейчас в теме
(217) у меня другой вопрос: ужель этот билет никто не сдал? хотя бы на троечку. ну там 1 способ нашел:)
219. spe1c 5 02.07.17 16:49 Сейчас в теме
(218)Когда-то просочится наверное информация.
229. Darklight 32 20.07.17 12:35 Сейчас в теме
Очень странное обсуждение. Я правда не знаю 12 способов решения данной задачи. Но я знаю самый главный способ - обновить статистику таблицы регистра сведений. И всё - это вполне должно быть достаточно. В задаче не указано, что статистка актуальная или вообще хоть когда-то обновляется. Для подобных проблем оптимизации - это самое первое, что должно быть проверено и выполнено. Количество записей в таблице - хранится в статистике. И долгое выполнение выбрать Количество(*) из РегистрСведений.какойтотам лишь говорит о том, что статистика не актуальна и не используется.
Fox-trot; +1 Ответить
230. AvalonE2008 100 10.08.17 19:27 Сейчас в теме
Позвольте высказать своё дилетантское мнение. Может быть все ответы которые давались здесь правильные, но преподаватель видит в них один существенный минус - это тыканье пальцем в небо? Есть замечательная блок схема расследования проблем производительности в книжке по подготовке к эксперту. Может быть имеет смысл на этот вопрос не отвечать, а задавать вопросы?
А настроена ли для базы регламентное обслуживание и как давно оно выполнялось.
А есть ли проблемы загрузки оборудования
А повторяется ли данная проблема при работе одного пользователя ... и так далее пока мы не выйдем на то место где у нас будет затык? По крайней мере такой подход мне кажется более системный и показывает что вы знаете не заученные ответы а именно сам метод диагностирования проблемы?
shlegel; xinex; +2 Ответить
231. spe1c 5 10.08.17 23:28 Сейчас в теме
(230)
Есть замечательная блок схема расследования проблем производительности в книжке по подготовке к эксперту.
Что за книга? Эта https://www.1c-interes.ru/catalog/all6964/20752408/ ?
232. AvalonE2008 100 11.08.17 09:47 Сейчас в теме
(231)Да, эта книга.На первых страницах есть алгоритм поиска узкого места. Если выполнять "решенияе" задачи по нему то таки может и набереться все 12 вариантов решения проблемы начиная от замены оборудования(база работает на селероне 200-х годов) и до перестроения бизнес логики системы.
233. nvv1970 16.12.17 17:49 Сейчас в теме
То что Морозов задавал такой вопрос совсем не значит, что на него существует односложный ответ или ответ вообще существует. Александр не преподаватель, а практик. И свои интересные мысли выплескивает на участников экзамена и смотрит "куда они плывут"
234. DenisCh 16.12.17 19:15 Сейчас в теме
Всю тему не читал.
На моё имхо, правильный ответ будет "да идите вы к такой-то матери с такими вопросами", если нельзя сделать предопределённые счётчики.
И ни один Гилёв с прочими икспердами меня не переубедит.
235. talych 17 10.06.18 22:46 Сейчас в теме
erlang, scala, linux..Вы точно 1Сники?! ))) Так где 12 способов? Эксперты?
236. user1105663 07.12.18 14:23 Сейчас в теме
Вижу решение проблемы в установке счётчика строк в виде приёмника, который будет хранится в ИБ (например, константы или др.). Значение счётчика менять при операциях с данными целевого объекта ИБ, в описанной ситуации при операциях с данными регистра сведений (например, при проведении или отмене проведения документа). В результате считывание счётчика будет происходить моментально.

P.S. В развитие темы для автоматизации подобного рода задач можно создать план видов характеристик (ПВХ) с типами значений, для которых мы хотим моментально получать информацию, подобную количеству строк. Затем в список ПВХ добавить нужные типы значений с настройками, по которым мы будем собирать нужные сведения. Первоначальные значения сведений заполнять программно при записи нового элемента ПВХ, а потом менять эти значения при изменении данных типа объекта из списка ПВХ. Для этого можно написать глобальный модуль и прописать его вызов программно в модуле объекта ИБ. Или, например для группы документов, создать обработчики событий, подключить необходимые события и указать модуль, который будет обрабатывать изменение данных.
237. DarkUser 07.12.18 16:08 Сейчас в теме
Возможно, что решение задачи в области использование СУБД опции "parametr sniffing". При первом выполнении запроса, с неким параметром, СУБД запоминает план запроса и просто подставляет в него другие параметры. Что может быть не оптимально если первое выполнение было по низкоселективным параметрам.
Соответственно решение - в коде 1с указывать параметры в тексте запроса через конкатенацию, или добавлять любой другой символ в запрос, что бы для него в СУБД строился свой план.
238. Blackspb 03.10.19 11:50 Сейчас в теме
Можно предложить вынести запрос в серверный модуль с повторным использованием возвращаемых значений.
При таком подходе APDEX операции с целевым временем t=1 будет 0.999 (при условии, что 1000 обозначенных в задаче пользователей обращается к данному модулю в интервале актуальности возвращаемых значений).
farukshin; +1 Ответить
239. user633166 12 16.02.20 20:01 Сейчас в теме
Данная тема перекликается с https://infostart.ru/public/1195044/?detail=Y&ID=1195044 но там всё-таки пятнично :) шуточно.
Спрошу здесь - не имеет ли смысл получить ответ на вопрос, разделив размер таблицы на размер записи? Может быть это ответ?
240. herfis 505 25.02.20 10:53 Сейчас в теме
(239) В каждой шутке есть доля правды. В статье по ссылке приводится пример получения количества строк таблицы из статистики сиквела (sys.dm_db_partition_stats)
241. triviumfan 94 02.04.21 18:00 Сейчас в теме
Еле дочитал... реально тема превратилась в помойку
У меня похожая ситуёвина.
ДО КОРП. 25 Гб.
Запрос на количество версий объектов выполняется 2-2.5 секунды. Очень похоже на условие задачи из топика.
ВЫБРАТЬ
	Количество(*)
ИЗ
	РегистрСведений.ВерсииОбъектов

Всего 25кк записей. Но видимо около 70 активных пользователей часто делают записи в неё. Хотя, вру, фоновое задание какое-то ещё дублирует версии, но это уже другое. Но смысл такой, что таблица активно используется.
Так вот, железо хорошее (xeon gold 6244, 128Гб ОЗУ, SSD), а запрос 2+ секунды и всего 25кк записей.
242. sh_oleg 21.08.21 13:47 Сейчас в теме
Осмелюсь предположить, что ключевой фразой в условии задачи является "В базе работают 1000 пользователей". И, если допустить, что с этим регистром идет интенсивная работа (модификация), то очевидно, что будем иметь определенные проблемы при подсчете кол-ва строк в таблице. Т.е., если исключить фактор модификации данных регистра в момент выполнения запроса, то все должно быть ощутимо быстрее (само собой статистика должна быть в акт. состоянии). Т.е., если перед выполнением установить упр. блокировку на весь регистр, то тем самым и будет исключен фактор модификации данных регистра в других транзакциях.
243. shanginre 19.08.22 11:07 Сейчас в теме
Вроде, такое решение будет работать:

Создать новый реквизит, проиндексировать его. Тип допустим будет числовой - 1 знак, чтобы меньше весил. Этот реквизит НИКОГДА не будет заполняться.

В запросе поиска количества строк просто указать отбор по этому реквизиту:

ВЫБРАТЬ
Количество(МойРегистр.ФиктивныйИндексированныйРеквизит) КАК КоличествоСтрок
ИЗ
РегистрСведений.МойРегистр
ГДЕ
МойРегистр.ФиктивныйИндексированныйРеквизит = 0
244. Sashares 35 19.08.22 11:26 Сейчас в теме
(243)Зачем его индексировать, если он никогда не будет заполняться? Зачем вообще накладывать условие, которое вернет все строки? То есть будет тоже самое, что без условия?
Fox-trot; +1 Ответить
246. shanginre 22.08.22 07:58 Сейчас в теме
245. shanginre 22.08.22 07:56 Сейчас в теме
(244) прошу прощения, немного ошибся в решении.

Ускорения это не придаст особо, так как все равно придется сканировать все страницы нового индекса, а вес строки индекса может быть большим, так как в новый индекс будут включаться еще и все измерения регистра. Хотя, если в ресурсах регистра и других его реквизитах содержатся тяжелые данные (а это может быть, судя по времени подсчета 100 млн строк за 60 сек), то ускорение будет, так как при сканировании строк нового индекса не будет требоваться читать тяжелые листовые страницы кластерного индекса, которые содержат в себе все данные (здесь только без * нужно выбирать естественно).

Основная идея в том, чтобы создать более легкий индекс, который бы сканировался быстро для подсчета количества строк. Поэтому как решение, можно создать вспомогательные непериодический регистр сведений с одним измерением с типом уникальный идентификатор и в это регистр писать столько строк, сколько добавляется в регистр (ну и обыграть все сценарии изменения строк для согласованости данных в регистрах). Записывать можно в режиме без замещения, что будет ускорять загрузку.

Кластерный индекс у него будет легкий и как раз можно будет за 1 сек просканировать 100 млн строк (замерял на своем компе). Единственное, что индекс по ГУИДу будет сильно фрагментирован, и чтобы он работал хорошо, требуется каждый день делать реорганизацию и периодически ребилд.

понятно, что в таком варианте мы будем проигрывать на операции записи. но именно скорость подсчета количества строк ускорим, что и требуется по задаче
247. gybson 22.08.22 09:32 Сейчас в теме
(245) А зачем уникальный идентификатор? Не проще писать просто 0?

И почему (*) ? Впишите сюда любое одно поле.
248. sh_oleg 24.03.23 19:04 Сейчас в теме
ChatGPT предлагает просто делать sel ect count по индексу. Т.е. следуя этой логике верный ответ
ВЫБРАТЬ
	КОЛИЧЕСТВО (*)
ИЗ

(ВЫБРАТЬ
	Измерение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 секунду.
METAL; starik-2005; +2 Ответить
249. akR00b 22 27.03.23 16:55 Сейчас в теме
250. starik-2005 3051 28.03.23 09:44 Сейчас в теме
260. METAL 297 23.01.24 16:31 Сейчас в теме
(250) Как минимум тем, что к моему удивлению (если ничего не пропустил в этом большом чате), ChatGPT первым предложил обратить внимание на загруженность оборудования

...а вообще, Александр Морозов любит каверзные вопросы :)
251. Indgo 410 28.03.23 10:32 Сейчас в теме
Я конечно не эксперт. Пишу так:
ВЫБРАТЬ
Сумма(1) КАК КоличествоСтрок
ИЗ
РегистрСведений.МойРегистр
252. Sashares 35 28.03.23 16:29 Сейчас в теме
(251)https://its.1c.ru/db/v8std#content:787:hdoc

Вычисление количества записей в запросах
#std787

Область применения: управляемое приложение, мобильное приложение, обычное приложение.

1. При вычислении количества записей на языке запросов следует всегда использовать функцию КОЛИЧЕСТВО, а не СУММА. В противном случае, при количестве записей 10 млн. и более произойдет переполнение, что связано с разрядностью числа по умолчанию (7 разрядов), используемого в СУБД платформой 1С:Предприятие.

Правильно:

КОЛИЧЕСТВО(*)
КОЛИЧЕСТВО(<Поле>)

Неправильно:

СУММА(1)
ЕСТЬNULL(СУММА(1), 0)
Показать
253. Indgo 410 28.03.23 17:04 Сейчас в теме
(252) Вы бы сначала потестили, потом писали ерунду
254. Sashares 35 28.03.23 17:19 Сейчас в теме
(253)Ссылка на стандарты ерунда? Ну ок))
255. Indgo 410 28.03.23 18:40 Сейчас в теме
(254)
Ссылка на стандарты ерунда? Ну ок))

Ну если статья ИТС - это есть стандарт для вас, то не значить - для всех.
256. Sashares 35 28.03.23 18:56 Сейчас в теме
(255)То есть даже ссылку открыть вы не осилили. Мда.
Вы слышали когда нибудь о Системе стандартов и методик разработки конфигураций?
258. Indgo 410 03.04.23 10:18 Сейчас в теме
(256)
То есть даже ссылку открыть вы не осилили. Мда.
Вы слышали когда нибудь о Системе стандартов и методик разработки конфигураций?

Причем тут стандарты. вопрос стоит о ускорении запроса, включая нестандартные подходы.
259. Sashares 35 03.04.23 10:26 Сейчас в теме
(258)Из темы:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей.

Стандарт явно говорит, что на некоторых СУБД может быть ошибка при использовании Сумма для подсчета количества записей, если более 10млн записей в регистре.
Нет смысла в ускорении, если это в принципе не работоспособно.
Только для этого привел цитату.
262. VmvLer 23.01.24 17:34 Сейчас в теме
(259) именно так: СУММА (1) - просто валит платформу с переполнением.
257. user1880116 28.03.23 19:29 Сейчас в теме
(253) Ты очередной из, который элегантно так забывает про существование файловых баз со своим движком. И тот факт, что лично тебе они не нужны, не делает их менее важными для фирмы 1С.
261. soft_wind 23.01.24 17:08 Сейчас в теме
еще вариант, скорость очень сильно зависит от "железа"
у нас Выбрать Количество() на регистре с 155 000 000 записями выполняется 20 сек
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот