Таблица значений. Нюансы

Общие сведения

Таблица значений (далее ТЗ) — универсальная коллекция, наиболее близко моделирующая "классическую" таблицу базы данных. Она имеет колонки различных типов, в т.ч. неопределённого "произвольного" типа, и строки с содержимым; свойства и методы для работы с колонками и строками. Всё это, надеюсь, общеизвестно, изложено в десятках статей и есть в СП. ТЗ можно заполнять произвольным кодом, из наборов регистров, или по результатам работы запроса, построителя запроса, процессора СКД, загружать из табличных частей, заполнять массивами. В ТЗ есть выгрузка журнала регистрации и результатов поиска ссылок. ТЗ можно использовать для заполнения таб.частей, наборов регистров, как источник данных в запросах, построителях запросов, построителях отчётов и наборах данных СКД. ТЗ является входным аргументом и результатом специальных функций СКД, в т.ч. расширяющих возможности встроенного языка 1С.

ТЗ работает в COM-обмене, где поддерживает те же методы (включая и индексацию на стороне базы-провайдера), за малыми исключениями допускается русскоязычная нотация в свойствах и методах.

ТЗ сериализуется в XDTO. Наряду с деревом значений, ТЗ не существует на тонком и веб-клиенте, хотя сериализуется для обмена с сервером; в толстом клиенте может являться реквизитом формы "в естественном виде" и с интерфейсной ипостасью, а также с модальным окном просмотра/выбора, в тонком клиенте существует на сервере, а на клиенте отображается специальной коллекцией. Также может являться реквизитом (в т.ч. явно указанного типа), например, у отчётов и обработок. ТЗ удобно просматривается отладчиком. За уникальными исключениями, чтение и запись ТЗ всегда монопольны, что устраняет все проблемы конкурентного доступа.

Размещение

ТЗ всегда существует в сеансовых данных. Сеансовыми данными рулит менеджер кластера, и если в нём несколько серверов, то сеансовые данные располагаются равномерно по всем серверам (если, конечно, не указаны требования функциональности). ТЗ может быть сформирована одномоментно, некоей выгрузкой, или расти постепенно, но платформа обрабатывает ТЗ всегда одинаково — блоки по 64 МБ (больше бывает только при помещении во временное хранилище согласно мнению rmngr’а о производительности) выделяемые менеджером кластера, пишутся в конец файла сеансовых данных. Как и другие коллекции, ТЗ сначала размещается в памяти rphost, потом бинарным потоком передаётся rmngr’у. В отличие от других сеансовых данных, чей срок жизни считается по открытой форме, или по серверным вызовам, данные ТЗ считаются актуальными до конца сеанса или существования указателя на таблицу (имени переменной, реквизита экземпляра отчёта/обработки). Если ТЗ заняла более четверти объёма файла, то выделение блоков происходит с учётом прочих актуальных сведений в файлах, каждые 5 сек. делается актуализация и сборка мусора. Если ТЗ невелика, то актуальные сеансовые данные копируются в новые файлы, а сборка мусора идёт потом.

Сеансовые данные обычно располагаются в папке 1cv8srvinfo
eg_1541snccntx, дописанной специфическим UID, и лежат там в файлах вида snccntx.000057F1.dat (по сути это noSQL key-value storage). Конкурентный доступ к ним в норме невозможен (если только не задвоились процессы rmngr в памяти и не смотрят на одну и ту же папку реестра кластера). Таким образом, для работы с ТЗ не важен сервер СУБД и она сама, а важна скорость дисковой подсистемы ПК, где лежат сеансовые файлы, и мощность процессора, обрабатывающего их. Особенно это стоит учитывать при совмещении серверов СУБД и приложения. Также, очевидно, поведение ТЗ на разных СУБД и в файловом варианте идентично и в логическом, и в физическом чтении. При этом существует несколько ситуаций, определяемых платформой согласно объёму данных, когда индексы ТЗ размещаются в ОЗУ сервера приложений на время их перестроения.

Типизация

ТЗ, как и другие универсальные коллекции, может содержать простые и ссылочные типы, другие коллекции, com-объекты, системные перечисления, указания на экземпляры объектов, модули, служебные переменные и т.д. Для этого достаточно не объявлять тип колонки, а оставить на откуп платформе — описание типов такой колонки пусто, а квалификаторы определены по умолчанию (длина 0, точность 0, любые длина и знак, любые части даты), и это не мешает заносить туда простые типы, вроде бы противоречащие квалификаторам. При явном указании типа ТЗ контролирует это: если знаков дробной части недостаточно для числа, то округляет (причём 0.5 округляет всегда до 1); если не влезает строка — обрезает; если объявлена фиксированная строка и реальная длина меньше, то дописывает пробелами; сообразно обрезает дату/время — словом, всё ожидаемо. Если тип колонки строковый, то возможны дополнительные свободы преобразования (так, ЗаполнитьЗначения, где указано значение другого типа для внесения в строковую колонку, отработает, внеся строковое представление значения; аналогично работает ЗагрузитьКолонку). "Никакое" значение имеет тип "Неопределено", при работе с запросами и внешними источниками может содержаться и Null (как наряду с другими типами, так и в качестве единственного типа, и наполнения, колонки). Изменить тип колонки ТЗ невозможно (даже для произвольного), нельзя изменять и свойства квалификаторов.

При передаче ТЗ в параметр запроса и в конструктор описания источника данных для построителя запроса/отчёта чёткая типизация обязательна. Для источника набора данных СКД это не требуется (поля набора не будут никак типизированы), но по опыту желательно. В ранних релизах 8.3 произвольный тип колонки в коллекции на клиенте не поддерживался, в толстом клиенте при конфигурировании его нельзя сделать и поныне (но можно создать и отобразить программно).

События, касающиеся ТЗ, отслеживаются в технологическом журнале только косвенно — это, конечно, "ALL", а также "MEM" (увеличение объёма памяти под серверные процессы); на 8.2.16-19 иногда наблюдался "LEAKS", связанный с ТЗ. Русскоязычные упоминания ТЗ в logcfg в ряде случаев могут вызывать ошибку и логи тихо перестают писаться.

Строка таблицы значений

Элемент таблицы — строка ТЗ — самостоятельный объект языка, и по сути она же — первичный внешний ключ. Ссылка на строку ТЗ и массив ссылок, найденный поиском, всегда содержит активные ссылки на строки; изменение данных в них сказывается на ТЗ; строка может храниться в той же ТЗ, в переменной и любом соответствующем реквизите формы или объекта. При удалении строки и очистке ТЗ такая переменная по-прежнему имеет тип "СтрокаТаблицыЗначений", но операция со значениями её колонок вызывает ошибку чтения, а с ней самой в рамках ТЗ вызывает ошибки, свидетельствующие об индексовой, "ключевой" сути строки — "индекс за границами диапазона". Тип свой такая переменная (и массив таких переменных) сохранит, даже если сама ТЗ уничтожена, осталась в покинутом контексте или явно очищена, что может стать причиной утечек памяти. Аналогичный эффект наблюдается при свёртке — если некая строка сохранена в переменной, но исчезла в результате свёртки, её тип остаётся, но работа с ней невозможна. Никакую ссылочную целостность 1С для ТЗ не проверяет.

Явные номера строк в ТЗ можно организовать либо добавлением соответствующей колонки и заполнением в цикле, либо запросом, либо использованием служебного поля СКД "НомерПоПорядку". Также, номера образуются при выгрузке из табличной части — при этом появляется колонка с именем "НомерСтроки", заголовком "N", типом "Число" с пустым квалификатором, нумерация в ней идёт не с 0, а с 1. Неявная нумерация строк организована платформой — важно, что это не доступный в языке первичный ключ, а внутреннее служебное поле.
 

Изменение содержимого

Добавление данных выполняется только построчно. Метод "ЗагрузитьКолонку" заполняет уже имеющиеся строки, начиная с нулевой, столько, сколько есть (если массив больше по размеру, остальное пропадёт), т.е. если строк нет, не добавляет их. Метод "ЗаполнитьЗначения" также оперирует имеющимися строками. Если надо вставлять блоки данных, разумно использовать метод, предложенный Гилёвым: http://www.gilev.ru/%d0%bf%d1%80%d0%be%d1%81%d1%82%d0%be%d0%b9-%d1%82%d1%80%d1%8e%d0%ba-%d0%b4%d0%bb%d1%8f-%d0%b1%d1%8b%d1%81%d1%82%d1%80%d0%be%d0%b3%d0%be-%d0%be%d0%b1%d1%8a%d0%b5%d0%b4%d0%b8%d0%bd%d0%b5%d0%bd%d0%b8/

К сожалению, ТЗ в 8.Х не обладает возможностями "вырезки" кусков с указанием начального и конечного номеров строк, как было в 7.7, но это можно смоделировать в запросе или СКД, пронумеровав строки и наложив условие на них. На эту тему, как и на тему сравнения ТЗ, на ИС достаточно публикаций.

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

Индексация

ТЗ имеет возможность индексации с целью ускорения поиска. Индексов может быть много, они добавляются и удаляются средствами языка; индекс может содержать несколько колонок в произвольном порядке, индекс как элемент коллекции имеет строковое представление по именам колонок, входящих в него. Перечисление колонок в добавлении индекса не связано с их порядком в таблице. Изменение состава индекса невозможно. Разные индексы могут касаться одних и тех же колонок. Пример:

тз.Индексы.Добавить("Кол1,Кол2,Кол3"); // 1-й индекс, покрывающий все колонки
тз.Индексы.Добавить("Кол2"); // 2-й индекс, работающий с одной колонкой
тз.Индексы.Добавить("Кол3,Кол1"); // 3-й индекс, по 2 колонкам в обратном порядке

Индексы используются при поиске методами "Найти" и "НайтиСтроки", причём для "НайтиСтроки" критически важно точное совпадение порядка колонок в конструкторе структуры отбора с порядком в индексе, поэтому рекомендуется явный конструктор "Структура("Поле1,Поле2",знч1,знч2)". При таком поиске идёт перебор ключей структуры, неприменимые индексы и индексы с лишними элементами отбрасываются, и если платформа находит подходящий индекс, то задействует его. Пример:

тз.Индексы.Добавить("Кол1,Кол2"); // единственный индекс ТЗ
тз.НайтиСтроки(Новый Структура("Кол1,Кол2",знч1,знч2)); // индексный быстрый поиск
тз.НайтиСтроки(Новый Структура("Кол2,Кол1",знч2,знч1)); // безындексный медленный поиск
тз.Найти(знч1,"Кол1"); // безындексный медленный поиск
тз.Найти(знч2,"Кол2"); // безындексный медленный поиск
тз.НайтиСтроки(Новый Структура("Кол1,Кол2,Кол3",знч1,знч2,знч3)); // безындексный медленный поиск

У индексов примерно с 8.2.16 нет ограничения на количество полей, длину ключа (900 байтов, 16 колонок), т.к. применяется хэш по ключу полей, что несколько медленнее привычных индексов СУБД. Ни о какой статистике, оценке фрагментированности и прочая для ТЗ речи не идёт, а выбор полей для индексации (согласно их содержимому, селективности итд) целиком на разработчике.

Построение/перестроение индексов выполняется сервером приложения, даёт пик по занятости процессора и активности диска, незначительно по % использования памяти. Файлы подкачки не используются. При индексном поиске идёт обращение к диску (% активности серьёзно колеблется), виртуальная держится стабильно. При безындексном вся нагрузка ложится на процессор. Поиск по индексированным и неиндексированным полям вместе, либо поиск по нескольким полям, порядок и состав которых не имеют точного совпадения ни у одного из индексов, в плане нагрузки на оборудование всегда является безындексным.

Зависимость индексов от изменений ТЗ

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

Изменение может касаться состава строк. Наиболее ресурсозатратно добавление/вставка строк в индексированную таблицу, это сильно загружает процессор и на 60-70% медленнее добавления в неиндексированную. Чем больше есть индексов, тем больше также загружен диск. Падение скорости при перестроении индексов для каждого добавления строки нелинейно, связь между характером и порядком индексов и содержимым строк не прослеживается. Рекомендуется сначала добавлять строки, потом строить индекс. Пример:

тз=НекаяИсходнаяТаблица.Скопировать(,"Кол1");
// индексировать до добавления - нерационально
Для й=1 По N Цикл
тз.Добавить().Кол1=й;
КонецЦикла;
тз.Индексы.Добавить("Кол1"); // после добавления разово строим индекс

Если индексы уже есть, разумнее их удалить и создать заново, если добавляется более 1/4 от прежнего объёма ТЗ.

Перестроение индексов происходит при изменении содержимого конкретных ячеек, причём присвоение значения — это сразу перестроение, и это ещё одна причина использовать ЗаполнитьЗначенияСвойств — при её применении индексы перестраиваются, когда процедура отработала по всем колонкам строки. Методы ЗаполнитьЗначения и ЗагрузитьКолонку вызывают разовое перестроение индексов по завершении своего выполнения, и тоже выполняются на 30-35% медленнее, чем при работе с неиндексированной ТЗ.

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

Вплоть до 8.3.8 включительно при изменении значения в колонке, не входящей ни в какой индекс, всё равно происходило перестроение индексов; потом это исправили.

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

Особенности индексов

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

Поведение построения индексов и поиска для колонок, имеющих несколько типов, зависит от этих типов (несмотря на хэширование); так, для простых типов отличие от работы с однотипной колонкой минимально, если есть ссылочные типы и системные значения/системные перечисления — в среднем на 5% дольше. Если наполнение состоит из ссылок на формы и модули, скорость даже выше на 2-3%, чем для простых типов. Для наполнения из сложных коллекций прямой зависимости не выявлено.

Строки неограниченной длины индексируются в общем порядке и поиск правильно находит фрагменты любого размера; скорость индексации и поиска не отличается от таковой по иным простым типам. Хранилища значений индексируются и ищутся аналогично, прямой зависимости от объёмов не выявлено.

Сортировка индексированной таблицы в релизах до 8.3.9 медленнее на 10-15%, чем неиндексированной, даже если делается по неиндексированным полям; в новых релизах — медленнее на 2-5%.

При использовании ЗначениеВСтрокуВнутр и ЗначениеВФайл, и обратно, при сериализации через СериализаторXDTO, индексы сохраняются и работоспособны, время выполнения этих действий практически не зависит от наличия и характера индексов.

При передаче по ссылке, т.е. "ТЗ2=ТЗ1", при ТЗ2=ТЗ1.Скопировать() и Скопировать(,""), индексы сохраняются и работоспособны. Но при любом прямом указании колонок, в т.ч. если копируются все индексированные колонки, сами индексы не копируются. При указании любых отборов на строки индексы не копируются. Копирование индексированной ТЗ в среднем на 10-20% дольше копирования неиндексированной, в зависимости от её объёма и характера индексов.

При передаче ТЗ в процедуру/функцию и присвоении реквизиту соответствующего типа, при возвращении функцией — индексы сохраняются и работоспособны, единожды сделанные индексы везде "сопровождают" ТЗ. Важно, что директива "ЗНАЧ" в объявлении аргументов игнорируется: индексы, добавленные/изменённые для ТЗ внутри процедуры/функции, продолжают существовать и работать по её завершении, вне её контекста. Изменения ТЗ и индексы никак не связаны с принудительно объявляемыми транзакциями.

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

При подготовке обзора использована информация с партнёрских сайтов, сайт http://www.gilev.ru и материалы видеоуроков В.Богачёва. Эксперименты по производительности ставились на Win Server 12 R2 Стандарт х64, Intel Xeon 2.6 GHz, 16 Гб ОЗУ, и аналогичной ОС, 2.0 GHz, 44 Гб ОЗУ. Использовались платформы релизов 8.3.6.2237, 8.3.10.2561 и 8.3.15.1565. Наблюдения велись с помощью замеров конфигуратора, и Perfomance Monitor по показателям: "% загруженности процессора _Total", "% использования физ.диска _Total", "% использования файла подкачки", "% использования выделенной памяти" и ещё нескольким второстепенным. По другим ОС ничего сказать, к сожалению, не могу. Во всех случаях речь идёт о сервере приложений, в ряде случаев совмещённом с клиентским. Рассматривалась работа на клиенте в обычных формах и на сервере в тонком клиенте.

 

Кроме //infostart.ru/public/19720/ подходящих публикаций на ИС не нашёл; если есть — извиняюсь за баян. Картинок нету ввиду криворукости, моей и браузера, стоящей каждый раз мне и модераторам кучу нервов.

Успеха, интересной и приятной работы всем нам)