Хранение активно обновляемых полей в базе данных

Question

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

1. Создать столбец views в таблицеarticles и обновите его.
2. Создайте отдельную таблицу view_count с указателем FK на статью и числовыми представлениями для этой статьи.

Мой вопрос: есть лиРазница между этими двумя подходами с точки зрения скорости и почему?Есть ли лучшие альтернативы?

Я использую базу данных PostgreSQL.

Примечание , что я не рассматриваю различные способы накопления этих значений в отдельных файлах внебазы данных и последующей вставки, потому что i) мы не получаем столько обращений, ii) функцию в второстепенном, и если для этого потребуется такая стычка, мы бы скорее отказались от нее и использовали для этого какой-то другой сервис.

Answer 1

Различия двух предложений довольно тонкие, вот как я их вижу:

Та же таблица

• Хранение в той же таблице позволит вам получить его по более низкой цене
• обновления могут блокировать те части БД, которые нужны другим запросам в очереди для их замедления
• расширение таблиц увеличивает число операций ввода-вывода (это всегда увеличивает число операций ввода-вывода при просмотре таблиц, но для поиска по индексу это не так просто - когда размер записи становится больше, чем размер блока файловой системы, тогда даже поиск по индексу придется сделать в 2 раза больше операций ввода-вывода или n х больше операций ввода-вывода в зависимости от размера записи / размера блока, если размер записи намного меньше размера блока, тогда эффект для поиска по индексу зависит от типа запроса / порядок данных на диске - при выборе записей из одного и того же блока вы почувствуете снижение производительности, а при выборе разреженных данных вы его не почувствуете)

Отдельные таблицы

• обновления будут происходить на меньшей таблице, поэтому меньше операций ввода-вывода (для проверки внешнего ключа могут потребоваться блокировки, в зависимости от уровня изоляции, но они должны быть короче, поскольку меньше операций ввода-вывода)
• для извлечения данных для статьи требуется соединение, которое увеличит число операций ввода-вывода
• если счетчик просмотров является новой функцией, отсутствующей в большинстве других ваших записей, вы также экономите место, и хотя объединение может увеличить требуемый ввод-вывод, это может повысить производительность

Примечания
Комментарии применимы, но они незначительны: размер записи, вероятно, не окажет значительного влияния на все запросы. Преимущества меньшего количества операций ввода-вывода с отдельной таблицей могут быть не ощутимы.

Answer 2

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

Answer 3

Если таблица articles получает много записей, то обновление столбца может быть немного медленнее из-за блокировок таблицы во время записи.

Использование отдельной таблицы только немного медленнее / тяжелее дляпрочитайте, но самый легкий с точки зрения обновлений.Но после загрузки записей вы можете легко перестроить таблицу без значительного снижения производительности, поскольку она будет довольно легкой.

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