yopp
change stream это по сути tailable курсор в rs.oplog
Oleg
yopp
с фильтром по нужному нейсмпейсу
yopp
а теперь сделайте explain(«executionStats»)
yopp
"totalKeysExamined" : 89419,
"totalDocsExamined" : 0,
yopp
это значит что запрос выполнен без обращения к документам, по индексу type_1_ad_id_1_ip_1
Oleg
это значит что запрос выполнен без обращения к документам, по индексу type_1_ad_id_1_ip_1
хорошо, но почему тогда время запроса 0.2 sec?
yopp
попробуйте хинтануть индекс type_1_ad_id_1
yopp
но это не то чоб глобально изменит ситуацию
Oleg
yopp
покажите executionStats с ip: 1 в проекции
Alexander
но это не то чоб глобально изменит ситуацию
А как монга выполняет count-запрос? В моих понятиях, это делается спуском по дереву и подсчётом детей. Но что-то это не очень похоже на 0.2 секунды.
yopp
но в любом случае, только поиск по индексу занимает 110мс
yopp
yopp
но вобщем-то быстрее уже не сделать
yopp
почему у вас так долго сканируется индекс, это уже вопрос не к монге
yopp
видать ресурсов мало
yopp
projection я так понимаю нужен чтоб из ключа индекса восстановить документ
Oleg
одинаковое время
yopp
возможно count уже использует covered query под капотом, да
Alexander
по какому дереву и каких детей?
Ну, по B+-дереву, скорее всего. Или что монга использует для хранения индексов?
Хотя, я сейчас посчитал: если каждый раз оно идёт мимо page cache напрямую в диск, то примерно где-то 0.1 секунды на скан и получается :(
yopp
вы куда-то далеко уже смотрите
yopp
монга это k/v на стероидах
yopp
всё — k/v хранилище. их минимум два: документы и _id
yopp
документы адресуются по внутреннему id, а _id как и другие уникальные индексы адресуются по value значения _id и содержит в себе внутренний id
yopp
ну и дальше как и в любом k/v хранилище: у нас есть fetch и scan
yopp
как оно там внизу уже работает примерно пофиг
yopp
в зависимости от того что придумает планировщик, туда монга и пойдёт
yopp
не знаю точно что сейчас монга умеет оптимизировать в count
yopp
в итоге, фиговый сценарий — будет делать fetch всего хранилища документов
yopp
или наилучший сценарий сделает fetch одного ключа индекса
yopp
а играть в игру угадай тайминг операции бесмысллено
yopp
200мс на 90к ключей говорят только о том, что где-то бутылочное горлышко. найти его, отдельная задача
yopp
оно может быть _где угодно_
yopp
между монгой и физическими данными наверное под сотню различных буфферов и кешей
yopp
и ещё с десяток различных планировщиков :)
Alexander
как оно там внизу уже работает примерно пофиг
Вот это как раз и интересно =).
То есть, запрос сейчас выполняется так: монга ставит курсор на дерево, и потом count перемещает его и постепенно вычитывает ключи, считая их.
А можно сделать так: бд ищет в дереве узел, который отвечает за нужный range ключей и забирает оттуда число "количество детей", но, видимо, монга так в принципе не умеет делать из-за слишком абстрактной модели вычисления.
yopp
ох
yopp
«количество детей» в дереве )
Alexander
между монгой и физическими данными наверное под сотню различных буфферов и кешей
Собственно, как правильно Вы и заметили.
yopp
количество детей в дереве кто и когда будет считать?
yopp
что делать когда дерево балансируется?
yopp
когда мержатся или делятся ветви?
yopp
что делать с tombstones?
yopp
это ребёнок?)
yopp
яж говорю, нет смысла глубоко смотреть. потому что какое там дерево и как по нему бегается, это практически нерелевантно
Alexander
что делать когда дерево балансируется?
Ну это довольно простая задача, на самом деле. Любое дерево при перестрояниях позволяет пересчитать количество детей, не ухудшая асимпотитку, собственно, перебалансировки.
Alexander
яж говорю, нет смысла глубоко смотреть. потому что какое там дерево и как по нему бегается, это практически нерелевантно
Не знаю как Вам, мне всегда интересно разобраться, что же там "глубоко".
yopp
там глубоко LSM
yopp
в случае с wt
Alexander
там глубоко LSM
Вот это уже интересно. LSM не позволит так быстро делать, как B-деревья, это правда.
yopp
вы пытаетесь мух оптимзировать
yopp
я сомневаюсь что сложность этой задачи что-то оправдывает
Alexander
вы пытаетесь мух оптимзировать
Да нет. Мы проблему решили добавлением ещё одного поля, чтобы не выполнять aggregate каждый раз =)
yopp
я конечено понимаю что когда CoW, нам в любом случае всю ветврь наверх обновлять и почему бы не обновить кроме указателей какие-то счётчики, но это очень сложная задача
Alexander
я конечено понимаю что когда CoW, нам в любом случае всю ветврь наверх обновлять и почему бы не обновить кроме указателей какие-то счётчики, но это очень сложная задача
Она сложная, на самом деле, только в части "какие пользовательские счётчики хранить".
yopp
лол
Alexander
Она сложная, на самом деле, только в части "какие пользовательские счётчики хранить".
Хотя, нет. Я неправ, конечно же: с LSM это всё сложнее становится. Но, тем не менее, возможно.
yopp
я очень плохо разбираюсь в проблемном поле дизайна индексов, но даже с моими скудными знаниями мне очень кажется что вы со сложностью ошибаетесь наверное на пару порядков)
Oleg
yopp
ну и я сразу могу сказать что ваша оценка о том что это не повлияет на сложность не верна :)
Alexey
всем привет, не подскажите, есть ли аналоги mlab - платформа предлагает бесплатную удаленную mongodb на 500мб, но сейчас правда уже не предлагает(.
А то решил попробовать на ноде попробовать что-то писать, и так получается, что буду делать это скорее всего на разных компьютерах, ну и хотелось бы какую-то базу иметь удаленную бесплатную небольщую, необязательно даже монгу, просто если есть аналоги какие бесплатные, то подскажите, пожалуйста
yopp
те-же самые 500 мегабайт бесплатно
yopp
ну и я сразу могу сказать что ваша оценка о том что это не повлияет на сложность не верна :)
потому что надо двигать больше байтиков по регистрам
yopp
больше байтиков, больше задержек
Oleg
Alexey
@dd_bb спасибо
yopp
перенос базы данных на ноутбук выдал такие данные
можно поиграть в игру «угадай селективность»