Используете MySQL триггеры или транзакции?

Question

Я хочу спросить ваше мнение об использовании триггеров MySQL или транзакций на веб-сайте.

На самом деле у меня есть история payment стол с - UserId | OperationId | Comment | Credits | Sign (debit or credit).Таким образом, каждая платежная операция заносится в эту таблицу.

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

Вот в чем проблема.Как я могу быть уверен, что общая сумма кредита составляет profile таблица останется синхронизированной с операциями из payment таблица истории ?

Я думал использовать 2 метода:

• MySQL запускает или
• транзакции, закодированные в исходном коде

Что более надежно?Что делать, если у меня большая база данных (более 100 000 пользователей)?

Есть ли у вас какие-либо предложения, как это сделать?

Движком BD MySQL является InnoDB.

Answer 1

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

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

Объедините это с тем фактом , что надлежащие протоколы проверки данных не реализованы в языке хранимых процедур MySQL. Бизнес-аналитику можно содержать в базе данных при условии, что язык хранимых процедур может обрабатывать транзакционную среду.Как администратор базы данных MySQL, я должен честно сказать, что в MySQL это не так.Oracle (PL / SQL), PostgreSQL (PL / pgSQL) и SQL Server (T-SQL) имеют это преимущество перед MySQL.

Что касается транзакций, MySQL использует InnoDB в качестве основного механизма хранения, совместимого с ACID (механизм хранения данных Deafult в MySQL 5.5).Он обладает превосходным аварийным восстановлением и соответствует протоколам соответствия ACID.

Я бы каждый раз выбирал транзакции, а не триггеры.

Answer 2

Я согласен с оценкой Роландо.Ваша бизнес-логика должна находиться в вашем приложении и вносить изменения в базу данных транзакционным путем.

Масштабирование до 100 000 пользователей, конечно, зависит от вашего приложения и генерируемого им трафика базы данных.Поскольку MySQL подвергается большой транзакционной нагрузке на запись, вы можете вскоре столкнуться с необходимостью сегментирования и / или репликации вашего набора данных для поддержания приемлемого отклика приложения.

Однако существуют альтернативы сегментированию MySQL.Одним из них является Кластеррикс (мой работодатель), которая представляет собой параллельно масштабируемую высокопроизводительную систему баз данных SQL с одним экземпляром.Это кластеризованная система баз данных, которая представляет себя как единый сервер MySQL.Плавное масштабирование базы данных, описанной в этом потоке, до 100 000 пользователей в одном экземпляре Clustrix не потребует сегментирования и дополнительной логики приложения.

Answer 3

Хороший ответ от Роландо.

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

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

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

Кроме того - у вас все равно будут транзакции - вы не будете выполнять свои триггеры без них...верно?Поэтому полезно знать, как начать транзакцию;сделай кое-что;а затем завершите транзакцию.Если вы увидите этот шаблон в своем коде, еще один фрагмент кода, использующий его, облегчит когнитивную нагрузку.Триггер, если вы помните, что он есть, заставит вас думать по-другому для тех транзакций, на которые влияет триггер, особенно если задействованы другие таблицы, которые также могут иметь триггеры.

В принципе, между регулярно запланированным заданием cron (или заданием агента базы данных) и хорошими хранимыми процедурами вы можете выполнить 99% того, что вы хотите.Тот самый 1%;переосмыслите проект.