In Memory Data Grids

Alexey Kharlamovaharlamov@gmail.comSkype: aharlamov

Web 2.0: AJAX и стремление к высокой интерактивности Экспоненциальный рост трафика Закон Мура умирает

Рост степени интеграции замедляется Увеличение плотности упаковки не ведет

к росту производительности

• Железо продолжает дешеветь

О этот новый мир

Что же делать? Расти вширь — использовать параллельную обработку (scale out) Гауссовское распределение — наш спаситель!

Мы можем делать только 20% работы и получать 80% заработной платы

Использовать принцип пули Сделать работу заранее и сохранить ее в памяти

Память продолжает дешеветь

Определение Grid — а что это вообще такое?

Машины действующие совместно для решения одной задачи

А In-Memory Data Grid Данные в памяти надежно хранятся

Всегда доступны и консистентны

Network Attached Memory

Ассоциативный массив Данные делятся на

разделы/партиции Партиция реплицируются на

несколько узлов

Динамический кластер ПО Grid-а автоматически управляет узлами Большое число партиций Появление нового узла

Перемещаем часть партиций на новый узел

Выход узла из системы Переводим backup-ы в master-а

Формируем backup-ы на живых узлах

Можем именять размер кластера во время работы

Кеширование базы данных Когда

Есть паттерн доступа в кеш

Высокая плотность записи

Что Read Through/Write behind

Вытеснение и обновление

Запросы не консистентны с кешем и нагружают БД

Все свое ношу с собой Когда: безкомпромисный read/write; 20/80 Что

Загружаем все данные в грид

Запросы в грид, подписываемся на события

Сеть — узкое место Параллельная обработка внутри узлов

грида

Near Cache

Когда использовать Скорость чтения/записи критична Запросы к данным постоянны Ваши данные влазят в 1ТБ Вы выжали из дисковой подсистемы все что можно Вам нужно горизонтально масштабироваться в онлайне, например на

public cloud

Когда использовать НО

Объем данных в памяти и в БД отличается в разы Разработка и администрирование распределенной системы это не

шутка Сеть: критическая точка

Распределенный запросы плохо масштабируются.

Стрельба дробью — тоже.

Дизайн данных Самый быстрый доступ по главному ключу Помещайте родственные данные в одну партицию

Их можно обрабатывать совместно прямо на узле грида

Сетевой запрос будет обрабатывать только 1 узел

Балансируйте размер объектов в кеше Маленькие объекты — много сетевых обращений

Большие объекты — избыточный трафик

Дизайн: Ускорение доступа Используйте денормализацию данных

Некоторые данные можно дублировать в нескольких местах Подсчитайте часто используемые агрегаты заранее

Минимизируйте обращения по сети Используйте индексы

IMDG предоставляет индексы для поиска по полям объектов Создавайте свои собственные индексы

Транзакции — КВИНТЭССЕНЦИЯ ЗЛА

Транзакций IMDG — распределенная система: мы должны

использовать 2PC Уже на 8 узлах скорость падает на 2 порядка

Существуют сценарии нарушения целостности

В большинстве систем транзакциями можно пожертвовать

Либо использовать цепочки идемпотентных операции

Перевод денег: шаг 1 Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма,

статус:начат) Считать счет 1 и проверить, что order_id еще к нему не применялся Обновить счет 1, списав деньги и добавив order_id в список

примененных операций Обновить статус order_id на списано

Перевод денег: шаг 2 Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма,

статус:списано) Считать счет 2 и проверить, что order_id еще к нему не применялся Обновить счет 2, начислив деньги и добавив order_id в список

примененных операций Обновить статус order_id на начисленно

Перевод денег: завершение Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма,

статус:начисленно) Считать счет 1 и удалить ссылку на order_id Считать счет 2 и удалить ссылку на order_id Обновить статус order_id на обработан Транзакция завершена

• Обычный рубрикатор электронного магазина

• Хотим

• Искать по ключевому слову

• Выбирать продукты из категории

• Пейджинг

• Фильтрацию продуктов по атрибутам (размер, цвет и т.д.)

• Код сервисов stateless

• Все данные находятся в IMDG

• Легко добавить сервер приложений в систему

• С ростом датасета мы можем увеличивать IMDG

• IMDG также используется как Message Bus

• Данные приходят в слой 1

• Проходят первичную обработку

• Передаются в слой 2

• Проходят аггрегацию

• Передаются в слой 3 для использования клиентами

Oracle Coherence

Gigaspaces GemFire Hazelcast Terracotta

Координация P2P Центр. P2P P2P P2P

Запросы Фильтрация

SQL ODQL Фильтрация

Нет

Лицензия Commercial Com./Free Commercial Free Free

Near Cache Да Да Да Нет Да

Выполнение Да Да Да Нет Нет*

Платформа Java/C/.Net Java/C/.Net Java Java Java

Scale-out Да Нет Да Да Нет*

Заключение При помощи IMDG вы можете

Радикально уменьшить нагрузку на БД и время отклика

Горизонтально масштабироваться во время выполнения (например на public cloud)

Вести параллельную обработку данных на кластере

Обрабатывать данные в реальном времени

Обрабатывать тысячи транзакций в секунду

Сделать невозможное возможным!

Материалы http://blog.griddynamics.com/ Сайты вендоров, особенно форумы поддержки InfoQ: http://www.infoq.com/ Cameron Purdy, /dev/null blog: http://www.jroller.com/cpurdy/ Nati Shalom: http://natishalom.typepad.com/ Brian Oliver: http://brianoliver.wordpress.com/ http://www.highscalability.com/

Вопросы ?

Спасибо

Alexey Kharlamovaharlamov@gmail.comSkype: aharlamov