Хранение данных BLOB в базах геоданных в Oracle

BLOB – используемое в СУБД сокращение, обозначающее большие двоичные объекты. Столбцы BLOB были введены несколько лет назад корпорацией Oracle для замены технологии LONG RAW для хранения двоичных данных.

Архитектура типа данных BLOB делится на три базовых компонента: столбец BLOB, сегмент LOB и индекс LOB. В столбце BLOB хранится локатор LOB (36 байт) и двоичные данные в строке, если длина строки составляет менее 3965 байт и если для столбца не отключено хранение в строках.

Примечание:

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

Если размер двоичных данных превышает 3964 байт, место для хранения в строках в столбце BLOB не выделяется, и локатор LOB ссылается на двоичные данные, хранящиеся в сегменте LOB.

В связи с этим, размер значения в столбце BLOB с включенным хранением в строках всегда составляет не менее 36 байт (место, выделенное на локатор LOB) и может составлять до 4000 байт (сумма места, выделенного на локатор LOB, и максимального места, которое может быть выделено на двоичные данные, хранящиеся в строке).

Сегмент LOB делится на блоки. Размер блока должен быть кратным размеру блока данных Oracle. Например, если размер блока данных составляет 8КБ, сегмент LOB можно создавать с размером блока не менее 8 КБ. Если длина данных в сегменте LOB составляет 5000 байт, они сохраняются в сегменте LOB, поскольку их длина превышает 3964 байт, а размер блока составляет 8 КБ или 8192 байт. В данном случае неиспользованными остаются 3192 байт блока из сегмента LOB. При преобразовании данных из LONG RAW в BLOB может потребоваться больше места в связи с наличием неиспользуемого места в сегменте LOB. Это увеличение может составить до 30 процентов. Этого нельзя избежать, если размер данных превышает 3964 байт, т.е. пороговое ограничение столбца BLOB для хранения внутри строк.

Размер блока 8 КБ обеспечивает наилучшую производительность ввода/вывода при минимальных ненужных затратах места. При использовании размера блока 16 КБ затраты места будут больше, чем для блока 8 КБ. В связи с этим, чтобы избежать потери места, рекомендуется перестроить базу данных с размером блока данных 16 КБ в базу с размером блока 8 КБ. Если же это невозможно, рекомендуется создать в табличных пространствах сегменты LOB с размером блока 8 КБ. Для этого нужно выделить буфер кэширования 8 КБ в глобальной области системы Oracle (SGA).

При использовании размеров блока 4 КБ и 2 КБ затраты составляют еще меньше, но снижение эффективности ввода/вывода не оправдывает их использование.

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

На следующих трех рисунках иллюстрируется три возможных примера сохранения двоичных данных в столбце BLOB. В первом случае в строке хранится 3000 байт двоичных данных, поскольку 3000 байт меньше 3965 байт или порогового ограничения объема хранения в строке. Если хранение внутри строк в столбце BLOB не отключено, сегмент LOB и индекс LOB не используются. Обычно это обеспечивает увеличение скорости доставки данных BLOB в связи с уменьшением числа операций ввода/вывода, поскольку Oracle не требуется получать доступ к сегменту LOB или индексу LOB.

Данные BLOB размером менее 3965 байт хранятся внутри строк

На следующем рисунке проиллюстрирован второй пример, в котором размер двоичных данных превышает 3964 байт (в этом случае размер данных составляет 81920 байт), и данные не помещаются внутри строк. В связи с этим, локатор LOB ссылается на двоичные данные, которые хранятся в сегменте LOB. Поскольку двоичные данные не занимают более 12 блоков в сегменте LOB, локатор LOB сохраняет его адреса. В этом случае индекс LOB не используется.

Данные BLOB размером более 3964 байт хранятся вне строк. Локатор LOB в таблице сегмент указывает на сегмент LOB, где хранятся данные.

На последнем рисунке показаны двоичные данные такого большого размера (106496 байт), что для их размещения требуется индекс LOB. В этом случае размер двоичных данных превышает ограничение для хранения внутри строк, и для их хранения требуется более 12 блоков в сегменте LOB. Для данных такого размера локатор LOB ссылается на индекс LOB для получения месторасположения блоков внутри сегмента LOB. Эта ситуация чрезвычайно редко встречается для векторных данных, а для растровых данных ее можно избежать.

Данные BLOB хранятся вне строк, и при этом требуется индекс LOB

Установка параметров DBTUNE для хранения столбцов BLOB

Параметры хранения в таблице DBTUNE определяют создание таблиц и индексов ArcGIS в Oracle. Некоторые параметры хранения также определяют типы данных, которые используются при создании таблицы. Подробную информацию о таблице DBTUNE можно узнать в разделе Что такое таблица DBTUNE? Общая информация о параметрах хранения DBTUNE приведена в разделе Какие существуют ключевые слова конфигурации и параметры DBTUNE?

Параметры хранения DBTUNE, GEOMETRY_STORAGE, RASTER_STORAGE и ATTRIBUTE_BINARY определяют, какие типы данных Oracle используются для хранения данных.

Параметр GEOMETRY_STORAGE контролирует хранение векторных данных в классе пространственных объектов. Параметр RASTER_STORAGE определяет хранение растровых данных в растровом наборе данных, растровом каталоге или растровом атрибуте. Наконец, параметр ATTRIBUTE_BINARY определяет хранение всех других двоичных данных, которые не являются векторными или растровыми.

Для создания столбцов BLOB необходимо установить следующие параметры с заданным ключевым словом DBTUNE:

GEOMETRY_STORAGE SDELOB
RASTER_STORAGE BLOB
ATTRIBUTE_BINARY BLOB

ESRI рекомендует использовать следующие параметры хранения LOB для векторных и растровых данных:

• Хранение внутри строк всегда следует включать, поскольку большинство данных географической информационной системы (ГИС) умещается в блоках размером до 3964 байт, т.е. их размер не превышает порогового значения для хранения внутри строк. Наилучшая производительность достигается, когда данные хранятся в строках.
• Поскольку данные из базы геоданных часто считываются, кэширование следует включить.
• Поскольку ArcGIS не обновляет данные BLOB, а только выполняет операции вставки и удаления, необходимо установить для PCT_VERSION значение 0 в связи с отсутствием необходимости поддержки более старых версий данных в сегменте LOB.
• Не следует использовать размер блока менее 8 КБ. При использовании размеров блока 2 КБ и 4 КБ увеличивается количество операций ввода/вывода, поскольку процесс сервера Oracle должен доставлять больше блоков. В подавляющем большинстве случаев затраты места при размере блока 8 КБ меньше, чем при размере блока 16 КБ. При использовании размера блока 2 КБ или 4 КБ затраты места меньше, но испытания показали, что в этих случаях время отображения растровых и векторных данных значительно увеличивается по сравнению с хранением в блоках 8 КБ. Поскольку размер блока всегда должен быть кратным размеру блока данных, оптимальный размер блока данных для хранения данных GIS в блоках BLOB составляет 8 КБ.

В следующем примере показано, как параметры хранения растров DBTUNE изменены для соответствия таблице растровых блоков, хранящихся в качестве типа данных BLOB:

RASTER_STORAGE "BLOB"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)" 

AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (OBJECT) STORE AS 
             (TABLESPACE RASTER 
              CACHE PCTVERSION 0)"

RASTER_STORAGE "ST_RASTER"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE RASTER 
             LOB (BLOCK_DATA) STORE AS 
             (TABLESPACE RASTER_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

Если размер пиксельных данных растрового блока составляет менее 3965 байт, эти данные хранятся в столбце BLOCK_DATA в табличном пространстве RASTER. Однако при превышении этого порогового значения данные сохраняются в сегменте LOB в табличном пространстве RASTER_LOB_SEGMENT. Индекс LOB используется, только если количество блоков превышает 12. Обычно это не случается с данными из базы геоданных. Необходимо рассмотреть использование сегментов LOB с размером блока 8 КБ. До использования индекса LOB размер двоичных данных ArcSDE должен превышать 96 КБ.

В следующем примере показано, как параметры хранения векторов DBTUNE изменены для соответствия таблице объектов, хранящихся в типе данных BLOB:

GEOMETRY_STORAGE "SDELOB"

F_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE VECTOR 
             LOB (POINTS) STORE AS 
             (TABLESPACE VECTOR_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

GEOMETRY_STORAGE  "ST_GEOMETRY"

Если размер двоичных данных объекта составляет менее 3965 байт, эти данные хранятся в столбце POINTS в табличной области VECTOR. Однако при превышении порогового значения они сохраняются в сегменте LOB в табличном пространстве VECTOR_LOB_SEGMENT.

ATTRIBUTE_BINARY "BLOB"

B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

A_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE BIZZTABS 
             LOB (DOCUMENT) STORE AS 
             (TABLESPACE BIZZ_LOB_SEGMENT 
              CACHE PCTVERSION 0)"

Если в этом примере размер двоичных данных в рабочей таблице составляет менее 3965 байт, они хранятся в столбце BLOB рабочей таблицы в табличном пространстве BIZZTABS. Однако при превышении этого порогового значения данные сохраняются в сегменте LOB в табличном пространстве BIZZ_LOB_SEGMENT. В данном примере столбец BLOB называется DOCUMENT. Если параметр DBTUNE B_STORAGE выше используется для создания таблицы без столбца DOCUMENT, Oracle выводит следующую ошибку:

ORA-00904: "DOCUMENT": invalid identifier

В связи с этим неразумно добавлять параметры B_STORAGE или A_STORAGE, ссылающиеся на определенный столбец BLOB с ключевым словом DEFAULTS, поскольку рабочая таблица должна содержать эти столбцы. Вместо этого, необходимо создавать отдельные ключевые слова DBTUNE и добавлять эти параметры хранения к ключевым словам. Ссылки на ключевые слова, содержащие параметр хранения, определяются при создании таблицы. Также необходимо отметить, что параметры хранения ключевого слова DEFAULTS используются, если определенное ключевое слово не задано. В связи с этим отсутствует необходимость добавления определенных параметров хранения с ключевым словом, если его строка конфигурации идентичная параметру хранения с ключевым словом DEFAULTS. например, если все параметры хранения, кроме B_STORAGE и A_STORAGE для нового ключевого слова ROADS имеют ту же строку конфигурации, что и для ключевого слова DEFAULTS, необходимо только создать параметры B_STORAGE и A_STORAGE для ключевого слова ROADS. Все другие параметры хранения считываются из ключевого слова DEFAULTS, поскольку они отсутствуют в ключевом слове ROADS.