Журналы большого объема с пакетным сохранением в базе данных

Question

Я хочу хранить информацию о запросах на моих сайтах быстрым способом, который не создает дополнительной нагрузки на мою базу данных.Цель состоит в том, чтобы использовать эту информацию для предотвращения злоупотреблений и сбора информации о том, как пользователи взаимодействуют с сайтом (ip, GET / POST, url / action, timestamp).

В настоящее время я сохраняю новую строку для каждогозапрос страницы в базе данных.Тем не менее, это напрасная трата ресурсов с дополнительным вызовом базы данных, когда сервер также уже регистрирует ту же информацию в файле журнала nginx.

Я хочу знать, что я могу сделать, чтобы справиться с этим лучше, у меня есть две идеиЯ хотел бы знать, есть ли какие-либо более эффективные методы.

1. Задание CRON для анализа журнала доступа каждый день и сохранения в виде пакетной транзакции в базу данных.
2. Кэш ОЗУ (redis / memcached)для хранения данных о запросе, а затем CRON для сохранения в базе данных.

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

Я также не знаю, как анализировать журнал доступа таким образом, чтобы я не перечитывал записи.

Какможно эффективно записывать попытки доступа?

Answer 1

1. Используйте отложенные вставки, если вы используете MySQL (другим движкам это не нужно)
2. Остерегайтесь индексов, делающих операции записи дорогими
3. Поворот таблиц один раз в минуту / час/ день
4. Остерегайтесь чрезмерной нормализации и внешних ключей

Распространенным шаблоном является простая таблица для простых записей и перемещение журналов каждую минуту / час в основной набор таблиц,Основной набор может быть сильно нормализован и проиндексирован, а также может быть простой ненормализованной таблицей (для экономии места).

Другой способ - создать простую большую таблицу и выполнять сводный запрос каждую минуту / час.Простая таблица может быть проиндексирована по дате (не забудьте использовать собственный тип).

Последний совет, сделайте архитектуру и скрипты идемпотентными (если вы запускаете их несколько, данные все равно действительны).Очень часто возникают всплески, и простое повторное выполнение задачи для определенного окна минуты / часа / дня может быстро исправить все, вместо масштабного перестроения.