Какую Базу Данных лучше использовать для логирования и построения отчетов?
Лир.отступление: разработкой давно не занимался, ушел в поддержку, не в курсе тенденций и пр., но есть идеи... прошу совет.
есть одна задача (задумка) в проекте:
необходимо писать много логов (записи могут быть разные, зависит от количества "датчиков") по различным источникам. Данные по прошествии какого-то времени, скажем месяц, должны удаляться. Одна группа может содержать (за месяц) от 9к записей (1 источник) до ... условно 90к (10 источников) ,зависит от количества источников в группе, могут появляться, могут "пропадать", таких групп может быть NN (предполагается постоянное увеличение в будущем, на сколько не известно, пусть хотя бы до 500). По полученным данным необходимо строить отчеты, отчеты по группам источников (тип группы источников). На клиенте полученные коллекции пихать в чарты (графики). Выборка в двух видах - за весь период хранения по группе (в график) и текущие показания.
Как то так.
Что для этого лучше использовать: MySQL, PostgreSQl или MongoDB ?
Если MongoDB, какие индексы вообще делать и стоит ли? пока думаю только один expireAfterSeconds
PS: Нужна скорость вставки, выборка будет производится значительно реже чем вставка.
90k записей в месяц? 500 групп. 45 000 000 записей?
Да что угодно, от обычного MySQL, до модного ClickHouse.
Монгу - ну пощупайте, но мне кажется с производительностью там все плохо на самом деле.
Сергей, опять же если считать в лоб усредненно - 45kk за месяц это 17 запросов на запись в секунду всего-то.
Понятно что в реальности в пике может быть больше в разы, но все равно цифры небольшие.
В конце концов можно какую-то отдельную мега-быструю очередь запилить для вставки.
Дмитрий Энтелис, весь смысл в том что данные с ичтоников поступают асинхронно и вполне вероятно что может быть такое когда со всех сразу, тогда это намного больше.
нашел вот статейку про ArangoDB и если ей верить то MongoDB вообще полный тормоз )) https://www.arangodb.com/2018/02/nosql-performance...
Сергей, я вам дам один важный совет: не верьте никому, когда доходит до тестов производительности, вот прям вообще никому.
Есть задача с потенциальной нагрузкой - собрали среду которая её имитирует, провели собственный тест под нагрузкой и данными близкими к живым, приняли решение.
Да, на сборку тестовой среды уйдет время какое-то.
Но это стократно окупится потом.
Сергей, ну и нужно реально как-то формализировать граничные требования по нагрузке.
Сейчас путем нехитрой арифметики мы видим что ваши датчики шлют данные раз в 12,5 минут.
Соответственно одна из задач - научить их равномерно слать данные, потому что если ваши 10*500 = 5000 источников пришлют запрос с точностью до секунды - все упрется не в базу, все упрется гораздо раньше в веб-сервер.
Дефолтный PHP держит где-то 500-700rps.
Дмитрий Энтелис, // Дефолтный PHP держит где-то 500-700rps. // а какой держит больше? не обязательно PHP. Node.js? Не хочется потом все переделывать, желательно заранее все продумать.
PS: равномерно слать данные не получится, это независимые системы, сервис должен объединять их для сбора и отображения статистики.
Сергей,
а) самое правильное - делать горизонтальное масштабирование.
т.е делать проект так, что бы в любом момент времени, вместо 1 компонента системы их могло быть N.
b) полностью все переделывать - это нормально. не нормально сразу жечь 100500 денег в попытках сделать идеальную систему.
нагрузка не случается внезапно - делайте систему которая держит ту нагрузку что есть в обозримом будущем.
вырастет нагрузка - будете решать. в конце концов всегда сможете купить еще серверов и воткнуть на них полный клон системы отдельно)
Если нужна аналитика, то смело берите Clickhouse. Проблем с быстрой вставкой нет. 45кк записей ни о чем.
Grafana умеет юзать кликхаус как Data Source и строить красивые графики на основе данных.