Быстрая запись в постоянную очередь

Question

Я пытаюсь изменить текущее приложение для масштабирования.

В настоящее время оно может обрабатывать не более нескольких миллионов событий в час, но ожидается, что объем увеличится в 10-100 раз при переходе наМодель SaaS, поэтому важно иметь возможность выполнять обработку в распределенном режиме.

Приложение представляет собой веб-приложение, которое в настоящий момент получает 1,2 миллиона событий / час.Он использует 2 сервера Tomcat, каждый прослушивает 500 потоков и workManager для постановки событий в очередь, а затем создает пару сотен рабочих потоков для последующей обработки событий.

Я пытаюсь отделитьзапись из обработки и перемещение обработки в распределенную среду.

1. Быстрая запись на диск событий.

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

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

2. Переместить обработку событий в распределенную систему.

   Мне нужно переместить данные в распределенную систему (например, HDFS).Какие еще есть варианты?

   Обработка средней сложности (например, некоторая сложность заключается в самосоединении, которое генерирует частый набор элементов и дополнительно фильтрует этот набор, другие части включают агрегирование данных по нескольким иерархиям),В настоящее время я использую базу данных (MySql & DB2) и думаю о Hadoop.Любые другие варианты?

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

Я в настоящее время использую SOLR, какие-нибудь лучшие варианты?

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

Спасибо!

Себи

Answer 1

На сегодняшний день лучшая система, способная как к вставкам, так и к запросам, - это RDBMS.Но это не масштабируется.Системы NoSQL не являются масштабируемыми, потому что они построены лучше, а потому, что они что-то отказались ..
Давайте посмотрим, что из них можно построить.
Обе HBase и Cassandra созданы специально для перевода случайных вставок в последовательный дисковый ввод-вывод.Другими словами - это система, оптимизированная для записи, и вы можете считать их идеальным индексом распределенной базы данных.Таким образом, вы можете получить любую необходимую вам скорость вставки, добавив больше узлов

. Относительно объединений и агрегирования проблематично.
Если вам удастся спроектировать ключ так, чтобы данные, которые будут агрегироваться, располагались вместе - данные можно эффективно извлекать и агрегировать.
Объединение также проблематично, но есть возможность записать данные, которые уже были добавлены.Вы должны сделать это на уровне приложения.
Для более сложной обработки вам нужно прибегнуть к MapReduce, но это, вероятно, повлияет на скорость вставки.
Brisk от DataStax звучит неплохо для вашего случая, поскольку в нем Cassandra предварительно интегрирована с MapReduce с возможностью запуска MapReduce прямо над Cassandra Data.Он также имеет возможность уменьшить влияние MapReduce на часть истории OLTP.

Answer 2

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

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

https://github.com/peter-lawrey/Java-Chronicle

Answer 3

Несколько ваших проблем звучат так, как будто у них есть JMS в качестве решения.Это очередь, она должна быть быстрой, надежной (при сбоях машины) и постоянной.

Например, ActiveMQ можно настроить так, чтобы клиент ожидал, пока данные не будут записаны на диск.на более чем одной машине, настроив ее как «сеть брокеров».См. http://activemq.apache.org/networks-of-brokers.html

Он также позволяет помечать сообщения как постоянные, так что брокеры могут пережить перезапуски.Я настоятельно рекомендую ActiveMQ предложить http://activemq.apache.org/kahadb.html, так как более старые версии имеют серьезные проблемы.

Это помогает с распределением событий, но не помогает ни с обработкой, ни с фактическойвозможное хранение данных.Сколько клиентов будет нуждаться в доступе к какому количеству данных и через какое время после их получения?Вы можете использовать «разделы» в JMS для рассылки сообщений всем клиентам, а также такие понятия, как «разделы с последними изображениями», для сохранения некоторого состояния в брокере, чтобы ваши клиенты могли перезапускаться.http://activemq.apache.org/subscription-recovery-policy.html объясняет это.

Однако, несмотря на все это, звучит так, как будто вы собираетесь в конечном итоге использовать Hadoop для обработки информации, поэтому можете использовать все, что встроено в их стек.:)