Как правильно организовать систему хранение большого кол-ва данных (логов, счетчиков)?

Добрый день.

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

Условия:
- минимум админ. действий с БД, сервером
- большое количество записей
- чтение в основном последние n-записей (~1000), но при этом с условием (что-то вроде: SELECT * FROM tbl WHERE author = 'pabel' ORDER BY `id` DESC LIMIT 100). Тоже очень большое количество операций на чтение, отдаем данные в публичный API
- группировка (записи имеют поля по которым группируем или входят в условие выборки)
- простой полнотекстовый поиск (очень редко, но нужно будет и на разных языках)
- максимальное время жизни. Желательно хранить долго, а это значит что данных в таблице/коллекции будет очень много.

Данные в общем в виде лога http-запросов. Поля: хозяин счетчика, ресурс, данные http и т.д.

Само приложение пока делаем на php, по необходимости узкие места перепишут. А вот где хранить не можем решить. Хочется очень простой и гибкий инструмент, смотрим в сторону Amazon RDS и Amazon DynamoDB. Получается будет огромная очередь на запись и чтение последних n-записей.

С облачным хостингом мы закрываем условие "минимум админ. действий с БД, сервером", т.е. фактически просто добавляем ресурсов. Единственное они сами справляются с нагрузками или надо самим заниматься репликацией БД, если чтение данных будет очень большим?

Если нет особой важности в виде хранения данных (SQL / noSQL), то что лучше справится с нагрузкой RDS или DynamoDB?

Может использовать что-то другое?

Может кто встречал статьи по этому поводу? Посоветуете материал для чтения?

Заранее спасибо.
  • Вопрос задан
  • 3057 просмотров
Пригласить эксперта
Ответы на вопрос 2
index0h
@index0h
PHP, Golang. https://github.com/index0h
Elasticsearch
Для логов: some_logs_source > Logstash [ > Redis ] > Elasticsearch > Kibana
Ответ написан
Комментировать
onyxmaster
@onyxmaster
Программист, ненастоящий сисадмин
Соглашусь про Elasticsearch для логов, вместо Logstash можно посмотреть на Graylog2 (не говорю что он лучше, но посмотреть стоит).
По поводу счётчиков и вообще всяческих time series, буквально недавно натыкался на http://influxdb.com, до экспериментов руки не дошли, но учитывая то, что это обычно не такие критичные данные, можно и поиграться.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы