MongoDB как место хранения логов

[Alexander Danilov]

Добрый день, коллеги.

Мне требуется хранить различные данные с серверов, в том числе и логи. Рассматриваем как один из вариантов MongoDB.

Пожалуйста, подскажите:

1. На сколько правильно будет хранить логи в MongoDB? Много операций записи и немного операций выборки срезов и поиска.

2. Хранение параметров серверов (загрузка CPU, памяти, дисков). Немного записи, но сложные агрегационные правила: за промежуток времени, по хосту, по определенному параметру.

3. Слышал, что MapReduce лочит коллекцию на запись, а как с локами работает новый Aggregation Framework?

4. Не понятно, в каком формате даты хранить дату? в Unix-timestamp или в datetime? Что лучше воспринимает AF? Например, если запись каждую минуту, а выборку хочется сделать по среднему значению за час с интервалом по 5 минут. AF такое умеет?

Заранее спасибо за ответы сообществу.

[Maksim Leonov]

> 2. Хранение параметров серверов (загрузка CPU, памяти, дисков). Немного
> записи, но сложные агрегационные правила: за промежуток времени, по хосту,
> по определенному параметру.

А почему не использовать специально под это заточеные решения, типа
graphite, rrd и тому подобные?

>
> 3. Слышал, что MapReduce лочит коллекцию на запись, а как с локами работает
> новый Aggregation Framework?

The 3.0 WiredTiger storage engine provides document-level locking and
compression.

>
> 4. Не понятно, в каком формате даты хранить дату? в Unix-timestamp или в
> datetime? Что лучше воспринимает AF? Например, если запись каждую минуту, а
> выборку хочется сделать по среднему значению за час с интервалом по 5 минут.
> AF такое умеет?
>

Думаю стоит поэксперементировать с разными вариантами.

[Arthur Metasov]

29 сент. 2015, в 09:43, Maksim Leonov <event...@gmail.com> написал(а):

> А почему не использовать специально под это заточеные решения, типа
> graphite, rrd и тому подобные?

Написал же человек – как один из вариантов.
Очень правильно при проектировании оценить разные варианты а не просто просто брать что все берут.