mongo —eval ?

Где почитать про nosql атаки?

С наступющим! Как решить эту задачку? http://jsbin.com/kaputilapu/edit?js,console

const result = array.reduce((resObj, currEl) => { const { _id, subtitle, days = [] } = currEl; days.forEach(date => { if (!resObj[date]) resObj[date] = [] resObj[date].push({ _id, subtitle }); }); return resObj; }, {});

const result = array.reduce((resObj, currEl) => { const { _id, subtitle, days = [] } = currEl; days.forEach(date => { if (!resObj[date]) resObj[date] = [] resObj[date].push({ _id, subtitle }); }); return resObj; }, {});

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

Studio 3T => дорохо бохато

mongo compass?

поздно - studio 3t поставил успешно )

И как? Нра?

Привет! Я использую пакет питона pymongo. Есть функция поиска которая удолетворяет все в фильтре? Например у меня есть доки с параметром города. City может иметь различное значение. Найти например город можно вот так: collection.find({'city':'Chicago'}) Юзер выбирает искать по всем городам, тогда нужно будет вести типа: collection.find({'city':all}) Конечно я могу этот параметр и не включить в поиск, но мне надо чтобы он вернул все города

Привет Парни. Хотел спросить на счет репликации. Я хочу чтобы read операции осуществлялись в secondary. В монго есть для этого опция setReadPref. Вопрос в том, будут ли данные актуальные в secondary, если данные с primary в secondary синхронизируются ассинхронно?

Привет Парни. Хотел спросить на счет репликации. Я хочу чтобы read операции осуществлялись в secondary. В монго есть для этого опция setReadPref. Вопрос в том, будут ли данные актуальные в secondary, если данные с primary в secondary синхронизируются ассинхронно?

Можете подсказать смысл ошибки? The $changeStream stage is only supported on replica sets

Если это для масштабирования, то нужно использовать шардинг, а не пытаться нагрузить secondaries

Спорно и совершенно не рационально с точки зрения железа. Да и монговцы зачем-то casual consistency запилили в 3.6.

Если внимательно читать мои сообщения, можно увидеть фразу «оправдано в узком перечне кейсов». сделать кластер с надежным чтением с secondaries — дорого.

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

Я бы не был столько категоричен. Но все зависит от конкретного кейса и надо тестировать в конкретной ситуации. Если, например, 99% запросов - чтение, то профит будет достаточно серьёзный.

Анатолий правильно сказал. Этой штуке нужен oplog, а он ведётся только с включённой репликацией. Просто включи репликации и не добавляй других нод

Можно написать неудачных запросов, которые не будут использовать shard key и тогда хоть 10 шардов сделай - тоже никакого толку не будет.

Анатолий правильно сказал. Этой штуке нужен oplog, а он ведётся только с включённой репликацией. Просто включи репликации и не добавляй других нод

Но в 3.6 есть хорошие новости https://docs.mongodb.com/manual/core/read-isolation-consistency-recency/#causal-consistency

rs.init()

зарегался, но ничего не понял, тем более, у них нет rpm'a

Возьми за три бакса виртуалку на ovh

зарегался, но ничего не понял, тем более, у них нет rpm'a