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

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

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

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

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

✅ Копирование таблицы
Создаем массив, обходим таблицу значений, по некоторому положительному условию добавляем строки в наш массив и далее вызываем метод таблицы значений «Скопировать», куда передаем массив с нужными строками.

✅ Копирование строк
Создаем новую пустую таблицу значений с аналогичным составом колонок. Далее обходим исходную таблицу и по некоторому положительному условию добавляем строки в новую пустую таблицу методом.

✅ Предобработка и выгрузка с отбором
В исходную таблицу добавляем колонку «ОставлятьСтроку», с типом булево. Обходим таблицу значений, проверяем условие, и если строку нам нужно оставить, устанавливаем признак «Истина». Далее вызываем метод «Скопировать» у таблицы значений с отбором «ОставлятьСтроку» = Истина. Далее удаляем добавленную колонку.

✅ Выгрузка с отбором
Если в исходной таблице значений уже есть колонка, по которой однозначно можно сделать отбор, вызываем метод «Скопировать» у таблицы значений с этим отбором.

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

1️⃣ Выгрузка с отбором. Самый быстрый способ. Работает быстро, когда нужно удалить как малое количество строк, так и большое количество строк. К сожалению, не всегда получиться его применить.

2️⃣ Предобработка и выгрузка с отбором. Если нужно удалить большое количество строк, то этот способ на втором месте. А вот если нужно удалить малое количество строк, например <2%, то способ «Удаление строк по условию» будет немного быстрее, но разница менее 10% в выигрыше времени.

3️⃣Копирование таблицы. Этот способ немного уступает «Предобработка и выгрузка с отбором» по времени, но разница не более 10%.

4️⃣ Копирование строк. Этот способ на больших объемах немного уступает копированию таблицы.

5️⃣ Удаление строк по условию. Еще раз повторюсь, этот способ хорош, когда удаляемых строк мало, но если их много, то данный способ может отрабатывать даже дольше, чем удаление строк через запрос.

6️⃣ Удаление строк через запрос. Способ хорош, когда необходимо удалить строки с некоторым сложным условием, например, если в условии отбора участвуют данные из других таблиц и нужно выполнить соединение с этими таблицами. При этом самый медленный.

На моем оборудовании не получилось прогнать тест с количеством записей ~ 1.000.000 записей в таблице значений. Основным узким местом стал именно процессор, хотя изначально я предполагал, что это будет оперативная память. Один сеанс и один rphost, который загрузил бедное ядро на 💯%, при том что другие ядрышки простаивают...

Окончания теста с 1.000.000 записями я так и не дождался, ограничился результатами максимум на 100.000.

Также я провел замеры на 10.000 записей по использованию памяти (MemoryPeak) и процессорного времени (CpuTime), и получилось следующее:

👉🏻 Удаление строк по условию: кушает меньше всего памяти за серверный вызов, а также минимально использование процессорного времени, но разница со вторым местом в пределах 10%.

👉🏻 Удаление строк через запрос: кушает больше всех памяти, примерно в 2 раза по MemoryPeak. Процессор при этом как в других способах. Тут мы также нагружаем сервер СУБД своей временной таблицей.

Остальные способы +/- одинаково используют память и процессорное время.

Полнотекстовый поиск 2.0

Вы наверняка в курсе про полнотекстовый поиск, но знаете ли вы, что у него есть несколько версий?

Пару слов о том, для чего он нужен 👇🏼

Предназначен он для быстрого поиска нужной информации в информационной системе.

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

А что делает пользователь, если не смог найти? Правильно, создает нового. Так рождаются дубли…

Ну ладно, оставим лирику. Перейдём к делу. Как я сказал в самом начале, у полнотекстового поиска есть несколько версий 👇🏼

Версию №2 завезли в платформу относительно недавно, начиная с 8.3.22. По умолчанию используется версия 1, и чтобы заработала версия 2, нужно переключить в обработке «управление полнотекстовым поиском».

❗️❗️ Отличия версии 2 от версии 1:

В версии 1 создается основной и дополнительный индекс. В процессе работы новые изменения накапливаются в дополнительном индексе, и потом его необходимо слить в основной индекс. Это осуществляется всем знакомым регламентом заданием в типовых конфигурациях «Слияние индекса ПНД».

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

Индекс в версии 2 весит меньше, чем в версии 1. Я проверил это утверждение, и это действительно так. В демо-базе ERP индекс версии 1 весит 285 мб, а версии 2: 185 мб.

К сожалению версия 2 не поддерживается в файловой базе, т.е воспользоваться его возможностями можно только в клиент-серверном варианте работы.

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

Виктор Богачев и Антон Дорошкевич рекомендуют по возможности убирать команду ctrl+f из динамических списков, чтобы оставалась возможность искать только по Alt+F точечно по конкретной колонке.

Какие же звезды должны сойтись, чтобы полнотекстовый поиск работал в динамических списках?

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

2️⃣ поиск выведется только по видимым колонкам, которые присутствую в тексте запроса динамического списка.

3️⃣ полнотекстовый поиск должен своевременно обслуживаться и быть в актуальном состоянии.

4️⃣ для всех полей выводимых динамическим списком должен быть включен полнотекстовый поиск. Если, например, в форме есть соединение с регистром статусов и для этих реквизитов не включен полнотекстовый поиск, то он априори использоваться не будет.

Сталкивались ли с проблемами при работе полнотекстового поиска? Делитесь в комментариях.