Блог

Главная - Вопросы по программированию - повышение производительности поиска в mongodb для необщих ключей

повышение производительности поиска в mongodb для необщих ключей

#mongodb #performance #indexing

#mongodb #Производительность #индексирование

Вопрос:

У меня есть несколько примеров json, как показано ниже. 

  {
       "userid":1,
       "name":"test",
       "phone":"7878787878",
       "email":"test@mail.com",
       "uuid":"testingOne",
       "location":"ZoneA"
    }

Я выбрал shard key в качестве идентификатора пользователя, поскольку он имеет хорошую мощность. 

 db.userDetails.createIndex( { "userid": 1 }, { unique: true } )
db.userDetails.createIndex( { "phone": 1 } )
db.userDetails.createIndex( { "email": 1 } )
db.userDetails.createIndex( { "name": 1 } )

sh.shardCollection( "userDB.userDetails", { userid: "hashed" } )

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

Итак, теперь вопросы

  1. Какова наихудшая задержка поиска для этих только что проиндексированных ключей.

  2. Если у меня есть 5 сегментов, есть ли возможность заставить mongo выполнять такой поиск по всем сегментам параллельно

Есть ли лучший способ ускорить поиск без фрагмента

Комментарии:

1. Помните, когда вы спрашивали, какой ключ сегментирования выбрать, и я в основном подводил вас к пониманию, что вам, вероятно, еще не нужно сегментирование, если вы не понимаете, какой из них выбрать? Это в значительной степени тот же тип вопроса. Посмотрите на хэшированное и ранжированное сегментирование и две разные диаграммы и попытайтесь понять, что на самом деле делает здесь «хэшированный». Вопрос действительно слишком широкий, и вы должны понимать, почему он слишком широкий, поскольку здесь просто «слишком много переменных».

2. С очень простой точки зрения, у вас в основном есть два принципа проектирования. 1. Вы действительно хотите , чтобы запросы группировались в определенный сегмент и использовали для этого диапазоны. Здесь у вас могут быть просто общие запросы и операции, которые будут работать с данными, находящимися в одном сегменте, без необходимости «ходить повсюду». 2. На самом деле вы хотите распределить все как можно более равномерно по всем сегментам. Это тот случай, когда «хеширование» работает, потому что оно предназначено для равномерного распределения данных, что также означает равномерное распределение запросов.

3. Я понимаю., спасибо за подробное объяснение, в моем случае, распространяя данные, я могу выбрать правильный ключ сегмента, поэтому я должен использовать тот же общий ключ при выполнении поиска. Но, как я уже упоминал, я также выполняю поиск на основе дополнительных ключей, и это будет очень редко, но его восстановление происходит медленно из-за разброса и сбора. Как насчет сохранения сопоставлений коллекций с другим ключом поиска в качестве ключа сегмента, например, исходной коллекции с ключом сегмента в качестве идентификатора пользователя, затем новой коллекции сопоставления с номером телефона в качестве сегмента, и она будет иметь «{phone:»», userid:»»} .