Предложение по улучшению индексов MongoDB

Question

Одна из вещей, которые мы узнаем из видеоролика «Index Cardinality» [M101J: MongoDB для разработчиков Java], заключается в том, что когда документ с мультикидным индексом перемещается, все его индексы также должны быть обновлены, что несут значительные накладные расходы.

Я думал, что можно каким-то образом обойти это ограничение. Очевидным решением является добавление еще одного уровня косвенности (это известный шаблон для решения проблем компьютерной науки :-)), и вместо ссылки на документ непосредственно из индекса мы создаем сущность для каждого документа, который ссылается на этот документ и получает индексы для ссылки на этот объект, и теперь, когда мы перемещаем документ, нам нужно только модифицировать эту сущность (объект никогда не будет перемещаться, потому что его форма BSON всегда будет одинаковой). Проблема с этим решением, конечно, в том, что для торгового пространства для производительности (индексы также страдают от этой проблемы).

Но всякая надежда не потеряна; в MongoDB все документы имеют неизменяемое поле _id, которое автоматически индексируется. Учитывая все это, мы знаем, что если документ когда-либо перемещается, его связанный индекс _id также будет обновляться, поэтому почему бы не просто сделать все остальные индексы ссылками на соответствующий индекс _id документа?

Учитывая это решение, единственным индексом, который когда-либо будет обновляться при перемещении документа, является индекс _id.

Я хочу знать, может ли это решение быть реализовано в MongoDB или есть некоторые скрытые ошибки, которые сделают его непрактичным?

Благодаря

Answer 1

Вот ответ, который я получил от "Энди Шверин", когда я отправил тот же вопрос, как билет Jira: https://jira.mongodb.org/browse/SERVER-12614

Энди Шверин Ответ:

• Это осуществимо, но делает все чтения доступ к основному индексу. Итак, если вы хотите прочитать документ, который вы найдете через вторичный индекс, вы должны взять этот _id, а затем найти его в основном индексе, чтобы найти текущее местоположение. В зависимости от приложения это может быть хорошим компромиссом или плохим. Другие системы баз данных в прошлом использовали специальные маркеры в старом расположении записей, иногда называемых надгробиями, чтобы указывать на новые местоположения. Это позволяет вам оплачивать косвенные действия только тогда, когда документ действительно перемещается за счет необходимости периодической очистки индексов, чтобы вы могли мусор собирать старые надгробные плиты.

Также благодаря Leif для информативной связи http://www.tokutek.com/2014/02/the-effects-of-database-heap-storage-choices-in-mongodb/ я попросил автора тот же вопрос, и вот его ответ:

Zardosht Kasheff Ответ:

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