Относительно повышения эффективности системы с большим объемом кэш-памяти
я собираюсь повысить эффективность системы с большим объемом кеша, которая имеет следующие свойства/архитектуру:
Система состоит из 2 компонентов: серверной части с одним экземпляром и нескольких экземпляров внешнего интерфейса, распределенных по удаленным центрам обработки данных.
Серверная часть генерирует данные и записывает их в реляционную базу данных, которая реплицируется в несколько центров обработки данных.
Фронтенды обрабатывают клиентские запросы (на основе общего веб-трафика), считывая данные из базы данных и обслуживая их. Данные хранятся в локальном кеше в течение часа до истечения срока их действия, и их необходимо снова получить.
(Политика вытеснения кэша основана на LRU).
Я хочу отметить, что есть две проблемы с реализацией выше:
Оказывается, что многие обращения к базе данных являются избыточными, потому что базовые данные на самом деле не изменились. С другой стороны, изменение не отражается до тех пор, пока не истечет срок жизни кэша, что приводит к проблемам устаревания.
Можете ли вы посоветовать решение, которое устраняет обе эти проблемы?
должно ли решение измениться, если данные хранились в базе данных nosql, такой как cassandra, а не в классической базе данных?
Ответы 1
К сожалению, здесь нет серебряной пули. Есть два очевидных варианта:
- Сохраняйте длинный TTL или кеш навсегда, но делайте данные кеша недействительными при их обновлении. Это может стать довольно сложным и подверженным ошибкам
- Просто уменьшите TTL, чтобы получать более быстрые обновления. Подход с низким TTL - это ИМХО подход KISS. Мы идем всего за 27 секунд. Кэш с таким низким TTL не имеет большого количества попаданий при нормальной работе, но очень помогает, когда на ваше приложение попадает толпа флэш-памяти.
В случае, если ваша база данных достаточно мощная и имеет приемлемую задержку, подход 2 является самым простым.
Если ваша база данных не имеет приемлемой задержки или, возможно, ваше приложение выполняет несколько последовательных операций чтения из базы данных для каждого веб-запроса, вы можете использовать кеш, который обеспечивает опережающее или фоновое обновление. Это означает, что кеш обновляет записи автоматически, и нет дополнительной задержки, кроме первого чтения. Однако у этого подхода есть обратная сторона увеличения нагрузки на базу данных.
Cassandra может не поддерживать те же стратегии доступа, что и классическая база данных. Переход на Cassandara также повлияет на ваше кеширование, например. если вы кешируете также результаты запроса. Однако концепция высокого уровня остается прежней. Ваши уровни доступа к данным могут измениться на асинхронный или реактивный шаблон, поскольку Cassandara поддерживает это.
Если вы хотите сделать инвалидацию (решение 1), с помощью Cassandara вы можете получить информацию из базы данных, данные которой были обновлены, см. КАССАНДРА-8844. Вы можете получить подобную информацию из «классических» баз данных SQL, но это особенность поставщика.
а также я не уверен, связаны ли ваши 2 упомянутых варианта соответственно с моими 2 упомянутыми проблемами
и что ты имеешь в виду под "не нанимать"
Если ваши записи не такие тяжелые, то было бы лучше кэшировать данные на сервере в памяти (Redis), и каждая запись должна делать недействительными соответствующие ключи на сервере Redis, чтобы вы всегда обращались к постоянному хранилищу для кеширования пропущенных ключей.
привет cruftex большое спасибо! (: есть шанс, что вы можете быть более конкретным, можете ли вы предоставить более подробную информацию о том, как изменится решение, если данные будут храниться в Cassandra, а не в классической базе данных?