yopp
но ещё раз: лучше такой патерн не использовать
Aga
Здравствуйте товарищи, два вопроса
Aga
У монги же нет проблем с импортом базы данных на разные версии?
Aga
И какой самый тру способ, чтобы вытащить 4 рандомной записи, без повторений?
TAB_mk 🍑
И какой самый тру способ, чтобы вытащить 4 рандомной записи, без повторений?
Вообще $sample, но за повторения почитай лучше, там есть сноска warning, но я не знаю, к каждому запросу она относится или как. Я погонял немного, одинаковых не вернуло.
TAB_mk 🍑
Aga
Вообще $sample, но за повторения почитай лучше, там есть сноска warning, но я не знаю, к каждому запросу она относится или как. Я погонял немного, одинаковых не вернуло.
в принципе если примерно 100 записей, то вероятность почти нулевая. Но хотелось бы быть уверенным в этом
Aga
TAB_mk 🍑
Я раз 20 прогнал, ни разу не было.
Можешь сам попробовать тут - https://www.tutorialspoint.com/mongodb_terminal_online.php
Тут, правда, 3.4, но $sample с 3.2 есть, так что нормально.
Aga
Danil
Привет! Как получать только те документы, у которых есть определенное поле которое не required?
Bandikoot
Привет! Как получать только те документы, у которых есть определенное поле которое не required?
db.collection.find({ thatField : { $exists : true }})
можно дополнительно добавить проверку на null:
{ thatField : { $exists : true, $ne : null } }`
Sergey
У $exists есть одна важная особенность. $exists не умеет задействовать индексы. Единственный известный мне способ — это partial индекс, когда условие с $exists является частью фильтра этого индекса.
Sergey
Если поле никогда не бывает null, то эффективнее будет использовать thatField: {$ne: null}. Такие запросы менее капризны по части использования индексов.
yopp
У монги же нет проблем с импортом базы данных на разные версии?
Если из старой в новую — нет. Из новой в старую могут быть проблемы при переходе межу некоторыми версиями. например с Decimal128
Gor
У $exists есть одна важная особенность. $exists не умеет задействовать индексы. Единственный известный мне способ — это partial индекс, когда условие с $exists является частью фильтра этого индекса.
Привет, интересная инфа но вроде как уже устаревшая?
Sergey
Привет, интересная инфа но вроде как уже устаревшая?
Разве $exists научился использовать обычные индексы? Было бы здорово, конечно.
Gor
Разве $exists научился использовать обычные индексы? Было бы здорово, конечно.
ну вот погуглил, где то с 2рой версии вроде.
Sergey
ну вот погуглил, где то с 2рой версии вроде.
На 3.6 точно ещё не умел. На четвёрке не уверен, но поставил бы на то, что это не поменялось.
Gor
На 3.6 точно ещё не умел. На четвёрке не уверен, но поставил бы на то, что это не поменялось.
спс. перепроверю. есть где
yopp
$exists: true =?
"indexBounds" : {
"field" : [
"[MinKey, MaxKey]"
]
},
и $exists: false =>
"indexBounds" : {
"field" : [
"[null, null]"
]
},
yopp
"version" : "4.0.3",
Gor
ага. какраз видел закрытый issue с коментом - дайте детали и 3.6 устаревшая. но есть лайф проект на 3.6
yopp
но это в любом случае не очень идея
yopp
$exists это крайне неселективный запрос, который будет проезжать большие регионы индекса
yopp
да, это быстрее чем collscan, но это всё ещё широкое сканирование
Gor
$exists это крайне неселективный запрос, который будет проезжать большие регионы индекса
вот задумался заменить на програмное добавление поле с false если не предоставлен и искать уже на $eq: false
yopp
никакой разницы нет, null в индексе будет или false
yopp
поиск по наличию или отсуствию поля — антипатерн
yopp
это прокатывает для чужих датасетов, но если у вас есть контроль над схемой, то так делать не стоит
Gor
есть подмножество записей которые выводятся на условии "IsHidden"
yopp
при условии что у вас будет пересечение с другим индексом — да
yopp
но и то, я не у верен что тут можно эффективно пересечение сделать
Gor
ну там условие сложно составное да
Gor
не только это поле
Gor
но и еще разных куча - location, price, etc
yopp
помоему пересекаются найденные в индексе ключи, но я не уверен
Gor
ну я заметил что есть FETCH если есть поле которое на $exists false проверяется. но перед этим по индексу уменьшается список по другим полям. так что да, тут в тему вроде
yopp
FETCH это уже документ из хранилища достать
yopp
мы уже знаем внутренний id документа и делаем k/v fetch из хранилища
Gor
там он используется для проверки значения полей
Gor
пока не слелал сложный индекс - дергало очень сильно
yopp
find({"target_collection_name": {"$exists":false}, _type: {"$ne": "Command::Aggregate»}})
"indexBounds" : {
"target_collection_name" : [
"[null, null]"
]
},
"keysExamined" : 62,
yopp
ну короч takoe
Gor
на 4ке
yopp
лень разбираться, но find({"_type": /^Command.*/, "target_collection_name": {"$exists":false}})
тоже чот не триггерит пересечение у планировщика)
yopp
https://jira.mongodb.org/browse/SERVER-3071?focusedCommentId=508454&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-508454
yopp
With index intersection, we can now retrieve the documents with "electronics" and the documents with "laptops" using two separate index scans, and then fetch only the intersection of the two scans. This "self-intersection" can considerably reduce the number of complete documents that the query execution needs to retrieve. We currently cap the number of "self-intersection" scans at 10.
yopp
в 2.x действительно пересекали ключ
yopp
на месте планировщика я бы не стал пересекать с $exisits в этом случае
yopp
вероятнее всего там будет очень много ключей
yopp
интересно, может ли монга в filter у fetch делать запрос в индекс
yopp
это всяко дешевле чем ходить на диск, если индекс в памяти
yopp
Neither of the indices to be intersected are highly selective. If one of the indices is selective then the optimizer will choose a plan which simply scans this selective index.
yopp
ну уобщем вот
yopp
что?
Bro
Последний документ из коллекции
Bro
ну т.е. в objectid - первые 4-byte value representing the seconds since the Unix epoch
yopp
да, но никто не гарантирует что это время будет монотонно возрастать, совпадая с порядком вставки документом
yopp
там может быть и знаменитое 1 января 1970 года ;)
yopp
и у нескольких документов время может совпадать, это тоже не запрещается
yopp
а остальные байты тоже ничего о порядке не говорят: там по сути мусор
yopp
случайные величины
yopp
т.е. это не порядок вставки, это скорее _примерное_ время вставки
yopp
а время это такая субстанция, которую для определнения «порядка» надо использовать очень аккуратно, потому что время относительно
Bro
я просто если нужны такие сортировки делаю
Bro
created_at: datetime.utcnow()
Bro
и потом по нему сортирую
Bro
только если в колеекции много элементов (>100m) и в запросе есть find({something: True}).sort({created_at: 1})
Bro
нужно compound index делать {something: 1, created_at: 1}
yopp
а wall clock это привет от ntp
yopp
когда ntp решит подкорректировать время, ваши часы будут двигаться назад
yopp
не факт что будут, но могут
yopp
второй момент: если у вас два сервера, на них будет разное время
yopp
насколько разное ¯\_(ツ)_/¯
yopp
т.е. вопрос насколько порядок реально важен