Господа, есть какой-то хак из json-a класс сгенерить? Для вставки в код

Ну или инструкция как это ручками сделать

java*

Господа, есть какой-то хак из json-a класс сгенерить? Для вставки в код

http://www.jsonschema2pojo.org

http://www.jsonschema2pojo.org

Благодарю

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

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

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

Если документ самодостаточен, то почему бы и нет

?

Добрый день, можно ли сделать в монге upsert (по _id) сразу нескольких документов?

нескольких доков с одинаковым _id?

Добрый день, можно ли сделать в монге upsert (по _id) сразу нескольких документов?

https://docs.mongodb.com/v3.4/reference/method/db.collection.updateMany/ Но точки зрения атомарности в этом нет никакого смысла, тк эта операция будет не атомарной.

https://docs.mongodb.com/v3.4/reference/method/db.collection.updateMany/ Но точки зрения атомарности в этом нет никакого смысла, тк эта операция будет не атомарной.

атомарность не интересует, просто хочу пачкой слать документы в монгу

Опишу кейс подробней: хочу записывать документы пачками (запросы на вставку идут параллельно с разных аппликейшен нод) и среди этих разных пачек могут оказаться два документа с одинаковым _id, нужно просто оставить последний пришедший

Слать документы по одному получается дороже намного

тебе нужен bulkWrite

https://docs.mongodb.com/v3.4/reference/method/db.collection.bulkWrite/

просто делаешь всеоперации Update c включенны upsert

гляну, спасибо

В монге же в массивах порядок гарантирован?

Что элемент, который я добавлю, всегда будет последний до момента добавления следующего, например?

да

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

Трудный вопрос. Зависит от того как ты собираешься работать с этими данными

если хранить отдельно то встает беда с атомарностью и отсутсвием транзакций

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

придется писать projection'ы чтобы не нагружать систему в пустую

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

@dd_bb привет подскажи, вот тут я могу одну машину из реплика сет указать ? prometheus exporter # List of mongos instanes to connect mongos: - mongodb://user:password@localhost:27170 - mongodb://user:password@localhost:27171 - mongodb://user:password@localhost:27172

или все надо ?

Привет. Можешь и одну. Но если тебе нужно видеть инфу со всего кластера, то нужно все указать.

лучше все. При падении ноды, к которой идет коннект - драйвер не узнает что есть другие.

Это не про драйвер вопрос

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

Сейчас если в кластере кто-то упал, экспортер может перестать успевать собирать метрики

@dd_bb привет подскажи, вот тут я могу одну машину из реплика сет указать ? prometheus exporter # List of mongos instanes to connect mongos: - mongodb://user:password@localhost:27170 - mongodb://user:password@localhost:27171 - mongodb://user:password@localhost:27172

Только если у тебя не шард, то не в mongos а в mongod надо добавить

ага, так и сделал :)

Иначе коллекции не будут экспортироваться

?

Ребзя, подскажите. show dbs выдает мне базу 32 гб

я почистил коллекции

сделал repair

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

хотя когда вывожу стату коллекций - явно видно что они уменьшились

монгу ребутал, думал на fd

где что глянуть можно ?

индексы?

а как их размер можно глянуть ?

в stats ?

Можно прямо в каталоге глянуть

Где база лежит

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

Второе, но можно без коллекции связей.

а как связывать документы?

Достаточно будет у машины иметь ссылку на id организации

в приложении связывать

отдельными запросами выдёргивать?

Да, но это будет populate если у вас драйвер позволяет, фактически это отдельный запрос.

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

еще есть DBRef

ок, идею понял, спасибо

DBRef на практике ни где еще не встречал. Оно юзабельно?

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

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

как раз продумываю структуру

DBRef на практике ни где еще не встречал. Оно юзабельно?

Вполне, у нас юзается.

А по поводу «менять целиком», это не совсем так. Изменять значения атрибутов документов можно и без передачи в запросе всего документа. История с атомарностью это про изоляцию: несколько одновременно выполняющихся запросов, которые меняют одинаковые документы. Монга гарантирует что изменения будут атомарными а рамках одного документа, а не всех документов попадающих под запросы.

Я с DbRef я только познакомился в скопе MongoLime :D

Тогда как в реляционных базах изоляция обычно на уровне всех сущностей попадающих в запрос по принципу «все или ничего». Т.е. если какое-то обновление завершилось ошибкой, изменения в других сущностях не будут применены. И как следствие другие запросы будут видеть только конечный результат выполнения соседнего запроса для всех сущностей (или вообще не видеть результата, если запрос ещё выполняется), а не промежуточный результат когда только часть сущностей обновилась. В монге соседний запрос будет видеть как множество документы обновляются по одному, но при этом гарантированно будет видеть «цельное» представление конкретного документа. Т.е. неполностью обновлённый документ никто не увидит. Эт конечно капитанство, но некоторые историю про атомарность очень странно интерпретируют.

это хорошее капитанство

Вполне, у нас юзается.

А зачем? Оверхед же огромный

Плюс реализация целиком на совести драйвера.