Redis, Mongo или Hazelcast?

Question

У нас есть веб-приложение JAVA, которое использует postgres (отдельная база данных с ведомым устройством) для хранения всех важных данных.

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

1) Нелипкие идентификаторы сеанса для балансировки нагрузки и допусков на разделение.

2) Кэш часто читаемых данных, доступных со всех веб-серверов (в альтернативе Memory/Memcache).

3) Очереди (электронная почта, SMS, задачи, выполняемые над кластером). Как правило, все они должны выполняться поверх xml api или scraping экрана.
Избегание дублирования обработки задач важно, но иногда это может произойти :-)

4) Постоянное хранение запросов и ответов API (много XML, много строк, но небольшое количество столбцов). (возможно, архивируйте, удалив старые запросы и ответы, чтобы сохранить набор данных небольшим).

5) Вход в обычное место. Стол будет продолжать расти. Также мне понадобится инструмент для доступа к журналам производства, не останавливая их. Какой-то поиск должен быть возможен на основе времени и/или строки поиска.

Я хочу, чтобы одно решение отвечало всем этим требованиям и рассматривало варианты redis, mongo и hazelcast (по моему личному предпочтению) как возможные альтернативы.

Другие важные соображения: 1) Меньше вторжения в наш код. 2) Простая стратегия резервного копирования/репликации. По крайней мере, главный раб. 3) Управляемость, Сообщество и проверенные (запущенные в производство).

Который сможет выполнить все или большинство из этих функций и требований?

EDIT - Что я сделал

1. Redis поддержке менеджер сеансов для tomact.
2. Redis для кэширования
3. Jesque (версия java версии Response), поддерживаемая redis.
4. Postgres
5. SLF4J подкрепленные Log4j2

Answer 1

я могу обратиться к некоторым из них с точки зрения MongoDB в.

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

Во-первых, посмотрите на документацию для немного, чтобы получить чувство для него:

Replica Sets и Sharding

Некоторые другие мысли, основанные на ваших требованиях:

• По сравнению с другими методы масштабирования с разными хранилищами данных Метод горизонтального масштабирования с использованием товарного оборудования mongo очень прост в настройке, масштабировании и обслуживании. Это означает, что вы можете потратить больше времени на создание своего приложения вместо того, чтобы быть администратором базы данных.
• Вы также можете пропустить слой кеширования, если вы идете с монго. MongoDB использует файлы с отображением памяти, что означает, что если ваш рабочий набор может храниться в физической памяти, у вас в основном есть кеш памяти .
• MongoDB очень хорош для регистрации. Пользователям обычно не нужно безопасно записывать для такого типа приложений, поэтому производительность будет превосходной, если вы будете использовать стандартную модель для записи и записи по умолчанию.
• Означает ли это, что это будет вторгаться в ваш код меньше, тем не менее, для обсуждения, по сравнению с тем, что делает типичный сопоставитель объектных отношений, Mongo намного менее навязчив вашим данным. Он способен хранить данные в естественном состоянии использования, объекте!

Надеюсь, что это поможет, приветствия.

Answer 2

Я бы сказал, используя sql. Поскольку вы хотите, чтобы все реляционные базы данных были усовершенствованы годами. Насколько я вижу, вы хотите, чтобы решение для данных предназначалось не для «конкретных» целей (это то, что NOSQL пытается охватить), а для сценария «все-в-одном». Для чего нужен SQL.

Mongodb был бы самым близким хранилищем данных, если вы хотите, чтобы выбрать из тех 3, которые вы назвали, но снова: использовать sql.

Answer 3

Вы правы, что Redis решит первые 3 требования - нелипкие сессии, кеш и очереди.

Что касается централизованного ведения журналов, это не тривиальный вариант использования, но может быть выполнен на Redis, вот blog post, который объясняет, как это сделать. Обратите внимание, что гуру NoSQL Alex Popescu вызывает некоторые оговорки в отношении подхода в this post.

Что касается настойчивости, вот краткий обзор Redis.io of persistence options - есть некоторые проблемы, но он работоспособен.