Блог

У меня есть таблица SE11 со столбцом типа STRING , и мне интересно, как это хранится в базовой системе БД (в данном случае SAP Hana).

Я читал, что только ссылка на LOB фактически сохраняется в столбце, набранном как STRING , а сама строка сохраняется вне таблицы. Верно ли это и работает ли он так же на Hana? Я пытался использовать RTFM, но не смог найти эту информацию.

Рекомендуется ли вообще использовать CHAR с определенной длиной, когда это возможно?

Отказ от ответственности.Хотя я работаю в SAP SE, я не связан с командами или кодом SAP HANA. Приведенная ниже информация была собрана методом проб и ошибок в SAP HANA 2 SP02 (2.00.024.00.1519806017). Он не является ни надежным, ни юридически обязательным и может быть изменен в будущем без предварительного уведомления.

Хорошо, теперь с этим покончено, давайте посмотрим на некоторые вещи:

• В SAP HANA есть хранилище столбцов (= модная новинка) и хранилище строк (= как известно из других реляционных баз данных). Они очень разные. Поэтому вы должны знать, с каким хранилищем вы имеете дело при оптимизации своих структур.
• ABAP DDIC превращает STRING столбцы в прозрачных таблицах в NCLOB столбцы и CHAR в NVARCHAR .
• ABAP DDIC довольно специфичен для строк: их нельзя использовать в качестве ключей, поскольку они превышают максимальную длину ключа в 255 символов. Они также не позволяют серверу приложений буферизировать таблицу, увеличивая время ответа на повторяющиеся запросы. Обычно это само по себе является причиной воздержаться от STRING использования и использовать CHAR вместо этого. Подводя итог, можно сказать, что не имеет смысла добавлять более одного STRING столбца в прозрачную таблицу.
• SAP HANA действительно хранит LOB-объект вне таблицы, а таблица содержит только ссылку. Содержимое обрабатывается аналогично файлам. Их CONTAINER_ID можно получить из системного представления "SYS"."M_TABLE_LOB_FILES" . Связанный системный вид "SYS"."M_TABLE_LOB_STATISTICS" дает вам более подробную информацию о потребляемом пространстве.
• (Довольно) недавний блог о гибридных LOBS раскрывает еще один интересный факт: «Поскольку SAP HANA не будет сжимать LOB-столбцы, независимо от того, находится ли он на диске или в памяти […]». Это означает, что столбец будет занимать ровно столько места на диске, сколько содержимого, которое вы помещаете. Это сильно отличается от остального содержимого хранилища столбцов SAP HANA, которое подвергается сильному сжатию для оптимизации хранения и доступа. Также интересно отметить полученный вывод: «[…] важно, чтобы любая возможная логика алгоритма сжатия (например, gzip) применялась на прикладном уровне при записи / чтении из базы данных».
• В целом — и это верно для всех систем управления базами данных, которые я знаю — рекомендуется отдавать предпочтение переменным символьным типам, поскольку они дают системе свободу оптимизировать пространство, которое она фактически резервирует. Поскольку руководящие принципы SAP не рекомендуют использовать VARCHAR (= non-Unicode) для чего-либо, кроме чистого ASCII, разумным значением по умолчанию для SAP HANA должно быть NVARCHAR (= с поддержкой Unicode)’.