Согласованность данных для NoSQL + распределенный кэш в очень параллельной среде

На слайде вы видите очень грубую архитектуру системы бронирования. Это очень параллельная среда, в которой многие пользователи одновременно могут попытаться забронировать один и тот же отель/номер.

В основе у нас база данных NoSQL, для быстрого ответа/запроса есть распределенный кеш и приложение, которое запрашивает данные.

Идея этого слайда заключается в том, что при использовании NoSQL + Distributed Cache у вас возникнут проблемы с синхронизацией, то есть проблемы с согласованностью данных. Вам необходимо синхронизировать распределенный кеш с базой данных NoSQL.

Вопрос: Какие решения/методы уже существуют для такого случая, помимо IMDG? Это могут быть как фреймворки, так и/и лучшие практики. Существуют ли какие-то конкретные распределенные кеши, решающие эту проблему?

Вопрос2[обновлено]: По каким причинам мы записываем в базу данных NoSQL, а не в кеш? Это транзакции, возможность сбоя узла или что-то еще?

P.S. Это не мой слайд, и автор утверждает, что это отличный пример использования IMDG.

введите здесь описание изображения


nosql architecture caching data-consistency high-load
person VB_    schedule 19.02.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Вам действительно нужен распределенный кеш? Решения NoSQL по своей природе очень производительны, приближаясь к производительности автономных кешей (таких как memcached).

Я могу получить время доступа ~ 10 мс из Cassandra, что не намного медленнее, чем у большинства кешей.

Держу пари, что к тому времени, когда вы добавите накладные расходы на проверку кеша и сетевые накладные расходы из-за пропущенных попаданий в кеш, вам будет лучше перейти прямо к своей базе данных.

Вы по-прежнему можете использовать кеши для менее изменчивых вещей, таких как типы номеров, цены и т. д.

person Rob Conklin    schedule 20.02.2015
comment
Спасибо за ответ! Можете ли вы объяснить, пожалуйста, ваше последнее утверждение? Почему я должен использовать кеши для номеров, цен и т. д., но не для отелей? Также не могли бы вы попытаться ответить на второй вопрос (я только что добавил его) - person VB_; 20.02.2015
comment
Я говорю, что вещи, которые меняются очень быстро (например, доступность номеров), вероятно, не должны кэшироваться. Я бы отделил определения номеров от наличия номеров. Поэтому, вероятно, храните документ для каждой комнаты и отдельные документы для каждого дня со списком доступных комнат в нем (документ доступности). Документ комнаты будет кэшироваться, так как статистика комнаты, фотографии и т. д. не изменятся. Документ доступности, который вы хотели бы получить для каждого запроса. - person Rob Conklin; 20.02.2015
comment
Кэши - это кэши, а не хранилища данных. Кэш не требует таких вещей, как постоянная долговечность (выживание после сбоя и т. д.). Он даже не требует временной прочности. Как правило, они имеют фиксированный размер и не могут хранить больше этого размера. Теперь вы можете (и многие люди) использовать хранилища данных в качестве кэшей, но кэширование — это описание операции, а не технологии. Но, как правило, технология кэширования не обеспечивает надежного или согласованного чтения/записи. Они жертвуют этим ради скорости, которая является их целью. - person Rob Conklin; 20.02.2015