время выполнения "millis" : 413,

В индексы судя по всему попадаю? "indexBounds" : { "startKey" : { "outSetupTime" : ISODate("2017-06-29T00:00:00.000Z") }, "startKeyInclusive" : true, "endKey" : { "outSetupTime" : ISODate("2017-06-29T23:59:59.999Z") }, "endKeyInclusive" : true }

это выжимка из db.system.profile.find().pretty()

https://docs.mongodb.com/manual/core/query-optimization

https://docs.mongodb.com/v3.4/administration/analyzing-mongodb-performance/

хм, что интересно, один и тот же запрос выполняется разное время в консоли монги и в node.js приложении в консоли 2 мс в node 436 мс

использую mongo native driver

что то в нем тормозит

нужно смотреть как строится запрос в драйвере

может он на самом деле не такой же самый

вопрос - есть коллекция, в ней {"_id": 1, "tags": []} {"_id": 2, "tags": ['foo']} {"_id": 3, "tags": ['foo', 'bar']} {"_id": 4, "tags": ['bar']} можно как-нибудь отсортировать* по наличию или отсутствию определенного элемента в тегах? типа db.coll.find({}).sort({'tags.$has': 'foo'}) чтоб вернуло, например, {"_id": 2, "tags": ['foo']} {"_id": 3, "tags": ['foo', 'bar']} {"_id": 1, "tags": []} {"_id": 4, "tags": ['bar']} подводный камень - версия сервера 2.6

Добрый день

root@lab1:/data# zcat user.gz | mongorestore —db vk —collection user 2017-06-29T12:19:13.424+0000 the —db and —collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use —nsInclude instead 2017-06-29T12:19:13.424+0000 using default 'dump' directory 2017-06-29T12:19:13.424+0000 see mongorestore —help for usage information 2017-06-29T12:19:13.424+0000 Failed: mongorestore target 'dump' invalid: stat dump: no such file or directory Что я делаю не так?

mongodb v3.4

Там же написали: mongorestore target 'dump' invalid: stat dump: no such file or directory

в архиве что?

в архиве результат команды mongodump -d vk -c vk —out=- | pigz > user.gz

Там же написали: mongorestore target 'dump' invalid: stat dump: no such file or directory

Что это значит?

не указал директорию

Директорию чего?

https://docs.mongodb.com/manual/reference/program/mongorestore/

И?

ну ты спросил что это значит

Да, и потом я спросил, директорию чего я не указал.

И?

Почитай внимательно документацию к mongodump/mongorestore

Я почитал.

Там в конце точь в точь такая же команда, как я вам показал.

Если я недостаточно внимательно читал, подскажите, где я ошибся.

Без ссылок на маны т.к. это равносильно ответу "не знаю"

Там в конце точь в точь такая же команда, как я вам показал.

Где именно?

You can also pipe data directly into to mongorestore through standard input, as in the following example: zcat /opt/backup/mongodump-2014-12-03/accounts.people.bson.gz | mongorestore —collection people —db accounts AUTHOR MongoDB Documentation Project COPYRIGHT 2011-2015

nsinclude уже пора юзать :)

А, кажется понял

В linux man кривой :)

По ссылке, что дал yopp видно "-" в конце команды, у меня же этого дефиса нету в мане

В linux man кривой :)

Да, неточность

последним аргументом с -d и -c оно ожидает путь к .bson файлу

Попробую зарепортить им баг

Проще сразу пуллреквест сделать :)

https://github.com/mongodb/mongo/blob/master/debian/mongorestore.1

о, попробую

чатик, нид хелп. При восстановлении конфиг-сервера из бекапа есть такая коллекция config.version https://docs.mongodb.com/manual/reference/config-database/#config.version Обязательно ли ее заменять при восстановлении и если допустим не затирать - чем это грозит? mongodb 3.4.5

чатик, нид хелп. При восстановлении конфиг-сервера из бекапа есть такая коллекция config.version https://docs.mongodb.com/manual/reference/config-database/#config.version Обязательно ли ее заменять при восстановлении и если допустим не затирать - чем это грозит? mongodb 3.4.5

Почему возникла мысль её _не_ восставаливать?

Почему возникла мысль её _не_ восставаливать?

Failed: config.version: error dropping collection: cannot drop config.version document while in --configsvr mode =)

поэтому вопрос такой. По сути ее можно восстановить иначе, но все же интересно.

всплыло в 3.4

забыл, https://jira.mongodb.org/browse/SERVER-28796

00))0)

O:

Сегодня четверг

Опять ты пытаешься меня обмануть

Я лишь заложнек имени

Failed: config.version: error dropping collection: cannot drop config.version document while in --configsvr mode =)

Это где такое?

mongorestore с флагом --drop

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

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

Не знаю. Вероятно есть смысл дропнуть базу целиком.

да, как альтернатива

господа, почему в brew так долго обновляют монгу?

3.4.5 вышла 2 недели назад

ну обнови сам

https://github.com/Homebrew/homebrew-core/blob/master/Formula/mongodb.rb https://github.com/Homebrew/homebrew-core/blob/master/CONTRIBUTING.md

3.4.5 как-то через час работы умудрилась сегфолтнуться 2017-06-20T12:07:56.256+0000 F - [thread2] Invalid access at address: 0x782017-06-20T12:07:56.306+0000 F - [thread2] Got signal: 11 (Segmentation fault). 0x7fa59499fbe1 0x7fa59499edf9 0x7fa59499f466 0x7fa592084890 0x7fa5920804d3 0x7fa5952d259b 0x7fa5952d6905 0x7fa595327baa 0x7fa5953227f3 0x7fa595322b87 0x7fa595324533 0x7fa59538e406 0x7fa59207d064 0x7fa591db262d---— BEGIN BACKTRACE —---{"backtrace":[{"b":"7FA593435000","o":"156ABE1","s":"_ZN5mongo15printStackTraceERSo"},{"b":"7FA593435000","o":"1569DF9"},{"b":"7FA593435000","o":"156A466"},{"b":"7FA592075000","o":"F890"},{"b":"7FA592075000","o":"B4D3"},{"b":"7FA593435000","o":"1E9D59B"},{"b":"7FA593435000","o":"1EA1905","s":"__wt_split_multi"},{"b":"7FA593435000","o":"1EF2BAA","s":"__wt_evict"},{"b":"7FA593435000","o":"1EED7F3"},{"b":"7FA593435000","o":"1EEDB87"},{"b":"7FA593435000","o":"1EEF533","s":"__wt_evict_thread_run"},{"b":"7FA593435000","o":"1F59406","s":"__wt_thread_run"},{"b":"7FA592075000","o":"8064"},{"b":"7FA591CCA000","o":"E862D","s":"clone"}],"processInfo" "mongodbVersion" : "3.4.5", "gitVersion" : "520b8f3092c48d934f0cd78ab5f40fe594f96863", "compiledModules" : [], "uname" : { "sysname" : "Linux", "release" : "3.16.0-4-amd64", "version" : "#1 SMP Debian 3.16.39-1 (2016-12-30)", "machine" : "x86_64" }, "somap" : [ { "b" : "7FA593435000", "elfType" : 3, "buildId" : "56B113C6F98A9A037CA6006A2E9C21BF89D61421" }, { "b" : "7FFC1D92C000", "path" : "linux-vdso.so.1", "elfType" : 3, "buildId" : "856A20F5A861E2D4F656A3D865B4D6158E2D607F" }, { "b" : "7FA592FB1000", "path" : "/usr/lib/x86_64-linux-gnu/libssl.so.1.0.0", "elfType" : 3, "buildId" : "21115992A1F885E1ACE88AADA60F126AD9759D03" }, { "b" : "7FA592BB5000", "path" : "/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0", "elfType" : 3, "buildId" : "32E9A5B9EED626E93DEEB00A49033F78652DB9A после этого не падала, но отношусь к ней настороженно

кстати уже пуллреквест есть https://github.com/Homebrew/homebrew-core/pull/15112

Как сделать lookup масива который в масиве?

setIsSubset может?

Всем привет, подскажите, как правильно настроить индекс для полнтекстового поиска. Для модели вида: { ru: {title: 'Электроника'}, en: {title: 'Electronics'}, icon_id: "electronics" }

Полнотекстовый поиск только с помощью regex можно сделать, насколько я понял. Но он очень не эффективно работает, кроме случая, когда постфиксное выражение ищется. Я сделал массив дополнительный для каждого документа, куда спличу по пробелу слова из нескольких свойств документа. На него сделал индекс. И по нему ищу.

Всем привет, подскажите, как правильно настроить индекс для полнтекстового поиска. Для модели вида: { ru: {title: 'Электроника'}, en: {title: 'Electronics'}, icon_id: "electronics" }

https://docs.mongodb.com/manual/core/index-text/

Проблема в том, что индекс нужен для двух языков

Проблема в том, что индекс нужен для двух языков

Проблема в том, что надо внимательно читать ссылки. https://docs.mongodb.com/manual/tutorial/specify-language-for-text-index/#create-a-text-index-for-a-collection-in-multiple-languages

Я внимательно читал ссылки, но схемы очень разные

Да, тебе надо поменять схему. А ты чего ещё ожидал?

С текстовым индексом "полнотекстовый" поиск не выйдет же.

Полнотекстовый поиск != полнотекстовый индекс.

Если нужно искать по всему документу то это text и $**

Если нужен полнотекстовый индекс для конкретных атрибутов, то просто индекс. Но не размер поля ограничен 1024 байтами.

В любом случае схема <lang>.<field> не индексируется нормально.

Плюс это банально не эффективно (если вынести за скобки вопрос индексации, то я не понимаю почему не <field>.<lang>)

Банально как фильтровать по наличию поля?

Все языки в запросе указывать?

Проблема в том, что индекс нужен для двух языков

может лучше что-то типа ElasticSearch?