Mongodb против Cassandra для сбора, поиска и анализа многих журналов

Question

Я работаю над проектом, который объединяет и анализирует журналы как часть более крупного проекта.Я не знаю, какую базу данных выбрать для обработки этих журналов.В последнее время я возвращаюсь назад и назад между MongoDB и Cassandra, но я уверен, что есть и другие, которые соответствуют моим потребностям.Какой из них выбрать и почему?

Все это в самом начале, но вот требования:

• журналы в формате системного журнала
• запросы в основном в маленькой строке, которая сейчас находится в сообщении, но я получу ее в отдельном поле.Также будут фильтры по дате, серьезности или тегу.Очень редко люди просто ищут случайную строку в сообщении.
• почасовая аналитика по некоторым записям журнала
• ведет журналы в течение настраиваемого промежутка времени
• я уверен, что еще больше придет :) Вот почему я думаю, что NoSQL более уместен, потому что мы можем изменить схему.

Мы ожидаем, что база данных увеличится до некоторого ТБ данных (и ~ 50K вставок в секунду), поэтому шардинг является обязательным.Запросы не так часто, потому что они в основном используются разработчиками более крупного проекта.Но результат должен быть возвращен через несколько секунд.

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

Основные идеи, которые я получил до сих пор, заключаются в том, что MongoDB имеет больше функций, таких как регулярное выражение или сортировка.результаты, и его легче настроить на приличную конфигурацию, в то время как Cassandra кажется более масштабируемой (путем простого добавления серверов), а также имеет несколько полезных функций, таких как наложение TTL на данные.

Answer 1

Редко столбчатые хранилища данных, такие как Apache Cassandra, превосходны в агрегировании данных временных рядов. См. Следующие статьи для примеров:

• Базовый временной ряд с Кассандрой
• 4 месяца с Кассандрой
• Понимание модели данных Cassandra

Answer 2

MongoDB действительно подходит для ваших требований.И вот почему:

• индексы: поскольку вы хотите запускать случайные запросы, было бы неплохо не поддерживать их в вашем приложении или иметь отдельное приложение для поиска (Lucene).
• хорошо масштабируется (встроенная поддержка шардинга, репликация)
• записи являются асинхронными (по умолчанию вы можете сделать их синхронизированными), то есть неблокирующими и быстрыми.Вы можете потерять немного в определенных сценариях сбоев, но для журналов и аналитики это не будет иметь значения.
• довольно мощный API запросов (не как реляционный, без объединений, но лучше, чем все другие хранилища значений ключей nosql, и звучит более мощно, чем то, что предлагает Cassandra).

Вы можетедаже найти правильную конфигурацию, чтобы иметь ее в незащищенной установке.Например, по умолчанию он синхронизируется с диском каждые 60 секунд, что означает, что 60 секунд записи будут буферизованы, следовательно, уменьшится количество операций ввода-вывода.Я пробовал пол терабайта данных на одной машине, и запросы с одним индексированным полем выполняются за 100-200 мс.