Update 3. 8 Мая. Я готов признаться в провокации -) Мне было интересно, что напишут люди отвечающие за продажи продукта, насколько они понимают архитектуру решения, ее баланс. Коротко, я стал атаковать утверждение, что базы данных целиком будут сжиматься в 10 раз.
Короткий ответ на провокацию должен бы быть такой: "это не важно, в 10 или в 8, или в 4. У нас есть только 3 варианта: 45 Tb, 22 Tb, 9 Tb и ты обязательно поместишься в один из них. После того как ты поместишься в один из вариантов мы сожмем несколько важных таблиц для увеличения скорости критических бизнес отчетов, но так, чтобы не убить процессоры для остальных задач. Насколько мы сожмем зависит от природы данных конкретной таблицы и характера твоего приложения. Нужно будет посильнее - отсортируем. Пока можешь оценить сам с помощью dbms_advisor.". Точка. Ну если я купил 9 Tb ну нахрена мне держать там пережатым 1Tb и ждать пока они декомпрессуются если у меня есть еще 8 ? Что там, картошку хранить ? Ну конечно же лучше пожать что-то сильнее, что -послабее чтобы был лучше баланс между IO и CPU. Размер БД когда есть всего 3 варианта поставки вообще не важен - никакой экономии вы не получите все равно. Но для этого надо знать архитектуру, лицензирование и прочее...
Вместо этого, началось доказательство что обязательно в 10 раз, что точно и ни разом меньше, но обещать не можем. В довершении в лучших традициях перешли на личности. Это значит, что если в проекте с вами не получится в 10 раз, или вы не дай бог начнете задавать вопросы - то вы узнаете о себе много нового. Подумайте об этом -)
------------------------------------------------------------------------------------------------------------------------
Берем пост
про миграцию на Tukcell.
Читаем презентацию. Видим, что с 250 Tb база стала 25 Tb. Т.е. в Hybrid Columnar Compression сжала БД в 10 раз. Аплодисменты. Шампанское. Выпив, я рассудил трезво:
в презентации находим ссылку на
блог. Смотрим на табличку, понимаем что сортировать таблицу перед компрессией все таки не слишком честно, делим 137/21 получаем ~ 6.5. Отличный результат, между прочим, OLTP Compression дает примерно 2-3.
Я решил заняться пересчетом коэффициентов потому что вчера послушал
специальный Webcast про Hybrid Columnar Compression. В нем приводятся коэффициенты от 4-х до 6. При этом если почитать презентацию станет понятно что использовали они в production for archive low, т.е. 4.3. Также Real Customer Case между прочим.
Кстати, вы можете использовать advisor compression и без Exadata чтобы получить оценки. Как вы видите, он хотят и занижает результат, но в принципе дает очень близкий. Вот что я делал еще давно -
взял TPC-H схему и попробовал advisor. Получил примерно ~ 5 раз.
Видно, что очень зависит HCC компрессия от природы данных, от того захотите ли вы их сортировать каждый месяц или нет. Что точно неправильно - это рассчитывать что ВСЯ БД будет сжата во сколько-то раз на постоянной основе. Возможно если у Вас есть бесконечно много времени вы и вправду будете переезжать на Exadata сортируя данные. В презентации есть детали, 36 часов им понадобилось на основные 40 Tb, переливали они их с помощью pl/sql процедур, но сортировали они их или нет и когда - не ясно -(. Понятно что остальные 60 Tb им тоже пришлось переливать когда-то. Я уверен что Сергей Данилов выкрутиться и в этот раз, просто интересно как -))))
PS Чего нельзя отнять - так это то что турки молодцы. Все таки они клево пробились, переливать такие объемы вручную (pl/sql процедуры) - это сильно по ковбоиски ...
Update 1. 07 Мая
Я сделал скринщот оригинального поста про Туркселл:
Всем видно что написано "Технология HCC сжала данные в 10 раз "? Теперь в комментариях (там треш) читайте как следует на самом деле это понимать -))))
Правда заключается в том, что у турков
было 100 Tb (сжатых компрессией 10g, стр 3 презентации), они
перевели на Exadata 90 Tb (стр 11 презентации), для улучшения компрессии они сортировали данные в момент перелива,
получили 25 Tb.
90 / 25 каждый делит для себя сам.
Теперь пояснение для чего я это написал изначально - приходят заказчики, которым уже пообещали, что их
базы будут сжаты в 10 раз. Так как заказчик всегда прав, то теперь у вас есть возможность решить так это или нет.
Сергей Данилов знает о компрессии примерно столько же, сколько о жизни на Луне :^) Сергей Данилов объясняет бизнесу как вон тот ящик сделает бизнес качественнее, поэтому Сергей Данилов срезает технические углы. Нет ничего проще, чем аппелировать к технической неточности в словах Сергея Данилова. Это "как два байта переслать" :^)
Читаем что пишет сам Ферхат в своем техническом документе. Это данные от человека, который сделал проект своими руками.
. Там также отдельно выделена эффективность технологии сжатия: ~7-10х. Метрика 10x при переезде на Exadata была реально достигнута (как совершенно правильно пишет Ферхат, "при помощи HCC"). И аппелировать к неточностям надо в материале Ферхата, а не Сергея Данилова.
Под Oracle сжатие 10х никак, я повторюсь, никак не достижимо без Exadata.
В компании Форс, Партнерской Академии закончился семинар под кодовым названием 'RAC is Simple'. Семинар идет 3 дня и содержит помимо теоретической части 12 (!) лабораторных работ. Ведет семинар независимый консультант Дмитрий Кучугуров, который уже проводил серию из трех семинаров RAC: от мифов к реальности около двух лет назад.
Сообщения
