SAP for Banking: Зростання обсягу сховища, Інші СУБД, Бази даних, статті

Ржаксінскій Андрій

sapbanking.org


З ростом обсягу проекту, збільшенням числа сутностей в системі, зростає обсяг зберігання. Вже нікого не здивувати сховищами в 1-2-3-5 Тб. Але ці терабайти – не завжди показові. Сховище може рости, роздуватися з інших причин. Спробую оцінити, куди дівається табличне місце, як уникнути надмірного зростання БД.


SAP Нижній рівень – рівень 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 байта ні символ. Наприклад, якщо призначення платежу в документі може бути максимум 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-системах.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*