High Load 2009 Imdg Presentation

In Memory Data Grids Alexey Kharlamov Development Manager Grid Dynamics, 2009

О этот новый мир ●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 на обработан ● Транзакция завершена

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

Заключение ● П ри пом ощ и I M D G вы м о ж ете ● Радикально уменьшить нагрузку на БД и время отклика ● Горизонтально масштабироваться во время выполнения (например на 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 Kharlamov Development Manager Grid Dynamics, 2009

http://www.highload.ru	257
http://highload.ru	40
http://www.slideshare.net	2
http://highload.ontico.ru	1

High Load 2009 Imdg Presentation

by HighLoad2009 on Oct 11, 2009

Accessibility

Upload Details

Usage Rights

4 Embeds 300

Statistics

High Load 2009 Imdg Presentation — Presentation Transcript