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

Question

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

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

Я использую пессимистический подход к блокировке: «SELECT .. FOR UPDATE». Каждый раз, когда пользователь посещает какую-либо статью, я делаю блокировку определенной строки в таблице «Статья» и увеличиваю счетчик «посещений».

Правильно ли этот подход?

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

Answer 1

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

На веб-сайте с очень высокой загрузкой вы хотите реализовать очередь сообщений и отправить «посещенные» события в очередь.

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

Answer 2

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

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