1. In Memory Data Grids
Alexey Kharlamov
Development Manager
Grid Dynamics, 2009
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 на обработан
●
Транзакция завершена
17. Oracle
Gigaspaces GemFire Hazelcast Terracotta
Coherence
Координация 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 Да Нет Да Да Нет*
18. Заключение
●
П ри пом ощ и I M D G вы м о ж ете
●
Радикально уменьшить нагрузку на БД и время отклика
●
Горизонтально масштабироваться во время выполнения
(например на public cloud)
●
Вести параллельную обработку данных на кластере
●
Обрабатывать данные в реальном времени
●
Обрабатывать тысячи транзакций в секунду
●
С дел а ть н ево з м ож н о е во з м о ж н ы м !
19. Материалы
●
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/
