Нужно понимать какую роль выполняют бекапы, что нужно бекапить очень часто, что можно бекапить реже, что вообще не надо бекапить.

Резервное копирование ОЧЕНЬ дорогое удовольствие.

Ну вот допустим ежесуточно 500 гигов

Сколько хранится бекап?

тогда db.tst.createIndex({ v1: "text", v2: "text" }); // db.tst.insertMany([{ "v1" : "word", "v2" : "тест" },{ "v1" : "word", "v2" : "тест2" },{ "v1" : "word2", "v2" : "тест" },{ "v1" : "тест", "v2" : "word" }]); и дальше по русскому слову db.getCollection('tst').find({ $text:{$search:"тест"} }) по англицкому db.getCollection('tst').find({ $text:{$search:"word"} }) два одновременно db.getCollection('tst').find({ $text:{$search:"\"тест2\" \"word\""} })

с таким объёмом mongodump справится при быстрых дисках?)

с таким объёмом mongodump справится при быстрых дисках?)

Нет

{ "v1" : "текст", "v2" : "word" }

выше

Сколько хранится бекап?

2 недели

а чем тогда большие объемы бэкапить?

с таким объёмом mongodump справится при быстрых дисках?)

И не в mongodump дело, а в том, что mongodump по сути просто делает find({}) на всех коллекциях. Для этого монге их надо так или иначе сложить в память

ах, вот оно что....

14 дней по 500 гигов это уже 7Тб

верно

А чем бэкапить тогда?)

С фактором репликации хотяб 3, это уже 21Тб

А чем бэкапить тогда?)

Я же говорю, вопрос стоит в корне не верно

ну где диски на это брать - проблема заказчика )

Нет, это не проблема заказчика, это проблема архитектора решения

Согласен

Не в дисках дело, а в надёжности резервного копирования

В данном случае - архитектор решения захотел бэкапы )

Архитектору решения надо разобраться что такое «бекапы», я же говорю

Самый простой способ это сделать — через стоимость данных. Например через ущерб от их недоступности (в долларах в минуту) и полной потери

Не бывает так, что все 500 гигов убер критически важны

В большинстве случаев критически важных данных там от силы 10%

В данном случае в монге хранятся документы, и они важны.

а их будет в итоге очень много

А. Будет :)

А сколько есть?

И когда будет?

пока в тестовой эксплуатации

можно сказать сейчас почти нет

а после запуска в течении года заказчик расчитывает на 500 гигов

надо составить три модели роста размера данных (оптимизм, пессемизм и реализм), после чего планировать решение исходя из этих цифр. Вкладывать денег в бекап 500 гигов, при наличии 5 расточительство :)

Потому что цена бекапа 5 гигов и 500 будет отличаться даже не на два порядка

Спасибо за ответы про mongodump.

У заказчика есть системы бэкапа в т.ч. на ленты

в общем насколько я понял, заказчика не волнует как эта служба будет по 500 гигов ежедневно бэкапить 2 недели )

и сколько это будет стоить

Не бывает так, чтоб не волновало сколько это будет стоить

Да я согласен, но этими вопросами не я занимаюсь

На деле у вас выбор не такой большой: 1) mongodump 2) бекап фс

я ещё прочитал в доке про снапшоты fs, lvm...

С п.2 у вас есть какой-то выбор ещё, например снепшоты

пойду детали про снапшоты почитаю...

спасибо

тогда db.tst.createIndex({ v1: "text", v2: "text" }); // db.tst.insertMany([{ "v1" : "word", "v2" : "тест" },{ "v1" : "word", "v2" : "тест2" },{ "v1" : "word2", "v2" : "тест" },{ "v1" : "тест", "v2" : "word" }]); и дальше по русскому слову db.getCollection('tst').find({ $text:{$search:"тест"} }) по англицкому db.getCollection('tst').find({ $text:{$search:"word"} }) два одновременно db.getCollection('tst').find({ $text:{$search:"\"тест2\" \"word\""} })

Супер! Спасибо большое!

то, что нужно

Здравствуйте. Трабла такая. $bulk->update( ['_id' => 2], ['$set' => ['accountBag.CashInventory.items.1' => ['count'=>'213']]], ['multi' => false, 'upsert' => false] ); Запрос на изменение параметра count, а вместо этого удаляется всё что есть в массиве items и вставляется count 213.

а нужно обновить значение у элемента с индексом 1?

['accountBag.CashInventory.items.1.count' => '213']

чтото такое попробуйте

https://docs.mongodb.com/ доступен сейчас у кого ?

https://docs.mongodb.com/ доступен сейчас у кого ?

д@

хм

Здравствуйте, есть ли способ вылечить вот это ==== "errmsg" : "exception: no NamespaceDetails for index: { v: 1, key: { _id: 1 }, name: \"_id_\", ns: \"viewsStatistics. statistics_reduced_1\" }", "code" : 17329, === ? кроме как бэкапа того, что можно забэкапить и восстановления версия 2.6.12

['accountBag.CashInventory.items.1.count' => '213']

путь)

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

у вас items не массив

значит нужно просто указать путь

у вас items не массив

Тогда как правильно будет указать, массив в объект переводить ?

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

приведите в изначальный вид

Получается так, вроде сработало, не удалило ничго. ['$set' => ['accountBag.CashInventory.items.1.count' => '213']],

очень трудно после SQL под монго сделать скрипт, всё кажется таким нелогичным)))

в любом случае спасибо за помощь, вроде получилось)

может тогда отказатсья от монго?

я бы с радостью, но там целый сервер под монго, мне только веб чатсь надо сделать)

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

интересно это нормальное поведение или нет, никто не вкурсе?

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

так пробую, вродне всё равно объектом он и остается быть. ['$set' => ['accountBag.CashInventory'=> array('items'=> ['1'=> ['count'=>123]])]],

Как сделать массивом?

Не знаю синтаксиса, так что не поскажу, читайте доки к вашему драйверу

Это же PHP, его все знают, по крайней мере мне так казалось)

Если жизнь заставит, то да, но добровольно лезть в нем разбираться эт без меня

А подскажите ещё такой момент, ищу информацию, но однозначно не могу найти. Если создать комплексный текстовый индекс, влияет ли в нем очерёдность полей?

не влияет

А подскажите ещё такой момент, ищу информацию, но однозначно не могу найти. Если создать комплексный текстовый индекс, влияет ли в нем очерёдность полей?

Это же индекс

но он один на коллекцию может быть

я так понимаю, там немного свой алгоритм

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

видите, вам не подходит монга под ваши задачи

по крайней мере с текущей структурой документов

видите, вам не подходит монга под ваши задачи

+

ну это на самом деле подзадачи большой задачи, там много чего, для чего монго очень подходит сама по себе. вопрос в том, что только поиск по документам для конкретного варианта подзадачи может быть не таким молниеносным, как хотелось бы. Но в целом не должно быть коллецкий больше 3 500 000 документов, а по ним более или менее адекватно даже без индекса искать. Всегда хочеться оптимизировать и ускорить, но бывают такие затыкания. Если вязть за место монги другой движок, то в других местах может больше проблем появиться в целом в проекте

Вам точно не к монге, имхо

А что например?

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

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

Постгрес умеет в докумен

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

не поймите не правильно, я очень люблю постгрес и это великолепная база. Но разные задачи, разные инструменты. Хорошо бы найти серебренную пулю на все и сразу, но пока такой нет(