Vertica ANSI SQL совместимый сервер. ScyllaDB не может быть ему конкурентом, он с другой оперы и конкурент Cassanda насколько я понимаю :) У Vertica конкуренты немного другие — Teradata, Exadata, Nettiza, GreenPlum…
По GPL 1 тб у Вертики стоит 30 тыс. Плюс 6 тыс за поддержку. Откуда 120 тыс? :) Ну и скидки никто не отменял.
Ну а так цена на хранилище в 50-100 тб выходит где то на порядок ниже, чем у аппаратно ориентированных хранилищ данных. Понятное дело, для маленьких объемов, платить за 10 тб может показаться жирным, проще взять классический OLTP, но есть нюанс — Вертика не ограничивает количество серверов и их мощности в кластере. Иногда требуется на 10 тб построить высоконагруженное в реалтайм хранилище данных с моментальным откликом на ad-hoc запросы и горизонтальным масштабированием без остановки хранилища. Вот тогда может запросто оказаться, что цена Вертики за 10 тб окажется разумнее, чем затраты на реализацию и сопровождение этих требований.
P.S. Слышал, что у Вертики готовят решения для SMB, с другой ценовой политикой, но пока на нашем континенте таких редакций пока не видел.
Ну логически там полная реляционная модель с таблицами, PK/FK/UK, все как полагается. А вот на уровне физического хранения да, там поколоночное хранение со своими интересными идеями. Все это достаточно подробно в статьях на Хабре других описано, том числе моих :)
Маскировка интеллектуальная, умеет заменять адреса, ФИО, номера счетов и ИНН, телефоны и т.д. — то есть максимально выдавать данные приближенные к тому, что ожидается в бизнес логике по полю. Для этого внутри есть англоязычные словарики по разным бизнес сущностям и алгоритмы формирования в нужном формате значений. В отличие от рандом и хэш значений это очень помогает при разработке BI отчетов и позволяет интеграторам клиентов работать все таки с бизнес данными, пусть и «левыми», а не мешаниной цифр и букв. Не все пока полностью реализовано, но библиотека развивается и кстати используется нашим лоадером, который позволяет грузить в Вертику данные сразу маскируя нужные поля без промежуточных операций и гарантируя, что в ХД уже по любому не запишется даже в промежуточные таблицы персонализированных данных. Достаточно по нужным полям указать, как их нужно маскировать и в ХД уже автоматом попадут замаскированные данные.
А вообще в комментах всего не перескажешь, что сделали — это и лоадер, который как полноценным DSL получился, позволяющим описать обычным конфигом сложную прогрузку данных или перемещение файлов на файловых системах и веб шедулер с мониторингом и управлением на множестве серверов задач по расписаниям, аналог коммерческого Кварца или Таленда. Хадуп сейчас активно подтягиваем и вот с VoltDB начинаем работу. Весело в общем ;)
Вот руки не дойдут еще статьи написать, информации полезной полно, но мы сейчас full-time на развитие софта автоматической загрузки в Вертику с первоисточников, никак не вырву денек. По Хадупу сейчас Вертику интегрируем, народ с флекс таблицами активно возиться, по разработке на Java своих UDF опыт уже неплохой, например сделали библиотеку функций маскирования данных, что позволяет клиентам для своих интеграторов выгружать данные из прода в дев зоны маскируя персональные данные и снимая вопросы разворачивания похожих на правду стендов для разработки на них интеграторами решений для них.
Кстати скоро выложим наш лоадер на HP Market Place, документация основная готова, не хватает демо примеров по настройке работы. Для Community Вертики можно будет спокойно использовать, идеальная связка получится для среднего бизнеса для построения своих аналитических хранилищ данных до 1 тб на отказоустойчивом 3 нодовом кластере на абсолютно бесплатном полнофункциональном ХД + так же бесплатном софте выгрузке-загрузке данных без требования кодирования или разработки ETL задач. Скорость построения пилотов и рабочих решений для небольших хранилищ получается космическая ;)
Привет. Данные по нодам каждой таблицы изначально распределяются по уникальному набору полей (обычно это PK). Однако для detail таблиц, которые имеют FK к master таблице распределение стоит по ключу parent_id, то есть по PK мастер таблицы. Это убирает необходимость при джойне этих таблиц Вертике пересылать записи мастера и детальки между нодами, собирая их для соединения.
Уважаемые коллеги, обратите внимание: внес небольшие правки в статью касательно новых типов проекций. Было ошибочно указано, что оптимизатор самостоятельно может увидеть, что под запрос подходят такого типа проекции и воспользоваться этими проекциями. Как выяснилось, на самом деле оптимизатор не может это сделать, нужно просто в запросе вместо имени таблицы явно указать имя созданной проекции, чтобы запрос отработал именно по ней. На самом деле вы можете в запросах вместо имен таблиц явно указывать и простые проекции, получается этакий аналог хинта использования индексов. Но в большинстве случаев это вредно, так как оптимизатор производя выбор использования нужной проекции, может анализировать не только метаданные, но и состояние и нагрузку кластера. Ну а новые проекции уже получается являются чистой материализацией новых данных на основе существующих в таблице, именно поэтому к ним и нужно обращаться явно.
Привет. Извините, что долго не отвечал. По вопросам:
1. Рекомендуется, чтобы кластеры были одинаковых размеров. Иначе возможна ситуация, когда загрузка данных из всех серверов Хадуп в ноды Вертики может сильно затормозить работу Вертики за счет множества сессий. Вообще при больших массовых загрузках имеет смысл самостоятельно на Хадупе разбить данные на серии мелких файлов и инициировать их загрузку с множества нод Вертики командой COPY FROM HDFS.
2. Быстрый доступ возможен в любом случае, если Key в PK, тот же SELECT WHERE PK = <ключ> моментально вернет запись из таблицы любого объема. Другое дело в JDBC реализован интерфейс, позволяющий быстро искать данные без явного выполнения запроса. На физическом уровне, уверен этот метод делает тоже самое, что SELECT с поиском по ключу.
Всем привет. В документацию Vertica вернули описание функции MERGE_PARTITIONS и убрали ее с deprecated. Видимо коллектив Вертики понял, что «погорячился» с функцией, которая реально нужна :)
Так что я убрал со статьи раздел «Устаревшее» про эту функцию.
Мы, это разработчики проекта хранилища данных для Йота :) Решили выделится в отдельную единицу в России и заняться экспертизой по большим данным, в первую очередь занимаясь Vertica как партнеры HP и продуктами, которые с ней хорошо дружат. Не все кстати из последних представлены в России, вот потихоньку налаживаем контакты и дружеские отношения. Дальше если интересно, мое мыло ascrus@easydata.ru :)
По поводу Вертики согласен — на текущий момент думаю самое удачное решение на рынке хранилищ данных для аналитики. Горизонт применения очень большой. Легко собирается реалтайм, что особо интересно для телекомов и банков, для которых контроль работы сети или безопасности проводимых транзакций имеет критическое значение.
Жалко мы не смогли присутствовать, в следующем году исправим ситуацию :)
Спасибо за оценку моей статьи :) Тоже очень интересно было почитать про Ваш доклад.
По поводу группировки колонок — имеет смысл ее делать для полей фактов, которые используются почти всегда вместе. На примере телекома — поля Download, Upload, Duration почти всегда тащатся в запросах вместе, для анализа и расчета объема и скорости трафика. Енкодинг на них не нужен, это чистые цифры, которые красиво не упаковать. А вот их чтение с одного места повышает эффективность запросов, так как вместо чтения и соединения трех колонок, считывается и далее рассчитывается сразу одним проходим все три колонки. Ну а поля измерения же конечно нельзя объединять в группы, получится деградация производительности :)
P.S. Давайте дружить на почве Вертики и не только :) Сейчас мы для расширения помощи экспертизы в России организовали компанию easydata.ru, специализирующуюся как раз по Большим Данным и Vertica. Скоро подключим экспертизу и по Cassandra. Занимаемся с вами фактически на одних и тех же технологиях, можем обмениваться опытом, удачным и не очень :)
Спасибо за критику, учту! Писал статью в расчете на то, что читатель знаком с Groovy и может в Groovy API найти описание BuilderSupport. Когда вызываются методы CreateNode и setParent вроде написал вкратце, в API есть более подробное описание. Книга отличная, всем кто заинтересовался DSL на Groovy было бы здорово почитать. Вот только я не встречался с русскоязычным переводом, не могли бы Вы кинуть ссылку, где ее можно купить или скачать?
Ну а так цена на хранилище в 50-100 тб выходит где то на порядок ниже, чем у аппаратно ориентированных хранилищ данных. Понятное дело, для маленьких объемов, платить за 10 тб может показаться жирным, проще взять классический OLTP, но есть нюанс — Вертика не ограничивает количество серверов и их мощности в кластере. Иногда требуется на 10 тб построить высоконагруженное в реалтайм хранилище данных с моментальным откликом на ad-hoc запросы и горизонтальным масштабированием без остановки хранилища. Вот тогда может запросто оказаться, что цена Вертики за 10 тб окажется разумнее, чем затраты на реализацию и сопровождение этих требований.
P.S. Слышал, что у Вертики готовят решения для SMB, с другой ценовой политикой, но пока на нашем континенте таких редакций пока не видел.
А вообще в комментах всего не перескажешь, что сделали — это и лоадер, который как полноценным DSL получился, позволяющим описать обычным конфигом сложную прогрузку данных или перемещение файлов на файловых системах и веб шедулер с мониторингом и управлением на множестве серверов задач по расписаниям, аналог коммерческого Кварца или Таленда. Хадуп сейчас активно подтягиваем и вот с VoltDB начинаем работу. Весело в общем ;)
Вот руки не дойдут еще статьи написать, информации полезной полно, но мы сейчас full-time на развитие софта автоматической загрузки в Вертику с первоисточников, никак не вырву денек. По Хадупу сейчас Вертику интегрируем, народ с флекс таблицами активно возиться, по разработке на Java своих UDF опыт уже неплохой, например сделали библиотеку функций маскирования данных, что позволяет клиентам для своих интеграторов выгружать данные из прода в дев зоны маскируя персональные данные и снимая вопросы разворачивания похожих на правду стендов для разработки на них интеграторами решений для них.
Кстати скоро выложим наш лоадер на HP Market Place, документация основная готова, не хватает демо примеров по настройке работы. Для Community Вертики можно будет спокойно использовать, идеальная связка получится для среднего бизнеса для построения своих аналитических хранилищ данных до 1 тб на отказоустойчивом 3 нодовом кластере на абсолютно бесплатном полнофункциональном ХД + так же бесплатном софте выгрузке-загрузке данных без требования кодирования или разработки ETL задач. Скорость построения пилотов и рабочих решений для небольших хранилищ получается космическая ;)
Прошу прощения за эту неточность.
1. Рекомендуется, чтобы кластеры были одинаковых размеров. Иначе возможна ситуация, когда загрузка данных из всех серверов Хадуп в ноды Вертики может сильно затормозить работу Вертики за счет множества сессий. Вообще при больших массовых загрузках имеет смысл самостоятельно на Хадупе разбить данные на серии мелких файлов и инициировать их загрузку с множества нод Вертики командой COPY FROM HDFS.
2. Быстрый доступ возможен в любом случае, если Key в PK, тот же SELECT WHERE PK = <ключ> моментально вернет запись из таблицы любого объема. Другое дело в JDBC реализован интерфейс, позволяющий быстро искать данные без явного выполнения запроса. На физическом уровне, уверен этот метод делает тоже самое, что SELECT с поиском по ключу.
Так что я убрал со статьи раздел «Устаревшее» про эту функцию.
Жалко мы не смогли присутствовать, в следующем году исправим ситуацию :)
По поводу группировки колонок — имеет смысл ее делать для полей фактов, которые используются почти всегда вместе. На примере телекома — поля Download, Upload, Duration почти всегда тащатся в запросах вместе, для анализа и расчета объема и скорости трафика. Енкодинг на них не нужен, это чистые цифры, которые красиво не упаковать. А вот их чтение с одного места повышает эффективность запросов, так как вместо чтения и соединения трех колонок, считывается и далее рассчитывается сразу одним проходим все три колонки. Ну а поля измерения же конечно нельзя объединять в группы, получится деградация производительности :)
P.S. Давайте дружить на почве Вертики и не только :) Сейчас мы для расширения помощи экспертизы в России организовали компанию easydata.ru, специализирующуюся как раз по Большим Данным и Vertica. Скоро подключим экспертизу и по Cassandra. Занимаемся с вами фактически на одних и тех же технологиях, можем обмениваться опытом, удачным и не очень :)
Презентации здесь: www.vertica.com/
Описание Vertica под проект здесь: ascrus.blogspot.ru/2013/02/hp-vertica.html
Повод для холиваров по выбору платформы здесь: ascrus.blogspot.ru/2013/01/vertica-vs.html
:)