Кэш/очередь для записи с высокой частотой

Question

Предположим, что веб-приложение (PHP) с X00 000 запросов в минуту и ​​база данных SQL с примерно таким же количеством записей.

Каждый запрос вызывает несколько (< 5) db-файлов и одну запись db (в основном, обновление). Меня беспокоит проблема производительности, вызванная записью, и поиск решений для увеличения количества запросов в минуту.

Какие решения вы бы предложили, как бы вы их реализовали и почему?

Вещи, о которых я думал, включают в себя кеш для записи, который синхронизируется с db один раз каждые с некоторым интервалом времени или в очереди, такой как Gearman, или просто вставка SQL вставляется с задержкой.

Однако, поскольку ожидается, что одна и та же нагрузка будет постоянной, вставка с задержкой, вероятно, не поможет, когда загрузка сервера будет постоянно на уровне> 90%, поэтому я ищу способы значительно снизить нагрузку на сервер по сравнению с одиночной записью.

Благодаря

Answer 1

При обновлении таблицы вы также чтение, то да, эти обновления будут замедляться читает, потому что они Виль недействительными MySQL запросов-кэш и возможные блокировки таблицы. Одним из распространенных примеров является таблица деталей продукта, в которой вы обновляете количество посещений.

Простой подход не обновляет основную таблицу, а вместо этого использует отдельную таблицу для изменяющихся значений (например, product_views) и изменяет ваши запросы на использование JOIN для извлечения значений. Используя этот подход, ваша основная (и большая) таблица будет в основном статичной и не затронутой недействительностью и блокировкой кеша запроса.

Более продвинутый подход заключается в том, чтобы НЕ использовать ОБНОВЛЕНИЯ, но INSERT. Вместо того, чтобы обновлять строку на каждом просмотре страницы, добавьте новое значение INSERT в таблицу temp (например, product_views_temp), поэтому каждый вид будет 1 строка. Затем планируйте задание cron, например каждые 5 минут, чтобы выполнить запрос, например SELECT COUNT(*) FROM product_views_temp GROUP BY prod_id, и на основе номеров обновите основную таблицу (должно быть возможно в 1 запросе). Главное преимущество заключается в том, что эти ВСТАВКИ быстрее, и вы можете иметь подсчеты в основной таблице, если вам нужна по какой-либо причине. Небольшим недостатком является то, что будет небольшая задержка, прежде чем посетители увидят обновленные подсчеты.

EDIT: Если вы можете позволить себе потерять данные рассчитывает на эти 5 минут, вы можете сделать его супер-быстро, создавая эту временную таблицу с MySQL MEMORY storage engine. Они очень быстрые для INSERT (но могут быть немного медленнее для UPDATE). Когда сервер выходит из строя/завершает работу, сама таблица все еще существует, но ее содержимое теряется.

Вы также можете использовать механизм MEMORY для данных сеанса (не имеет значения, нужно ли пользователям снова входить в систему после неожиданного сбоя сервера, поскольку это не так часто бывает).