Как правильно организовать систему хранение большого кол-ва данных (логов, счетчиков)?
Добрый день.
Есть небольшая задача, на которую сегодня можем потратить время для того чтоб завтра не болела сильно голова.
Поэтому пока на бумажке проектируем и хотелось узнать мнение более знающих и опытных людей. Ну или просто может кто посоветует что.
Условия:
- минимум админ. действий с БД, сервером
- большое количество записей
- чтение в основном последние 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?
Может использовать что-то другое?
Может кто встречал статьи по этому поводу? Посоветуете материал для чтения?
Соглашусь про Elasticsearch для логов, вместо Logstash можно посмотреть на Graylog2 (не говорю что он лучше, но посмотреть стоит).
По поводу счётчиков и вообще всяческих time series, буквально недавно натыкался на http://influxdb.com, до экспериментов руки не дошли, но учитывая то, что это обычно не такие критичные данные, можно и поиграться.
