Дано:
Игровой сервер, к которому подключается множество пользователей.
Для каждого пользователя пишем в БД различные статистические данные об использовании сервера (логи, статистика).
Что сейчас:
Выполняется большое кол-во insert и update в базу данных, высокая нагрузка, тормоза и пр.
Какие есть решения, чтобы все эти данные собирать, и не мучить базу данных? Специальные БД? Какие?
Михаил: Конкретно, увы, не отвечу - сам такого не делал. Но эта штука, по сути, ориентирована на сбор и анализ логов (в т.ч. с кастомными форматами) с разнообразных систем. Если у Вас ОДИН сервер и свои известные структуры данных, возможно, это будет из пушки по воробьям и лучше просто запилить самостоятельно, на том же Эластике.
Отключить индексы. Это основной вид тормозов при вставке. Для поиска использовать слейв копию.
Смотря что ищите в данных. Но может подойдёт Mongo, Redis.
а у меня сейчас на работе такая же фигня ....
давайте будем применять NO SQL .... и началось....
Ну запишешь ты 10 миллионов строк в секунду
как ты их потом обрабатывать будешь?
Яровая стайл?
выход простой - писать в маленькие секционированные таблицы в которых (маленькие по времени - например данные хранить в них не более 2 недель, есть варианты где и по суткам секционированно)
потом переключать эти таблицы в хранилище - там хранить месяца 2-3 (примерно)
когда уже обработка вся закончилась (данные стали редко востребованными) перекидывать в долгосрочное хранение при этом грохать все индексы, включать компрессию страниц и хранить уже полгода (желательно в другой БД)
потом эту Архивную БД бэкапить и убирать с сервера
И правильно сказали выше
чем больше индексов тем больше тормозят операции вставки и апдейты
так же встречал схему где такие базы логов хранятся исключительно на отдельном сервере - а в аналитические хранилища переходят логшипингом или олвейс Он или бэк аром раз в два дня
Не переживайте - и Монго Вы тоже можете забить инсертами, а уж Апдейты там вообщето уязвимое место (данные копируются сразу в несколько таблиц - денормализация, и что бы апдейтануть одну запись она будет искаться везде где она есть .... надеюсь понятно объяснил. А искаться блин JSONом! ) :)
для статистики influxdb - как раз разработана для быстрого сохранения огромного количества показателей. sic! для сбора показателей, но вовсе не для их длительного хранения.
для хранения переносить в другую СУБД.
для логов elasticsearch, можно логи туда загонять в отложенном режиме.
Средний
