Ищете высокопроизводительное распределенное масштабируемое решение для хранения большого количества сообщений журнала. У нас есть несколько одновременных источников журналов (= серверов).
Здесь интересно то, что производительность имеет решающее значение и мы даже готовы потерять небольшой процент (допустим, максимум 2%) всех ежедневных сообщений, если система регистрации будет работать лучше.
Мы хотим ежедневно обрабатывать сообщения журнала с помощью онлайн-алгоритма, поэтому нам не нужны какие-либо причудливые реляционные базы данных. Просто хочу последовательно просмотреть данные и вычислить некоторые агрегаты и тенденции.
Вот что нам нужно:
Никакая РСУБД здесь, конечно, не вариант, поскольку она гарантирует слишком много (для этой задачи ненужных) свойств.
Я думаю ты хочешь Лоток. Кажется, он соответствует большинству требований, которые вы ищете - множественные источники, надежность (гарантия E2E), возможность записи в HDFS (распределенное, отказоустойчивое хранилище, интегрируется в Hadoop для сопоставления / уменьшения.
Изменить: я также хотел бы упомянуть Писец как еще одна возможность. Он основан на C ++, написан Facebook, но, похоже, от него отказались в основном разработчики. Тем не менее, он занимает меньше места, чем Flume, тем не менее, он включает в себя все зависимости Flume, такие как Zookeeper. И он тоже может записывать в HDFS.
Распределенный Splunk настройка соответствовала бы вашим потребностям, но похоже, что у вас большой объем данных журнала; он лицензируется на основе количества данных, индексируемых в день, поэтому это будет недешево.