Распределение таблиц между областями хранения
Распределение таблиц между областями хранения
После того, как мы узнали про оптимальное количество записей в блоке, пришло время поговорить о размещении таблиц в областях хранения. При распределении обычно руководствуются следующими мотивами:
- возможность управлять операциями ввода/вывода (т.е. нагрузкой на дисковую подсистему)
- соответствовать требованиям приложения
- желание ускорить «тяжелые» офф-лайновые утилиты для обслуживания БД
Пока еще не все утилиты для обслуживания БД OpenEdge могут быть запущены в онлайне, но их число увеличивается с каждой версией.
Другой критерий при выносе таблицы в отдельную область — оценка активностей по записи и по чтению. Если таблица растет линейно и используется индекс по первичному ключу таблицы,то большинство чтений из неё происходит в последовательном порядке по этому индексу. При изолировании этой таблицы в другую область можно добиться некоторого прироста производительности. Если эта таблица — большая, то прирост будет значительный.
Улучшения производительности мы добиваемся по двум причинам:
- Чтение одной записи извлекает на самом деле не одну, а множество записей из базы данных. Вероятность того, что эти извлеченные записи будут запрошены следующими операциями чтения будет высока. Таким образом, мы увеличиваем показатель попадания в буферный пул БД (buffer hit)
- Большое количество дисковых систем обладают возможностью упреждающего чтения, т.е. следующие блоки файловой системы поднимаются в кэш дискового устройства. При этом скорость последовательного чтения из БД сильно возрастает.
И последнее — данные в базе неоднородны с точки зрения требований к производительности. Например, доступ к данным о складских запасах происходит очень часто и критичен по времени, а записи, содержащие комментарии пользователей к каким-либо сущностям — обновляются или читаются из базы относительно редко. Мы можем поместить области с критичными таблицами на «быстрые» дисковые устройства. Для такого подхода требуется исследование работы приложения. Увидеть активности таблиц можно в OpenEdge Management или в виртуальных системных таблицах (VST — Virtual System Tables). В OE Management активности видно по временной оси — это позволяет лучше всего вникнуть в происходящее.
Целями сбора такой информации являются
- Больший контроль над данными
- Ускорение оффлайновых утилит
- Максимальная эффективность по размещению записей без каких-либо серьезных затрат
Вычисления, которые мы делали в предыдущем разделе, определяли количество записей на блок в области. При размещении таблицы в области могут возникнуть вопросы. Например, что делать, если область имеет RPB меньший, чем средний размер записи в таблице или больший (что может вызвать фрагментацию).
Рассмотрим такую ситуацию на примере.
Пример.
Допустим, у нас есть таблица в БД, в таблице — 1 миллион записей. Средний размер записи — 41 байт.
1. добавим служебную информацию к этому числу (примерно 20 байт)
2. разделим размер блока БД на полученное число
Теперь необходимо принять решение. Нам надо выбрать число от 1 до 256, являющееся степенью двойки. Получившееся значение 134 предполагает выбор между 128 и 256. Если мы выберем 128, то исчерпаем слоты для записей прежде чем закончится место в блоке. То есть, в каждом блоке у нас будет неиспользуемое пространство. При выборе 256 мы рискуем тем, что записи будут фрагментированы. Присмотримся к записям в таблице пристальней. Если записи в таблице активно изменяются, то мы должны выбрать меньшее число для RPB (128) — тем самым мы избегнем фрагментации. Если же записи только добавляются в таблицу и не меняются с течением времени, то нужно выбрать больший номер (256), ведь OpenEdge, как правило не разбивает запись на фрагменты при добавлении её в БД. Фрагментация записи происходит при дальнейшем обновлении, поэтому надо быть внимательным с такими записями — как правило их размер при этом увеличивается.
Если мы выбрали меньшее число RPB, то мы можем определить, сколько места на диске не будет использовано (wasted space)
1. для этого мы возьмем число записей в таблице и разделим на значение RPB. Мы определим число блоков, которые будут выделены для хранения записей.
2. умножим фактический размер записи на RPB. Из размера блока базы данных вычтем полученное значение. Мы определим количество неиспользуемых байт в блоке.
3. общее число блоков умножим на неиспользуемое пространство в блоке
В нашем примере неиспользуемое пространство при выборе меньшего значения RPB почти 3Mb. С точки зрения стоимости дискового пространства — устранение фрагментации записей практически ничего нам не стоит. Однако, для статических записей мы должны были бы выбрать значение RPB равным 256 — в этом случае утилизируются все слоты для записей в блоке и мы получаем больше записей при чтении блока в буферный пул.
Неиспользуемые слоты
Есть и другая сторона медали — если у нас есть неиспользуемые слоты для записей в блоке, то максимальное количество записей в области хранения будет меньше, чем могло бы быть. С введением 64-битного recid в 10.1B ситуация стала не такой сложной, как в предыдущих версиях. Написанное выше не означает, что необходимо стремиться сделать RPB всех областей равным 256 для максимальной плотности записей. Просто необходимо знать, что существуют определенные лимиты и они представлены на таблице ниже. Кроме того, существует способ определить идеальное значение RPB и BPC (blocks per cluster) для области и он будет описан ниже в главе «Определение размера блока».
Таблица приблизительно показывает максимальное количество записей на область хранения
В случае, если таблица маленькая, индексы этих таблиц можно хранить в одной области с таблицами. Для больших таблиц (таблицы, содержащие большое число записей) отделение индексов в другую область необходимо. Этим действием мы серьезно увеличиваем производительность.