Нетривиальные подходы в решении всем известных проблем: ускорение «больших» документов в 1С и ускорение поиска по подстроке. Как добиться эффекта в разы?

Публикация № 884649 30.08.18

Администрирование БД - HighLoad оптимизация

Часто у пользователей 1С поиск информации по большим спискам данных по подстроке занимает продолжительное время. Павел Баркетов рассматривает причины торможения запросов с поиском по подстроке и описывает возможности и подходы к их оптимизации и ускорению. Также в статье разобраны причины длительного проведения «больших» документов (более 10 000 строк) и даны рекомендации по ускорению этих операций.

Меня зовут Павел Баркетов, я работаю в компании «Софтпоинт». Мы уже более 10 лет занимаемся решением задач оптимизации производительности. И несмотря на большое количество решенных задач, их количество не уменьшается, а растет в геометрической прогрессии. Объемы данных увеличиваются, и задачи по оптимизации работы с этими данными усложняются. Этот процесс неизбежен.

Тема статьи – нетривиальные подходы к оптимизации. Будут рассмотрены два аспекта:

  • Первый – поиск по подстроке. Пользователи часто его используют, и многие, наверное, уже сталкивались со значительным ожиданием, поиск по подстроке выполняется недостаточно быстро.
  • Второй – проведение больших документов, таких, как закрытие месяца, расчет себестоимости. Наверняка многие сталкивались с тем, что бухгалтеры проводят эти документы по 5–9 часов, ночью и в нерабочее время. Самое интересное, что классические методы оптимизации здесь не всегда помогают. Если вы при проведении таких документов запустите в отладчике замер производительности, то увидите, что наибольшее количество времени тратится на запись во временные или реальные структуры – таблицы, регистры и т.д. И решить эту задачу классическими методами не получается.

 

Поиск по подстроке

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

 

Поиск по начальным символам

Начну с первого примера, когда поиск осуществляется по начальным символам. Это – частный случай поиска по подстроке, когда пользователь точно знает, что искомое значение начинается с определенных символов.

Поиск по начальным символам реализуется в 1С с помощью команды ПОДОБНО (или в английском варианте, LIKE) с указанием значения с «%» в конце («%» обозначает последовательность любых других символов). Например, мы ищем:

Наименование ПОДОБНО "ивано%"

Обратите внимание, что если у вас в системе существует индекс по этому полю, то в SQL-запросе для этого поиска будет использоваться Index Seek – это поиск по индексу.

Условие «ПОДОБНО поисковой строке» эквивалентно поиску в диапазоне значений. В частном случае, когда мы ищем «ивано%» – это эквивалентно поиску в диапазоне фамилий, которые начинаются на «ивано», и, заканчивая «иванп» (потому что символ «п» идет после символа «о»).

Современные оптимизаторы самостоятельно преобразуют запрос LIKE на запрос поиска по диапазону. Следовательно, если у вас в системе существует индекс по этому полю, вы при интерпретации запроса в термины SQL получите именно такой результат – оптимизатор представит запрос с LIKE в виде поиска по диапазону.

Таким образом, можно осуществлять классический быстрый поиск с использованием индекса (Index Seek). С этим проблем нет или решить их можно простым способом.

 

Поиск по вхождению

Теперь возьмем пример посложнее, когда неизвестно, в каком именно месте строки стоит наше искомое значение, и реализуется поиск по вхождению строки. В этом случае в запросе «ПОДОБНО» «%» стоит с двух сторон.

При преобразовании такого запроса в SQL мы видим, что изменяется только команда (в значении используется уже два «%»).

Рассмотрим подробнее план выполнения. Здесь мы видим тот же Index Seek, но в данном случае он не работает эффективно.

Дело в том, что индекс по наименованию справочника, который мы рассматриваем, состоит из нескольких полей.

  • Первое из них – это разделитель учета.
  • Дальше непосредственно идет поле поиска.

И поэтому, когда в плане выполнения отображается «Index Seek», это означает, что поиск делается по первому полю разделителя – на слайде выше можно увидеть, что поиск по нашему искомому значению Desc абсолютно не используется.

Что делать в этой ситуации? У меня на практике было очень часто, что пользователям запрещали использовать запросы на вхождение. И пользователи в ряде случае сами не использовали этот функционал, потому что время выполнения очень значительное, а надо продолжать работать. Поэтому им приходилось выкручиваться другими способами – выбирали в списках, пытались найти по первым символам и так далее.

Но это приводит к недовольству функционалом и неправильному восприятию системы. Пользователь понимает, что система с чем-то не может справиться и не работает как положено. Это неправильно.

 

Нетривиальный подход к решению задачи поиска по подстроке

Давайте теперь рассмотрим нетривиальный подход к решению этой задачи.

Обозначим ряд допусков:

  • Первое – поскольку современные диски имеют неограниченный размер, допустим, что пространство на диске, которое вы можете использовать, у вас есть достаточно большое.
  • Второе – пользователь ищет не по одному-двум символам, а по какому-то фрагменту. Например, никто из нас не ищет по «ал» – это слишком маленькая селективность. Ищут какую-то значимую последовательность символов. Здесь мы для примера выбрали поиск по шести символам.

Пример искомой строки «алексе» записали в форму и будем с ее помощью тестировать.

Дальше пойдет подробное описание, как это можно сделать:

  • Предположим, у нас есть поле с фамилией, именем и отчеством клиента. Первым шагом мы автоматически раскладываем это значение на фрагменты из шести символов со сдвигом «1» и получаем массив фрагментов (см. выше), которые одновременно всегда принадлежат искомому значению. Мы получили фрагменты, которые теоретически может вводить пользователь. А именно, на прошлом слайде определили, что мы ищем шесть символов. Их может быть и пять, и четыре, просто размер структуры будет больше.

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

  • И на третьем шаге, мы при поиске по подстроке к конструкции запроса 1С «ПОДОБНО» добавляем дополнительное условие «И», которое фильтрует количество возможных комбинаций, и вытаскиваем из этой дополнительной структуры (это может быть регистр сведений) все элементы, которым принадлежат нужные фрагменты строк.

Например, пользователь ищет клиента с фамилией «Солдатов». Это – восемь символов, значит, будет три фрагмента длиной в шесть символов, которые мы ищем в служебной структуре. Далее объединяем это все в запросе. Таким образом, получается дополнительная фильтрация.

В результате мы избавляемся от знака «%» (т.е. впереди этих фрагментов всегда будет нужный нам символ), и при выполнении внутреннего запроса будет идти Index Seek, за который мы и боролись.

На практике получается очень интересная история – ускорение в десятки, в сотни раз. Причем, все это можно сделать средствами 1С, что очень приятно. Переписывать логику не потребуется, пользователь порадуется, что у него ускорился запрос поиска. В примере ускорение с 4 секунд до 0,05 секунды, а если бы у нас изначально запрос выполнялся две минуты, он стал бы исполняться менее секунды.

Механизм, что я вам показал, не является каким-то экспериментальным примером, это уже работает у реальных клиентов.

 

Подготовительные мероприятия для внедрения

Теперь я расскажу кратко о подготовительных мероприятиях.

  • Сначала необходимо заполнить регистр начальными значениями. Для этого мы должны запланировать регламентное окно.
  • Далее мы должны соблюсти консистентность данных – это значит, должна быть подписка на изменение значения, чтобы эта Фрагменты автоматически перестраивались.
  • И последнее – дописать стандартную форму поиска.

Заполнение регистра можно делать как средствами 1С, так и с помощью SQL.

Могу сказать, что заполнение такой структуры для 17-ти миллионов значений занимает где-то 20-25 минут. Естественно, пользователи в этот момент не должны изменять значения справочника.

Далее можно добавить либо триггер, либо 1С подписки, которые позволяют синхронизировать фрагменты с реальным значением поля.

Можно и нужно рассчитать необходимое дисковое пространство. Здесь все зависит от того, сколько символов в наименовании, какую мы взяли длину фрагмента, и какой размер ссылки на искомый объект.

Если мы рассчитаем для одного миллиона значений где-то 100 символов по 6 во фрагменте, получится где-то 4,7 Гб. Нужно запланировать, чтобы это место у вас было. Если у вас в справочнике, например, 100 миллионов значений, то вы должны запланировать место, которое будет доступно на диске.

 

Необходимость учета статистики популярности фрагментов

Всегда ли этот метод будет работать быстро?

На это влияет статистика популярности фрагментов.

  • Например, у вас есть фрагмент «алексе», который может входить в имя Алексей, в отчество Алексеевич, в фамилию Алексеенко и т.д. Этот фрагмент может входить в 50-100 тысяч записей.
  • А есть редко используемые фрагменты.

Таким образом, появляется статистика популярности по фрагментам.

Обратите внимание, что если популярность фрагментов низкая (100 элементов), то мы получаем ускорение – 0,1 секунду.

Если подстрока достаточно популярная (50 тысяч элементов), то мы получаем деградацию, причем гораздо большую, чем если бы не было оптимизации.

Таким образом, необходимо сделать улучшенную схему выполнения запроса, в которой мы сначала бы получили значение популярности подзапроса. Это делается тремя-пятью строчками в 1С. При этом мы точно знаем, что если строка непопулярная, то идет по первой ветке, а если популярная, то по второй.

Как работает ускорение? Идет запрос поиска из формы, далее мы обращаемся к регистру сведений со статистикой, получаем элемент и дальше выбираем, что использовать – классический или ускоренный запрос.

А теперь давайте рассмотрим, как выполняется SQL-запрос на SQL-сервере.

На слайде представлена упрощенная схема:

  • идет запрос к оптимизатору;
  • мы смотрим статистику по полям, которые используются в запросе;
  • выбираем, какой план выполнения использовать, то есть выбираем стратегию выполнения запроса (например, вложенный цикл).

На что похожа реализованная нами схема?

  • Мы сделали свой индекс. Не стандартный индекс SQL, не индекс 1С, а свой индекс, который нужен для решения этой задачи;
  • Более того, столкнулись с тем, что нужна своя статистика;
  • И нужен собственный оптимизатор, который по этой статистике решает, какую ветку выбрать.

Исходя из этой логики, можно сказать, что этот процесс раскрывает смысл того, для чего нам индексы, статистика и оптимизатор.

Кто не знал, для чего нужно обслуживать статистику в SQL, загляните в эту логику, и вы поймете, что если она неправильная или неактуальная, то мы пойдем по неправильной ветке. Запрос будет тормозить. Понимаем, для чего качественно и правильно обслуживать статистику – это влияет на производительность, на индекс.

Если индекса нет – будем сканировать все значения.

Таким образом, мы создали хоть примитивный, но свой оптимизатор. Можно сказать, что прощупали «на пальцах» то, как это делает MS SQL и другие СУБД, причем создав свои структуры.

 

Ускорение «больших» документов

Перейду ко второй теме – ускорение больших документов.

Мы в производственных задачах часто сталкиваемся с какими-то регламентными процедурами, как: закрытие месяца, отчет агенту, расчет себестоимости. Эти тяжелые, массивные документы проводятся и заполняются значительное количество времени. А когда мы заглядываем в отладчик и делаем на этих операциях трассировку, то видим, что 1С построчно вставляет значения в какую-то таблицу и на это уходит основное время. И ничего с этим поделать нельзя. Единственная рекомендация, которую можно предложить – это ускорить диск (эффективность этого решения очень сомнительная и требует предварительного анализа).

Предлагаю вернуться в историю и рассмотреть, как это делалось в 1С, начиная с 8.0 до 8.3 – это делалось построчно. SQL-сервер каждый раз анализировал запрос, его обрабатывал, создавал план выполнения, добавлял, отправлял команду в сторону 1С об успешности и получал следующий запрос. И такими step by step шли запросы от 1С сервера приложения к MS SQL.

Понятно, что если у вас 40 записей в документе, то проблем возникнуть не должно. Если записей у вас становится 10 тысяч и более (бывают организации, где в регламентных документах миллион записей), то этот процесс занимает очень длительное время. Одна запись обрабатывается очень быстро, но в документе их слишком много. На что уходят накладные расходы? На сеть, на выполнение запроса, на обратный сигнал, на обработку этого сигнала в системе 1С – итого, сумма четырех этапов. Все этапы суммируются, умножаются на миллион строк, и получаются наши длительные ожидания. Понятно, что это не ужасно.

В 1С, начиная с 8.3, сделаны улучшения. Теперь запрос для вставки во временные таблицы и в регистры сведений подготавливается на SQL-сервере, и его дальнейшее выполнение происходит с помощью классических RPC-вызовов, где сам провайдер доступа 1С (Native или OLE DB) группирует записи и вставляет их по N строк (как правило 100 строк).

Таким образом, достигается ускорение от 30% до 300%. Но это все равно недостаточно, потому что сегодня у вас 10 тысяч строк, завтра 20 тысяч строк. Это не принципиальное решение проблемы, вы все равно с ней столкнетесь, но только через полгода/год.

Какая наиболее быстрая вставка в SQL-сервер, да и вообще в любую СУБД?

Это BULK INSERT. В 1С BULK INSERT используется, но для других задач. Работу с «большими» документами также хотелось бы ускорить путем укрупнения вставок INSERT и добавления записей единым массивом в базу данных SQL-сервера.

Посмотрим, какой достигается эффект. В рассматриваемом примере получено ускорение где-то в 5 раз, но можно ускориться и в 10 раз. Теоретически основная проблема для того, чтобы это ускорялось значительно сильнее – это скорость диска. Диск может является узким местом.

Также важно помнить про такой критерий, как индексы. Если бы мы вставляли BULK INSERT в таблицу без обновления индексов, то мы бы получили значительное ускорение (результат менее чем за секунду). Здесь мы получаем 69 секунд за счет того, что каждая вставка в таблицу требует REFRESH индекса.

В любом случае, этот способ позволяет достичь эффекта в 5-10 раз.

Плюс здесь не рассматриваются такие возможности, как партиционирование, секционирование. Можно было бы улучшить ситуацию, если бы мы знали, что BULK INSERT вставляется в актуальный период, а неактуальный мы вынесли бы в другую партицию. Это был бы еще больший эффект. Получается, что ускорение очень хорошее.

 

Возможности оптимизации безграничны

Таким образом, возможности оптимизации безграничны. Единственное – не увлекаться. До оптимизации всегда имеет смысл посчитать, будет ли предполагаемый эффект или нет. Также я бы советовал в каких-то ситуациях «подниматься» над проблемой, использовать не классические методы оптимизации запроса, а какие-то совсем иные, которые могут принести более значительный результат.

****************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2017 COMMUNITY. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Выбрать мероприятие.

Специальные предложения

Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. Сурикат 362 30.08.18 22:41 Сейчас в теме
А рассматривались такие решения как Сфинкс или ElasticSearch?
2. Sybr 239 31.08.18 09:27 Сейчас в теме
BULK INSERT предназначен для загрузки из данных из файла, как его использовать для записи движений при проведении документа? Так себе вариант на мой взгляд. Рабочее решение - это распараллелить запись, создавая несколько служебных документов регистраторов при проведении документа.
5. nicxxx 241 31.08.18 11:45 Сейчас в теме
(2) Присоединяюсь к вопросу. Сколько времени занимает подготовка файла данных?
24. gallam99 233 10.09.18 17:54 Сейчас в теме
(5)
Скорость подготовки данных (создается не файл, а поток данных) занимает очень незначительное время, так как формируется в оперативной памяти. Сложно сказать в абсолютных величинах, но десятки тысяч строк - несколько секунд.
28. nicxxx 241 11.09.18 10:05 Сейчас в теме
(24)два вопроса. Как называется поток данных в оригинале на английском языке? И как его прикрутить к платформе 1С не являясь разработчиком платформы?
29. gallam99 233 11.09.18 10:24 Сейчас в теме
(28)
Формат пакета можно посмотреть по ссылке: https://msdn.microsoft.com/en-us/library/dd340549.aspx
В таком формате MS SQL примет команду. Также полезно для решения задачи будет ссылка на спецификацию TDS: https://msdn.microsoft.com/en-us/library/dd304523.aspx
Теперь по внедрению к платформе 1С: в вашем вопросе скрыт ответ, платформой 1С занимаются разработчики платформы, поэтому там ничего нельзя "прикрутить". Следовательно необходимо внедрить решение за платформой 1С, мы это делаем между платформой и сервером БД. Создан прокси - сервер между ними, происходит анализ запросов SQL, в случае наших запросов на массовую вставку - они парсятся, формируется общий пакет по формату из первой ссылки и после общий пакет отправляется на MS SQL вместо большого количества маленьких. Таким образом главное обеспечить достаточное количество памяти для прокси-сервера и настроить высокоскоростную сеть для исключения замедления работы в целом. По нашим расчетам среднее время задержки запроса из-за прокси около 100мкс, таким образом задержка практически никак не влияет на скорость. Надеюсь стало понятнее.
30. nicxxx 241 11.09.18 19:39 Сейчас в теме
(29) да, так понятней. спасибо.
31. СергейК 51 14.09.18 23:01 Сейчас в теме
(29) Что-то это напоминает модификацию/оптимизацию запросов к SQL в 1С 7.7 через "хакерские" компоненты.
Развитие идет по спирали: энтузиасты оптимизируют платформу, пока вендор думает :-)
14. AlexFort1961 1 01.09.18 12:04 Сейчас в теме
(2) Вы предлагаете рабочее решение с распараллеливанием записи путем создания нескольких служебных документов. Можете поподробнее (схематично, конечно) описать этот путь? Предложенное в этой статье решение описано неконкретно, скорее концептуально.
gallam99; +1 Ответить
20. Sybr 239 03.09.18 11:43 Сейчас в теме
(14) При проведении создаем пул фоновых заданий, каждое из которых создает документ и записывает свою часть движений. Возможна эскалация блокировок, нужно обрабатывать этот момент. Подойдет для служебных документов, в которых все данные для движений уже рассчитаны и записаны в ТЧ.
21. AlexFort1961 1 03.09.18 13:48 Сейчас в теме
25. gallam99 233 10.09.18 17:58 Сейчас в теме
(14)
В публикации действительно описано концептуально. В реальности решение есть - оно представляет из себя аналог решения (Softpoint data cluster) - можно прочитать на сайте, трафик от сервера приложения проходит через него и анализируется. Когда встречаются построчные вставки в реальные и временные таблицы, то "на лету" формируется поток данных и вместо построчных операций вставки на сервер БД идет операция bulk insert.
3. Silenser 543 31.08.18 10:11 Сейчас в теме
Не пробовали использовать полнотекстовый поиск SQL? Он, насколько я помню, работает быстрее аналогичного в 1С, особенно при поиске нескольких слов. Для поиска одного фрагмента вполне подойдет и полнотекстовый поиск самой платформы и скорость будет вполне приличная, разве что результат разбирать дольше.
26. gallam99 233 10.09.18 18:00 Сейчас в теме
(3) Тут зависит от задачи и возможностей использования полнотекстового поиска в конкретной ситуации, для ускорения поиска по подстроке вполне интересное решение)
4. Mortum 31.08.18 11:11 Сейчас в теме
Написали про BULK INSERT, который нельзя использовать из 1с. В чём оптимизация?
Yashazz; Aser2000Aser; Irwin; CSiER; bulpi; syberman; +6 Ответить
6. Greeen84 68 31.08.18 11:50 Сейчас в теме
(4) +1, выглядит как
1)BULK INSERT
2)...
3)PROFIT в 10 раз! =)
EliasShy; Plotks2017; Aleskey_K; Irwin; cefew; bulpi; +6 Ответить
27. gallam99 233 10.09.18 18:02 Сейчас в теме
(6)
Цели демонстрации 2:
1. Есть решения конкретной ситуации (ускорение неускоряемого типовыми средствами) и раскрыт принцип в публикации и возможность реализации.
2. Может разработчики платформы 1С улучшат платформу)
7. nicxxx 241 31.08.18 12:04 Сейчас в теме
Если говорить про BULK-и, то есть в SQL Server запросы MERGE. Из моего опыта, копирование 7 000 000 строк между таблицами длится 60 секунд. Построчная вставка - гораздо дольше, измеряется часами. Но! Для запроса MERGE нужно как-то подготовить данные, ту же временную таблицу, и эта подготовка съедает большую часть оптимизированного времени.
8. bulpi 201 31.08.18 12:43 Сейчас в теме
1)По ускорению поиска по подстроке - очевидное решение выдается за новаторское.
2)По ускорение документов - вообще толком ничего не написано.
9. KAV2 135 31.08.18 13:39 Сейчас в теме
(8) а мне понравилось про поиск, очень доступно написано. Найти доступное описание того как можно индексировать полнотекстовый поиск не так то просто. Но понятно что это не автором статьи придумано, поэтому хотелось бы ссылки на литературу.
12. kalyaka 803 31.08.18 16:33 Сейчас в теме
(8) вот же в чем парадокс - на поиск простого очевидного решения может уйти много времени, а когда решение найдено - кажется ничего в нем и нет такого. Ну это ж очевидно :)
10. YPermitin 12200 31.08.18 15:27 Сейчас в теме
Темы до конца не раскрыты, но написано в любом случае доступно.
Некоторые задумки их этого использую на продакшене.

За публикацию + несомненно.
11. kalyaka 803 31.08.18 16:22 Сейчас в теме
Понравилась идея с полнотекстовым поиском. Действительно очень простое эффективное решение.

В свое время у нас ребята решали задачу поиска договора по номеру из назначения платежа при загрузке из банка с использованием оператора LIKE %Номер% и это было очень не быстро + напрягало сервер - в результате отказались от такого "сервиса" и перешли на поиск по началу.

Использование же полнотекстового поиска тоже чревато затратами на обслуживание + при обновлении падает производительность сервера приложений.
13. KAV2 135 01.09.18 05:50 Сейчас в теме
(11) Полнотекстовый поиск встроенный в платформу еще нельзя программно вызвать, а в некоторых случаях обработку ввода по строке необходимо кастомизировать.
15. TMV 14 03.09.18 05:28 Сейчас в теме
(13)
Полнотекстовый поиск встроенный в платформу еще нельзя программно вызвать
Разве нельзя, А это что?
16. KAV2 135 03.09.18 07:34 Сейчас в теме
(15) Я имел в виду полнотекстовый поиск по определенным таблицам, а не по всей базе. Сама платформа позволяет включить полнотекстовый поиск для ввода по строке, там используется полнотекстовый поиск по определенной таблице, но как это сделать программно?
17. Silenser 543 03.09.18 09:28 Сейчас в теме
(16)Так вы можете программно вызвать полнотекстовый поиск и задать его область. Попробуйте, сравните результат с вашим вариантом, он будет, скорее всего сопоставим, если ищете по одному слову. Разве что свободное место на диске сервера приложений нужно будет контролировать, чтобы полнотекстовый индекс его не съел.
18. TMV 14 03.09.18 11:06 Сейчас в теме
(16)
Я имел в виду полнотекстовый поиск по определенным таблицам, а не по всей базе

Можно же задать по каким объектам метаданных искать:

СписокПолнотекстовогоПоиска (FullTextSearchList)
ОбластьПоиска (SearchArea)
Использование:

Чтение и запись.
Описание:

Тип: Массив.
Содержит массив метаданных, описывающий, в каких данных нужно осуществлять поиск.
Например:
МассивОтбор = Новый Массив();
МассивОтбор.Добавить(Метаданные.Справочники.Товары);
МассивОтбор.Добавить(Метаданные.Документы.КассовыйЧек);
СписокПоиска.ОбластьПоиска = МассивОтбор;


Область поиска может содержать только основные объекты конфигурации. Подчиненные объекты (например, табличные части, реквизиты) не могут входить в область поиска.
LordKim; KAV2; +2 Ответить
19. KAV2 135 03.09.18 11:35 Сейчас в теме
(18) спасибо, не по глазам была эта возможность
22. Rustig 1466 04.09.18 11:00 Сейчас в теме
(0) интересные исследования. поиск по подстроке - это ведь перебор всех вариантов. я не понял сути задачи - зачем среди миллионных фамилий искать совпадение подстроки? однофамильцев будет тысяча - и результат поиска будет предсказуем - тысяча одинаковых фамилий. я рекомендую решать задачи поиска исходя из контекста - найти человека по инн, по таб. номеру, по телефону, по снилсу, по адресу регистрации - по району, по городу; по дате рождения. возможно поле поиска трансформируется в отдельное окно с несколькими полями для фильтрации и ограничения списка вариантов.... поиск по подстроке для большинства организаций работает достаточно быстро,а для организаций, у которых миллионные справочники,- подход должен быть Иным.
по поводу документов - надо делать декомпозицию длительных операций. Про регламентные документы с записями в 10 тыс. строк - не ясно, что за пример такой? из жизни? может такая реализация - это ошибка разработчика?
23. ufedor 56 05.09.18 09:23 Сейчас в теме
Собственный индекс - огонь.
Только 1с уже умеет использовать полнотекстовый индекс (свой конечно), если эта функциональность включена. При установке ограничения по области работает весьма неплохо. Посмотрите в типовых поиск номенклатуры.
А там уже можете решить, что использовать для поиска (реквизиты, тч, доп.сведения, связанные справочники)
Оставьте свое сообщение

См. также

Долго открывается конфигуратор Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    45282    Gilev.Vyacheslav    1    

Оптимизация высоконагруженных конфигураций: история маленькой победы, или советы тем, кто столкнулся с проблемой впервые и не знает, что делать

HighLoad оптимизация Администрирование СУБД v8 8.3.14 ERP2 Россия Бесплатно (free)

Пост будет больше интересен руководителям отделов ИТ сопровождения или проектным менеджерам, перед которыми будет стоять задача решения проблемы деградации производительности баз данных 1С. Пост для тех, кому эта тема нова, нет особого опыта, и с ходу непонятно, с чего начать.

вчера в 09:30    1115    avolsed    12    

Исправляем проблемы производительности в конфигурации ERP - 7 примеров

HighLoad оптимизация v8 ERP2 УТ11 КА2 Бесплатно (free)

Злободневные примеры поиска и исправления проблемных мест в конфигурациях ERP/УТ/КА на СУБД Postgres.

23.05.2022    1266    ivanov660    20    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация v8 ERP2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1075    it-expertise    19    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. В видео показан пример с внедрением конфигурации Тест-центра в произвольную информационную базу и создание простого сценария нагрузочного теста.

16.09.2012    36815    Aleksey.Bochkov    29    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA v8 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    714    ivanov660    0    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация v8 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    2549    ivanov660    21    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация v8 v8::БУ БП3.0 БУ Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    3030    DBOdin_Lab    25    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    70113    yuraos    112    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы v8 ERP2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    3175    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация v8 ERP2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    2805    it-expertise    47    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

HighLoad оптимизация Технологический журнал v8 Бесплатно (free)

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    7276    ivanov660    18    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    59905    Антон Ширяев    117    

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация v8 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    5494    stg2005    105    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация v8 ERP2 Россия Бесплатно (free)

Хочется поделиться одним подводным камнем, с которым могут встретиться другие пользователи ERP. Искал решение в интернете, но ничего похожего не нашел. Поэтому решил создать эту тему.

06.12.2021    1046    Rokky78    6    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB HighLoad оптимизация v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    2769    sorter1    2    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    62096    Gilev.Vyacheslav    46    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    920    info1i    5    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода Технологический журнал v8 Бесплатно (free)

Расскажем про инструменты, рассмотрим планы запросов, увидим, как отслеживать и бороться с проблемами производительности на боевой базе.

07.09.2021    6831    ivanov660    26    

Адекватный параллелизм в 1С

HighLoad оптимизация v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    6638    Shmell    7    

Параллельные вычисления в 1С 8 Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38564    gallam99    19    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    11758    ivanov660    77    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация v8 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    11312    vasilev2015    17    

Поиск причин блокировок СУБД

HighLoad оптимизация v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    6657    vasilev2015    13    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных HighLoad оптимизация v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45706    madmpro    32    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    4280    a.doroshkevich    5    

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    6074    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    4047    vasilev2015    22    

Долгое воспроизведение звука по RDP с удаленной машины

HighLoad оптимизация v8 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    1177    pashamak    2    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    4272    zhichkin    7    

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

07.10.2020    5871    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    6005    Iaskeliainen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

С помощью этого приложения вы можете измерить производительность своего устройства, используя для этого мобильную платформу 1С:Предприятие. Набор действий теста полностью повторяет аналогичный тест для стационарных ПК, поэтому результаты сравнимы.

14.09.2020    2132    capitan    25    

Нестандартные блокировки при работе с OLAP-нагрузкой

HighLoad оптимизация v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    3003    Филин    7    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

HighLoad оптимизация v8 Бесплатно (free)

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

18.05.2020    2863    Aleksey.Bochkov    4    

Эти занимательные временные таблицы

HighLoad оптимизация Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    19448    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

HighLoad оптимизация v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    10606    feva    15    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

HighLoad оптимизация WEB Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    17039    informa1555    35    

Многострочный контекст событий

HighLoad оптимизация Технологический журнал v8 Бесплатно (free)

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    4174    vasilev2015    11    

Анализ взаимоблокировок

HighLoad оптимизация Технологический журнал v8 v8::blocking Бесплатно (free)

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

20.03.2020    7898    vasilev2015    34    

Многопоточность

HighLoad оптимизация v8 Бесплатно (free)

Увеличиваем скорость загрузки данных в 20 раз. Как следует использовать многопоточность и готовый модуль для внедрения.

18.03.2020    9624    kaliuzhnyi    45    

Планы запросов - это просто! Разбор оптимизаций запросов PostgreSQL на живых примерах

HighLoad оптимизация v8::Запросы Бесплатно (free)

Проблема быстродействия 1С напрямую зависит от производительности запросов. Но как понять механику работы СУБД с помощью плана запроса? Андрей Овсянкин и Никита Грызлов на конференции Infostart Event 2019 Inception подробно рассмотрели алгоритм работы с планом запроса СУБД PostgreSQL, полученным из технологического журнала, и рассказали, на что обратить внимание, чтобы оптимизировать работу системы.

17.02.2020    17436    Evil Beaver    13    

Оптимизатор запросов. Вторая часть

HighLoad оптимизация v8 Бесплатно (free)

Продолжение статьи об оптимизаторе запросов. Во второй части мы попробуем создать свой оптимизатор и попутно разберемся с такими вопросами, как: хранение файлов; индексы; статистика.

23.01.2020    7906    darkdan77    59    

Улучшаем производительность 1С. Рекомендации

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

Каждый уважаемый разработчик 1С сталкивался или столкнется с вопросом производительности высоконагруженных систем. В статье агрегирован основной набор рекомендаций, который позволит повысить производительность системы. Эти рекомендации должны быть просто must have по определению.

23.01.2020    14637    Kaval88    26    

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С

HighLoad оптимизация v8 Бесплатно (free)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    9275    EugeneSemyonov    11    

Обслуживание баз данных. Не так просто, как кажется

HighLoad оптимизация Администрирование СУБД v8 1cv8.cf Бесплатно (free)

Считаете, что обслуживание индексов и статистик дело простое? Что ж, это не всегда так.

14.10.2019    23987    YPermitin    32