Документ обсуждает концепцию in-memory data grids (IMDG) и их применение в обработке больших объемов данных с высокой производительностью. Подчеркивается важность масштабирования и параллельной обработки, а также необходимость оптимизации доступа к данным с использованием кеширования и денормализации. Рассматриваются транзакции и их управление в распределенных системах, с примерами практических операций, таких как перевод денег.

1. In Memory Data Grids Alexey Kharlamov [email_address] Skype: aharlamov

2. О этот новый мир Web 2.0: AJAX и стремление к высокой интерактивности Экспоненциальный рост трафика Закон Мура умирает Рост степени интеграции замедляется Увеличение плотности упаковки не ведет к росту производительности Железо продолжает дешеветь

3. Что же делать? Расти вширь — использовать параллельную обработку (scale out) Гауссовское распределение — наш спаситель! Мы можем делать только 20% работы и получать 80% заработной платы Использовать принцип пули Сделать работу заранее и сохранить ее в памяти Память продолжает дешеветь

4. Определение Grid — а что это вообще такое? Машины действующие совместно для решения одной задачи А In-Memory Data Grid Данные в памяти надежно хранятся Всегда доступны и консистентны Network Attached Memory

5. Ассоциативный массив Данные делятся на разделы/партиции Партиция реплицируются на несколько узлов

6. Динамический кластер ПО Grid-а автоматически управляет узлами Большое число партиций Появление нового узла Перемещаем часть партиций на новый узел Выход узла из системы Переводим backup-ы в master-а Формируем backup-ы на живых узлах Можем именять размер кластера во время работы

7. Кеширование базы данных Когда Есть паттерн доступа в кеш Высокая плотность записи Что Read Through/Write behind Вытеснение и обновление Запросы не консистентны с кешем и нагружают БД

8. Все свое ношу с собой Когда: безкомпромисный read/write; 20/80 Что Загружаем все данные в грид Запросы в грид, подписываемся на события Сеть — узкое место Параллельная обработка внутри узлов грида Near Cache

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

10. Когда использовать НО Объем данных в памяти и в БД отличается в разы Разработка и администрирование распределенной системы это не шутка Сеть: критическая точка Распределенный запросы плохо масштабируются. Стрельба дробью — тоже.

11. Дизайн данных Самый быстрый доступ по главному ключу Помещайте родственные данные в одну партицию Их можно обрабатывать совместно прямо на узле грида Сетевой запрос будет обрабатывать только 1 узел Балансируйте размер объектов в кеше Маленькие объекты — много сетевых обращений Большие объекты — избыточный трафик

12. Дизайн: Ускорение доступа Используйте денормализацию данных Некоторые данные можно дублировать в нескольких местах Подсчитайте часто используемые агрегаты заранее Минимизируйте обращения по сети Используйте индексы IMDG предоставляет индексы для поиска по полям объектов Создавайте свои собственные индексы Транзакции — КВИНТЭССЕНЦИЯ ЗЛА

13. Транзакций IMDG — распределенная система: мы должны использовать 2PC Уже на 8 узлах скорость падает на 2 порядка Существуют сценарии нарушения целостности В большинстве систем транзакциями можно пожертвовать Либо использовать цепочки идемпотентных операции

14. Перевод денег: шаг 1 Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма, статус: начат ) Считать счет 1 и проверить, что order_id еще к нему не применялся Обновить счет 1, списав деньги и добавив order_id в список примененных операций Обновить статус order_id на списано

15. Перевод денег: шаг 2 Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма, статус: списано ) Считать счет 2 и проверить, что order_id еще к нему не применялся Обновить счет 2, начислив деньги и добавив order_id в список примененных операций Обновить статус order_id на начисленно

16. Перевод денег: завершение Считать ордер на перевод денег (order_id, счет 1, счет 2, сумма, статус: начисленно ) Считать счет 1 и удалить ссылку на order_id Считать счет 2 и удалить ссылку на order_id Обновить статус order_id на обработан Транзакция завершена

18. Обычный рубрикатор электронного магазина Хотим Искать по ключевому слову Выбирать продукты из категории Пейджинг Фильтрацию продуктов по атрибутам (размер, цвет и т.д.)

19. Код сервисов stateless Все данные находятся в IMDG Легко добавить сервер приложений в систему С ростом датасета мы можем увеличивать IMDG IMDG также используется как Message Bus

20. Данные приходят в слой 1 Проходят первичную обработку Передаются в слой 2 Проходят аггрегацию Передаются в слой 3 для использования клиентами

21. 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 Да Нет Да Да Нет*

22. Заключение При помощи IMDG вы можете Радикально уменьшить нагрузку на БД и время отклика Горизонтально масштабироваться во время выполнения (например на public cloud) Вести параллельную обработку данных на кластере Обрабатывать данные в реальном времени Обрабатывать тысячи транзакций в секунду Сделать невозможное возможным!

23. Материалы 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/

24. Вопросы ?

25. Спасибо Alexey Kharlamov [email_address] Skype: aharlamov