Настройка:
Представьте себе услугу "Twitter", где пользователь отправляет сообщение, которое затем считывается многими (сотнями, тысячами или более) пользователями.
Мой вопрос касается наилучшего способа архивирования кеша и базы данных для оптимизации быстрого доступа и многих чтений, но при этом сохраняйте исторические данные, чтобы пользователи (если они захотели) могли видеть старые сообщения. Предположение здесь состоит в том, что 90% пользователей будут интересоваться только новыми вещами, и что старые материалы получат доступ к ним изредка. Другое предположение здесь состоит в том, что мы хотим оптимизировать 90%, и это нормально, если более старые 10% занимают немного больше времени для извлечения.
Учитывая это, мои исследования, похоже, указывают на использование кеша на 90%, а затем для хранения сообщений в другой долгосрочной перспективе. Поэтому до сих пор моя идея - использовать Redis для кеша. Преимущества в том, что Redis работает очень быстро, а также встроен в паб /sub, который идеально подходит для публикации сообщений многим людям. И затем я рассматривал возможность использования MongoDB в качестве более постоянного хранилища данных для хранения тех же сообщений, которые будут доступны по мере их истечения из Redis.
Вопросы:
1. Поддерживает ли эта архитектура воду? Есть лучший способ сделать это?
2. Что касается механизма хранения сообщений как в Redis, так и в MongoDB, я думал о том, что приложение делает 2 записи: 1-й - пишите Redis, а затем он доступен для подписчиков. 2-й - после успешного хранения в Redis, немедленно напишите MongoDB. Это лучший способ сделать это? Должен ли я вместо этого использовать Redis, нажимая истекшие сообщения в MongoDB? Я подумал об этом, но я не мог найти много информации о том, как напрямую перенаправить MongoDB из Redis.
