LINUX.ORG.RU

Приблизительное число комментариев


0

4

Интересно, а зачем сабж?

Для тех, кто еще не увидел. Заходим не в свой профиль (например). Созерцаем надпись:

Число комментариев: приблизительно 7000

★★★

Последнее исправление: observer (всего исправлений: 1)

Ответ на: комментарий от KRoN73

Пруф.

www.linux.org.ru/people/fritew5/profile - юзер id и время регистрации намекают

по второму пункту

это к максу, я могу также как и ты, судить империативно, однако у тебя в расчетах ошибка - сообщения не валятся непрерывным потоком - в 4 часа ночи по москве - их мало, а в рабочее время - «много», а сколь это «много» я могу лишь судить по треккеру

Deleted
()
Ответ на: комментарий от Deleted

юзер id и время регистрации намекают

Не обязательно. Скажем, у меня:

mysql> select max(id), count(*) from users;
+---------+----------+
| max(id) | count(*) |
+---------+----------+
|   96621 |    15605 |
+---------+----------+
1 row in set (0.06 sec)

Те же самые спаммеры, например, не дремлют.

однако у тебя в расчетах ошибка - сообщения не валятся непрерывным потоком

А это пофиг. mysql на update num_posts будет тратить в худшем случае единицы миллисекунд. Даже при двух записях в секунду нагрузка будет совершенно незаметной. А две записи в секунду — это экзотика и редкость.

В общем, никак сова на глобус не натягивается. О чём вся вменяемая мировая практика и говорит. На любых популярных форумных движках (включая форумы, где нагрузка на порядок с лишним выше ЛОРовской) используют поле числа сообщений юзера.

И только ЛОР, оказывается, занимается хитрыми велосипедостроениями :)

KRoN73 ★★★★★
()
Последнее исправление: KRoN73 (всего исправлений: 2)
Ответ на: комментарий от KRoN73

А это пофиг. mysql на update num_posts будет тратить в худшем случае единицы миллисекунд. Даже при двух записях в секунду нагрузка будет совершенно незаметной. А две записи в секунду — это экзотика и редкость.

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

но на самом деле непонятно что мы обсуждаем, если ве кешируется уже:

https://github.com/maxcom/lorsource/blob/master/sql/updates/2013-03-11-user_c...

Deleted
()
Ответ на: комментарий от KRoN73

Обновление числа постингов — редкая операция.

Спасибо, поржал. Мы еще о форуме говорим? По-моему одна из основных R/W операций в базу форума - это создание/удаление/редактирование сообщений, не?

Pinkbyte ★★★★★
()
Ответ на: комментарий от KRoN73

На любых популярных форумных движках

Популярные движки написаны на глобальном и надежном и тормозят они в других местах :-)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

По-моему одна из основных R/W операций

А я где-то говорил про R/W? Я про общий вклад в нагрузку на БД. Обновление числа сообщений юзера — копеечная операция, на которой никак ничего не сэкономить. Отрицать это может только человек, совершенно не знакомый с форумной практикой.

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

http://www.balancer.ru/img/forums/1303/pinkbyte-stat-151332.png

Вообще, для таблиц размером пусть даже в 100 тыс. записей говорить о цене единичных update — это смешно.

KRoN73 ★★★★★
()
Ответ на: комментарий от Pinkbyte

Популярные движки написаны на глобальном и надежном и тормозят они в других местах :-)

А в Киеве — дядько.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

таблиц размером пусть даже в 100 тыс. записей говорить о цене единичных update — это смешно.

Об одном update говорить действительно смешно. Но текущее положение вещей можно объяснить двояко - сделать «как у всех» действительно проблемно или - так сложилось исторически.

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

В вашем споре выигрывает то у кого патч, тоесть Макс. :]

hizel ★★★★★
()
Ответ на: комментарий от KRoN73

Отрицать это может только человек, совершенно не знакомый с форумной практикой.

Ты сделал мой день. Говорю это как человек, в своё время занимавшейся оптимизацией этого вашего phpBB(тогда еще 2.x) под нужды заказчика. В том числе и оптимизацией запросов...

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Говорю это как человек, в своё время занимавшейся оптимизацией этого вашего phpBB

Ага. Я так про тебя и понял. Человек, забивший гвоздь, начинает считать себя великим столяром?

KRoN73 ★★★★★
()
Ответ на: комментарий от maxcom

Для оптимизации я периодически пересчитываю счетчики сообщений для всех пользователей и выдаю их с округлением до 1000 (т.к. счетчик все равно отстает от текущего количества).

Устами максикома ЛОР глаголит %)

derlafff ★★★★★
()
Последнее исправление: derlafff (всего исправлений: 1)

Интересно, а зачем сабж?

думаю, что-бы не мучить БД запросами, сколько комментов юзер A может увидеть у юзера B.

drBatty ★★
()
Ответ на: комментарий от emissar

впрочем в случае PostgreSQL это не надо оптимизировать

maxcom ★★★★★
()
Ответ на: комментарий от KRoN73

Которая обычно хранится в соответствующем поле БД пользователя и ничего не стоит. А обновление её нужно только при ответе и оказывается совершенно копеечным.

а если коммент удалили? А если звездатые его всё равно видят, ибо оно в «показывать удалённые»? А если оно в клубе?

Вообще, вопрос «сколько всего комментов у юзера» не так уж и прост. Если-бы тут комменты хранились вечно, и стирать их было невозможно…

А ты говоришь «сколько комментов юзер ОТПРАВИЛ». Это другое. Бот может Over9000 комментов отправить, их тоже считать?

drBatty ★★
()
Ответ на: комментарий от amomymous

Ну вон у человека 2021, а у него - приблизительно 3к. Интересно, будет ли у меня тоже 3к или все-таки 2, как положено?

cdshines ★★★★★
()
Ответ на: комментарий от maxcom

А сколько по времени занимает пересчет всех комментариев и выбор последней даты сообщенния для всех пользователей?

emissar ★★
()
Ответ на: комментарий от KRoN73

Человек, забивший гвоздь, начинает считать себя великим столяром?

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

Pinkbyte ★★★★★
()
Ответ на: комментарий от emissar

30-60 секунд вместе с INSERT'ом в табличку статистики

maxcom ★★★★★
()
Последнее исправление: maxcom (всего исправлений: 1)
Ответ на: комментарий от maxcom

и выдаю их с округлением до 1000 (т.к. счетчик все равно отстает от текущего количества).

ээ, может округлять до, скажем, 10? А то это уж как-то сурово.

Вообще, может nosql воткнуть? Написал пост- счётчик обновился. Иногда можно пересчитывать чтобы учесть полтергейст и удалённые комментарии.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Думаю рано или поздно у нас будет redis для этого.

maxcom ★★★★★
()
Ответ на: комментарий от maxcom

Запрос числа комментариев это «дорогая» операция для БД в случае если у пользователя их много.

maxcom, you're doing it wrong

Chaser_Andrey ★★★★★
()
26 ноября 2013 г.
Ответ на: комментарий от Eddy_Em

Сказал чувак с готом на аве и пятью неактивными звездами? :-)

//алсо, что такого?

abcarado
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.