Как держать в таблице только последние 10 записей?

Question

[Виктор]

Есть записи некоторых действий пользователей на сайте, эти действия записываются в базу (в минуту может быть до 30 записей и больше), но мне нужно только последние /n записей по дате добавления, как держать в таблице только эти последние /n записи? Добавить запись и удалить последнюю по дате, как правильно это сделать или есть другие решения?

Comments

[Дмитрий]

Добавлять все записи, выбирать последние. Чистить по крону раз в сутки

[Akina]

Вообще неплохо было бы указать, что за десять записей... вообще? на юзера? на УРЛ? что-то ещё?

А вообще 30 записей в минуту - это 50 тыс. в день. Для сервера БД объёмы вообще ни о чём... так что согласен с тем, что предлагает Дмитрий, очистки раз в день хватит за глаза.

Answer 1

[Дмитрий]

1. По крону сносить не нужные записи, а в запросе пока не снеслись юзать лимит /n;
2. Через триггер который при каждом добавлении записи будет сносить не нужные;
3. Делать не insert а update где в качестве id записи выбирать подзапросом самую старую запись.

update event, (select id from event order by date limit 1) as s set value = 'changed', date = now() where t.id = s.id;

но предварительно придется нагнать туда 10 записей.

4. Сделать тоже самое через insert on conflict update. Тогда не придется нагонять

Но как то задача странная. На каждое внесение записи - делать еще процедуру удаления. Дополнительная нагрузка для чего?

Comments

[Виктор]

Спасибо за ответ, то что нужно!

[Дмитрий]

Виктор, вариант akina лучше моего update - я зачем то в айди упоролся, у него проще.

[Akina]

1. По крону сносить не нужные записи, а в запросе пока не снеслись юзать лимит /n;

Эммм... как? ну то есть с кроном понятно, а вот вторая часть фразы неясна совсем.

2. Через триггер который при каждом добавлении записи будет сносить не нужные;

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

4. Сделать тоже самое через insert on conflict update.

Это синтаксис Постгресса. Да и что с чем конфликтовать должно? как-то не видать ничего конфликтного...

вариант akina лучше моего update

У моего решения есть серьёзный минус - он работает только при поштучной записи. Если надо вставлять пакетно - придётся поизвращаться (хотя можно, можно)... или замутить на такой случай (а лучше - на любой случай) хранимую процедуру. Правда, тут же набегут адепты не-разделения логики и заплюют...

Но как то задача странная.

Как по мне, единственная странность - это требование "строго десять". Остальное вполне укладывается в стандартный шаблон.

[Дмитрий]

Akina,
1. Ну то есть если мы сносим данные каждый час, у нас может накопиться несколько больше 10 записей. И что бы они не маячили - в запросе просто используем limit.
2. Возможно обойти наверно - через промежуточную таблицу тоже с триггером.
3. Да перепутал с on duplicate update, с mysql не работал уже лет 5. но принцип то схож

Как по мне, единственная странность - это требование "строго десять". Остальное вполне укладывается в стандартный шаблон.

Мне представляется странной задача ДЕРЖАТЬ в таблице не больше n записей. Мы получаем кучу геммороя с тем что у нас не просто вставка - а вставка с проверкой и возможным удалением. То есть вместо 1 задачи у нас 3. Вопрос зачем, в чем ценность этого для приложения или бизнеса? Что случится если там какое то время будет лежать больше 10 записей? Коллапс?

[Виктор]

Akina,

Как по мне, единственная странность - это требование "строго десять". Остальное вполне укладывается в стандартный шаблон.

Я удалил все записи, оставил 100 записей, из них подтягиваю сколько нужно, спасибо за помощь!

[Akina]

Дмитрий,

И что бы они не маячили - в запросе просто используем limit.

Ааа... в запросе на получение записей! а я гадаю, к какой заднице это в инсерте прислонить...

Answer 2

[Akina]

1. Создать сразу 10 записей с достаточно древней датой.
2. Вместо вставки записи обновлять самую старую:

UPDATE table
SET {columns} = {values}
ORDER BY created_at ASC LIMIT 1;

Само собой created_at - ON UPDATE CURRENT_TIMESTAMP. Ну или обновлять вручную, если больше заняться нечем.

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

Answer 3

[Олег]

странная задача. Может быть до 30 в минуту и больше. Блок Вы просматривали ?
тут такой момент посетители сайтов бывают двух типов
1) Случайно залетели в глубь сайта из поисковика (по прямой ссылке)
средняя глубина просмотра 1,5 страницы
2) Ведет себя как поисковый бот - смотрит кучу страниц

Предложение Akina разумно для авторизованных пользователей
В чистке по крону Дмитрий засада в случае редких просмотров. Как оставить именно не более 10 у каждого

И общая проблема такого хранения в муське. Квери кеш идет лесом.

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

Comments

[Дмитрий]

В чистке по крону Дмитрий засада в случае редких просмотров. Как оставить именно не более 10 у каждого

delete from table where id not in (select id from table order by date desc limit 10);

[Олег]

explain и время отработки запроса при посещаемости 30к уников в сутки ?

[Виктор]

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

[Дмитрий]

Олег,

explain и время отработки запроса при посещаемости 30к уников в сутки ?

это сейчас кому?