суббота, 8 февраля 2014 г.

MPP OLTP "братец" для сервера Vertica

Все мы знаем, что сейчас наиболее востребованной технологией организацией хранилищ данных является массово параллельная архитектура MPP. Такой подход позволяет гибко распределять нагрузки обработки данных на кластер серверов, организовывать отказоустойчивые решения и легко увеличивать мощность кластера, просто добавляя новые сервера в кластер, получая фактически горизонтальное масштабирование. На таких принципах построены в большинстве все крупные игроки рынка хранилищ данных, в том числе и HP Vertica, с которой я имею честь работать.

Сейчас автоматизация охватывает всё большее количество источников информации. Поэтому, в задачах сбора информации операционными системами OLTP, выставляются те же условия, которые применимы к хранилищам данных. Это загрузка в реальном времени больших объемов данных, хранение и управление больших массивов данных, быстрый поиск и преобразование информации. Можно ли все это обеспечить существующими классическими серверами баз данных? Все это делается и сейчас, но по мере роста объема собираемых в реальном времени данных, традиционная SMP архитектура дает ряд недостатков, приводящих к усложнению построения решений. Это: более низкая у SMP возможность масштабирования, узкое место работы с дисковым массивом по записи и чтению информации, меньшая надежность хранения данных, вынуждающая делать репликацию данных на другой сервер, сложное управления большим объемом данных и т.д. Однако, SMP всегда на фоне MPP имели неоспоримые преимущества, которые не так важны для хранилищ данных, но критичны для операционных систем: ACID, поддержка ссылочной целостности, гарантированное восстановление после сбоев накатом транзакций по логам и т.д. Долгое время эти преимущества являлись тем козырным тузом, который позволял SMP архитектурам удерживать первенство в задачах OLTP класса.

Майкл Стоунбрейкер, разработчик и автор таких известных нам СУБД, как Ingres, Informix, PostgeSQL, Vertica решил со своими коллегами и на фронте OLTP поспорить с засильем SMP архитектуры. Успешно запустив в 2005 году проект Vertica, он с единомышленниками в 2007 году создал экспериментальный проект HStore, который после разработки и приведения в коммерческий вид был назван VoltDB.

VoltDB является полноценным реляционным OLTP сервером, с полным ACID, отказоустойчивостью, поддержкой ANSI SQL, хранимых процедур, стандартных драйверов доступа. В тоже время он является мощным и быстрым MPP сервером, позволяющим в реальном времени одновременно вставлять, изменять и удалять записи сотням тысяч транзакций одновременно, параллельно эффективно выполняя запросы получения информации. Как и в Vertica, VoltDB сегментирует хранение данных между нодами своего кластера, позволяет разбивать на партиции таблицы, умеет распределять нагрузки при выполнении запросов между нодами кластера и обеспечивать быстрое накопление вставляемых данных в область памяти, неявно обеспечивая функционал InMemory сервера для сбора и работы с информацией, управлять зеркалированием данных между нодами (KSafe).

Похожего с Vertica очень много, что не удивительно, ведь у VoltDB и Vertica один создатель. Но много и разного, ведь это СУБД разного класса задач. VoltDB имеет коннекторы, которые позволяют ему напрямую потом загружать данные в Vertica или Netezza. Наверное, одним из самых оптимальных вариантов использования VoltDB хорош в связке с MPP хранилищем данных. Здесь, VoltDB полностью обеспечивает построение операционной базы данных для сбора больших потоков информации в реальном времени с множества источников. Постоянно обновляемое операционное хранилище позволяет быстро клиентским приложениям искать нужную информацию. Установленное рядом хранилище данных переливает на себя в определенные промежутки времени данные из операционной базы, обеспечивает их консолидацию с другими источниками, очистку и дальнейшее построение витрин для анализа и отчетности. Здесь мне видится самым большим плюсом то, что если оба сервера, OLTP и OLAP являются MPP, то получается высоко-отказоустойчивая масштабируемая система в режиме работы 24x7, способная обрабатывать любые объемы данных. Оба сервера замечательно масштабируются, не требуют затрат на оптимизацию при возрастании количества данных и имеют нулевое администрирование. Все это выливается в низкую цену сопровождения такого решения. А это по моему мнению наиболее актуальный момент любой системы, в которой крутятся действительно большие данные.

Всем, кто заинтересовался этим "чудо" MPP OLTP сервером, даю ссылку на его сайт: http://voltdb.com. Для меня еще одним приятным моментом при знакомстве с этим сервером было то, что в команде VoltDB русскоязычные разработчики. Это позволяет легко и быстро на нативном языке обсуждать с ними продукт и разбираться с ним. Для меня это очень большой плюс.

Ну а чуть позже, как соберусь с временем и силами, я выложу более подробную статью о VoltDB и надеюсь, уже поделюсь опытом эксплуатации этого интересного продукта на просторах нашей Родины.


До связи!

3 комментария:

  1. VoltDb ужасен =) по крайней мере его python и php биндинги =)

    откровенно говоря OLTP приложения через Sharding сейчас уже дофига СУБД их нормально реализуют...
    PgSQL pg\pl proxy\MySQL Fabric
    они конечно в пересчете на бокс поменьше TPS покажут чем VoldDB

    большинству проектов важнее горизонтальное масштабирование помноженное на "узнаваемость инструмента" (мы кодим на том, на чем имеем опыт)...
    чем эффективность на отдельно взятый бокс...
    ну конечно на определенных этапах роста... пока у тебя меньше сотни серверов ;)

    большинство экономических моделей (рекламная, freemium, free-to-play, subscribe) имеют около 10-20% всего затрат на сервера
    а дальше слазить с MySQL уже очень сложно, потому что уже куча своей обвязки мониторинга и т.п. и даже если "перейти на VoltDb",
    то не факт то в денежном выражении не факт что будет ОЩУТИМЫЙ эффект

    ОтветитьУдалить
  2. Привет. Речь я так понял идет о нестандартных драйверах доступа к VoltDB :) Официально в документации VoltDB описана реализация доступа к серверу через Java и C. Так что насчет "ужасен" я правильно понимаю, речь идет о клиентских драйверов php и python ?

    ОтветитьУдалить
    Ответы
    1. Именно так, в клиентских драйверах я никакого SQL вообще не увидел...

      Удалить