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