MongoDB: основанная на документе ACID против многодокументной ACID - PullRequest
Новая
       34

MongoDB: основанная на документе ACID против многодокументной ACID

2 голосов
/ 19 апреля 2020

Рассмотрим приложение, в котором у нас есть несколько документов (я использую do c вместо документа, чтобы отличить его от документа MongoDB), и в них выполняются изменения. Единственное требование, которое у нас есть, - это то, что изменения в нескольких документах выполняются атомарно (все они выполнены или отсутствуют). Есть два способа реализовать это:

  1. Транзакция запускается, и все изменения в документах выполняются внутри нее. Тогда это передано. Всякий раз, когда нам нужен do c, мы извлекаем его по его идентификатору.
  2. Новый документ добавляется в MongoDB, который включает все изменения в документах (пример ниже). Поскольку документ вставляется атомарно, транзакция не требуется. Мы помещаем индекс в changes.docId и всякий раз, когда мы хотим получить do c, мы находим все изменения в do c (по индексу) и объединяем их и производим do c . 
{
    _id: ...
    changes: [
            {docId: 1, change: ...},
            {docId: 10, change: ...},
            {docId: 5, change: ...},
            ...
        ]
}

Обратите внимание, что поскольку нам нужна история изменений, даже в первом решении мы сохраняем измененные значения внутри do c. Таким образом, по мере места хранения эти два решения не сильно отличаются (без учета индексов, ...).

Вопрос в том, какое из этих решений лучше?

Некоторые из моих собственных мыслей по этому вопросу:

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