Alexander Ryndin,

Если ответить по существу вопроса :

Alexander Ryndin

Alexander Ryndin
Вот некоторые перлы:
- Data is compressed according to identical columnar values (columnar compression) (человек, не понимая, несет чушью - нет никакой поколоночной компрессии на Netezza, по крайней мере интернет об этом не знает)
- You don't need data modeling on Netezza (да здравствует хоронилище)
- At billions of rows in a table, B-tree index becomes expensive, impacting response time (а мужики то не знают! хотя может это проблема DB2 - они там про partitioning по времени и hash слышали?)




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

Со вторым утверждением я сам не согласен. Я не смотрел ролик, но видимо, автор имел ввиду, что требуется меньше физического моделирования.
В смысле, выбора типов таблиц, секционирования, индексов и прочего. В Netezza действительно все максимально упрощено и думать над этим надо гораздо меньше.
От необходимости тщательного логического моделирования никто не избавлял.

С третим утверждением, Вы должны согласиться и сами как Oracle специалист. Скан по B-tree индексу становится неэффективным, если сканировать большое количество строк. Уже процентов с 10-20 строк фул скан может быть эффективнее, даже в Оракле.
Не говоря уже про системы, оптимизированные под full scan. В Netezza реализован "умный" фул скан, с кучей оптимизаций, выполняющихся на специализированном железе.
Кроме того, Вы видели хоть одну shared-nothing систему с B-tree? В Teradata есть нечто похожее - VONUSI, но это все равно не B-tree :)