Новая тема   Ответить

 S_Flash
Если надо в MySQL InnoDB вносить частые непериодичные данные типа просмотров страниц\счётчики etc стремящиеся по чатстоте в пике до нескольких правок в секунду типа инкремента или перезаписи, что лучше выбрать в практичном смысле:
1. Не париться и тупо по Первичному ключу писать\инкрементить в строку таблицы данные.
2. Кешировать в Redis и с периодичностью раз в 2-5 минут делать множественный апдейт нескольких сотен или тысяч строк?

Может уже есть какя-то другая проверенная практика?

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

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

но прежде имеет смысл попробовать
http://devacademy.ru/posts/kak-dobavliat-nosql-zaprosy-v-mysql-inti…ubuntu-14/
https://dev.mysql.com/doc/refman/5.6/en/innodb-memcached-setup.html

еще конечно можно вообще взять тарантул и использовать без mysql - но это уже приложение придется переписывать полностью.

 Stek
Mysql имеет Memory тип таблиц, где данные в памяти хранятся. Можно ее использовать как временную и синхронизировать уже в нормальную таблицу.

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

 lalex
Stek писал:
А также MEMORY имеет table lock, который может случиться, когда он совсем не нужен.

Золотое правило из двух пунктов:
1) Быстро, а главное последовательно, писать лог куда-нибудь (локальный файл, MySQL-InnoDB/MyRocks, Redis-list, etc.).
2) Читать пачками записанное, суммировать в памяти, обновлять значения конечных счетчиков "одним" запросом.
В итоге, запись будет всегда за константное/короткое время.

 Pentarh
Ну да, так и делают. Это все надо писать в рав таблицу без индексов. А может и отдельную базу данных, а может и на отдельном сервере. Ну и периодически ее обрабатывать, стирая рав данные после.

Я давно отошел от дел, хз что сейчас лучше, чем старушка MyISAM для этого. Только не InnoDB!!! Инна мало того что глючила, так еще и ошибку типа "table busy, try later" выдавала Ох бля, и смех и грех

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

Более 10 млн в сутки лог записей принимал так.

А, еще можно короче конкурентные запросы превратить в 1 тред. Я называл это "выпрямитель" В общем, вешаешь промежуточный mysql серв, он принимает туеву хучу конкурентных запросов INSERT/UPDATE от логов. Теперь берешь, настраиваешь репликацию на свой главный серв и этот проксик на главный серв начинает слать все эти запросы последовательно одним тредом репликации. Иногда прямо спасало, т.к. на главном сервере можно без проблем локнуть таблицу и че нить с ней сделать без риска домино.

Последний раз редактировалось: Pentarh (06/10/16 в 22:01), всего редактировалось 1 раз

 Ailk
https://clickhouse.yandex/
собирай суда стату, а потом обсчитывай и рассовывай куда нада.

 lalex

ClickHouse рекомендует писать в него пачками от 1000 записей, не более чем 100 запросов в секунду. Так что какой-то буфер перед ним все равно потребуется.