В качестве вступительного слова
На Хабре и других источниках уже было описание HP Vertica, но, в основном, вся информация сводилась к теории. До недавнего времени в реальной промышленной эксплуатации Vertica использовалась (так как мы называем ее Вертика, предлагаю назначить женский род) в Штатах и немного в Европе, на Хабре же о ней писали ребята с LifeStreet Media. Уже прошло полтора года работы с Vertica, наше хранилище данных содержит десятки терабайт данных. В минуту сервер данных обрабатывает тысячи запросов, многие из которых охватывают десятки миллиардов записей. Загрузка данных идет не переставая в реалтайме объемами порядка 150 гб в сутки … В общем я подумал, что стоит восполнить пробел и поделиться ощущениями от езды на реально современных новых технологиях под BigData.
Кому это будет полезно
Думаю, это будет полезно для разработчиков, архитекторов и интеграторов, которые сталкиваются с задачами хранения и аналитической обработки больших данных по объему, содержанию и сложности анализа. Тем более, у Vertica сейчас наконец то есть вменяемая бесплатная полноценная версия Community Edition, которая позволяет развернуть кластер из 3 серверов и загрузить в хранилище данных до 1 тб сырых данных. С учетом производительности и легкости развертывания решений на Vertica, считаю это предложение достойным для того, чтобы его рассмотреть при выборе хранилища данных для компаний, у которых объем данных впишется в 1 тб.
В один абзац о том, как мы выбирали
Кратко без повода к холивару:
При выборе сервера хранилищ данных нас интересовали принципы ценообразования, высокая производительность и масштабируемость работы с большими объемами данных, возможность загрузки данных в реалтайм с множества разных источников данных, легкость стартапа проекта своими силами и минимальная стоимость сопровождения: в итоге по всем этим показателям лучше всего для нас выступила Vertica, победив IBM Netezza и EMC GreenPlum, которые не смогли полностью удовлетворить всем нашим требованиям, что вылилось бы в дополнительные издержки на разработку и сопровождение нашего проекта.
Как выглядит Verica с точки зрения архитектора
Архитектор — это самый важный для хранилища данных человек в Vertica. Именно в первую очередь от него зависит успешность и производительность функционирования хранилища данных. У архитектора две сложных задачи — грамотно подобрать техническую начинку кластера Vertica и правильно спроектировать физическую модель базы данных.
На что влияет техническая архитектура
Даю свои личные ощущения по мере убывания критичности:
- Являясь MPP сервером, Vertica в первую очередь предъявляет жесткие требования к сетевой архитектуре. Если у Вас 3 сервера в кластере и база 3 тб, то обмен данных между ними и пользователями не особо заметен по сетевым расходам. Если же у Вас 6 серверов и база в 30 тб данных, то в пиковых нагрузках сеть может стать самым слабым местом всей работы кластера. А представьте себе, что у Вас 100 серверов и база более 1 петабайта? Страшно? :)
- Правильно собранные массивы на локальных дисках серверов кластера залог успешного балансирования между производительностью, объемом хранения и стоимостью железа. Собрали райды на дешевых медленных дисках, но с большим объемом? Дешево и сердито, но медленно. Собрали все на быстрых дисках, но с меньшим объемом? Дорого, быстро, но не хватает места для базы, нужно еще подключать сервера в кластер. Прочитали документацию по технологии Flex в Vertica, на сервера кластера повесили быстрые и медленные диски, распределив хранение столбцов таблиц (проекций) по их участию в запросах как фильтров и возвращаемых данных? Молодцы, получили оптимальный для работы кластер. Если же еще добавить на сервера локальные быстрые диски и туда вынести темповое пространство Vertica, все вообще будет выглядеть супер.
- Секрет полишинеля: памяти много не бывает и дешевле сразу купить сервера с большим объемом RAM, чем потом доставлять уже к существующим серверам. Тут стоит помнить, что аналитические запросы к биллионам записей данных хотят очень много памяти, физику никто не отменял, поэтому запросто одна сессия одного аналитика может скушать и 20 гигабайт памяти. Посчитайте Ваших аналитиков, посчитайте тяжелые запросы, которые будет выполнять Ваш ELT и не начинайте впадать в панику и думать покупать терабайт памяти. Vertica позволяет успешно сбалансировать нагрузки потребления ресурсов с помощью пулов ресурсов, так что можно ориентируясь на предполагаемый объем хранилища данных, поделенный на количество серверов в кластере, с учетом предполагаемой нагрузки выбрать золотую середину размера RAM на серверах кластера и перестраховаться от пиковых нагрузок с помощью разграничения по пулам ресурсов.
- Что меня всегда удивляет в Vertica после Sybase IQ – это низкие нагрузки на процессорную мощность. Если у IQ в ходе выполнения тяжелых запросов, все процессора работают в full-time, то у Vertica при тех же условиях они на фоне Sybase выглядят так, как будто отдыхают в отпуске. Причем оба сервера колонко-ориентированные, оба сжимают все данные при хранении в базе данных. Чудеса, да и только, но факт остается фактом – процессоры не самое критичное место у Vertica, хотя я надеюсь, Вы не воспримите это как руководство к тому, что достаточно 2 ядер. Чудес не бывает — как и везде, выполняющиеся запросы занимают ядра, тяжелый запрос может распараллелить свое выполнение на множество потоков и занять множество ядер. Поэтому выбираем количество ядер серверов кластера, ориентируясь на предполагаемые нагрузки.
На что влияет физическая модель базы данных
Здесь сложно проставить уровень критичности, все является важным, поэтому список без нумерации:
- На фоне Sybase IQ, Vertica на удивление эффективно работает с JOIN даже больших таблиц, но все-таки колонко-ориентированные СУБД изначально ориентировались на то, чтобы постараться избавиться от лишнего количества соединений и упростить схемы данных. Везде, где можно, пользуйтесь денормализацией данных, это не увеличивает затраты на хранение данных, но зато ускоряет выполнение запросов и в том числе упрощает их написание, убирая лишние таблицы с запроса. Единственный здесь минус – это то, что денормализованные данные в таблицах занимают место в лицензии, но если подумать логически – вывод в таблицу фактов имени и цены товара займет на одну запись в среднем 30 байт, то есть на миллиард записей в фактах это выльется в 30 гб лицензии, не бог весть какой объем, чтобы экономить байты.
- Раньше я думал, что партиционирование таблиц не самая важная вещь при проектировании схемы данных (на старых версиях Vertica так и было), но сейчас глядя на новые версии Vertica, я так перестал думать. Партиционирование позволяет разбить данные таблицы на логические контейнеры, с которыми Vertica легче манипулировать по хранению и доступу к данным. Вердикт разработчиков Vertica суров: ключей партиций не должно быть много и не должно быть мало. В первом случае Vertica заткнется при выполнении запросов путем пересмотра тучи контейнеров партиций, во втором случае Vertica будет тратить много времени на сливание и чтение контейнеров размерами в сотни гигабайт на диске. Так же, планируя партиции, стоит помнить, что Vertica умеет быстро и эффективно удалять, а так же переносить в другие таблицы контейнеры по ключам партиций. Вывод из всего этого прост: не надо делать контейнеры по логическим признакам, таким как например города или клиенты. Спросите сами себя: разве у Вас возникнет повод удалить или перенести в архивную таблицу из фактов всю информацию по городу или клиенту? А вот удалить или перенести информацию за прошлый период, день, неделю или месяц — это хороший повод подумать о таком ключе для партиции таблицы фактов. Для тех же, кто верит в будущее своей компании и долгую счастливую жизнь хранилища данных и не согласен с тем, что данные не нужно хранить вечно, в Vertica есть замечательная функция MERGE_PARTITIONS, которая позволит соединить указанный промежуток ключей партиций в единый контейнер и удерживать количество ключей партиции таблицы в разумном пределе. Про измерения надеюсь и так понятно –партиции там точно не нужны.
- Любой MPP сервер, будь то Vertica, Hadoop или Cassandra любит равномерно распределенные данные по серверам кластера. Любой автолюбитель подтвердит, что плохая балансировка при высокой скорости движения сразу же визуально ощущается. MPP здесь не исключение – если Вы в качестве сегментации хранения данных укажите сегментацию по городу, то на одном сервере кластера у Вас окажется 15 миллионная Москва, а на другом 40 тысячный Урюпинск. Думаю уже понятно, какой сервер будет работать над запросами, пока остальные сервера кластера будут просто простаивать и ожидать завершения работы «московского» сервера. Если сегментация явно неуказана, Vertica по умолчанию просто сегментирует по хешу всех полей таблицы. Это дает равномерное распределение данных между серверами кластера, но есть моменты, когда это можно вдумчиво сделать вручную, а именно в случаях частой группировки данных по каким либо полям при условии, что записей по этим полям группировки всегда примерно равномерное распределенное количество. Например, у нас на каждый город на каждый день проходит определенное количество фактов продаж. Конечно в Москве это будут десятки тысяч записей в день, а в Урюпинск выдаст всего с десяток продаж, но так как городов в России много и дней в году тоже, то при определении сегментации фактовой таблицы по хешу дня продажи и города, записи той же Москвы будут равномерно ложится между серверами кластера по дням, а Урюпинск будет всего лишь статистической погрешностью балансировки распределения данных такой таблицы. Что же мы получим с такой сегментации? Запрос по фактам с группировкой по дню всех данных с учетом того, что пунктом выше мы сделали партиции по дням, приведет к тому, что каждый сервер кластера поднимет партицию за нужный день, агрегирует данные, перешлет на сервер инициатор запроса, который следом приведет уже окончательную агрегацию и отдаст результат вызвавшей сессии. Запрос с группировкой по городу всех продаж приведет к тому же — каждый сервер агрегирует у себя по городам и передаст на окончательное агрегирование инициатору запроса. Тоже самое будет и для этих запросов для таблицы без указания явной своей сегментации по городам и дням. Основная расходная часть здесь выполнения запроса – это передача промежуточных результатов агрегирования по сети и вычислению окончательных результатов агрегации, здесь будут идти нагрузки на сеть, а потом память сервера инициатора запроса. А вот запрос с группировкой по дням и городам уже в случае явной сегментации отработает по-другому – серверам будет достаточно каждому уже агрегировать по городу и дню, передать окончательные результаты на сервер инициатор, который их просто сложит и отдаст результат сессии. Когда такая овчинка стоит выделки? Мое мнение – только если будут идти запросы по данным, в которых тысячи городов по большим периодам продаж. То есть в данном примере явно такую сегментацию не стоит и достаточно сделать обычную равномерную сегментацию данных таблицы продаж. Но как говорится, на то он и пример, чтобы просто показать, а не делать. С сегментацией же измерений все тоже просто – для измерений с разумным количеством записей проще сделать зеркальное хранение всех копий на серверах, для остальных равномерное распределение данных между нодами. Здесь стоит помнить, что при зеркальном хранении измерения, затраты каждого сервера кластера при соединении таблицы фактов с измерением уйдут только на то, чтобы просто получить копию записей измерения себе в память и начать соединение. В обратном случае придется получать куски измерения с каждого сервера и далее соединять по ним. Здесь сетевых расходов на зеркало получается меньше по принципу – все получили с одного, чем все получили со всех.
- Одно из преимуществ Vertica у маркетологов гласит: в Vertica нет индексов. Правильно, индексов нет — зато есть сортировка и формат кодирования хранения данных. Фактически от этих вещей напрямую зависит, насколько эффективно Ваша таблица или ее проекция будут готов выполнять различные запросы и кто больше из проекций понравится оптимизатору запросов при построении плана выполнения запроса. Честно говоря, описание всех нюансов учета, как лучше кодировать поля и какая сортировка наиболее оптимальна для больше части запросов тянет на диссертацию по тематике Вуду, поэтому я ограничусь в рекомендациях простыми правилами проектирования:
- При выборе способа хранения значения колонки, Vertica автоматически ориентируется на ее тип данных. Так как, никаким алгоритмом не возможно угадать, что BIGINT в каком-то случае это значение факта, а в каком-то идентификатор измерения, стоит при описании таблиц не игнорировать указание ENCODING той части полей, которая будет востребована при фильтрации и агрегации в запросах, то есть является не фактами, а значением измерений. При правильном описании этой опции колонок, Vertica легче будет хранить и искать данные по ним, а оптимизатору учитывать при построении более эффективных запросов. Так же не забываем про GROUPING, если есть поля, которые всегда в запросах возвращаются и обрабатываются вместе, есть хороший повод объединить их хранение в одном месте, снизив затраты на их чтение и сборку записей.
- При назначении сортировки таблице или проекции помним, что на все случаи сортировкой не запасешься и от создания проекций не убережешься. Поэтому для таблицы выбираем сортировку с точки зрения выполнения наиболее часто идущих запросов, а на остальные случаи уже делаем проекции.
- При выборе полей и порядка сортировки ориентируемся примерно на такие правила: в начале сортировки ставим колонки, по которым наиболее часто идет поиск в запросах по равенству и которые наиболее подходят под определение уникальных, далее в середину сортировки неплохо поместить поля, которые используются в соединениях или поиску по списку оператором IN. Последними уже стоит поместить поля, по которым идут операции сравнения. В случае нашей многострадально рассмотренной таблицы продаж, с точки зрения сортировки наиболее выгодно было бы поставить следующие порядок полей: Регион, Клиент, Дата_Продажи. Такой порядок сортировки покрывает все запросы, у которых в фильтрации есть поиск по регионам и/или клиентам в указанном разрезе периода дат. Если же эти запросы используют в ORDER BY поля сортировки, Vertica еще проще выполнить запрос.
- Так как все равно нельзя быть полностью уверенным, что кодировка и сортировка, да и сегментация, будут наиболее оптимальными, всегда можно сделать ход конем – развернуть на Vertica прототип таблицы без явного указания сегментации и сортировки, заполнить ее определенным объемом данных, побольше написать в файлик типовых запросов к этой таблице и прогнать через Database Designer утилиты Vertica adminTools. Дизайнер проанализирует запросы, создаст под таблицу нужные проекции с оптимальными с его точки зрения кодировкой и сортировкой данных. Далее можно будет погонять запросы по этой таблице, посмотреть их планы запросов, оценить насколько предложенные проекции эффективны и уже сделать рабочую таблицу, ориентируясь на предложенную в созданных проекциях сортировку, сегментацию и кодирование полей. Ну и при необходимости создать сразу же дополнительные проекции для запросов, которые не покрывает сортировка самой таблицы и которые были предложены дизайнером Vertica.
Как выглядит Vertica с точки зрения разработчика ETL/ELT
Разработчику ETL логики живется легко и вольготно: Vertica имеет все стандартные драйвера доступа к данным (ODBC, JDBC, .NET, Python) и содержит внушительный набор штатных собственных средств пакетной загрузки плоских файлов команды COPY, которые к тому же можно расширять собственными парсерами, фильтрами и валидаторами. Файлы можно загружать как с самих серверов кластера, так и локально с рабочих машин посредством COPY LOCAL. JDBC драйвера Vertica поддерживают вставку batch insert через JDBC prepared statement, автоматически преобразуя пакеты вставляемых значений в пакетную вставку COPY, что гарантирует высокую скорость вставки записей. Единственной ложкой дегтя можно отнести то, что функции расширения пакетной загрузки можно писать только на Си, что сразу же усложняет разработку. Судя по последним слухам, Vertica уверенно движется к интеграции с миром Java (поближе видимо к Hadoop), поэтому вполне возможно в скором будущем, такие вещи можно будет писать и подключать на Java. Касаясь вопросов производительности и эффективности параллельной загрузки больших объемов данных, Vertica с своей архитектурой полностью забирает их на себя, не требуя при разработке загрузки данных в хранилище каких-либо особенных знаний нюансов организации загрузки в реалтайм.
С точки зрения разработчика ELT логики, к Vertica можно вынести только две претензии – нет поддержки языка хранимых процедур и нет возможности написания собственных функций кроме примитивов в виде выражений или на языке Си. Последнее команда Vertica обещает скоро исправить в виде поддержки функций на Java, а вот с хранимыми процедурами пока обещаний никто не давал. Так что придется логику ELT хранить и выполнять с помощью своих ETL инструментов. В остальном же Vertica полностью удовлетворяет даже самому требовательному разработчику скриптов: полная поддержка стандарта ANSI SQL, множество функций, знакомых по другим серверам данных, простая работа с типами данных и их приведение, поддержка локальных глобальных сессионных временных таблиц для хранения промежуточных результатов, наличие оператора MERGE, поддержка быстрых UPDATE и DELETE, расширение функциональности OLAP за счёт поддержки интервалов времени (TIME EVENT), соединений по времени (TIME JOIN) – все это позволяет легко писать сложные запросы по трансформации и наполнению данных из стейджинговой области в область витрин, рассчитывать агрегаты и KPI и выполнять прочую работу по расчету данных в хранилище. Как показала практика, с Vertica на уровне сложных запросов достаточно быстро находят общий язык разработчики, знающие Oracle, MSSQL или Sybase IQ СУБД. Для Oracle же разработчиков отсутствие языка хранимых процедур и курсоров возможно является дополнительным стимулом поменять свою парадигму к подходам разработки логики расчетов данных. Возможно это одна из причин, почему разработчики Vertica уходят от вопроса поддержки хранимых процедур, IMHO возможно боятся, что курсоры убьют производительность (шутка конечно, но с долей истины).
Как выглядит Vertica с точки зрения разработчика BI
С точки зрения разработчика BI решений, в Vertica явно не хватает возможности некоего аналога параметризованных представлений, аналогами которых в MSSQL например являются табличные функции, а в Sybase IQ хранимые процедуры. При разработке сложных запросов под BI, часто фильтрация данных в запросах используется где-то там внутри подзапросов и невозможность вынести их как точки входа в Vertica, вынуждают разработчиков BI копировать сложные запросы между различными универсами, экстрактами и прочим, что у кого есть в BI инструментах. В остальном, как и в случае с ELT разработчиками, Vertica полностью покрывает весь спектр выполнения аналитических запросов любого уровня сложности, не имеет никаких ограничений в SQL запросах, есть поддержка функций и расширений OLAP, WITH, TIME SERIES, TIME JOIN, EVENT SERIES, работы с гео-данными, ip адресацией, url-ами и т.д. Сами метаданные хранилища Vertica замечательно видятся в BI и никаких сложностей при работе с Vertica у всех основных продуктов BI не наблюдается. Здесь стоит для интересующихся взаимодействию Vertica с BI заметить такую замечательную связку как Vertica+Tableau, выдающую на выходе мощный анализ, осуществляемый аналитиками прямо в реальном времени, который был по достоинству оценен в нашей компании. Я считаю, что главные вопросы для BI разработчиков, а именно производительность ad-hoc запросов и ограничения функциональности в Vertica просто отсутствуют, что положительно сказывается на скорости и качестве разработки BI решений.
Как выглядит Vertica с точки зрения администратора
Администрирование Vertica условно можно считать нулевым. Это не означает, что Vertica не нуждается в администрировании – имеется ввиду, что администрирование Vertica требуется эпизодически, по мере потребностей, причем вместо выделенной штатной единицы постоянного администратора вполне возможно удаленное администрирование сервера или администрирование архитектором, разработчиком ETL или BI. Само администрирование сервера можно условно разбить на некоторое количество категорий:
- Управление ролями и пользователями – стандартный процесс описание в базе данных пользователей, их распределения по ролям и описания доступа ролей к объектам базы данных. Работа не частая, производится по мере добавления пользователей и ролей.
- Управление нагрузками на кластер – более сложный процесс, требующий представления архитектуры работы сервера Vertica. Требует проведения анализа текущих нагрузок на кластер различных процессов и групп пользователей для оптимального распределения ресурсов серверов Vertica по пулам ресурсов. С помощью пулов ресурсов можно разбить выполнение запросов по категориям и выделить по их потребностям различное описание использования ресурсов, указывая горячий зарезервированный размер памяти, максимальный объем потребляемой памяти, количество конкурирующих соединений, приоритет получения ресурсов, максимально допустимое время выполнения запросов и ограничения на уровне использования ядер процессоров. Грамотная разработка пулов ресурсов и распределение по ним различных пользователей гарантирует сбалансированную работу кластера даже в случаях пиковых нагрузок, позволяет эффективно распределить выполнение между реалтайм, оперативными и длинными аналитическими запросами, а так же на уровне ограничений предотвратить неэффективное использование ресурсов серверов Vertica. Обычно такая работа уже проводится на продакшн-сервере, с устоявшимися нагрузками и представлением, когда и как возникают пиковые нагрузки на сервер. Пока условия нагрузок не изменяются, смысла изменять пулы ресурсов нет.
- Управление серверами кластера – сам процесс добавления новых серверов в кластер, замены или удаления серверов из кластера с последующей ребалансировкой данных не является сложным и производится посредством утилиты, однако требует четкого понимания архитектуры работы сервера и планирования проведения работ таким образом, чтобы частичное падение производительности кластера при проведении таких работ не совпало с другими затратными работами в хранилище данных, например перегрузки большого объема данных. К примеру, на нашей практике добавление к 3 серверам еще 3 серверов в кластер с ребалансировкой данных между ними заняло порядка суток с незначительной потерей производительности, которую в итоге никто из пользователей не заметил.
- Восстановление работы кластера – в случае падения одного из серверов кластера, администратор Vertica может заново запустить этот сервер, если сервер физически работоспособен и по сети видит другие сервера или же заменить его на другой, если сервер вышел из строя. На момент отключения сервера от кластера, происходит частичное падение производительности хранилища данных за счет того, что другой сервер кластера был вынужден взять на себя работу остановившегося сервера. Администратор имеет утилиты, позволяющие запустить или заменить сбойный сервер, дальнейшую работу по автоматическому восстановлению данных на сервере и его включению в работу, Vertica берет на себя. Если аппаратная часть серверов надежная, то эта работа не частая — в нашей практике у Vertica всего два раза останавливался один из серверов кластера. Первый раз из-за того, что был сбой при работе с RAM, второй раз при сбое работе RAID контроллера. В обоих случаях, Vertica не останавливал работу и пока производились технические работы с серверами, пользователи и загрузчики данных продолжали работать в штатном режиме работы с хранилищем данных.
- Апгрейт версии сервера – производится путем закачки дистрибутива на один из серверов Vertica, временной остановки сервера Vertica в пределах 10 минут, запуска инсталляции апгрейта и обратного старта сервера Vertica. С этой работой справится любой администратор, умеющий загрузить файлы на Linux и запускать программы.
Как выглядит Vertica с точки зрения руководства
Для начала перечислю то, о чем никогда не болела голова у нашего руководства с пояснением почему:
- Требуется быстро добавить новые источники данных для анализа – добавляются новые схемы и таблицы, делаются в них загрузчики данных, работа прозрачна и понятна
- Требуется увеличить производительность с учетом возросших нагрузок от пользователей хранилища данных – анализируются запросы пользователей, при необходимости добавляются новые проекции, ускоряющие их работу. В случае кратного увеличения нагрузок докупаются и подключаются в кластер новые сервера.
- Требуется подключить на ряд работ интеграторов или другие подразделения, передав им задачи по разработке загрузки данных или построению BI – стандартные протоколы доступа к Vertica и ANSI SQL позволяют максимально быстро новым разработчикам начать работу с хранилищем данных
- Требуется обеспечить хранение и анализ на порядок большего количества данных с источников – в кластер покупаются и подключаются новые сервера.
- Требуются ресурсы на апгрейт лицензий – при покупке новых серверов и подключении их в кластер для увеличения производительности или области хранения данных, это никак не затрагивает лицензию на исходный объем разрешенных к загрузке данных. Так же лицензию не затрагивает создание дополнительных структур (проекций) для ускорения выполнения работы запросов. Таким образом, апгрейт лицензии потребуется только при условии, что объем исходных данных достиг планируемого при покупке лицензий объема и нет возможности удалить устаревшие архивные данные с целью высвобождения места. Мы пока до этого не доросли, но вопрос хранения архивных старых данных уже как никогда актуален — данных оказалось гораздо больше, чем мы планировали из-за возросших аппетитов компании.
Что всегда нравилось нашему руководству:
- Быстро ставить задачи и так же быстро получать результат.
- В любой момент времени быстро получать аналитическую отчетность за любой период по любым условиям.
- Видеть состояние происходящих процессов нашей компании в реальном времени.
- Не слышать никаких жалоб про Vertica или указаний, что задачи не выполнены по каким-либо причинам из-за Vertica.
Что всегда не нравилось нашему руководству:
- Цена – за качество и скорость увы, приходится платить. Vertica не бесплатное и не самое дешевое решение, поэтому руководству требуется моральная готовность потратить деньги, осознавая при этом, что с этого они приобретут.
Как выглядит Vertica с точки зрения интегратора
По моему личному мнению Vertica хороша для тех интеграторов, кто кормиться с стартапов и так себе для тех, кто кормиться с сопровождения. Однако большинство интеграторов сейчас кормятся с сопровождения проектов с классическими СУБД и хотели бы у своих клиентов развернуть быстрые и эффективные стартапы по разработке хранилищ данных: здесь мне кажется Vertica им может здорово понравится.
Резюмируя
Общие ощущения о Vertica у меня, моих коллег и моей компании за полтора года практической эксплуатации сложились очень хорошие. Поводов к разочарованию ни у кого (постучали по столу — тьфу тьфу) не было. В большинстве случаев, столкнувшись с этим сервером, наши интеграторы с удовольствием брались за проекты на нем, а некоторые и вовсе сосредоточились на Vertica, приостановив свою работу с другими аналогичными продуктами (тсс … это по секрету). Много руководителей и архитекторов компаний приезжало в гости посмотреть и оценить, что у нас есть. Много специалистов консультировалось с нами удаленно при выборе хранилища данных, некоторые из них так же выбрали в итоге Vertica и уже запустили стартапы. Были и компании, которым Vertica совершенно не понравилась по своим моральным и политическим причинам и они решили остановить свой выбор на других серверах хранилищ данных. В любом случае, все признали, что продукт Vertica чертовски перспективен и HP не прогадало, купив Vertica и оставив всю структуру компании как есть без внутреннего поглощения.
В общем, краткий экскурс по «большому» серверу закончен, спасибо за внимание.
С уважением, архитектор DWH Константинов Алексей
P.S. Пожалуйста при использовании материалов данной статьи ссылайтесь на данную статью Хабра или мой блог, чтобы помочь защитить мои авторские права по русскоязычной информации на Vertica ;)
Автор: ascrus
