Какое решение NoSQL лучше всего хранить в Apache error_log и access_log? Кассандра или МонгоДБ?

Question

Мы разработали PaaS-решение для PHP.В рамках этого мы предлагаем разработчикам просматривать файлы Apache error_log и access_log через наш API.

В настоящее время мы записываем журналы в файлы на диске отдельно для каждого развертывания (vhost).

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

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

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

Другим вариантом была Cassandra, которая мне нравится, поскольку каждый узел равенподход, но у них нет чего-то похожего на ограниченные коллекции.

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

Так что я хотел бы знать, кто-нибудь раньше использовал одну из двух систем для регистрации?Какой у вас опыт, можете ли вы дать мне несколько советов?Или есть другие решения, которые лучше соответствуют нашим потребностям?

Answer 1

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

Честно говоря, сейчас мы проходим этот тест с некоторыми серьезными данными журнала. (и прямо сейчас, я имею в виду, некоторые из нас поздно вечером провели эти тесты).

Для меня вот две отличительные особенности: простота использования и проверенное масштабирование .

Удобство использования

• MongoDB было легко. Через пару часов я перешел с чистого компьютера на активный экземпляр Mongo с импортированными данными из MySQL и несколькими завершенными картами-редукциями.
• В тот же период времени команда Cassandra занималась перекомпиляцией файлов Java, пытаясь настроить Hadoop для работы с существующей реализацией Cassandra, чтобы они могли даже запускать map-redunds.

Проверенное масштабирование

• Sharding MongoDB все еще находится в бета-версии. Он планируется к запуску в ближайшие несколько недель. Это довольно плотно.
• Осколок Кассандры доказано в некоторых очень крупных случаях.

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

Answer 2

Вы можете проверить эту статью из Cloudkick, если вы планируете использовать Cassandra: 4 месяца с Кассандрой, любовная история .

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

EDIT:

Если вы еще не решили, что использовать, вот отличное решение, использующее MongoDB в качестве бэкэнда:

Graylog2 - это реализация системного журнала с открытым исходным кодом, которая хранит ваши журналы в MongoDB. Он состоит из сервера, написанного на Java, который принимает ваши сообщения системного журнала через TCP или UDP и сохраняет их в базе данных. Вторая часть представляет собой веб-интерфейс Ruby on Rails, который позволяет просматривать сообщения журнала.