Redis, Mongo или Hazelcast?

Question

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

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

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

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

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

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

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

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

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

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

РЕДАКТИРОВАТЬ - Что я сделал

1. Redis-поддерживаемый менеджер сессий для tomact.
2. Redis для кеширования
3. Jesque (Java-версия Respue) при поддержке Redis.
4. Postgres
5. SLF4J при поддержке Log4j2

Answer 1

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

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

Сначала, взгляните на документацию, чтобы почувствовать это:

Наборы реплик и Sharding

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

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

Надеюсь, это помогает, ура.

Answer 2

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

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

Answer 3

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

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

Что касается персистентности, вот обзор Redis.io вариантов персистентности - имеет некоторые проблемы, но выполнимо.