Жизнь без транзакций

Поддерживает транзакции ACID, но, хотя транзакций в MongoDB нет, у нас есть атомарные операции. Ну, атомные операции означают, что когда вы работаете над одним документом, эта работа будет завершена до того, как кто-либо еще увидит документ. Они увидят все сделанные нами изменения или ни одно из них. И используя атомные операции, вы часто можете выполнить ту же самую вещь, которую мы выполнили бы с помощью транзакций в реляционной базе данных. И причина в том, что в реляционной базе данных нам нужно внести изменения в несколько таблиц. Обычно таблицы должны быть объединены, и поэтому мы хотим сделать это все сразу. И для этого, поскольку существует несколько таблиц, нам нужно будет начать транзакцию и выполнить все эти обновления, а затем завершить транзакцию. Но с MongoDB мы собираемся внедрить данные, так как мы собираемся предварительно присоединить к ним в документах, и это эти богатые документы, которые имеют иерархию. Мы можем часто выполнять одно и то же. Например, в примере блога, если мы хотим убедиться, что мы обновили сообщение в блоге атомарно, мы можем это сделать, потому что мы можем сразу обновить весь блог. Если бы это была куча реляционных таблиц, нам, вероятно, пришлось бы открыть транзакцию, чтобы мы могли обновлять коллекцию записей и комментариев.

Итак, каковы наши подходы, которые мы можем предпринять в MongoDB, чтобы преодолеть недостаток транзакций?

• реструктурировать - реструктурировать код, чтобы мы работали в одном документе и использовали атомные операции, которые мы предлагаем в этом документе. И если мы это сделаем, тогда, как правило, мы все настроены.
• реализовать в программном обеспечении - мы можем реализовать блокировку в программном обеспечении, создав критический раздел. Мы можем построить тест, тест и установить с помощью поиска и изменения. Мы можем строить семафоры, если это необходимо. И в некотором роде, так устроен более крупный мир. Если мы подумаем об этом, если один банк должен перевести деньги в другой банк, они не будут жить в одной и той же реляционной системе. И у каждого из них есть свои собственные реляционные базы данных. И они должны иметь возможность координировать эту операцию, даже если мы не можем начинать транзакцию и завершать транзакцию в этих системах баз данных только внутри одной системы внутри одного банка. Таким образом, есть определенные способы в программном обеспечении, чтобы обойти проблему.
• переносить - окончательный подход, который часто работает в современных веб-приложениях и других приложениях, которые используют огромное количество данных, - это просто терпеть немного несогласованности. Например, если мы говорим о фиде друзей в Facebook, неважно, будут ли все одновременно видеть обновление вашей стены. Если okey, если один человек несколько бьет позади в течение нескольких секунд, и они догоняют. Часто во многих конструкциях системы не критично, что все должно быть идеально согласованным и что каждый имеет абсолютно последовательный и одинаковый вид базы данных. Таким образом, мы могли бы просто терпеть немного несогласованности, которая несколько временная.

Update, findAndModify, $addToSet (в рамках обновления) и $push (в рамках обновления) операции работают атомарно внутри одного документа.

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

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

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

Настоящая проблема заключается в том, что пользователь может использовать условия гонки и отправлять больше сообщений, чем позволяет его баланс. Это также относится к РСУБД, если только вы не отправляете SMS внутри транзакции с блокировкой поля баланса (что было бы большим препятствием). В качестве возможного решения для MongoDB сначала следует использовать findAndModify, чтобы уменьшить баланс и проверить его, если он отрицательно отклоняет отправку и возвращает сумму (атомный приращение). Если положительный, продолжите отправку и в случае, если он не сможет вернуть сумму. Также можно сохранить коллекцию истории баланса, чтобы помочь исправить/проверить поле баланса.

Транзакции отсутствуют в MongoDB по уважительным причинам. Это одна из тех вещей, которые делают MongoDB быстрее.

В вашем случае, если транзакция является обязательной, mongo кажется не очень подходящей.

Может быть RDMBS + MongoDB, но это добавит сложности и затруднит управление и поддержку приложения.

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

Итак, если вам действительно нужен пилотный проект для MongoDB, выберите тот, который прост в этом отношении.