Загрузка больших наборов растровых данных в ArcSDE
Эта тема относится только к ArcGIS for Desktop Standard и ArcGIS for Desktop Advanced.
Растровые данные, по своей природе, требуют больших объемов дискового пространства. Наборы растровых данных и каталоги растров редко бывают менее нескольких гигабайт (GB) и могут занимать до нескольких терабайт (TB) в вашей СУБД (DBMS). Копирование большого объема растровых данных является сложной задачей даже для опытного администратора. В этом разделе приводятся основные шаги, необходимые для загрузки больших объемов растровых данных в набор растровых данных или в каталог растров. Предполагается, что вы уже решили, что ваши растры будут храниться в базе геоданных ArcSDE.
Примечание:Набор данных мозаики содержит ссылки на растровые данные, входящие в него; в отличие от каталога растров, хранящегося в базе геоданных ArcSDE, набор данных мозаики не загружает данные в базу геоданных. Если вы создаете набор данных мозаики, содержащий растровые данные из базы геоданных ArcSDE, воспользуйтесь этим разделом как руководством по загрузке данных.
Построение большой базы растровых данных можно разделить на три этапа: подготовка к загрузке данных, собственно загрузка данных и проверка полученного результата, вместе с исправлением ошибок. Необходимо выполнить следующие задачи:
Подготовка к загрузке данных
- Конфигурирование вашей системы
- Оценка размера области хранения в СУБД
- Выделение области хранения в СУБД
Загрузка данных
- Подготовка исходных данных
- Создание растрового объекта
- Загрузка растровых данных в растровый объект
- Построение статистики СУБД
- Построение статистики растра
Проверка данных
- Просмотр результата
Конфигурирование вашей системы
Конфигурирование вашей системы состоит из двух задач: конфигурирование СУБД и конфигурирование ArcSDE.
Конфигурирование параметров СУБД
Конфигурация каждой СУБД, поддерживаемой Esri, уникальна, но основная задача остается неизменной – увеличение пропускной способности базы данных настолько, насколько возможно. Для загрузки больших объемов растровых данных, СУБД должна быть оптимизирована для записи; однако, СУБД, оптимизированная для загрузки сотен гигабайт растровых данных, может снизить производительность других приложений, использующих те же самые ресурсы для выполнения других задач. Поэтому, если ваша СУБД служит не только для загрузки растровых данных, рекомендуется изменить конфигурацию системы и выполнить загрузку данных в нерабочее время, чтобы это не повлияло на работу других сотрудников. Также, это позволит не создавать отдельную копию СУБД, предназначенную только для загрузки растровых данных.
Рекомендации по хранению растровых данных в SQL Server, Oracle, DB2 и Informix. Приведенная ниже информация кратко описывает то, что можно найти в более подробном виде в каждом из соответствующих руководств.
Конфигурирование параметров СУБД SQL Server
- Следуйте инструкциям по SQL Server только в том случае, если на сервере работают другие приложения.
- По возможности, установите database recovery model (модель восстановления базы данных) на simple. Это следует сделать, т.к. восстановление на определенную точку времени не является обязательным при загрузке растровых наборов данных, а запись журнала неоправданно увеличивает его объем.
- Отключите параметры autoclose и autoshrink, т.к. они отрицательно сказываются на производительности.
Более подробно о растровых данных в базе геоданных под управлением SQL Server
Конфигурирование параметров СУБД Oracle DBMS
- Сконфигурируйте интервал контрольных точек так, чтобы они выполнялись только во время переключения на следующую группу. Oracle DBAs устанавливает параметры инициализации Oracle LOG_CHECKPOINT_INTERVAL и LOG_CHECKPOINT_TIMEOUT на 0. При этом происходит принудительная запись контрольных точек во время переключения на следующую группу.
- Увеличьте размер каждого файла журналов до 1 Гб, как минимум.
- Увеличьте кэш буфера блоков данных, чтобы в нем могли храниться «грязные блоки», увеличив размер DB_BUFFER_CACHE.
- Создайте базу данных Oracle с размером блоков данных 8 KB. Это оптимальный размер блоков данных для хранения данных типа BLOB, которые по умолчанию являются основным типом хранения всех двоичных данных ArcGIS. Использование более крупных блоков данных, по 16 KB или 32 KB, скорее всего, приведет к ненужной трате свободного места, которое будет выделяться для сегментов BLOB. Для общего представления о хранении данных BLOB, обратитесь к документации Oracle.
Более подробно о растровых данных в базе геоданных под управлением Oracle
Конфигурирование параметров СУБД DB2
- Создайте отдельные буферные пулы для растровых табличных областей.
- Создайте большой буферный пул для табличной области, в которой будет храниться таблица растровых блоков.
- Если DB2 установлен на платформе AIX, установите следующие параметры:
- db2set DB2_MMAP_READ=OFF
- db2set DB2_MMAP_WRITE=OFF
Более подробно о растровых данных в базе геоданных под управлением DB2
Конфигурирование параметров СУБД Informix
Конфигурирование параметров onconfig:
- Установите достаточно большое значение BUFFERS, чтобы не использовать очистители (cleaners).
- Установите LOGSIZE на 100000.
- Убедитесь, что файл журнала расположен не в rootdbs dbspace.
- Установите LOG_BACKUP_MODE в режим непрерывного архивирования логических журналов.
- Установите LOGSMAX на 100.
- Установите RA_PAGES на 125.
- Установите RA_THRESHOLD на 85.
- Установите RESIDENT на -1.
- Установите параметр NETTYPE на поддержку удаленных соединений, если вы собираетесь использовать прямые подключения.
Более подробно о растровых данных в базе геоданных под управлением Informix
Конфигурирование ArcSDE Server
ArcSDE использует транспортные буферы для передачи данных между клиентом и сервером ArcSDE. Во время записи, когда клиентский буфер данных достигает порогового значения, он записывается на сервер ArcSDE. Пока сервер ArcSDE обрабатывает этот буфер, ArcSDE клиент собирает в буфер другие данные. Затем, клиент снова посылает серверу содержимое буфера, но только в том случае, если сервер ожидает этого. Для растровых данных, размер транспортного буфера контролируется параметром сервера RASTERBUFSIZE. По умолчанию, этот параметр установлен на 200 KB, что подходит для большинства операций загрузки данных. ArcSDE выделяет объем памяти, указанный параметром RASTERBUFSIZE в двойном размере, как на серверной, так и на клиентской стороне. Поэтому, если вы используете рекомендованное значение 200 KB, на стороне клиента и сервера выделяются по 400 KB. В дополнение к буферам транспорта, ArcSDE выделяет еще три буфера на сервере для данных, прочитанных и записанных в и из СУБД. Это увеличивает общее количество памяти, выделяемой на сервере, до 1000 KB. Если вы используете прямое подключение, функции клиента ArcSDE и сервер работают на компьютере клиента; таким образом, объём памяти, выделяемый прямым подключением, семикратно превышает объём заданный RASTERBUFSIZE. Вам нужно изменить только размер RASTERBUFSIZE, если его размер по умолчанию недостаточно большой, чтобы соответствовать размеру несжатого листа растра. Размер несжатого листа растра определяется шириной и высотой листа, а также глубиной пиксела. Например, при использовании значения по умолчанию 128 х 128 для ширины и высоты листа произведение двух значений составит 16384. Умножьте полученное значение на коэффициент глубины пиксела из таблицы ниже для получения несжатого листа растра. Если глубина пиксела равна 32, размер несжатого листа составит 65.536 байт. Это вполне укладывается в значение 200 KB, принятое по умолчанию для буфера. Тем не менее, если вы решите увеличить размер листа до 256 на 256, несжатый размер возрастет до 262.144 байт. Если вы не увеличите размер буфера (параметр RASTERBUFSIZE), вы можете получить ошибку SE_RASTER_BUFFER_TOO_SMALL (-294). В этом случае, следует обязательно увеличить размер буфера приблизительно до 300 KB.
Глубина пиксела | Фактор пиксельной глубины |
|---|---|
1 бит | 0.125 |
4 бит | 0.25 |
8 бит | 1 |
16 бит | 2 |
32 бит | 4 |
64-разрядная | 8 |
sdeconfig -o alter -v RASTERBUFSIZE=10240000 -u sde -p esri
Новое значение будет внесено в таблицу SDE.SERVER_CONFIG. Это значение будет действовать для всех сеансов ArcSDE, которые были начаты после изменения данного параметра.
Не следует увеличивать значение параметра RASTERBUFSIZE больше, чем необходимо для размещения несжатого ласта растра. Установка слишком большого значения может усложнить прохождение растровых данных по всей системе.
Архитектура соединения
Построение пирамидных слоев с пониженным разрешением является многопоточной, ресурсоемкой операцией. Эта задача выполняется встроенными средствами ArcSDE. Разместив сервер на компьютере с наиболее мощным процессором, вы можете получить максимальную скорость загрузки растровых данных в базу. Мощность определяется числом отдельных процессоров и их скоростью.
Вы можете использовать отдельный сервер и создать подключение к сервису ArcSDE, или использовать прямое соединение, тогда серверная часть будет внедрена в клиентское приложение (например, в ArcCatalog).
В зависимости от того, какой из компьютеров, клиент или сервер, на котором установлен сервис ArcSDE , имеет более мощный процессор, вы можете выбрать, использовать ли прямое подключение. Если клиентский компьютер более мощный, используйте прямое подключение, чтобы выполнять построение пирамид на нем.
Также, следует учитывать общую нагрузку на сервер с установленным сервисом ArcSDE. Весьма вероятно, что более мощный серверный компьютер находится на пределе своих возможностей, обслуживая запросы других приложений. Если сервер не полностью загружен, и более производителен, чем клиентский компьютер, подключайтесь к сервису ArcSDE.
Оценка размера области хранения в СУБД
Рекомендуется подготовить место для хранения СУБД заранее, перед началом загрузки больших наборов растровых данных. Чтобы сделать это, необходимо выделить в базе место для хранения растровых данных, а также предусмотреть место для размещения файлов изображений, откуда они будут загружаться в базу. После того, как вы оцените необходимый объем, вы можете выделить память в СУБД, установить параметры ArcSDE DBTUNE, и начать загрузку растровых данных.
Таблица BLK – самая большая из всех растровых таблиц и индексов. Как правило, она в 150 раз больше, чем второй по величине объект СУБД, составной индекс таблицы растровых блоков. Остальные таблицы растровых объектов и индексы в тысячи раз меньше и, в основном, сгруппированы вместе с составным индексом таблицы растровых блоков в общей области хранения в СУБД. Поскольку таблица растровых блоков значительно превышает объем остальных объектов, оценка требуемого пространства проводится, в основном, по ней.
Для наборов растровых данных и каталогов растров, данные пикселов хранятся в СУБД в таблице BLK. С другой стороны, наборы данных мозаики ссылаются на наборы растровых данных и не хранят данные пикселов в таблице BLK. Таблица BLK останется пустой, пока обзоры наборов данных мозаики хранятся в СУБД.
Существуют два базовых метода оценки объема, который занимает таблица растровых блоков в базе данных. Один метод состоит в загрузке нескольких изображений и экстраполяции общего объема таблицы растровых блоков по объему нескольких проверочных изображений. Другой метод – вычисление требуемого объема на основе формулы, для которой используются параметры загружаемых растровых объектов. Первый метод дает более точные результаты, чем второй, однако, метод вычисления можно использовать тогда, когда исходные данные не полностью подготовлены для загрузки. Чтобы достаточно точно определить размер таблицы растровых блоков, вы должны знать следующие параметры, которые влияют на объем таблицы блоков:
Более подробно о получении информации о наборе растровых данных
Оценка размера таблицы блоков растра по образцу
Создание небольшого растрового объекта путем загрузки нескольких наборов растровых данных с помощью ArcCatalog. Растровый объект должен иметь тот же тип сжатия, степень сжатия, глубину пиксела, количество каналов и размер листа, что и итоговый растровый объект, который будет создан на его основе. Эти свойства растра влияют на размер растрового объекта, который он занимает в базе данных.
После загрузки растровых данных, использующихся в качестве образца, вы сможете определить, сколько места требуется в базе данных для этой таблицы блоков.
В Oracle, это можно определить, создав запрос к столбцу BLOCKS системной таблицы USER_TABLES, содержащей данные о таблице блоков растрового объекта. Чтобы сделать это, сначала необходимо определить имя таблицы растровых блоков объекта, которое, в свою очередь, требуется для получения индекса rastercolumn_id из таблицы SDE.RASTER_COLUMN.
Примечание:В следующих примерах предполагается, что бизнес-таблица проверочного растрового объекта называется EARTH.
- Получение индекса rastercolumn_id растрового объекта.
SQL> select rastercolumn_id from sde.raster_columns where table_name = 'EARTH'; RASTERCOLUMN_ID =--------------- 14 - Получение размера таблицы блоков растра со следующим запросом.
SQL> exec dbms_stats.gather_table_stats (NULL,'EARTH'); SQL> select sum(length(rasterband_id)) + sum(length(rrd_factor)) + sum(length(row_nbr)) + sum(length(col_nbr)) + sum(length(block_data)) "total size" from sde_blk_14; total size =----------- 762707968Общий размер таблицы блоков растра – 762.707.968 байт, или приблизительно 727 MB.
-
Определите соотношение размера оценочного набора растровых данных и общего размера всех файлов наборов растровых данных, которые вы собираетесь загрузить. Размер этого образца составляет 2 Гб, общий объем файлов растров – приблизительно 3 Тб.
Сначала конвертируйте 3 терабайта в гигабайты:
3 TB * 1024 = 3072 GB
Общий размер отношения набора растровых данных к проверочному вычисляется как
total size of all rasters / sample raster size = total size to sample size
Например:
3072 / 2 = 1536
- Умножение отношения общего размера к проверочному на размер проверочного набора данных даст приблизительную оценку дискового пространства, требующегося для хранения всех файлов наборов растровых данных в растровом объекте.
727 MB * 1536 = 1,116,672 MB = 1090 GB = 1.06 TB
Чтобы определить размер образца в SQL Server, сначала необходимо получить первый размер образца, затем перейдите к шагу 3 выше.
- Получите rastercolumn_id для растра.
1> select rastercolumn_id 2> from sde.sde_raster_columns 3> where table_name = 'EARTH'; rastercolumn_id =-------------- 3 - Используйте этот ID, чтобы определить объем, занимаемый проверочными данными.
1> exec sp_spaceused 'sde_blk_3'; 2> go name rows reserved data index_size used =-------------------------------------------------------------- SDE_blk_3 4233 29712 KB 29632 KB 16 KB 64 KB
В этом случае, размер оригинального набора растровых данных составлял 50 Мб, но после загрузки в базу, было использовано 29632 Кб + 16 Кб = 29648 Кб, или примерно 29 Мб.
Оценка размера таблицы растровых блоков на основе формулы
Описываемый метод вычисления объема по формуле дает грубую оценку размера таблицы растровых блоков. Если исходные данные частично или полностью доступны, следует использовать вышеприведенный метод оценки размера таблицы растровых блоков, поскольку он дает более точный результат.
- Проведите грубую оценку экстента в метрах или футах. Для наборов растровых данных, имеющих разрешение в метрах (т.е., 5 м, 15 м или 150 м), оцените экстент в этих единицах. Сходным образом, если разрешение указано в футах или дюймах, оцените экстент в этих единицах. Лучший способ рассчитать экстент – создать полигональную рамку по экстенту изображения с помощью ArcMap. При этом, следует исключить пустые пространства, поскольку база геоданных не хранит пустые блоки.
-
Конвертируйте экстент в пикселы.
(Extent of raster in pixel units) / (pixel resolution) = Number of pixels
Для набора данных с разрешением 15 метров и экстентом 450 км. кв., конвертация в пикселы может быть сделана по следующей формуле:
(km2 to m2 conversion factor) / (the pixel resolution in m2) = pixels (450 km2 * 1,000,000) / (15 x 15) = 2,000,000 pixels
В этом примере, рассматривается 50 кв. миль с разрешением 1 фут. Примерная оценка экстента может быть сделана так:
(mi2 to ft2 conversion factor) / (the pixel resolution in ft2) = pixels (50 mi2 * 52802)/ (1 x 1) = 1,393,920,000 pixels
- Умножьте на количество каналов. Если вы используете одноканальный черно-белый или в оттенках серого набор растровых данных, вы можете пропустить этот шаг. Для этого примера, предположим, что данные с 15-метровым разрешением имеют три канала (модель RGB).
2,000,000 pixel extent * 3 bands = 6,000,000 pixels
- Переведите это число в байты, применив фактор пикселной глубины из нижеприведенной таблицы.
Список факторов байт пикселов для глубин пикселовГлубина пиксела
Фактор глубины
1 бит
0.125
4 бит
0.25
8 бит
1
16 бит
2
32 бит
4
64-разрядная
8
8-bit data: 6,000,000 pixels * 1 = 6,000,000 Bytes / 10242 = 5.7 MB 16-bit data: 6,000,000 pixels * 2 = 12,000,000 Bytes / 10242 = 11.4 MB
- Добавьте пирамидные слои с пониженным разрешением. Пирамидные слои с пониженным разрешением увеличивают размер растра на треть. Поэтому, умножьте значение, полученное в шаге 4 на 1,33.
5.72 MB * 1.33 = 7.67 MB
- Вычислите сжатие растра. В следующей таблице приведен пример ожидаемой экономии дискового пространства при использовании различных методов компрессии и степени сжатия. Точные значения могут отличаться, в зависимости от типа используемых данных.
Факторы сжатия для типов сжатияТип сжатия
Фактор сжатия
LZ77
0.5
JPEG 75%
0.15
JPEG 50%
0.1
JPEG 2000 80/100
0.36
JPEG 2000 60/100
0.15
JPEG 2000 55/100
0.11
JPEG 2000 50/100
0.07
JPEG 2000 45/100
0.06
- Если вы примените сжатие JPEG с качеством 50 процентов, умножьте значение из шага 5 на фактор сжатия 0,1.
7.67 MB * 0.1 = 0.77 MB
- Увеличьте допуск переполнения СУБД и число целочисленных столбцов таблицы растровых блоков. Значение, полученное в шаге 7, является оценкой объема дискового пространства, требующегося для хранения данных пикселов в таблице растровых блоков. Пикселы разделяются на блоки в зависимости от размера листа, который задается при создании растрового объекта. Эти блоки пикселов хранятся в блоках данных базы данных. Растровые блоки могут не точно соответствовать блокам данных из-за различий при сжатии. Поэтому, некоторое количество места в блоках данных может оставаться неиспользованным. Кроме того, таблица растровых блоков также содержит четыре столбца целочисленных значений и столбец BLOB, для уникальной идентификации каждого блока. Столбцы целочисленных значений также требуют места для хранения. Поэтому, увеличьте объем, полученный в шаге 7, как минимум, на 10 процентов.
Выделение области хранения в СУБД
Способ создания области хранения в СУБД зависит от того, как вы хотите ею управлять. Некоторые СУБД позволяют перемещать файлы с данными базы, поэтому, может потребоваться разместить все растровые таблицы и индексы в одной области. Если вам требуется возможность перемещения данных, создайте область хранения в зависимости от размера данных: выделите большую область для таблицы блоков, а меньшие используйте для хранения других растровых таблиц и их индексов.
Некоторые СУБД позволяют автоматически увеличивать область хранения; однако, следует все же выделить область хранения заранее, чтобы не испытывать проблем во время загрузки. Как только вы решите задачу оценки требуемого пространства, вы можете приступить к выделению места для данных.
Создание области хранения в СУБД Oracle
- Создать область таблицы нерастровых блоков.
create tablespace earth datafile 'd:\oradata\earth.dbf' size 500M extent management local uniform size 1M;
- Создать область таблицы нерастровых блоков.
create tablespace earth_blocks datafile 'e:\oradata\earth_blocks.dbf' size 50000M extent management local segment space management manual uniform size 100M;
Создание области хранения в СУБД SQL Server
- Создайте базу данных SQL Server, достаточно большую для размещения всего растрового объекта.
Создание области хранения в СУБД DB2
- Создать область таблицы, в которой будут храниться все данные нерастровых блоков.
create tablespace earth managed by database using (file 'd:\earth.dat' 500000);
- Создать область таблицы, в которой будут храниться все табличные данные нерастровых блоков.
create long tablespace earth_blocks managed by database using (file 'e:\earth_blocks.dat' 50000000);
Создание области хранения в СУБД Informix
- Создать dbspace для хранения всех таблиц нерастровых блоков.
onspaces -c -d earth -p d:\earth.dbs -o 0 -s 5000
- Создайте пространства базы данных для хранения таблицы блоков растров.
onspaces -c -d earth_blocks -p e:\earth_blocks.dbs -o 0 -s 50000000
Конфигурирование ключевых слов DBTUNE
Таблица SDE.DBTUNE содержит параметры хранения, используемые ArcSDE для создания таблиц и индексов внутри базы данных. Параметры хранения организованы в виде ключевых слов. Указав ключевое слово DBTUNE во время создания объекта базы геоданных, такого как растр, вы задаете параметры создания таблиц и индексов объекта базы геоданных, а также определяете, в каких блоках памяти базы данных они будут храниться.
Для каждой комбинации таблиц и индексов растра существует свой параметр хранения DBTUNE. Вы можете отредактировать таблицу DBTUNE, введя в нее новое ключевое слово и соответствующие спецификации для каждого параметра. Примеры ключевых слов показаны ниже.
Как редактировать содержание таблицы DBTUNE
В зависимости от СУБД, параметры хранения могут отличаться. 11 параметров хранения Oracle DBTUNE перечислены ниже; однако, многие из них соответствуют параметрам других СУБД.
- Параметром хранения для бизнес-таблицы является B_STORAGE, и, если бизнес-таблица имеет столбец ID зарегистрированных строк ArcSDE, его параметром является B_INDEX_ROWID. Бизнес-таблица набора растровых данных содержит одну строку, поэтому она очень мала. Бизнес-таблица каталога растров обычно также мала, поскольку содержит одну строку для каждого набора растровых данных.
Примеры параметров хранения B_STORAGE и B_INDEX_ROWID:
B_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" B_INDEX_ROWID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
- За хранение растровой таблицы отвечает параметр RAS_STORAGE, а за raster_id index в этой таблице отвечает параметр RAS_INDEX_ID. Растровая таблица набора растровых данных содержит только одну строку. Растровая таблица каталога растров обычно также невелика, поскольку содержит одну строку для каждого набора растровых данных.
Примеры параметров хранения RAS_STORAGE и RAS_INDEX_ID:
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
- Таблица каналов растра хранится в соответствии с параметром BND_STORAGE. Параметр BND_INDEX_ID отвечает за rasterband_id index, а BND_INDEX_COMPOSITE управляет хранением составного индекса в столбцах sequence_nbr и raster_id. Таблица каналов растра обычно невелика, и лишь чуть больше, чем растровая или бизнес-таблица растрового объекта. В ней хранится по одной строке для каждого канала растра. Таблица каталога растров, содержащего 1.000 трехканальных наборов растровых данных, будет иметь 3.000 записей.
Примеры параметров хранения BND_STORAGE, BND_INDEX_COMPOSITE и BND_INDEX_ID:
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
- Параметр хранения AUX_STORAGE отвечает за хранение вспомогательных таблиц растра, а параметр AUX_INDEX_COMPOSITE используется для составного индекса таблицы. Число записей в таблице вспомогательных файлов растра может различаться, в зависимости от дополнительных данных по каналам растра. Для повышения производительности, маска битов NoData хранятся для каждого растрового канала, но только если их объем не превышает 10 Мб; иначе, они отбрасываются и ArcSDE должен считывать маску битов NoData из блоков пикселов, хранящихся в таблице растровых блоков. К вспомогательным данным также относится статистика, если она была вычислена, и, если есть, цветовая карта. Возможно, что таблица дополнительных данных растра конкретного растрового объекта, может оказаться пустой, а иногда, она может содержать больше записей, чем таблица растровых каналов. Обычно, ее размер соответствует размеру таблицы растровых каналов.
Примеры параметров AUX_STORAGE и AUX_INDEX_COMPOSITE:
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH" AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
- Параметр BLK_STORAGE отвечает за хранение таблицы растровых блоков, самой большой таблицы растрового объекта. Таблица растровых блоков хранит данные пикселов в соответствии с размером листа, заданным при создании растрового объекта. BLK_INDEX_COMPOSITE управляет хранением составного индекса таблицы растровых блоков, который используется для индексирования четырех целочисленных столбцов: rasterband_id, row_nbr, col_nbr и rrd_factor. Таблица растровых блоков приблизительно в 150 раз больше, чем ее индекс. Однако, поскольку таблица растровых блоков может быть очень велика, удобно хранить ее индекс в том же самом табличном пространстве.
Примеры параметров хранения BLK_STORAGE и BLK_INDEX_COMPOSITE:
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE (INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE)" BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS"
Векторные отпечатки набора растровых данных и каталога растров хранятся в пространственном столбце. Если пространственный столбец создан как бинарный тип ArcSDE, вам потребуется сконфигурировать следующие параметры хранения DBTUNE:
- S_STORAGE – Таблица пространственного индекса
- S_INDEX_ALL – Индекс покрытия, в котором указаны все столбцы таблицы пространственного индекса
- S_INDEX_SP_FID – Столбец fid пространственной таблицы
Примеры написания ключевого слова DBTUNE в файле DBTUNE для каждой СУБД показаны ниже. Знак двойной решетки (##) означает начало ключевого слова EARTH DBTUNE, END означает его завершение.
Пример ключевых слов DBTUNE для SQL Server
##EARTH_15M
B_CLUSTER_ROWID 0
B_CLUSTER_SHAPE 1
B_CLUSTER_RASTER 0
B_INDEX_ROWID "WITH FILLFACTOR = 100"
B_INDEX_SHAPE "WITH FILLFACTOR = 100"
B_INDEX_RASTER "WITH FILLFACTOR = 100"
B_STORAGE ""
B_TEXT_IN_ROW 256
RAS_STORAGE ""
RAS_CLUSTER_ID 1
RAS_INDEX_ID "WITH FILLFACTOR = 100"
BND_STORAGE ""
BND_CLUSTER_ID 0
BND_INDEX_ID "WITH FILLFACTOR = 100"
BND_CLUSTER_COMPOSITE 0
BND_INDEX_COMPOSITE "WITH FILLFACTOR = 100"
AUX_STORAGE ""
AUX_CLUSTER_COMPOSITE 1
AUX_INDEX_COMPOSITE "WITH FILLFACTOR = 100"
BLK_STORAGE ""
BLK_CLUSTER_COMPOSITE 1
BLK_INDEX_COMPOSITE "WITH FILLFACTOR = 100"
END
Пример ключевых слов DBTUNE для Oracle
##EARTH_15M
RAS_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
RAS_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BND_INDEX_ID "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
AUX_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH"
BLK_STORAGE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS STORAGE
(INITIAL 500M MINEXTENTS 10) LOB( BLOCK_DATA) STORE AS (ENABLE
STORAGE IN ROW CHUNK 8K RETENTION CACHE)"
BLK_INDEX_COMPOSITE "PCTFREE 0 INITRANS 4 TABLESPACE EARTH_BLOCKS"
UI_TEXT""
END
Пример ключевых слов DBTUNE для DB2
##EARTH_15M
AUX_STORAGE "IN EARTH INDEX IN EARTH"
BLK_STORAGE "IN EARTH INDEX IN EARTH LONG IN EARTH_BLOCKS"
BND_STORAGE "IN EARTH INDEX IN EARTH"
RAS_STORAGE "IN EARTH INDEX IN EARTH"
END
Пример ключевых слов DBTUNE для Informix
##EARTH_15M
RAS_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"
RAS_INDEX_ID "FILLFACTOR 90 IN EARTH"
BND_STORAGE EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"
BND_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"
BND_INDEX_ID "FILLFACTOR 90 IN EARTH"
AUX_STORAGE "EXTENT SIZE 16 NEXT SIZE 16 LOCK MODE ROW IN EARTH"
AUX_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"
BLK_STORAGE "EXTENT SIZE 1000 NEXT SIZE 1000 LOCK MODE ROW IN EARTH_BLOCKS"
BLK_INDEX_COMPOSITE "FILLFACTOR 90 IN EARTH"
END
Подготовка исходных данных
Разместите исходные файлы набора растровых данных на диске, доступном для ArcCatalog или для скриптов ArcObjects, которые используются для загрузки данных в базу.
CD или DVD
Если наборы растровых данных находятся на CD или DVD, перепишите их на быстрый жесткий диск. Лучше использовать локальные, а не сетевые, жесткие диски. Загрузка файлов с CD или DVD не рекомендуется, поскольку скорость доступа к данным в этом случае будет существенно ниже.
Ленточный накопитель
Если вы загружаете данные с ленточного накопителя, файлы наборов растровых данных, перед началом загрузки в базу, следует поместить в кэш.
Организация исходных данных
Файлы изображений следует сгруппировать вместе, в отдельные папки для каждого этапа загрузки. Это позволит инструменту загрузки открыть все файлы, находящиеся в папке, и выполнить пакетную загрузку, вместо загрузки каждого файла по отдельности. Например, вы можете сделать мозаику из нескольких наборов растровых данных, загрузить каждый набор данных в отдельный растровый набор; сгруппировать наборы растровых данных в каталог растров; или создать каталог растров, используя уже собранные мозаики наборов растровых данных. Операционные системы могут иметь различные ограничения по числу одновременно открытых файлов. Поэтому, если вы столкнетесь с этим ограничением, вам потребуется создать дополнительные папки и перезапустить процесс загрузки.
Применение проецирования к исходным данным
Есть два основных способа проецирования растровых данных. Вы можете применить проекцию, создав копию исходных файлов изображений, или использовать проецирование при загрузке файлов изображений в базу геоданных.
На практике, лучше всего создать копию данных с нужной проекцией, а затем загрузить эти данные в базу геоданных. Проецирование исходных файлов во время загрузки может быть несколько быстрее, чем создание промежуточной копии проецированных данных. Однако, если вы планируете использовать несколько параллельных процессов для загрузки большого количества наборов растровых данных, лучше предварительно завершить проецирование исходных наборов растровых данных на клиентском месте, и только после этого загружать их на сервер. Проецирование данных одновременно с загрузкой их на сервер может потребовать значительного времени и ресурсов. Запустив множество процессов создания исходных проецированных файлов растров, одновременно с несколькими процессами загрузки готовых, проецированных файлов в базу геоданных, вы сможете рационально использовать ресурсы клиентского и серверного компьютеров. Это позволит избежать периодических простоев сервера, сменяющихся всплесками активности на грани вычислительной мощности.
Создание объекта растра и загрузка растровых данных
Если вам не требуется просто загрузить множество отдельных наборов данных, рекомендуется создать каталог растров или мозаичный набор растровых данных, содержащий все растры, которые вы загружаете. Однако, в любом случае, следует учесть свойства наборов растровых данных, которые вы загружаете, и свойства, которые эти данные получат после загрузки.
Возможно, вы уже задали эти свойства ранее, при оценке требуемого дискового пространства или при выделении области хранения. Или, вы уже отредактировали dbtune, чтобы задать ключевое слово, определяющее все параметры хранения. Если нет, необходимо задать эти параметры на этом этапе.
О свойствах набора растровых данных
Существуют четыре настройки растра базы геоданных, которые необходимо учитывать: пирамидные слои, статистика растра, сжатие и размер листа.
Пирамидные слои влияют на скорость отображения.
Более подробно о пирамидных слоях растра
Пирамидные слои можно построить во время создания мозаики растровых данных, или их можно построить после завершения загрузки в базу данных. Построение пирамидных слоев после завершения мозаики – самый быстрый метод. ArcGIS может выполнять частичное перестроение пирамидных слоев, что позволяет, при обновлении отдельных фрагментов мозаики, перестраивать только ту часть пирамид, которая соответствует обновленным исходных данным. Это помогает при обновлении мозаичного набора растровых данных, поскольку отпадает необходимость перестроения пирамид при добавлении нового набора растровых данных. Однако, если вы обновляете данные в начальной точке набора растровых данных (точка привязки пирамиды), пирамидные слои всего набора растровых данных придется перестроить.
Начало отсчета набора растровых данных – крайняя верхняя левая координата. Построение пирамидных слоев начинается с этой точки и продолжается вправо и вниз. Добавление в мозаику данных, расположенных левее и выше начальной точки заставляет ArcSDE сместить эту точку. Смещение начальной точки требует перестроения пирамидных слоев. Перестроение пирамидных слоев требует больших вычислительных ресурсов, особенно, если набор растровых данных создан методом мозаики из большого числа исходных растров.
Поскольку перестроение пирамид требует большого количества времени, с помощью анализа исходных данных следует определить верхнюю левую координату набора растровых данных, и явно задать ее при создании набора растровых данных. ArcSDE позволяет задать точку привязки пирамид при создании растрового объекта, вместо того, чтобы использовать верхнюю левую координату первого загруженного набора растровых данных. Поэтому можно избежать сдвига точки привязки и последующего перестроения пирамидных слоев, сразу задав эту точку при создании набора растров.
Для выполнения некоторых операций геообработки или определенных задач в ArcMap или ArcCatalog, таких как растяжка контраста или классификация данных, требуется статистика.
Более подробно о статистике растра
Сжатие зависит от типа растровых данных и планов по их использованию.
Более подробно о сжатии растров
Для хранения, ArcSDE разделяет наборы растровых данных на листы. Каждый лист хранится в виде бинарных данных в таблице хранения растров. Если используется многоканальный набор растровых данных, пикселы совпадающих растровых блоков из различных каналов хранятся в собственных строках таблицы.
Разделение наборов растровых данных на листы увеличивает производительность. Например, если вы увеличили изображение небольшой области, состоящей только из четырех листов, ArcSDE должен извлечь всего четыре строки из таблицы растровых блоков. Без разделения на листы, ArcSDE был бы вынужден считать весь набор растровых данных.
Размер листа рассматривается как число строк и столбцов, из которого он состоит. Например, размер листа 128 на 128 означает 128 пикселов на 128 пикселов. Чем больше лист, тем больше поле BLOB, при этом количество строк в таблице меньше, маленькие листы имеют небольшое поле BLOB, но число строк в таблице становится больше. По умолчанию используется размер ячейки 128 на 128 пикселов. Если загружаемые данные не имеют трех цветовых каналов, изменение размера листа может сократить объем требуемого пространства для хранения, т.к. при этом блоки данных базы могут использоваться более эффективно. Чтобы определить наилучший размер листа, требуется провести контрольные измерения с использованием репрезентативных растров. В общем виде, чем больше размер листа, тем выше степень сжатия, и тем меньше места занимает сжатый лист в базе данных.
Вы можете создать растровые объекты с помощью инструментов геообработки (например, в ArcCatalog), с помощью команды sderaster, или используя ArcObjects. Растровые объекты, созданные с помощью инструментов геообработки не содержат данных; они содержат все необходимые параметры, но данные пикселов в них отсутствуют, тем не менее, они распознаются базой геоданных. Чтобы создать набор растровых данных, см. раздел Создание пустого набора растровых данных в базе геоданных ArcSDE. Чтобы создать каталог растров, см. раздел Создание каталога растров в базе геоданных ArcSDE.
Растры, созданные с помощью команды sderasters всегда содержат данные пикселов. Тем не менее, они не распознаются базой геоданных; они не имеют столбца векторного отпечатка; а для выполнения мозаики их необходим точный файл привязки. Более подробную информацию о создании растров с помощью ArcObjects см. в разделе Esri Developer Network, примеры растровых данных, которые вы можете скачать и отредактировать, находятся на сайте Code Exchange. Например, вы можете сделать копию примера Create Geodatabase Raster Dataset, а затем изменить его, чтобы создать новый, отдельный набор растровых данных. Примеры Mosaic Rasters In A Directory and Subdirectories To An ArcSDE Raster позволят вам получить образец для построения отдельного мозаичного набора растровых данных из нескольких исходных наборов данных, расположенных в одной папке. Каталог растров можно создать, используя образец Create Geodatabase Raster Catalog. Вы можете совместить этот пример с примером Loading Raster Datasets In A Workspace To A GDB Raster Catalog, который позволяет разместить исходные наборы растровых данных в каталоге растров.
Хотя использование ArcObjects требует навыков работы с исходным кодом, этот способ имеет следующие преимущества:
- Вы можете использовать ссылку на папку, в которой хранится большое количество исходных файлов растровых данных, что позволяет не указывать каждый растр в отдельности
- Возможность настройки обработки исключений, например, поврежденных исходных файлов
Растровые данные можно загрузить в базу геоданных несколькими способами: с помощью варианта контекстного меню базы геоданных Импорт наборов растровых данных (Import raster datasets), с помощью инструмента геообработки Копировать растр (Copy Raster) (инструмента геообработки) или варианта контекстного меню набора данных ArcCatalog Загрузка данных (Load Data). Более подробно о загрузке растровых данных в базу геоданных см. в Импорт наборов растровых данных.
Более подробно о загрузке растровых данных с помощью sderaster, см. в Загрузка растров в ArcSDE с помощью sderaster.
Построение статистики
Построение статистики СУБД и растра может улучшить скорость и качество отображения растровых данных.
Построение статистики СУБД не является обязательным; однако, все СУБД, поддерживаемые ArcSDE, используют стоимостную оптимизацию. Стоимостная оптимизация использует статистику объектов СУБД для определения наилучшего плана выполнения задачи. SQL Server вычисляет статистику автоматически, при загрузке данных, для всех остальных СУБД, статистику следует построить вручную.
Чтобы построить статистику СУБД с помощью ArcCatalog, сделайте следующее:
- Щёлкните растровый объект правой кнопкой мыши и выберите Анализировать (Analyze).
- Убедитесь, что в диалоговом окне Анализ компонентов выбран компонент Таблица растра.
- Нажмите OK.
Также, для создания статистики вы можете использовать команду sdetable update_dbms_stats, как показано на следующем примере:
c:\>sdetable -o update_dbms_stats -t earth -m estimate -u mark -p mark -i 9000
Ниже приведен пример команды Oracle, с помощью которой можно быстро вычислить статистику таблицы блоков:
SQL> select rastercolumn_id from sde.raster_columns
where table_name = 'EARTH';
RASTERCOLUMN_ID
-----------------------
1
SQL> EXEC DBMS_STATS.GATHER_TABLE_STATS(NULL, 'SDE)BLK_1; NULL, 1);Для наборов растровых данных может вычисляться статистика растра, которая хранится в таблице ArcSDE AUX. Статистика растра содержит минимальное, максимальное и среднее значения, а также стандартное отклонение. Вычисление статистики растра на базовом уровне пирамидных слоев может потребовать значительного времени для очень больших наборов растровых данных.
Статистика растра необходима для данных, которые должны быть математически обработаны для того, чтобы объекты, содержащиеся в растре, можно было увидеть.
Более подробно о построении статистики растра см. Статистика набора растровых данных.
Просмотр растровых данных
Просмотр растровых данных осуществляется в приложениях, для которых они предназначены, в таких как ArcMap, ArcCatalog, ArcGlobe или ArcScene. Если статистика СУБД и пирамидные слои построены, растры отображаются быстро.
Если данные отображаются медленно, чаще всего это вызвано либо наличием устаревшей статистики СУБД, либо её отсутствием. Особенно важно наличие статистики СУБД для таблицы блоков. Инструкции по построению статистики СУБД даны в предыдущем разделе, Построение статистики.
С появлением функции частичного построения пирамидных слоев, стал возможным просмотр набора растровых данных во время построения мозаики. Однако, если вы просматриваете набор растровых данных во время построения мозаики, изображение с пониженным разрешением может периодически исчезать и появляться вновь. Такое поведение является следствием частичного построения пирамид, при котором происходит удаление и повторное создание верхних уровней пирамидных слоев.