Как лучше обновлять счётчик записей?

Question

[Slash]

Например, у статьи есть N комментов, это количество меняется при добавлении или удалении коммента +/-1. Так сейчас и обновляются счетчики у меня.

Задумался, а как лучше делать:
1. Добавлять/Отнимать единицу от количества, при добавлении или удалении.
2. Каждый раз пересчитывать общее количество записей, сразу после добавлении или удалении записи?

Как делаете Вы?

Answer 1

[tukreb]

Раньше использовалось так:
1. Первый вариант, пока ничего не тормозит.
2. Второй вариант используется для отложенного обновления, обычно для счётчика просмотров, но идея та же, раз в час работает cron, который пересчитывает записи. До этого момента, они не меняются.

Сейчас есть другие способы, например загружать всё сначала в кэш, например в тот же redis, а потом раз в пол часа обновлять БД.

Comments

[Slash]

А разница по нагрузке есть?

[tukreb]

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

[Slash]

tukreb, спасибо, Дружище!

[Slash]

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

[tukreb]

Slash, Да.
Хотя с точки нормализации БД, нельзя хранить то, что можно вычислить. Но мир не идеален и когда приходят нагрузки приходиться денормализировать БД.

[Slash]

tukreb, еще раз спасибо!

[Everything_is_bad]

Slash,

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

ты в очередной раз, даже не пытаешься чуток подумать, а еще лучше самим такое поднять на тестовом стенде и замерить

Answer 2

[rPman]

триггером на insert/delete, быстрее и удобнее некуда

Comments

[Everything_is_bad]

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

[rPman]

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

[tukreb]

rPman, это прошлый век, когда MySQL до 8 версии не умел самые базовые вещи реляционной БД, а точнее не имел встроенного механизма целостности данных и приходилось велосипедить через триггеры. Что и породило целых пласт гавна писателей на MySQL + php.
Триггеры - это магия, а магия зло.

[rPman]

tukreb, что? кого?

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

аналогия - вот решил ты что у тебя в тексте длина строки не должна превышать 80 символов, и вставляешь вручную переводы строк... а когда надоест, просишь текстовый редактор делать это автоматически.

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

[Everything_is_bad]

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

[rPman]

Everything_is_bad, ну такова селяви, ты используешь одновременно две технологии для реализации задачи, и жалуешься что не получается делать все в одном месте? Скажи что еще язык написания триггеров у тебя не javascript, ой 'бяда бяда'.

p.s. помню были базы данных в виде библиотеки (что значит были, sqlite остался, в нем даже тригеры есть), идеологически это и есть одно место, но по факту то же самое, sql придется писать (в sqlite можно определить user defined functions и прописать их в триггере, будет вызываться код приложения).

Answer 3

[Ипатьев]

Лучше всего вообще ничего не обновлять.
При наличии очевидного индекса на article_id, хоть какие-то проблемы подсчёт на лету начнёт создавать на объёмах уровня фейсбука.
Так что я бы сначала не со счётными палочками колупался, а проверил наличие индекса.

Answer 4

[Everything_is_bad]

Можно просто каждый раз рассчитывать кол-во комментов, при небольшой нагрузки это не проблема. Если это начинает сказываться на производительность, то делают денормализацию, отдельный счетчик это и есть такой случай. Если всё сделать правильно, то 1й первый без проблем работает, 2й вариант применяет при кривой реализации или есть случаи когда добавление/удаление происходит извне системы, другие решение это случая 1й вариант, с периодическим фоновым пересчетом.

А так, вообще не вижу тут проблемы, чтобы приходить сюда с таким вопросом, можно было просто подумать, поиспользовать на практике и тогда понять, какой подход нужен в конкретном случае. И главное, а при чем тут PHP?