Вопрос по mongodb, nosql, redis – MongoDB с редисом

92

Кто-нибудь может привести примеры случаев использования Redis и MongoDB в сочетании друг с другом?

Ваш Ответ

3   ответа
0

Redis отлично работает с MongoDB в качестве сервера кэширования. Вот что происходит.

Каждый раз, когда mongoose отправляет запрос в кэш, он сначала переходит на сервер кеша.

Сервер кэширования проверит, был ли этот точный запрос когда-либо выполнен ранее.

Если это не так, то сервер кэширования примет запрос, отправит его на mongodb, и Mongo выполнит запрос.

Затем мы возьмем результат этого запроса, затем он вернется на сервер кеша, сервер кеша сохранит результат запроса на себе.

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

Сервер кэширования примет ответ и отправит его обратно в mongoose, mongoose предоставит его для экспресс-обработки, и в конечном итоге он окажется внутри приложения.

Каждый раз, когда тот же самый точный запрос выполняется снова, mongoose отправит тот же запрос на сервер кеша, но если сервер кеша увидит, что этот запрос был выполнен, прежде чем он не отправит запрос на mongodb, вместо этого он собирается принять ответ на запрос, который он получил в последний раз, и немедленно отправил его обратно в мангуст. Здесь нет индексов, нет полного сканирования таблицы, ничего.

Мы делаем простой поиск, чтобы сказать, был ли выполнен этот запрос? Да? Хорошо, возьмите запрос и немедленно отправьте его обратно, и ничего не отправляйте Монго.

У нас есть сервер Мангуста, сервер кеша (Redis) и Mongodb.

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

Так что, возможно, мы ищем кучу постов от _id.

Так что, возможно, ключи здесь - это _id записей, которые мы просматривали ранее.

Итак, давайте представим, что mongoose выдает новый запрос, где он пытается найти запись блога с _id из 123, запрос поступает на сервер кеша, сервер кеша проверит, есть ли у него результат для любого запроса, который искал _id из 123.

Если он не существует на сервере кэширования, этот запрос принимается и отправляется экземпляру mongodb. Mongodb выполнит запрос, получит ответ и отправит его обратно.

Этот результат отправляется обратно на сервер кеша, который принимает этот результат и немедленно отправляет его обратно в mongoose, чтобы мы получили максимально быстрый ответ.

Сразу после этого сервер кэширования также примет выданный запрос и добавит его к своей коллекции выполненных запросов, примет результат запроса и сохранит его в соответствии с запросом.

Таким образом, мы можем представить, что в будущем мы снова выдадим тот же запрос, он попадет на сервер кеша, он смотрит на все имеющиеся у него ключи и говорит: о, я уже обнаружил, что blogpost не обращается к Монго, он просто берет результат запроса и отправляет его напрямую в mongoose.

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

Вот обзор того, как сервер кэширования (Redis) работает с MongoDB.

Теперь есть другие проблемы. Кешируем ли мы данные навсегда? Как мы обновляем записи?

Мы не хотим всегда хранить данные в кеше и читать из кеша.

Кеш-сервер не используется для каких-либо действий записи. Слой кеша используется только для чтения данных. Если мы когда-либо записываем данные, запись всегда будет передаваться экземпляру mongodb, и мы должны гарантировать, что каждый раз, когда мы записываем данные, мы очищаем любые данные, хранящиеся на сервере кэша, которые связаны с записью, которую мы только что обновили в Mongo.

23

Очевидно, естьfar больше различий, чем это, но для чрезвычайно высокого обзора:

Для случаев использования:

Redis is often used as a caching layer or shared whiteboard for distributed computation. MongoDB is often used as a swap-out replacement for traditional SQL databases.

Технически:

Redis is an in-memory db with disk persistence (the whole db needs to fit in RAM). MongoDB is a disk-backed db which only needs enough RAM for the indexes.

Есть некоторые совпадения, но очень часто используются оба. Вот почему:

MongoDB can store more data cheaper. Redis is faster for the entire dataset. MongoDB's culture is "store it all, figure out access patterns later" Redis's culture is "carefully consider how you'll access data, then store" Both have open source tools that depend on them, many of which are used together.

Redis можно использовать в качестве замены традиционного хранилища данных, но чаще всего его используют.with другой нормальный "длинный" хранилище данных, например, Mongo, Postgresql, MySQL и т. д.

155

Redis и MongoDB могут использоваться вместе с хорошими результатами. Компания, хорошо известная по работе с MongoDB и Redis (наряду с MySQL и Sphinx), является Craiglist. Увидетьэта презентация от Джереми Заводного.

MongoDB интересен для постоянных, ориентированных на документы, данных, проиндексированных различными способами. Redis более интересен для изменчивых данных или чувствительных к задержке полупостоянных данных.

Вот несколько примеров конкретного использования Redis поверх MongoDB.

Pre-2.2 MongoDB does not have yet an expiration mechanism. Capped collections cannot really be used to implement a real TTL. Redis has a TTL-based expiration mechanism, making it convenient to store volatile data. For instance, user sessions are commonly stored in Redis, while user data will be stored and indexed in MongoDB. Note that MongoDB 2.2 has introduced a low accuracy expiration mechanism at the collection level (to be used for purging data for instance).

Redis provides a convenient set datatype and its associated operations (union, intersection, difference on multiple sets, etc ...). It is quite easy to implement a basic faceted search or tagging engine on top of this feature, which is an interesting addition to MongoDB more traditional indexing capabilities.

Redis supports efficient blocking pop operations on lists. This can be used to implement an ad-hoc distributed queuing system. It is more flexible than MongoDB tailable cursors IMO, since a backend application can listen to several queues with a timeout, transfer items to another queue atomically, etc ... If the application requires some queuing, it makes sense to store the queue in Redis, and keep the persistent functional data in MongoDB.

Redis also offers a pub/sub mechanism. In a distributed application, an event propagation system may be useful. This is again an excellent use case for Redis, while the persistent data are kept in MongoDB.

Поскольку гораздо проще спроектировать модель данных с MongoDB, чем с Redis (Redis более низкого уровня), интересно воспользоваться гибкостью MongoDB для основных постоянных данных и дополнительными функциями Redis (низкая задержка). , истечение срока действия предмета, очереди, паб / саб, атомарные блоки и т. д.). Это действительно хорошая комбинация.

Обратите внимание, что вы никогда не должны запускать серверы Redis и MongoDB на одной машине. Память MongoDB предназначена для замены, а для Redis - нет. Если MongoDB запускает некоторую операцию обмена, производительность Redis будет катастрофической. Они должны быть изолированы на разных узлах.

Хорошие замечания о некоторых сравнительных сильных сторонах каждого.
MongoDB 2.2 (только что выпущен) добавляет поддержку TTL, которая касается вашего первого пункта:docs.mongodb.org/manual/tutorial/expire-data
само видео из выступления Джереми Заводного:youtube.com/watch?v=qFcB1Xw1WSk
Хорошие замечания о некоторых сравнительных сильных сторонах каждого. Одной из точек Redis является настройка в памяти. Существуют и другие проекты, ориентированные на низкую задержку, такие как AerospikeDB, которые ориентированы на кластеризацию и надежность, а также на хранилище SSD, которое можно использовать, когда сценарий использования в реальном времени выходит за рамки возможностей Redis.

Похожие вопросы