Embed Size (px)
DESCRIPTION
jug.ru
Citation preview
Распределённые кэши, блеск и нищета
Алексей Рагозин
jug.ru
Июнь 2014
Проблема выбора
Базворды
• Key value
• Distributed Hash Table
• In-memory
• Horizontal scalability
• Redundant storage
3 tier architecture
Data tier
Business logic tier
Presentation tier
Cache
Storage
Хранилище
Основная задача ‐ долговременное хранение
Худшее, что может случиться ‐ потеря данных
Время жизни данных ‐ годы
Операционная модель ‐ “база данных”
Распределённый кэш
Основная задача ‐ высокая доступность сервиса
‐ малое время доступа к данным
Худшее, что может случиться ‐ возврат неактуальных данных
Время жизни данных ‐ до перезапуска
Операционная модель ‐ “модуль приложения”
Кэши и хранилища
Распределённость кэша
Ёмкость
до единиц TiB
Время доступа
сетевые задержки + 0.5 ms
Request per Second
линейная масштабируемость
по серверам и по ядрам
Когерентность данных
Проблема гидрации
java.util.HashMap
100GiB – легко 1M RPS – легко
Хранение данных в памяти одного процесса зачастую на порядок эффективнее распределенного
Может быть полезно, иногда
Killer feature !!!
Кэш и бизнес логика
Кэш API должен органично стыковаться с языком бизнес логики
Один язык
“Толстая” библиотека
Rich API
Client side features: L1 caching, etc
Хранение Java объектов
Yet another serialization for Java
Кэш и сквозное чтение
Сквозное чтение – read through
Сквозная запись – write through
Отложенная запись – write behind
PRO: Кэш – логический интерфейс к хранилищу
CON: Нюансы интеграции
Cluster shared memory
Решение проблемы “shared state” для “share nothing” кластеров
Быстрый доступ (In-memory)
Когерентность данных
“Атомарные” операции
Redis
Пример “shared state” сервиса для PHP и других типичных web технологий
Уроки, которые я выучил при работе с Oracle Coherence и другими распределёнными
хранилищами.
Под грифом IMHO
Распределённость …
Технологии для диссертаций
Paxos
Consistent hashing
Технологии для enterprise решений
Партицирование
Ведущий – ведомый (протокол консенсуса нужен только для выбора ведущего)
Key / Value модель
Key / Value модель требует денормализации!
Минимизация числа запросов
Проблемы с referral integrity между таблицами
Проблемы атомарности изменений
Кэш – это индекс
Кэш — вспомогательная структура данных, позволяющая сократить время выполнения запросов к хранилищу данных.
Модель данных кэша должна выбираться исходя из запросов, время выполнения которых вы хотите сократить!
Распределённые очереди
Не делайте из кэша распределённую очередь
Не делайте!
Не делайте!
Если вам нужна очередь, возьмите очередь
Опыт работы с Coherence
Решения делятся на те, которые
Просто работают
web sessions, мало нагруженные кэши, …
Просто работают, при правильном дизайне
all in-memory, proactive caching
Постоянно доставляют проблемы
Тесная интеграция с БД, “распределённая” бизнес логика
Coherence + DB = …
Распределённый кэш Быстрые операции
Высокая конкурентной
Наивная потоковая модель
java.util.Map контракт
База данных Широкий разбросc времён выполнения операций
Вариативная производительность
JDBC
Coherence + DB = …
Problem
Learn
Tune Something
changes
Cache and database
disharmonized
All in-memory, proactive caching
Данные грузятся в кэш заранее
Источник данных исчезает с критического пути
Проблема загрузки данных
Проблема частичного восстановления данных
Проблема синхронизации данных с источником
Не панацея
In-memory не значит супер быстро
Есть запросы, которые могут убить кэш
Другие антипаттерны
Распределённый кэш – не вычислительный грид
Архитектура потоков не рассчитана на тяжёлые вычисления
Злоупотребления размером данных
Key и Value должны быть разумного размера
Батчи должены быть разумного размера
IO операции в потоке обработки данных
Например обращение к соседнему распределённому кэшу
Учите мат. часть
Какой MTU настроен в вашей OS?
Какой MTU настроен в вашем свитче?
Мониторите ли вы ошибки сетевых интерфейсов?
Какой у вас JDBC пул?
Используете ли вы отдельный read-only пул?
Используется ли у вас FIFO очередь JDBC пуле?
Распределённые кэши, перспективы и спекуляции
Под грифом IMHO
Попытки стандартизации
• JSR 107: JCACHE – Java Temporary Caching API
• JSR 347: Data Grids for the Java™ Platform
Нужно ли это?
В облаках побеждает железо
На плохо настроенном железе, любой софт работает плохо
Вертикально интегрированная аппаратно программная платформа, позволяет
обеспечить производительность
дифференцировать продукт от конкурентов
Cache is a feature
Кэш – галочка сервера приложений
Часть business logic tier
Насаждение правильных паттернов
Спекуляции о будущем
Развитие Open source – Hazelcast и прочие
Уменьшение хайфа
Вытеснение кэшей из областей лежащих за пределами уровня бизнес логики NoSQL решениями
Новые стандарты серверов приложений?
Thank you
Alexey Ragozin [email protected]
http://blog.ragozin.info - my articles http://code.google.com/p/gridkit http://github.com/gridkit - my open source code http://aragozin.timepad.ru - community events in Moscow
