ElasticSearch против MongoDB против Cassandra для журналов почтовых программ

У меня есть почтовая система, в которой мы отправляем 1-2 миллиона писем каждый день, а затем сохраняем все клики / открытия этих писем.

В настоящее время это отлично работает в MySQL.

Но теперь, с увеличением трафика, мы столкнулись с проблемой производительности Mysql.

Так что думаем перейти на Elastic/Cassandra/Mongo.

Мои возможные запросы включают: а) Получение пользователя, который открыл/щелкнул определенное письмо или нет. б) Расчет открываемости/кликабельности почты

Я думаю, что cassandra может не подойти здесь идеально, поскольку она хорошо подходит для приложений с большим количеством одновременных операций записи, но с меньшим количеством запросов на чтение.

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

Что мы должны использовать в этом случае и почему?

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


mongodb cassandra system-design elasticsearch
person Ankit Bansal    schedule 26.06.2019    source источник
comment
Если данные будут расти огромными, и вы планируете получить из них сложную аналитику, то, вероятно, вы будете использовать слишком много сложных агрегатов. В таком случае лучшим выбором будет эластичный.   -  person Nishant    schedule 27.06.2019

Ответы (2)


arrow_upward
0
arrow_downward

Стек ELK (Elastic Search, LogStash, Kibana) — лучшее решение для этого. Насколько я использовал стек ELK, он быстро обрабатывает журналы.

Кассандра определенно не лучший вариант.

Вы можете использовать MongoDB, так как большинство запросов являются запросами GET.

Но у меня есть несколько моментов, почему Elastic search превосходит Mongo для обработки журналов.

  1. Полнотекстовый поиск. Elastic Search реализует множество функций, таких как настраиваемое разбиение текста на слова, настраиваемое определение корней, фасетный поиск и т. д.

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

  3. Скорость. Эластичный поиск позволяет очень быстро выполнять сложные запросы.

Как следует из самого названия, Elastic search предназначен для поиска. И поиск в монго не такой быстрый, как в Elastic Search.

Но у обслуживания эластичного поиска есть и свои проблемы.

см.: https://apiumhub.com/tech-blog-barcelona/elastic-search-advantages-books/ https://interviewbubble.com/elasticsearch-pros-and-cons-advantages-and-disadvantages-of-elasticsearch/

Спасибо, я думаю, это поможет.

person GAURAV RAUL    schedule 26.06.2019

arrow_upward
0
arrow_downward

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

Поскольку эти записи обновляются при каждом открытии электронного письма, я считаю, что количество записей достаточно велико. Предполагая, что каждое письмо открывается в среднем 10 раз в день, оно будет иметь 10-20 лакхов записей в день с 1-2 лакхами электронных писем.

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

При этом, если ваш шаблон запроса на чтение имеет форму, в которой вы всегда запрашиваете идентификатор сообщения, то Cassandra/Hbase - лучший выбор, который у вас есть. Если это не так и у вас есть разные виды запросов или вы хотите сделать много аналитики, то я бы предпочел Mongo DB.

Эластичный поиск на самом деле не является базой данных, это скорее механизм запросов. И есть много случаев, когда потеря данных происходит в ES. Если вы планируете использовать его в качестве основного хранилища данных, Elastic Search/ELK — не лучший выбор.

Вы можете посмотреть это видео, чтобы понять, какая БД лучше всего подходит для каких сценариев. В качестве альтернативы сводку можно найти на @ веб-сайте CodeKarle

person Sandeep Kaul    schedule 15.08.2020