Какие есть хранилища для логов и статистики?

Question

[Михаил]

Дано:
Игровой сервер, к которому подключается множество пользователей.
Для каждого пользователя пишем в БД различные статистические данные об использовании сервера (логи, статистика).

Что сейчас:
Выполняется большое кол-во insert и update в базу данных, высокая нагрузка, тормоза и пр.

Какие есть решения, чтобы все эти данные собирать, и не мучить базу данных? Специальные БД? Какие?

Comments

[pi314]

https://www.elastic.co/products/logstash ?

[Михаил]

pi314: а если нужно хранить данные в некой структуре, доставать их из базы для построения графиков, например, это можно там сделать?

[pi314]

Михаил: Конкретно, увы, не отвечу - сам такого не делал. Но эта штука, по сути, ориентирована на сбор и анализ логов (в т.ч. с кастомными форматами) с разнообразных систем. Если у Вас ОДИН сервер и свои известные структуры данных, возможно, это будет из пушки по воробьям и лучше просто запилить самостоятельно, на том же Эластике.

[Михаил]

pi314: не, к сожалению > 300 серверов :)

[Николай Глушков]

Попробуйте big query, стоит не дорого, относительно простая интеграция

Answer 1

[Андрей Буров]

Elasticsearch

Comments

[Михаил]

И как я мог про него забыть :)

[MasterCopipaster]

Можно поподробнее - почему именно он?

Answer 2

[romy4]

Отключить индексы. Это основной вид тормозов при вставке. Для поиска использовать слейв копию.
Смотря что ищите в данных. Но может подойдёт Mongo, Redis.

Answer 3

[igruschkafox]

а у меня сейчас на работе такая же фигня ....
давайте будем применять NO SQL .... и началось....

Ну запишешь ты 10 миллионов строк в секунду
как ты их потом обрабатывать будешь?
Яровая стайл?

выход простой - писать в маленькие секционированные таблицы в которых (маленькие по времени - например данные хранить в них не более 2 недель, есть варианты где и по суткам секционированно)
потом переключать эти таблицы в хранилище - там хранить месяца 2-3 (примерно)
когда уже обработка вся закончилась (данные стали редко востребованными) перекидывать в долгосрочное хранение при этом грохать все индексы, включать компрессию страниц и хранить уже полгода (желательно в другой БД)
потом эту Архивную БД бэкапить и убирать с сервера

И правильно сказали выше
чем больше индексов тем больше тормозят операции вставки и апдейты

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

Не переживайте - и Монго Вы тоже можете забить инсертами, а уж Апдейты там вообщето уязвимое место (данные копируются сразу в несколько таблиц - денормализация, и что бы апдейтануть одну запись она будет искаться везде где она есть .... надеюсь понятно объяснил. А искаться блин JSONом! ) :)

Comments

[bnytiki]

Ну запишешь ты 10 миллионов строк в секунду
как ты их потом обрабатывать будешь?
Яровая стайл?

Ну представь, что это финансовая информация. Какая-нибудь платежная система.

Хранить важно все. Абсолютно все.
А обрабатывать - только при подозрениях. Используя фильтры по периоду времени, клиенту и пр. и пр.

Answer 4

[d'Ivan]

ClickHouse оптимизирована по хранению скорости записи/аналитики.
Есть также Druid.

Answer 5

[bnytiki]

для статистики influxdb - как раз разработана для быстрого сохранения огромного количества показателей. sic! для сбора показателей, но вовсе не для их длительного хранения.
для хранения переносить в другую СУБД.

для логов elasticsearch, можно логи туда загонять в отложенном режиме.