Высокая загрузка веб-проектов с использованием баз данных SQL

Question

Я хочу задать вопрос о подходах в разработке высоконагруженных веб-приложений с использованием баз данных SQL. Предположим, у нас есть простая система CMS, обеспечивающая доступ к различным статьям. Также мы хотим сохранить количество посещений статьи в базе данных. Счетчик посещений увеличивается каждый раз, когда пользователь просматривает статью.

Что касается базы данных SQL, у нас есть целое поле "посещения" в таблице "Статья", которое нам нужно увеличивать каждый раз, когда пользователь посещает статью. Если статья имеет большое количество одновременных посещений, необходимо правильно изменить значение поля «посещения» текущей строки базы данных.

Я использую пессимистическую блокировку: «ВЫБЕРИТЕ. ДЛЯ ОБНОВЛЕНИЯ». Каждый раз, когда пользователь посещает какую-то статью, я блокирую определенную строку в таблице «Статья» и увеличиваю счетчик «посещений».

Является ли этот подход правильным?

Я использую базу данных MySQL в своих проектах.

Answer 1

Я бы определенно не рекомендовал хранить сводные данные (например, «количество посещений») в данных статьи, а использовал бы отдельную таблицу, в которой вы регистрируете одну новую запись для каждого посещения. Храните там временную метку, article_id, IP-адрес и другие данные. Это объясняется тем, что вам не нужно будет блокировать запись в базе данных для каждой статьи для каждого посещения, что может привести к проблемам с блокировкой / конфликту.

Теперь, когда вам интересно узнать количество просмотров, сделайте простой выбор в таблице журнала. Для сайтов среднего размера это должно быть «достаточно хорошо»; при увеличении нагрузки вам придется регулярно рассчитывать количество просмотров на статью и кэшировать счетчики просмотров, чтобы ускорить доступ к этим данным.

Answer 2

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

На очень загруженном веб-сайте вы захотите создать очередь сообщений и отправить в очередь "посещенные" события.

Автономный процесс будет читать очередь и соответствующим образом обновлять столбцы. Это позволило бы только одному процессу в любой момент получить доступ к этому конкретному столбцу.