yopp
и сделать индекс ad_id: 1, type: 1
yopp
но в любом случае, если у вас там 90к документов, надо будет проехать по 90к ключам
yopp
время выполнения запроса будет зависеть от числа документов попавших в выборку
Alexander
больше байтиков, больше задержек
Это тоже правда. Но, может, не настолько много байтиков нужно таскать и не настолько возрастёт задержка, а скорость ответа на запрос — упадёт в разы.
yopp
разы в одном очень узком случае
yopp
при соблюдении ряда требований к топологии дерева ещё
yopp
товарищи которые пилят wt, делают базы данных не первое десятилетие
yopp
даже помоему не второе
Alexander
товарищи которые пилят wt, делают базы данных не первое десятилетие
Я не спорю с ними. Я пытаюсь понять, почему монга так принципиально не может делать :)
yopp
потому что в этом смысла нет
yopp
яж говорю, это очень сложно
yopp
похожую проблему можно решить иначе
yopp
и без усложенения индексов
Vladislav
Друзья, а кто-то использует Mongoose ?
Хотел спросить, можно ли seamless мигрировать из использования sub-schemes (схема в схеме, в созданных инстансах будут свои _id) на использования просто объекта в схеме ?
Lev
@dd_bb Как то можно понять по самой монге что либо о слушателях oplog? Может хотя бы количество? Или хотя бы обращается ли кто либо к этому оплогу?
yopp
можно попробовать включить отладочный лог и посмотреть с какими парамтерами открывается курсор в оплог
yopp
но я уверен что ваша проблема решается без этого
yopp
вы скорее всего что-то не то указали в подписке на изменения
Lev
вы скорее всего что-то не то указали в подписке на изменения
Я тоже так думаю. Но я без понятия что и в нете мало инфы почему то. Я с java пытаюсь прицепиться, через spring data
yopp
на джаве совсем плохо говорю
yopp
collection.watch().forEach(printBlock); из документации
yopp
так тоже не работает?
Lev
Или... я не в то время вешаю эту подписку
yopp
изолируйте свой кейс. сделайте приложение которое ничего не делает, кроме как открывает содениние в монгу и создаёт подписку и вечно ждёт документов из подписки
yopp
запустите приложение, убедитесь что оно смогло соединиться с монгой и добавьте несколько документов
yopp
жуть какая этот ваш спринг
yopp
попробуйте ещё operationType указать явно
Lev
Он просто много что за нас делает. Но иногда из-за этого проблемы. Можно отказаться от того, чтобы он сам все делал - будешь ручками сам такую тонну настраивать. Или можно самому все написать и наделать багов. Точек зрения много.
Nick
если чтото не понятно как делается, то сначала с этим надо разобраться
Lev
@yatoba Да, по хорошему надо разбираться во всем что делаешь. Но но но...
Nick
без но, спринг большая сложная штука и в ней надо разбиратсья чтобы использовать, если у вас приложение сложнее полутора недокрудсервисов на рестах и простшими круд операциями на бд
Lev
без но, спринг большая сложная штука и в ней надо разбиратсья чтобы использовать, если у вас приложение сложнее полутора недокрудсервисов на рестах и простшими круд операциями на бд
Спринг особенно boot как раз рассчитан на то, что интуитивно будет понятно что происходит. Иногда будешь спотыкаться, но в 90% случаев ты просто угадаешь что происходит на самом деле...
Lev
И да, такой подход обычно и за подход не считают %)
Nick
вот именно 90% случаев - простые микросервисы с примитивными операциями
Nick
вы попали в оставшиеся 10
Lev
Не.. я про... 90% это я не про типа приложений. Это про угадывание как оно работает. В 10% вы не угадаете и придется разбираться. Например в моем случае. Все усугубляется что даже на SO всего 4 совпадения и не совсем на мою тему.
Nick
я так понимаю не заводятся ченж стримы
Lev
В личку отпишу, а то это не про монгу
Lev
@yatoba @dd_bb В моем приложении не предусмотрено удаления или переименования коллекций, а drop db предусмотрено. При этом я получаю набор DROP коллекций, DROP_DATABASE и потом INVALIDATE operation в слушателе change stream. На этом change stream я строю работу интерфейса, который отображает живые данные. Как я понимаю, при получении таких operations я должен перерегистрировать слушателя, после чего сообщить всем обработчикам интерфейса чтобы они переинициализировались с базы данных (выкачали оттуда все с нуля и снова слушали что слет им слушатель). Но если я на каждый DROP буду делать переинициализацию... это тяжко будет, очень. Да и сам DROP_DATABASE может еще не наступить. Я ведь правильно понимаю, что в момент когда я получу INVALIDATE я уже могу смело перерегистрировать слушателя и переинициализировать интерфейс? Или есть какая то хитрость?
Lev
.... интересно... а как синхронизировать эту переинициализацию и change stream...
Nick
Может вам просто очередь событий завести?
Lev
Она есть. Этот слушатель бд перепаковывает сообщения в то, что мне надо и шлет в очередь (inmemory или amqp. последовательность сохраняется).
Lev
И туда же я могу вписать событие на переинициализацию.
Lev
А... ну там есть... этот resumeAt. Типа можно просто взять и попросить переинициализацию с момента ... с какого момента - не понятно
Lev
Тут еще и банальный рестарт приложения... при котором надо тоже инициализировать интерфейс, выкачав все с бд. И начать слушать ее. Как же это синхронизировать?
Lev
Сначала слушать а потом инициализировать или наоборот? @yatoba
Lev
Я пока вот как подумал:
1. Замеряю время
2. Читаю данные с бд.
3. Как закончил читать - я запускаю оплог с того времени, что замерял ранее.
Тогда, оплог между 1 и 2 повторится после снапшота, но его не побьет, потому что удалит и так удаленное, создаст и так созданное, изменит и так измененное. А т.к. на этом основан декларативный код - ничего не изменится. ну моргнет там окошко какое нить и все
Nick
Ни разу с извращениями с оплогом не страдал, поэтому особо не помогу
yopp
но вообще я не понимаю вашего потока мыслей
Nick
Не знаю вашей специфики, но изменения измененного это ой какая большая проблема
yopp
сквозь него не видно проблемы
yopp
кто такие обработчики интерфейса
yopp
зачем делать drop
Lev
@dd_bb Ну... все равно задача инициализации останется. Я же не могу перечитать вообще весь оплог
yopp
куда перепаковывать
Lev
Перепаковка это не суть важно, я просто вытаскиваю оттуда (из сообщения) нужные данные, это можно опустить
yopp
как я уже говорил change stream это просто обертка вокруг oplog
yopp
весь change stream это tailable курсор в rs.oplog
Lev
И... типа я могу весь оплог выкачать?...
Lev
Но это мне ничего не даст. Если сервер поработает пару лет... я ... я надеюсь оплог таки чистится.
yopp
вы начните с проблемы которую вы решаете
yopp
точнее с цели, которую вы пытаетесь достигнуть
yopp
вы что-то куда-то через change stream синхронизируете? вам нужные какие-то особые гарантии? откуда drop database?
Lev
@dd_bb Ну, у интерфейса есть внутрее состояние. Оно обновляется событиями от бд. Поменялась сущность - поменялось состояние, интерфейс пересчитался и отправился пользователю (reactjs vue вот этот вот все, это норма).
Но при включении, запуске - мне надо как то проинициализировать интерфейс. То есть забрать с бд данные, не все. Все не могу - много. Я заберу часть бд запросами. Одновременно мне надо начать слушать оплог, получая обнволения.
yopp
не грузите меня вашими интерфейсами )
Lev
Ок, можем забыть про интерфейс) И про drop database то же.
Мне надо поддерживать inmemory базу данных... набор сущностей, как угодно.
Lev
Можно сказать, что существует запрос к базе данных, такой, результатом которого будет нужное мне состояние.
Lev
Ща ведь понятно да?
Lev
Мне в памяти приложения надо держать набор документов.
yopp
всё равно ничгое не понятно
yopp
вы хотите синхронизировать состояние монги с какоим-то сторонним in-memory хранилищем?
Lev
да
yopp
зачем?
Lev
Чтобы на этом хранилище построить интерфейс. Так делают, это норма.
Lev
Задача - засинкать хранилище.
yopp
считайте что это близко к невозможному