Как не ACID RethinkDB или MongoDB поддерживают вторичные индексы для не равных запросов

Ответ 1

Это отличный вопрос.

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

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

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

Надеюсь, что это поможет.

Ответ 2

Это ответ MongoDB.

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

MongoDB имеет транзакции для одного документа, и это важно для обновления индексов. Эти операции могут быть отменены с использованием журнала, если возникнет такая необходимость.

это должно произойти с той же транзакцией.

Да, очень похоже на РСУБД. Чем больше индексов вы применяете, тем медленнее ваши записи будут, и, похоже, вы знаете, почему.

По мере записи MongoDB обновит все индексы, которые применяются к этой коллекции, с полями, которые применяются к определенным индексам.

кроме того, если индекс может находиться на другом хосте, чем данные

Я не уверен, что MongoDB разрешает это, я считаю, что для него существует JIRA; однако я не могу найти эту JIRA в настоящее время.

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

Скорее всего. Разрешить эту функцию было бы... ну, пусть просто скажем, создавая шарик.

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

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

Это не то, что означает двухфазное принятие. Я считаю, вам нужно разобраться, что такое двухфазное принятие: http://docs.mongodb.org/manual/tutorial/perform-two-phase-commits/

Я предполагаю, что если вы говорите о транзакции, охватывающей более одного осколка, тогда hmm ok.

какой метод они используют, чтобы гарантировать, что вторичные индексы, которые находятся в структурах B-деревьев отдельно от данных, не являются устаревшими?

Agan Я не уверен, почему транзакция с несколькими документами повлияет на то, будет ли индекс устаревать или нет, а не группировать документы. Исключением является уникальный индекс, но он работает и с отдельными документами; обратите внимание на то, что его уникальность становится любопытной в заштрихованных установках и не может быть гарантирована.

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

Ответ 3

RethinkDB всегда сохраняет вторичные данные индекса на том же компьютере, что и индексирование данных. Это позволяет обновлять его в рамках одной транзакции. Переопределите promises как ACIDy с помощью операций с одним документом и считайте, что индексирование документа является частью самого документа.