Может ли кто-нибудь привести примеры использования, когда вам было бы полезно использовать Redis и MongoDB в сочетании друг с другом?
95
Redis и MongoDB можно использовать вместе с хорошими результатами. Компания Craiglist, известная тем, что запускает MongoDB и Redis (наряду с MySQL и Sphinx). См. Презентацию Джереми Заводни.
MongoDB интересен постоянными, документально-ориентированными данными, индексируемыми различными способами. Redis более интересен для изменчивых данных или полупостоянных данных, чувствительных к задержкам.
Вот несколько примеров конкретного использования Redis поверх MongoDB.
В версии до 2.2 MongoDB еще не было механизма истечения срока действия. Коллекции с ограничениями на самом деле нельзя использовать для реализации реального TTL. Redis имеет механизм истечения срока действия на основе TTL, что позволяет удобно хранить изменчивые данные. Например, пользовательские сеансы обычно хранятся в Redis, а пользовательские данные будут храниться и индексироваться в MongoDB. Обратите внимание, что MongoDB 2.2 представила механизм истечения срока действия с низкой точностью на уровне сбора (например, для очистки данных).
Redis предоставляет удобный набор типов данных и связанные с ним операции (объединение, пересечение, различие на нескольких наборах и т. Д.). Довольно легко реализовать базовый механизм фасетного поиска или тегов поверх этой функции, что является интересным дополнением к более традиционным возможностям индексирования MongoDB.
Redis поддерживает эффективную блокировку всплывающих операций со списками. Это можно использовать для реализации специальной распределенной системы очередей. Он более гибкий, чем настраиваемые курсоры MongoDB IMO, поскольку серверное приложение может прослушивать несколько очередей с тайм-аутом, атомарно передавать элементы в другую очередь и т.д ... Если приложению требуется некоторая организация очереди, имеет смысл сохранить очередь в Redis и сохраните постоянные функциональные данные в MongoDB.
Redis также предлагает механизм публикации / подписки. В распределенном приложении может быть полезна система распространения событий. Это снова отличный вариант использования Redis, в то время как постоянные данные хранятся в MongoDB.
Поскольку намного проще разработать модель данных с MongoDB, чем с Redis (Redis - более низкоуровневый), интересно извлечь выгоду из гибкости MongoDB для основных постоянных данных и дополнительных функций, предоставляемых Redis (низкая задержка , истечение срока действия элемента, очереди, публикация / подписка, атомарные блоки и т. д.). Это действительно хорошее сочетание.
Обратите внимание, что вы никогда не должны запускать сервер Redis и MongoDB на одном компьютере. Память MongoDB предназначена для замены, а Redis - нет. Если MongoDB инициирует некоторую операцию подкачки, производительность Redis будет катастрофической. Они должны быть изолированы на разных узлах.
Очевидно, различий гораздо больше, но для очень подробного обзора:
Для вариантов использования:
Технически:
Есть некоторое совпадение, но очень часто используются оба. Вот почему:
Redis можно использовать как замену традиционному хранилищу данных, но чаще всего он используется с другим обычным «длинным» хранилищем данных, таким как Mongo, Postgresql, MySQL и т. Д.
источник
Redis отлично работает с MongoDB в качестве кэширующего сервера. Вот что происходит.
Каждый раз, когда мангуст выдает запрос кеша, он сначала переходит на кеш-сервер.
Кэш-сервер проверит, был ли когда-либо выдан этот точный запрос.
Если этого не произошло, то кеш-сервер примет запрос, отправит его в mongodb, и Mongo выполнит запрос.
Затем мы берем результат этого запроса, затем он возвращается к кеш-серверу, кеш-сервер сохранит результат запроса на себе.
Он скажет, что каждый раз, когда я выполняю этот запрос, я получаю этот ответ, и поэтому он будет поддерживать запись между отправленными запросами и ответами, которые возвращаются из этих запросов.
Кеш-сервер примет ответ и отправит его обратно в mongoose, mongoose даст его для выражения, и в конечном итоге он окажется внутри приложения.
Каждый раз, когда тот же точный запрос выдается снова, mongoose отправит тот же запрос на сервер кеша, но если сервер кеша увидит, что этот запрос был выпущен до того, как он не отправит запрос на mongodb, вместо этого он будет принимать ответ на запрос, который он получил в последний раз, и немедленно отправить его обратно мангусту. Здесь нет ни индексов, ни полного сканирования таблицы, ничего.
Мы делаем простой поиск, чтобы узнать, был ли этот запрос выполнен? Да? Ладно, прими запрос и немедленно отправь его обратно, не отправляя ничего на mongo.
У нас есть сервер мангуста, сервер кеширования (Redis) и Mongodb.
На кэш-сервере может быть хранилище данных с типом значения ключа хранилища данных, где все ключи представляют собой некоторый тип запроса, выданного ранее, а значение - результат этого запроса.
Так что, возможно, мы ищем кучу сообщений в блоге от _id.
Так что, возможно, здесь ключи - это _id записей, которые мы искали раньше.
Итак, давайте представим, что мангуст выдает новый запрос, в котором он пытается найти сообщение в блоге с _id, равным 123, запрос поступает на сервер кеширования, сервер кеша проверяет, есть ли у него результат для любого запроса, который искал _id из 123.
Если он не существует на сервере кеширования, этот запрос принимается и отправляется экземпляру mongodb. Mongodb выполнит запрос, получит ответ и отправит его обратно.
Этот результат отправляется обратно на сервер кеша, который принимает этот результат и немедленно отправляет его обратно в мангуст, чтобы мы получили как можно более быстрый ответ.
Сразу после этого кэш-сервер также примет выданный запрос и добавит его в свою коллекцию запросов, которые были выданы, и получит результат запроса и сохранит его прямо напротив запроса.
Итак, мы можем представить, что в будущем мы снова выдадим тот же запрос, он попадет на сервер кеширования, он просмотрит все ключи, которые у него есть, и скажет, что я уже нашел этот блог, он не обращается к монго, он просто требует результат запроса и отправляет его прямо мангусту.
Мы не делаем сложной логики запросов, индексов и ничего подобного. Это как можно быстрее. Это простой поиск значения ключа.
Это обзор того, как кеш-сервер (Redis) работает с MongoDB.
Теперь есть другие опасения. Кешируем ли мы данные навсегда? Как мы обновляем записи?
Мы не хотим всегда хранить данные в кеше и читать из кеша.
Кэш-сервер не используется ни для каких операций записи. Слой кеша используется только для чтения данных. Если мы когда-либо записываем данные, запись всегда будет переходить к экземпляру mongodb, и нам нужно убедиться, что каждый раз, когда мы записываем данные, мы очищаем любые данные, хранящиеся на сервере кеширования, которые связаны с записью, которую мы только что обновили в Mongo.
источник