`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Дмитрий Гудков

IBM покупает Netezza

+33
голоса

IBM покупает Netezza. Приблизительно за 1.7млрд.долл. или 6.8 годовых продаж, ожидаемых в 2010году, что означает почти 9 оборотов 2009 года - что очень неплохо для акционеров Netezza.

Netezza - производитель программно-аппаратных комплексов для BI-систем и аналитических хранилищ данных, активно эксплуатирующий идею дисковых супер-контроллеров (я о ней писал ранее). Агрессивная ценовая политика, направленная прежде всего против Teradata, хорошая производительность и благосклонные отзывы отраслевых аналитиков позволили  Netezza завоевать сердца и бюджеты 350 заказчиков по всему миру, что с одной стороны в разы меньше чем у классика программно-аппаратных BI/DWH систем Teradata, но с другой стороны - в разы больше чем у ближайших конкурирующих игроков в этой области, если смотреть на pure-play вендоров типа Kognitio.

Если с выгодой Netezza в сделке все более-менее очевидно, то вот зачем IBM купила Netezza не совсем понятно. С одной стороны, очевидно было что долго выдавать свои квази-специализированные Balanced Warehouse за полноценные DWH-appliance нельзя - любому более-менее посвященному было понятно, что это не так. IBM Balanced Warehouse - это по сути стандартные серверы IBM со стандартным ПО Cognos и/или InfoSphere. Вся оптимизация сводилась лишь к хорошо просчитанной конфигурации и грамотной настройке под конкретную задачу. Это конечно дает отдачу, так как хороший расчет железа под BI/DWH решения скорее редкость, чем правило, но далеко не такую как специализированная программно-аппаратная архитектура, где софт и железо намного больше оптимизированы друг для друга. Поэтому с приобретением Netezza IBM получает в свой портфолио настоящий высокопроизводительный DWH-appliance. И это очевидный шаг не сколько против Teradata, сколько против Oracle, агрессивно продвигающей Exadata по своей клиентской аудитории. И шаг наверное сильный - у IBM есть что предложить с точки зрения аппаратной части - недавний выход Power7 и zEnterprize с гибридной архитектурой это только еще раз подтверждают.

А вот с программной частью не все так понятно. Останется ли на Netezza своя СУБД или же она уступит место DB2 в какой-нибудь Appliance Edition? Как насчет колоночной архитектуры СУБД? СУБД Netezza имеет построковое хранение данных - архитектурно это не лучший вариант для OLAP-систем, но он компенсировался специализированной аппаратной частью. Oracle Exadata кроме специализированной аппаратной части имеет пусть и достаточно примитивный, но все-же колоночно-ориентированный движок. Чем IBM ответит на это? IBM до сих пор не имеет своей колоночной СУБД - и покупка например Vertica была бы весьма логичным шагом. Может это просто вопрос времени?

+33
голоса

Напечатать Отправить другу

Читайте также

Дмитрий, а с каких пор Oracle Exadata имеет "колоночно-ориентированный движок"? Может Вы путаете с hybrid-columnar compression - по моему единственное где прослеживается что то "поколоночное"))

Да и MPP архитектуру Netezza сравнивать с shared everything Oracle Exadata по моему не совсем правильно...Это разные подходы и для подобных задач Ораклу пока особо предложить нечего...

Антон, да вот этот самый Exadata Storage я и имею в виду. Он все же худо-бедно но умеет хранить данные в виде групп колонок. Хотя это и не отдельные колонки как в Vertica или Sybase IQ, да и результаты запросов все равно передаются в стандартный движок Oracle, который опять же не способен выполнять операции на по-колоночно компрессированных данных, как это делает Vertica.

PS. Кстати по рынку ходят слухи что Oracle уже пробует делать Vertica предложения о приобретении (http://www.dbms2.com/2010/09/20/ibm-netezza-acquisition/)

Худо-бедно?) Возможно я что то пропустил но что Exadata умеет хранить что-то поколоночно правда слышу впервые.Ссылку в студию!
Я ваще считаю что Exadata хороша как OLTP - но для DWH не очень. И дело тут не в поколоночном или не поколоночном хранении - Teradata тоже пока поколоночно не хранит и ничего.
Дело в том что Oracle остался последним вендором к-му нечего предложить на арене MPP

Вот же ж научились требовать ссылки в студию :) ... вот вам ссылки:

http://www.dbms2.com/2009/09/03/oracle-11g-exadata-hybrid-columnar-compr...

там есть упомнинание о PAX, которая хорошо описывается здесь

http://dbmsmusings.blogspot.com/2009/09/tour-through-hybrid-columnrow-or...

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

Плохо то, что у DB2 нет даже и такого. Если IBM опять прохлопает Vertica, как 2 года назад прохлопала Sun (а главное Java) - будет жаль.

Ну так вот в Оракле это применяется только в случае компрессии что опционально, и на что я указывал с начала дискуссии. Я все равно продолжаю настаивать что Exadata по умолчанию поколоночно ничего не хранит!))

А так же то что на shared everything коим является Exadata толковых хранилищ не построить!

По моему мнению, для построения толкового ХД необходимы толковые люди. И в этом случае опциональность поколоночного сжатия данных в Exadata как раз плюс, а не минус.

По первому тезису вопросов нет, особенно если учесть что необходимо != достаточно.

А вот второй тезис вы не могли бы раскрыть детальнее?

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

Согласен касательно того, что не всем таблицам нужно сжатие. Замечу только что при колоночном хранении есть некоторые алгоритмы которые практически не расходуют процессорного времени на компрессию/декомпрессию. Поэтому в некоторых случаях сжатие даже небольших таблиц все равно дает эффект поскольку выигрыш от экономии на дисковом I/O (которое как правило узкое место в производительности) превышает затраты CPU (которые часто недогружены). А в случае c Vertica так там вообще некоторые агрегаты (count, sum, min, max, avg и т.д.) считаются прямо на сжатых данных, без декомпрессии т.е. вообще нет никаких дополнительных нагрузок на CPU. Так что планка размера для таблиц, которым не нужно сжатие очень невысока, хотя конечно зависит от продвинутости реализации колоночного хранения в разных СУБД.

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT