y
вопрос: может ли монга сторить бинарник ~10кб в документе без сериализации в base64?
да. в Binary bson type
Size: a a a
2020 April 29
e
да. в Binary bson type
а почему в клиентской проге я вижу, что он в base64? или это для удобства?
y
Если там Binary(…, <base64>), то да, для удобства
e
тогда понятно, спасибо
y
странно, я как раз таки наоборот делаю, именно потому что authenticationDatabase по умолчанию используется та база, к которой коннект присходит. По крайней мере в mongo модуле для nodejs
а это ещё один уровень веселья, это зависит от того как вы настраиваете подключение
y
потому что uri string будет работать вот так
y
Specify the database name associated with the user’s credentials. If
authSource is unspecified, authSource defaults to the defaultauthdb specified in the connection string. If defaultauthdb is unspecified, then authSource defaults to admin.y
TL;DR: при подключении не стоит указывать базы данных или authDB
DS
Specify the database name associated with the user’s credentials. If
authSource is unspecified, authSource defaults to the defaultauthdb specified in the connection string. If defaultauthdb is unspecified, then authSource defaults to admin.ну да, видимо все наши прогеры указывают. ну и пусть. Зато в одном месте хранится и роль и юзер.
k
Всем привет! В какой ситуации монгод может выбирать разные индексы на один и тот же запрос?
Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация).
Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN.
В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n
Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация).
Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN.
В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n
y
Всем привет! В какой ситуации монгод может выбирать разные индексы на один и тот же запрос?
Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация).
Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN.
В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n
Есть коллекция в боевой базе, делаю с неё дамп, ресторю на локальный монгод в докере вместе с индексами (версия сервера та же, отличаются тем что локально один сервер, а в боевой есть репликация).
Делаю два одинаковых запроса в боевую и локальную, по логам видно что используются разные IXSCAN.
В обоих случаях составные индексы. Просто в одном случае он обходит n документов, в другом 10*n
В момент когда в первый раз выполняется запрос по шейпу, который не находится в кеше планов, монга пытается предсказать сколько времени и ресурсов займёт по каждому из подходящих под этот шейп планов, выполняя тестовую выборку. Какой план будет дешевле, тот и победит и попадёт в кеш.
Почему выйграл один план, но проиграл другой сказать сложно. Причин много, начиная от нагрузки в момент выполнения тестовых выборок, заканчивая количеством попавших в неё документов.
Если вы хотите чтоб монга выбирала конкретный индекс, то используйте hint
Почему выйграл один план, но проиграл другой сказать сложно. Причин много, начиная от нагрузки в момент выполнения тестовых выборок, заканчивая количеством попавших в неё документов.
Если вы хотите чтоб монга выбирала конкретный индекс, то используйте hint
k
спасибо) а где об этом почитать подробнее?
k
в доке не помню таких подробностей
y
The evaluation of the most efficient query plan is based on the number of “work units” (
works) performed by the query execution plan when the query planner evaluates candidate plans.k
спасибо!
VM
Привет! Нужен wildcard-индекс такого рода:
db.mycoll.createIndex( { "manual_responsibilities.$**.responsibility_class_id": 1 } );. Думаю из строки понятно, что я пытаюсь сделать. Но монга не дает такое провернуть. Есть ли способ это обойти?DL
Привет! Нужен wildcard-индекс такого рода:
db.mycoll.createIndex( { "manual_responsibilities.$**.responsibility_class_id": 1 } );. Думаю из строки понятно, что я пытаюсь сделать. Но монга не дает такое провернуть. Есть ли способ это обойти?Каждый раз создавать новый индекс при появлении нового значения, это можно автоматизировать, но это такое себе решение, проще сделать такую схему данных, где не возникнет такой проблемы
VM
Каждый раз создавать новый индекс при появлении нового значения, это можно автоматизировать, но это такое себе решение, проще сделать такую схему данных, где не возникнет такой проблемы
спасибо. То есть с помощью wildcard такое нельзя сделать вообще, получается?
DL
спасибо. То есть с помощью wildcard такое нельзя сделать вообще, получается?
Вообще в доке написано, что:
«The wildcard index can support arbitrary single-field queries on product_attributes or its embedded fields»
«The wildcard index can support arbitrary single-field queries on product_attributes or its embedded fields»