Ну если тестовая то пофиг

Совершенно нет

Всем привет. Вопрос про mongoose/mongo; В Schema Mongoose модели описал требующее индексации поле таким образом: { query: { type: String, text: true, index: true } } в query может лежать очень жирный текст с версткой и пр; Вопрос: как правильно совершить like поиск по этому полю? попробовал таким образом: https://stackoverflow.com/questions/24714166/full-text-search-with-weight-in-mongoose но match совершается только при соответствии слово в слово; по слогам не матчит

Совершенно нет

Что страшного случится при потере тестовой бд?

Что страшного случится при потере тестовой бд?

Сломаный CI ведёт к потере времени разработчиков, что убытки для компании.

Сломаный CI ведёт к потере времени разработчиков, что убытки для компании.

Ну иногда да, но если деплой сложный то экономии больше

Не надо деплоить монгу каждый раз

случайно ваш тред увидел - а чего для тестов не юзать in-memory монгу? типа https://www.npmjs.com/package/mongodb-memory-server ?

Не надо деплоить монгу каждый раз

Тестовую для локальной разработки то чего нет

Потому что проблема не в хранилище, а в доступности сервиса.

Тестовую для локальной разработки то чего нет

Слово «каждый раз» ключевое

Ладно я понял к чему вы клоните

по умолчанию 20

бредовое предложение: попробуйте разбить на два этапа, на первом вы получаете нужно N доков, на втором делаете выборку по обычному find

Если у вас stand-alone нода, да пожалуйста. Если вы деплоите кластер для разработки то быстрее это делать через mlaunch

спасибо сейчас попробую

поулчится что вы фактически часть обогащения данных делаете вручную

спасибо сейчас попробую

добрался до ноута. во-первых, не используйте базу данных чтоб управлять отображением. "$ifNull": ["$smi_type", "No data"] это отвественность потребителя данных, а не монги

тоже самое касается подстановок title, description и тд

@dd_bb а подскажите, плиз, доку, где можно почитать про то, как wt хранит данные на диске? там же какой-то минимальный размер страницы должен быть. и отдельно это все в разрезе компрессии :) или только в сорцах?

не надо это читать

зачем!

я псих интересно

зачем?

не бывает просто так интереса, бывает попытка решить проблему вообще не тем способом :)

у меня тут много решений "не тем способом", к сожалению. и я тут для себя понял, что не понимаю, как это всё лезет на диск. потому и хочу понять, для теории.

вообще не важно как лезет

проблема не в этом 100%

спасибо сейчас попробую

без данных и индексов очень сложно, но да, @yatoba вероятно прав, про несколько запросов. Без $expr будет эффективнее, потому что $expr в вашем случае похоже не пытается пересекать индексы

@dd_bb а подскажите, плиз, доку, где можно почитать про то, как wt хранит данные на диске? там же какой-то минимальный размер страницы должен быть. и отдельно это все в разрезе компрессии :) или только в сорцах?

страницы чего?

памяти, хранилища?

хранится в байтах, да действительно постранично. размер динамический, жмётся всё содержимое перед записью, если включена компрессия

понял, спасибо!

спасибо сейчас попробую

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

понял, спасибо!

но зачем?

но зачем?

я и правда это для теории. Возникла она из вопроса в воздухе - если мы будем писать в документ на ~40% / 1k данных меньше, какой будет профит и в каком %% соотношении с точки зрения монги и нашей нагрузки. отсюда и стало интересно понять, как wt пишет данные.

да, я отдаю отчёт, что это не подход к решению решения проблемы, что есть еще индексы на этой коллекции, есть сжатие, вот это всё. но для себя -интересно. не более.

а ответ на возникший вопрос будет сделан в боевых условиях :)

я и правда это для теории. Возникла она из вопроса в воздухе - если мы будем писать в документ на ~40% / 1k данных меньше, какой будет профит и в каком %% соотношении с точки зрения монги и нашей нагрузки. отсюда и стало интересно понять, как wt пишет данные.

исходя из теории ограничений, ваш профит будет зависеть от того, в какие ограничения вы уже уперлись

в целом меньше пишем, меньше IO, меньше места занимаем

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

по этому теоритические изыскания не имеют смысла вообще

берём срез, берём тестовый стол и меряем

Диск на данный момнет - узкое место. его утилизация в пиках - 100% а в не-пиках — те же 100%, но секондари начинает отматывать время обратно. в этот момент меняется соотношение read/write, что, в общем-то, логично и ожидаемо.

что такое «отматывать время обратно»?

берём срез, берём тестовый стол и меряем

однозначно. потому - не только теория, а чтобы и тесты были хоть с какой-то теорией. И чтобы результаты тестов на теорию накладывались.

то как оно на диске или в памяти хранится вообще к вашей проблеме отношения не имеет :)

точнее это знание ничего не изменит

что такое «отматывать время обратно»?

во время пиков реплика не успевает догнаться и начинает отставать.

а, лаг увеличивается, окей

то как оно на диске или в памяти хранится вообще к вашей проблеме отношения не имеет :)

отрицательный результат - тоже результат. и понять, что мне это не надо - тоже результат :)

вопрос скорее стоит в том, что будет дешевле — заменить железо или заменить софт

40% снижения размера документа, если у вас уже включена компрессия, не приведёт к 40% снижению размера данных

если у вас много cpu, вы можете попробовать переехать на zlib

но опять-же, это всё надо оценивать с точки зрения экономической целесообразности

потому что zlib потребует перелива всех данных

"creationString" : "access_pattern_hint=none,allocation_size=4KB,app_metadata=(formatVersion=1),assert=(commit_timestamp=none,read_timestamp=none),block_allocation=best,block_compressor=zlib

ну тоды ой :)

Уже на злибе

но опять-же, это всё надо оценивать с точки зрения экономической целесообразности

всё так и очевидно, что нет волшебной ручки, которая сделает счастье. но иногда интересно поковыряться там, где раньше не был, гг

«будем меньше писать» это будущий эффект, так как проблемы у вас уже сейчас, то либо вам придётся ретроспективно почистить данные, либо эффекта не будет

там ничо интересного. wt внутри интересен когда хочешь написать свой kv сторадж :)

там ничо интересного. wt внутри интересен когда хочешь написать свой kv сторадж :)

нет, не хочу :))

«будем меньше писать» это будущий эффект, так как проблемы у вас уже сейчас, то либо вам придётся ретроспективно почистить данные, либо эффекта не будет

Всё так.

ну вобщем-то дороги две: если можно влезть в какое-то ещё железно за разумные бабки — вертикально масштабироваться. если такое железо дороже, чем заводить себе шардированный кластер, то горизонтально масштабироваться

чикать данные конечно можно, но маловероятно что это пройдёт без измнений в по, а это скорее всего будет очень дорого

Изменение диска в амазоне не дает ощутимого прироста. даёт, но не ощутимый :) это странно, потому и лезу в теорию. Софт поменять будет в разы проще, но перед этой заменой как раз и хочется понять, стоит ли овчинка выделки.

да, у нас всё не как у людей :)

Изменение диска в амазоне не дает ощутимого прироста. даёт, но не ощутимый :) это странно, потому и лезу в теорию. Софт поменять будет в разы проще, но перед этой заменой как раз и хочется понять, стоит ли овчинка выделки.

вы могли уперется в шину, которую амазон использует для подключения хранилищ

я не беру это в расчет - я опираюсь на то, что купил у амазона. а там явно и иопсы, и скорость, и вот это вот всё.

ну у амазона вообще дофига органичений по пропускной способности. они зависят как он инстанса, так и от типа EBS

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSOptimized.html

там таблички есть

если у вас не EBS-optimized инстанс, то там не такие уж и большие цифры по bandwidth

да, я в курсе этих дел - там всё подходит, - и лимиты по iops на конкретный инстанс, ну и на сами диски, конечно же.

да, я в курсе этих дел - там всё подходит, - и лимиты по iops на конкретный инстанс, ну и на сами диски, конечно же.

А что именно 100% используется: iops или ширина?

чтото мне подсказывает, что то одно, то другое суть в чем - утилизация в 100%, что достаточно красноречиво. по метрикам с самого инстанса иопсы редко за 10к вылезают, равно как и по bw никак до лимита по ebs не влазит.

но тесты fio на этот диск упирались в iops - что логично, в общем-то

10k иопсов - это если мерять со стороны самого инстанса. у aws их будет поменьше чуть, скорее всего - они ж умеют merge-ить запросы.

чтото мне подсказывает, что то одно, то другое суть в чем - утилизация в 100%, что достаточно красноречиво. по метрикам с самого инстанса иопсы редко за 10к вылезают, равно как и по bw никак до лимита по ebs не влазит.

не, цифра в отрыве от измеримого значения — бессмысленна

100% iops это одна история, 100% bw это другая совершенно