Вертика

[kaipa]

(фотография сделана в офисе Вертики под Бостоном)

Написал статью на хабре. Минимум технических подробностей, так как я не совсем уверен, что может попадать под NDA. Несколько еще менее технических деталей.

До того, как их купил HP, с вертиковцами было просто очень приятно общаться. Несмотря на то, что мы для них были одним из самых небольших аккаунтов, они потратили кучу времени. Единственный русскоговорящий в их компании оказался Alex Entin, в то время Product Manager, а сейчас руководитель группы performance. Он потратил часов 8-10, проводя нескольких наших инженеров через несколько веб-презентаций и объясняя основные возможности и принципы работы Вертики в куда более подробных деталях, чем я описал в статье. Затем я по дороге в Сан-Франциско остановился в Бостоне на день, где успел встретиться и с CEO Tokutek (компания разрабатывает классный storage engine для MySQL, с использованием технологии фрактальных деревьев для индекса) и провести пол-дня в офисе Вертики. Симпатичная field-инженерка по имени Диана ответила на многие мои вопросы, благо мы уже почти построили свою вертиковскую инфраструктуру и вопросы были, показала несколько еще более глубоких презентаций. А потом мы заключили контракт. Причем, отдам должное переговорщикам с нашей стороны, контракт получился отличный. Настолько отличный, что когда HP купила Вертику, и мы захотели в соответствии с контрактом расширить свою квоту на объем данных, HP уперся рогом. Даже наши американцы были удивлены, так как в Америке не принято не выполнять контракты. В конце концов контракт восторжествовал, но осадок остался. Вообще, общение с sales до и после покупки Вертики HP -- это две большие разницы. Увы, не в пользу HP. Остается лишь радоваться, что инженерная команда и команда поддержки остались те же, и качество продукта только растет.

Comments

[zhengxi.livejournal.com]

Еще бы хотелось сравнения с Apache Accumulo.
Понятно, что когда вы делали выбор, её еще не было, но сейчас есть.

[ushastyi.livejournal.com]

Вы меня познакомили с новым продуктом. Из того, что я понял, просмотрев документацию по диагонали, это не сильно отличается от Кассандры. И для аналитики в общем случае не подходит хотя бы потому, что не поддерживает SQL. Возможно, можно какие-то специальные задачи на нем делать, что делает Твиттер, но не в общем случае. Единственный сносный аналитический пример, который я там нашел, это rolling average -- написан на джаве. В Вертике для этого есть просто SQL-функция.

Кстати, похоже, что Accumulo использует log structured merge trees для индексов. Это они молодцы, правильная технология (гугл ее уже много лет использует).

А у Вас есть опыт с Accumulo?

[zhengxi.livejournal.com]

Вот сейчас играюсь, 3Tb загнал туда и пишу запросы на скале.

[ushastyi.livejournal.com]

DSL написали?

[zhengxi.livejournal.com]

Нет.
Возможно, напишу.
Когда таких запросов накопится некоторое количество, на котором будут видны общие места.

[kranov.livejournal.com]

А сколько жестких дисков у типичной ноды? Сколько дисковая на последовательном чтении выдает?

[ushastyi.livejournal.com]

Ну это вопрос из серии, "а сколько гигабайт на сервере". Скорость дисковой подсистемы от базы данных не зависит. В общем случае, чем больше дисков в каком-нибудь рейде, тем лучше. Мы обычно используем до восьми не очень больших дисков. Больше уже очень дорогие сервера. Если требуется выжать максимум с одного сервера -- то максимально быстрые диски. Если кластер -- то не так важно, можно просто больше узлов добавить.