Андрей ВыходцевПервое утверждение = правда (Data is compressed according to identical columnar values).
Данные сжимаются по колонкам, но внутри одного экстента (3Мб перед сжатием).
При этом что мне нравится, по сравнению с другими СУБД, что не надо мучительно думать над типом сжатия таблицы или колонки, система сама подбирает сжатие по сэмплу.Можно таки ссылку? Хочется именно про Netezza, а не про DB2

Андрей ВыходцевСсылки на документацию, увы, не будет - так сложилось, что Netezza не публикует столько материалов о своем внутреннем устройстве, сколько Oracle. Для тех кто не верит - продолжайте не верить ;) Для заказчиков мы используем метод убеждения через PoC.И во сколько раз сжимаются данные обычно? Вообще, странно, что доступа к документации нет. Чего скрывать то?
Андрей ВыходцевPost 2008 от Курта Монаша:

http://www.dbms2.com/2008/05/22/netezza-on-compression/
Там есть моменты, которые можно было бы уточнить, но в целом ОК написано.Да вот у него как раз и непонятно. Что такое блок у него?

Андрей ВыходцевAlexander Ryndin,

У Курта в статье много неточностей.
Вся документация есть в открытом доступе. Но про внутреннее устройство компрессии там не написано.

Сжатие на практике у меня бывало от 3х до 11 раз, если смотреть по отдельным таблицам. Среднее число как правило где-то между 4 и 5. Это не намного отличается от среднего значения в Exadata - 4.5 если верить этой ссылке (слайд 24) , а там речь о HC/Advanced Compression.Advanced Compression - это не поколоночное сжатие. На моей личной практике сжатие Exadata именно в HCC (то что в презентации называется HCC – Query и HCC – Archive) от 6 до 20 раз. Среднее я бы оценил как на Query High в 9-10 раз.

Андрей ВыходцевВся документация есть в открытом доступе. Но про внутреннее устройство компрессии там не написано. Вот тогда непонятно, на основе чего вы делаете выводы о "Данные сжимаются по колонкам, но внутри одного экстента (3Мб перед сжатием)". Почему, кстати 3 Мб? Какое-то некруглое с точки зрения IT число.

Если у вас элемент поколоночного сжатия это 3 Мб, то непонятно, почему такое плохое сжатие получается. У Exadata элемент сжатия (compression unit) меньше, а жмет лучше.

Андрей ВыходцевAlexander RyndinВот тогда непонятно, на основе чего вы делаете выводы о "Данные сжимаются по колонкам, но внутри одного экстента (3Мб перед сжатием)". Почему, кстати 3 Мб? Какое-то некруглое с точки зрения IT число.


Александр, делаю такие выводы, потому что работаю в IBM. Андрей, мамой клянетесь? :) Неужели заказчик должен верить всему, что говорит человек, работающий в IBM, и не требовать никаких технических подробностей?

Андрей ВыходцевЕсли можете демонстрировать в пилотах среднее сжатие по базе 9-10 - рад за вас.
Но я если честно, не верю. Даже на слайдах у вас написано HCC Query up to 10x, в связи с чем мне кажется более реалистичная цифра и у вас будет в районе 4-5. Для сайзинга берете цифру 9-10? Сомневаюсь. Если это действительно так, буду говорить заказчикам что Oracle их обманывает предлагая quarter rack под базу 80 TB :) Должно хватить осьмушки?Слайдам я давно не верю. Предпочитаю щупать руками. Так вот на личном опыте в финансах на крупных таблицах у меня была и 6 раз, и 20 раз. 20 раз я видел только на одной таблице. По остальным таблицам было 6-10 раз. В телекомах я видел 6-8 раз на таблицах фактов, на денормализованных "звездочках" 12 раз на query high и 7 раз на query low.

Андрей ВыходцевА если вы посчитаете сжатие по отношению к чистым данным, включая все доп структуры, общий коэффициент будет и того меньше. Какие еще доп структурам? Индексы? Там мы же без них меряем. Кому-то они нужны, кому-то нет. Я уже приводил пример выборки истории по одному customer из 100.000 - там они нужны. На Netezza нет выбора - один черт придется перелопатить всю таблицу (насколько я знаю), а на Exadata - хотите сделаем на full scan, хотите будет индексом, хотите storage index.

Андрей ВыходцевМне кажется, у Вас просто замылен взгляд - Вы видите только Oracle и считаете что это лучшее решение для всего. Я считаю что для сложной аналитики с непредсказуемыми запросами Oracle - далеко не лучшее решение. А я считаю, что вы конкретный вопрос про "поколоночное" сжатие и вопрос про "дорогивизну" b-tree индекса перевели в какие-то теоретические изыскания.

Я задал конкретные вопросы по теме презентации "эксперта":
1) Покажите мне ссылку на документацию Netezza, где написано про поколоночное сжатие и хотя бы на пальцах показано, как оно работает
2) С какого перепуга на Netezza не требуется моделирование
3) Почему на миллиардах строк b-tree становится дорог (пример я привел, где индекс бывает очень полезен)

С 2) вы согласились. По 1) и 3) я слышу весьма неубедительные попытки что-то возразить.

loki1984Alexander Ryndin Advanced Compression - это не поколоночное сжатие. На моей личной практике сжатие Exadata именно в HCC (то что в презентации называется HCC – Query и HCC – Archive) от 6 до 20 раз. Среднее я бы оценил как на Query High в 9-10 раз.

Александр, позволю себе также усомниться в цифре 20. Сможете привести здесь DDL и данные, которые это подтвердят? Это реальный пример, на реальных данных процессинга. Самая крупная таблица ужалась в 20 раз. Остальные хуже - в районе 6-10. DDL привести не смогу - не имею права.

loki1984По поводу рекламы - почти каждый ваш пост реклама oracle, но мы не жалуемся, просто пропускаем.Можно пример привести, где я что-то рекламировал, а не отвечал на чей-то вопрос.

loki1984P.S. а вообще можно открыть тему "недостатки Exadata" и подробно пообщаться на тему - подходит ли Exadata для хранилищ большого объёма, её недостатки перед MPP (teradata, netezza, greenplum, vertica) и стоимость.С удовольствием почитаю. С моей точки зрения Exadata - это некоторый компромисс между MPP и shared storage. Например, real-time хранилище на Exadata делается легко, а на MPP с трудом. Катастрофоустойчивость на Exadata делается легко, а на MPP не очень. Добавить новый узел в Exadata быстро и без простоя легко, в MPP не очень. Производительность нужно смотреть каждый конкретный случай - желательно не абстрактный.

loki1984Есть кейс, когда Exadata в несколько десятков раз стоила дороже выбранного MPP решения. Случаи бывают разные. Кому-то нужен вездеход, кому-то самокат. Всегда нужно сравнивать по комплексу критериев - стоимость поддержки, стоимость внедрения, стоимость оборудования, софта, выполнению критериев по производительности. Не хочу спорить здесь на абстрактные темы и сравнивать коней в вакууме.

В этой теме я задал конкретные вопросы, которые при честном , но достаточно критическом просмотре 40 минутного ролика появились у меня.

loki1984Alexander Ryndinпропущено...
Это реальный пример, на реальных данных процессинга. Самая крупная таблица ужалась в 20 раз. Остальные хуже - в районе 6-10. DDL привести не смогу - не имею права.

Реальный пример на 1-й таблице, ddl которой вы не указываете, данные не приводите. Ну-ну. Там, наверное, был справочник из 2000 одинаковых varchar-ов, который вы сжали в 20! раз, а теперь выдаете это за достижение.Ну так я начал нарушать NDA только лишь бы угодить вам. Таблица реальная, данные реальные. Таблица крупнейшая или одна из Top5 процессинга (я уже не помню), взятая один-в-один из OLTP, т.е. денормализованнная в 3NF, что подразумевает "отсутствие 2000 одинаковых varchar-ов".

Наверное, стоит объяснить как работает поколоночное сжатие в Exadata, чтобы демистифицировать "а как такое вообще возможно".
Oracle берет пачку строк (сотни-тысячи). Эти строки распиливаются - сначала сохраняются все значения первого столбца, потом второго и т.д. Каждый из столбцов жмется одним из стандартных алгоритмов сжатия (bz2, zlib, lzo). Поскольку степень повторяемости данных внутри одной партиции таблицы (партиции по дате и субпартиции по филиалу) может быть очень высокой, то и степень сжатия также может быть очень высокой.

Возвращаясь к моему пример, это был по сути журнал документов, в котором, в частности, были и даты (которые внутрии партиции в столбцах одинаковы), и идентификаторы операторов, вводивших документы. Все это и дало высокую степень сжатия.

loki1984Alexander Ryndinпропущено...
С удовольствием почитаю. С моей точки зрения Exadata - это некоторый компромисс между MPP и shared storage. Например, real-time хранилище на Exadata делается легко, а на MPP с трудом. Катастрофоустойчивость на Exadata делается легко, а на MPP не очень . Добавить новый узел в Exadata быстро и без простоя легко, в MPP не очень. Производительность нужно смотреть каждый конкретный случай - желательно не абстрактный.


Единственный кейс, где Exadata может худо-бедно тягаться с MPP - realtime хранилище с которым вы носитесь из темы в тему..
Вы очень дипломатичны. Exadata при построении real-time хранилищ - это лучше решение, а не "худо-бедно тягается". Это очень легко демонстрируется - достаточно попытаться одновременно писать и читать данные из одной и той же таблицы. Real-Time хранилище ведь подразумевает постоянное обновление данных параллельно с работой пользователей. Не скажу про все - не хочу врать, но встреченные мной MPP системы это блокировочники, а значит либо не умеют одновременное чтение и запись в одну таблицу, либо могут это делать только в "грязном режиме".

loki1984Про катастрофоустойчивость MPP полный бред. Но разубеждать сотрудника Oracle не буду.
Я опять не стану говорить про все MPP, но на той же Teradata это делается как-то так . Т.е. параллельный ETL в 2 системы на разных площадках. За все нужно платить - в том числе и за отсутствие лога операций, который в Oracle позволяет байт-в-байт создавать полную копию на удаленной площадке.
loki1984Про добавление узла - приведите ссылки на документацию, т.к. сомневаюсь, что это правда.Пожалуйста. Exadata состоит из двух типов узлов - вычислительных и storage. И вычислительные , и storage добавляются и удаляются online.

GVF112GVFIvan Durakпропущено...

Greenplum - версионник, наследник postgresa с такой же версионностью.
Кстати скорее всего Netezza тоже версионник - т.к. тоже на базе постгреса сделана.

Если интересует Netezza - No indexes in Netezza, what's up with that?
https://www.ibm.com/developerworks/community/blogs/Netezza/entry/no_indexes_in_netezza_what_s_up_with_that12?lang=ru

PS: Уже существуют технологии, которые скоро смогут заменить B-tree индекс (по причине его
низкой производительности).

С уважением,
Вадим.Маркетинговый булшит. B-Tree индексы, в первую очередь, нужны на OLTP-системах. Как только Netezza сможет работать как OLTP - я сразу же признаю, что они нашли замену B-Tree индексу. Zone Maps, про которые вы рассказываете есть в Netezza с 2011 года, но что-то я не слышал о применении Netezza как OLTP-машины.

Ну и опять таки Zone Maps есть на Exadata (там они называются Storage Indexes). И, о боже, они есть в обычном Oracle . Так что это далеко не только фича MPP.

GVF112GVFА кто Вам сказал что в Netezza используются B-tree индексы или что для OLTP-систем они не используются ?!
Вам сказали, что уже существуют другие технологии построения индексов, которые более эффективные чем B-tree индексы (в том числе и для OLTP-cbcntv) !!!Речь в статье идет про Netezza. И человек пишет, что в Netezza есть Zone Maps, которые успешно заменяют B-Tree индексы, которые суть дьявольское порождение. Так вот они не заменяют B-Tree индексы даже близко, ибо это разные вещи - индексы и анти-индексы.

GVF112GVFЧто ВЫ слышали, например про "Маркетинговый булшит" - Latch Free Hash Index или R-tree индексы ???Ничего не понял из этой фразы. R-Tree индексы - это вообще пространственные индексы. R&D Netezza прочитала про пространственные индексы и таки решило реализовать их? :)
GVF112GVFОтносительно Netezza - там действительно, используется Zone-Maps и Netezza не используется для OLTP-задач.
Но кто сказал, что сейчас не ведеутся в R&D разработки более новых технологий и продвинутых решений ?! .... ;-)Скоро мы все будем более лучше одеваться ;)

GVF112GVF >Ничего не понял из этой фразы. R-Tree индексы - это вообще пространственные индексы. R&D Netezza прочитала про >пространственные индексы и таки решило реализовать их? :)

Это не удивительно.
Вам дали понять, что уже существуют разработки которые превосходят по производительности B-tree индексы
(как Я уже отмечал ... Netezzа, использует другие технологии для быстрого доступа). Поведайте нам, чем R-Tree индексы лучше чем B-Tree индексы, плиз.