В последнее время интерес к облачным архитектурам растёт с каждым днём, поскольку это один из самых эффективных способов масштабирования приложения, не прилагая особых усилий, а узким местом любого высоконагруженного проекта является хранилище данных, в частности реляционная база данных.
Для борьбы с недостатками традиционных баз данных в основном используются два подхода: 1) Кэширование результатов запроса
- Плюсы: высокая скорость доступа к данным
- минусы: требует компромисса между актуальностью данных и скоростью доступа, поскольку данные в кеше могут устареть, а удаление старых данных из кеша и последующее кэширование новых означает дополнительные задержки и нагрузку на систему
- Плюсы: хорошая горизонтальная масштабируемость, модель данных предметной области соответствует модели хранения данных.
- Недостатки: низкая скорость получения результатов при использовании диска; практически невозможно обеспечить работу внутрикорпоративного программного обеспечения, ориентированного на работу с конкретной реляционной базой данных.
Такой подход очень быстро получил широкое признание среди специалистов в области проектирования облачных платформ, а также любых систем, требующих практически неограниченного масштабирования системы хранения данных.
Многие известные компании выпустили на рынок системы такого типа:
- Когерентность Оракула - Ява/С/.
NET
- VMWare Gemfire — Джава
- ГигаПространства - Ява/С/.
NET
- JBoss (RedHat) Infinispan - Джава
- Терракота Джава
Итак, что такое сетка данных в памяти?
Это кластерное хранилище типа «ключ-значение», которое предназначено для высоконагруженных проектов с большими объемами данных и повышенными требованиями к масштабируемости, скорости и надежности.Основными частями IMDG являются кэши (в GemFire они называются регионами).
Кэш в IMDG — это распределенный ассоциативный массив (т.е.
кэш реализует интерфейс Java Map), обеспечивающий быстрый одновременный доступ к данным с любого узла кластера.
Кэш также позволяет обрабатывать эти данные распределенным образом, т.е.
модификацию любых данных можно производить с любого узла кластера, причем не обязательно вынимать данные из кэша, изменять их и затем помещать обратно.
.
Почти все кэши IMDG поддерживают транзакции.
Данные в кэшах хранятся в сериализованной форме (т.е.
в виде массива байтов).
1. Скорость
Все данные располагаются в оперативной памяти кластера, что существенно сокращает время доступа.Поскольку все данные сериализованы, то время получения объекта из кэша = (время перемещения объекта на конкретный узел кластера) + (время десериализации).
Если запрошенный объект находится на том же узле, на котором был сделан запрос, то (время получения) = (время десериализации).
И здесь мы видим, что доступ к данным мог бы быть совершенно бесплатным, если бы объект не нуждался в десериализации, для чего в концепцию IMDG было введено понятие околокэша.
Near-cache — это локальный кэш объектов для быстрого доступа, все объекты в нем хранятся готовыми к использованию.
Если для данного кеша настроен околокэш, то объекты попадают туда автоматически при первом запросе на получение этих объектов.
Поскольку околокэш со временем может вырасти до больших размеров, что может привести к нехватке памяти, для ограничения роста количества кешируемых объектов предусмотрены следующие опции:
- expiration — время жизни объекта в кеше
- выселение - удаление объекта из кэша
- ограничение на количество хранимых объектов
2. Надежность
Данные в кластере хранятся в разделах (частях), причем эти разделы равномерно распределены по всему кластеру, причем каждый раздел реплицируется на определенное количество узлов (в зависимости от конфигурации кластера и требований к надежности хранения данных).Попадание объекта в ту или иную партицию однозначно определяется хеш-функцией.
Поскольку при работе в условиях высокой нагрузки выход из строя одного узла кластера (или сразу нескольких узлов, если бы это были виртуальные машины внутри одного аппаратного сервера) не является чем-то невероятным, то для обеспечения сохранности данных в конфигурации кэша задается количество узлы, потерю которых кластер должен пережить безболезненно.
Этот показатель определяет количество копий каждого раздела.
Те.
если мы укажем, что потеря 2-х узлов не должна приводить к потере данных, то каждый раздел будет храниться на 3-х разных узлах кластера, и при выходе из строя 2-х узлов данные останутся нетронутыми.
Если одновременно в кластере останется более одной ноды, то снова будет создано 3 копии всех данных, и кластер будет готов к новым неприятностям.
3. Масштабируемость
Состав кластера (количество узлов) может меняться без остановки работы всего кластера, а корректность работы кластера, а также целостность и доступность данных контролируется самой сеткой без какого-либо вмешательства со стороны программиста.Те.
при увеличении нагрузки или объема данных можно просто поднять еще несколько настроенных узлов, которые автоматически присоединятся к кластеру, а данные внутри самого кластера будут перебалансированы для равномерного распределения данных по узлам, при этом объем перемещаемых данных увеличится быть минимальным, чтобы не создавать лишней нагрузки на сеть.
4. Актуальность данных
При использовании IMDG вы всегда получаете актуальные данные, потому что.при выполнении put на все узлы кластера отправляется уведомление о том, что объекты с такими-то ключами получили новое значение.
Каждый узел обновляет свои разделы, содержащие эти ключи, и удаляет старые значения из своего околокэша.
5. Уменьшение нагрузки на базу данных
IMDG можно использовать не только как автономное хранилище, но и как системный узел, снимающий нагрузку со сложно масштабируемой реляционной базы данных.
Для чтения и записи из/в базу данных в конфигурации каждого кэша указывается Загрузчик, который будет отвечать за чтение/запись объектов в базу данных.
Существует несколько вариантов организации доступа к данным:
- во время запуска приложения засасывать в сетку все необходимые данные из базы данных (так называемая предварительная загрузка).
Увеличивается время запуска приложения, увеличивается и потребление памяти, но увеличивается скорость работы
- во время работы приложения подтягивать необходимые данные на основании запросов клиентов (read-through).
Выполняется автоматически с использованием объекта Loader для этого кэша.
Время запуска приложения невелико, первоначальные затраты памяти также невелики, но есть дополнительные затраты времени на обработку запросов, вызывающих сквозное чтение.
- При каждой операции помещения в кэш автоматически делается запись в базу данных с помощью Loader (так называемая отложенная запись).
Подходит только для систем, где основная нагрузка приходится на чтение.
- Данные, ожидающие записи в базу данных, накапливаются, а затем делается один запрос на запись в базу данных.
Сигналом для выполнения такого запроса может быть определенный объем данных, ожидающих записи, или тайм-аут. Подходит для систем с интенсивным объемом записи, но сложнее реализовать.
, продолжают работать в прежнем режиме.
Заключение
In-memory-data-grid — относительно молодая, но хорошо зарекомендовавшая себя технология, которую разрабатывают многие крупные вендоры.Он сочетает в себе преимущества NoSQL и систем кэширования, устраняет некоторые их существенные недостатки и позволяет поднять производительность системы на новый уровень.
Если эта статья показалась вам интересной, то в следующий раз я буду рад рассказать о любом конкретном решении из семейства IMDG, а также коснуться вопросов построения и использования индексов, механизмов сериализации и взаимодействия с другими платформами в этих системах.
УПД: следующая статья Теги: #in-memory-data-grid #imdg #oracle coherence #gemfire #infinispan #gigaspaces #хранилище данных #масштабирование #высокая нагрузка #облачные технологии #Высокая производительность
-
«Яндекс.такси» Запустили В Ульяновске
19 Oct, 24 -
Обход Капчи С Помощью Headless Chrome
19 Oct, 24 -
Objective-C: Как Работают Блоки
19 Oct, 24 -
Intellij Идея 2020.3
19 Oct, 24
