Posts Tagged ‘объем данных’

Рост объема хранилища

Вторник, Март 24th, 2009

Ржаксинский Андрей

С ростом объема проекта, увеличением числа сущностей в системе, растет объем хранения. Уже никого не удивить хранилищами в 1-2-3-5 Тб.  Но эти терабайты – не всегда показательны. Хранилище может расти, раздуваться по иным причинам.  Попробую оценить, куда девается табличное место, как избежать чрезмерного роста БД.

Нижний уровень – уровень ABAP. Представим, что данные предварительно грузятся не в само хранилище, а в набор таблиц на нижнем уровне системы, ABAP самописный слой.  Данные грузятся из различных источников, размечаются, приводятся к единым нотациям.  И уже на этих данных сверху надстроены экстракторы для выгрузки в BW. Приведу небольшую табличку соответствия типов ABAP словаря и БД Oracle:

ABAP Oracle
INT1 NUMBER 3
INT2 NUMBER 5
INT4 NUMBER 10
FLTP FLOAT
DEC 17 2 NUMBER 17 2
NUMC 10 VARCHAR2 30
DATS VARCHAR2 24
CHAR 100 VARCHAR2 300
SSTRING 100 VARCHAR2 300
STRING 300 CLOB
STRING CLOB
LCHR 300 VARCHAR2 900

Как видно – типы для хранения числовых величин достаточно компактны. Все sid и dim в кубах построены на основе INT4. Занимает мало места и работает быстро.
Кроме типа numeric – это по сути строка.

Теперь обратим внимание на строки. Здесь ситуация грустная.  Для хранения строки с фиксированной длиной необходимо отвести места в 3 раза больше её максимальной длины. Это связано с кодированием данных SAP под unicode, где, по стандарту они могут занимать 2-4 байта ни символ. По всей видимости это связано с настройкой конкретной инстанции SAP. К примеру, если назначение платежа в документе может быть максимум 180 символов, то в таблице необходимо зарезервировать 540 байт. А реально будет использоваться где-то 25-50% места, т.к. назначение платежа обычно намного короче.

Если же использовать тип STRING с переменной длиной, то в oracle они преобразуется в CLOB, который не позволяет удобно работать в SQL с этими данными. Эти строки выделены в таблице жирным шрифтом. Чтобы анализировать содержимое, необходимо полностью извлекать объект в программу и там уже работать с ним.   Всё описанное – больше неудобство, чем проблема, но всё же.

Загружаем данные

Записи о неких документах приходят в CSV файле c разделителем.  И заказчик говорит – у меня 1 Гб таких данных. Сколько дискового места необходимо отвести под загрузку этих данных?

Структура полей самая минимальная:

  1. номер документа INT
  2. дата datum
  3. счет дебета char 20
  4. счет кредита char 20
  5. назначение платежа char 100
  6. сумма dec 17.2

Попытаемся примерно посчитать занимаемое место и вывести коэффициент-мультипликатор для начальной загрузки такого типа данных. Подсчет грубый и не будет учитывать журналов, логов и проч. Только ABAP и BW.

Предположим, что в хранилище мы грузим эти документы из таблицы словаря ABAP через экстрактор и PSA в DSO объект.

Анализируем исходные файлы.  Длина записи, с учетом разделителя может быть в среднем 120 байт, максимальная 180. Итого 1 Гб/120 = 9 милл записей.

Грузим файлы в словарь ABAP.  Каждая запись будет примерно занимать 10 + 30 + 60 + 60 + 300 + 8 = 468 байт, без учета индексов и прочего.

Сделали экстрактор и запись легла в PSA – значит еще 468 байт на запись.

Сделали трансформацию и запись пришла в DSO. Здесь запись будет лежать в журнале и в активных(неактивных данных).

Итого 1*ABAP + 1*PSA + 2*DSO – начальная загрузка потребует учетверения записи в системе. А значит – 4*468 = 1872 байта.  При средней длине записи в CSV файле в 120 байт значение мультипликатора составит  1872 / 120 = 15,6.

Разумеется, PSA со временем очистится. Журнал DSO можно удалить, на уровне ABAP данные можно не хранить, но всё равно, для загрузки 1 Гб данных в системе должно быть свободно минимум 15,6 Гб в таблспейсах для данных. И,  после всех выверок и очисток избыточных данных, объем хранения можно будет сократить до 3,9 Гб.  Такие мультипликаторы объема возникают из-за специфичности как самого SAP так и из идеологии БД. Не стоит забывать, что длинные тексты надо резать по 60 символов и ложить в разные инфо-объекты. Это одно из неудобств, но быстро привыкаешь.

В реальных системах  в день может прийти несколько миллионов документов. Вот и посчитайте месячный рост.  Поэтому терабайты – это уже не достижение, а грустная реальность в современных BI системах.