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

это фича драйвера. все вопросы к драйверу

в монге нет схем, напоминаю

я перестал понимать что они нахуевертили с авторизацией.

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

я тут поиграю в jonanc и скажу: ¯\_(ツ)_/¯, обращайтесь к авторам ;)

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

но вообще я бы забил совершенно. разница там будет в пределах мс

я знаю очень мало кейсов где это может играть хоть какую-то роль

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

не знаю как там в ноде это принято, но в рубях я бы просто сделал один метод типа def current_<name>_time; @current_<name>_time ||= Date.now.utc;end;

и из замыкания бы его дёргал

в жс любая ф-ция это замыкание

ты не понял идеи

думаю что на протипной поеботе это вообще решается как-то элементарно типа object['foobar'] ||= Date.now

но идея в том, чтоб сделать у объекта метод/переменную, которая устанавливается один раз

lazily

хм, писал телегу, пока писал въехал

да

с ejdb кстати кто-нибудь работал? nw.js просто предлагает его как вариант для локал стораджа

но надо будет ебаться со сборкой под платформы

интересно просто стоит ли оно того или можно взять какой-нибудь PouchDB который будет как бы на 'фронте'

вообще если кто знает какие удобные NoSQL обертки для фронта, буду рад услышать

не очень понятно какую проблему ты пытаешься решить

Просто проект состоит из вебморды и nw.js обертки с оффлайн фичами. Веб это mean stack, а проблема стоит в выборе хранилища для nw.js которое ему нужно для оффлайн работы. Удобно было бы что-то на подобии монги

ребят всем привет

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

db.currentOp()

"desc" : "rsSync", "threadId" : "140500350007040", "active" : true, "opid" : 7, "secs_running" : -1404615, "microsecs_running" : NumberLong("11480286677028"), "op" : "none", "ns" : "local.oplog.rs",

"secs_running" : -1404615

это жопэ получается?

это реплика сет и это примари

это жопэ получается?

вполне мог overflow у счётчика случится %)

на самом деле посмотри в rs.status()

если нет лага, то всё норм

монга какой версии?

просто у меня мониторинг постоянно жалуется что на серваке цпу ядрышки жрутся. там только эта монга примари. вот и птыаюсь понять мониторинг пздит или монга реал грузит. монга 3.2.4

вроде статус впорядке

примари секондари арбитр

просто у меня мониторинг постоянно жалуется что на серваке цпу ядрышки жрутся. там только эта монга примари. вот и птыаюсь понять мониторинг пздит или монга реал грузит. монга 3.2.4

top / htop?

ну монго жрет канеш. но у меня 4 ядра, Load_avg 1m < 1.5

считаю норм для 4 ядер

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

а вообще надо на iowait смотреть. и на io в целом

ну у меня в том то и дело что графит видит как будето по одному ядру загружается переодически типа [BEACON] CRITICAL <CPU LOAD IS TOO HIGH> server_prod.cpu-0.cpu-user failed. Current value: 95.3% [BEACON] CRITICAL <CPU LOAD IS TOO HIGH> server_prod.cpu-2.cpu-user failed. Current value: 93.7%

io да печален

ну если io печален, значит пришло время изучить что тупит

скорее всего индексов нет, а если есть — они неэффективные или в память не влазят

Могу посмотреть (не раньше следующей недели). 120€/hr, контракт, все дела.

))) понял спасибо

)

можешь сам попробовать разобраться. https://github.com/y8/mongo_collection_exporter

прикрутить к прометею и смотреть на коллекции

а у меня не sharded

оно будет работать?

да

просто реплики в shards воткни и всё

я арбитрами не пробовал, может что-то сломаться

если сломается — заведи ишшуй

))) окай

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

Latest: 3.4.4 (Apr 21, 2017), Stable: 3.2.12 (Feb 1, 2017) 3.4.4: https://docs.mongodb.com/manual/release-notes/3.4/#apr-21-2017 3.2.12: https://docs.mongodb.com/manual/release-notes/3.2/#feb-1-2017 Пришло время обновлятся до 3.4.1+: https://aphyr.com/posts/338-jepsen-mongodb-3-4-0-rc3

С выходом новой версии монги, как лучше поступать Прикрепить новое сообщение и отправить уведомление – 9 👍👍👍👍👍👍👍 53% Прикрепить новое сообщение и не отправлять уведомление – 8 👍👍👍👍👍👍 47% 👥 17 people voted so far.

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

да

к примеру, есть в базе id клиента, который что-то добавляет в базу, есть date, есть _id Правильно ли я понимаю, что в случае client_id чанки будут создаваться на том шарде, где находится этот чанк с совпадающим ID, а если по полю возрастающей date, то всегда на одном?

чанки не «создаются»

они делятся

у тебя есть первый чанк {MinKey, MaxKey}

он будет на primary shard

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

после чего балансер будет их растаскивать по другим шардам

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

что не имеет никакого смысла в среднем

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

и будешь ты сидеть с этим jumbo chunk, который никуда не может дется.

ок, то есть, в случае, условного client_id поделился чанк, уехал на другой шард. Запись следом за ним переместится? туда где есть данные с нужным client_id?

блин, надо уже написать статью про то как шардинг устроен

никто не понимает как это работает!

чанк это просто диапазон твоего shard key. это само по себе не является данными!