yopp
Когда поправлюсь и перестану прокрастинировать, выкачу бинарную сборку, которую по прометеевским заветам надо будет на каждую ноду отдельно запускать.
yopp
Сейчас если в кластере кто-то упал, экспортер может перестать успевать собирать метрики
Oleg
yopp
@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 надо добавить
Oleg
ага, так и сделал :)
yopp
Иначе коллекции не будут экспортироваться
yopp
👍
Oleg
Ребзя, подскажите.
show dbs выдает мне базу 32 гб
Oleg
я почистил коллекции
Oleg
сделал repair
Oleg
место не уменьшилось практически
Oleg
хотя когда вывожу стату коллекций - явно видно что они уменьшились
Oleg
монгу ребутал, думал на fd
Oleg
где что глянуть можно ?
David
индексы?
Oleg
а как их размер можно глянуть ?
Oleg
в stats ?
David
Можно прямо в каталоге глянуть
David
Где база лежит
Chebyrash
Ruslan
привет всем, камрады, проясните идеологию, монго хранит документы и обесепечивает "транзакцию" в рамках одного документа, т.е. если его меняем, то целиком.
Как там хранить иерархические данные, например, машины определённой организации? Всю инфу писать в одном документе или делать коллекцию организаций, коллекцию машин и коллекцию связей?
Как этим правильно пользоваться?
Yury
Второе, но можно без коллекции связей.
Ruslan
а как связывать документы?
Yury
Достаточно будет у машины иметь ссылку на id организации
Aleksey
в приложении связывать
Ruslan
отдельными запросами выдёргивать?
Yury
Да, но это будет populate если у вас драйвер позволяет, фактически это отдельный запрос.
Ruslan
у меня много инфы с неопределёнными полями, поэтому смотрю на монго, на реляционке делать сложнее, но с монгой только начал разбираться
CC-BY-SA-4.0/Docker-ce30.0
еще есть DBRef
Ruslan
ок, идею понял, спасибо
Yury
DBRef на практике ни где еще не встречал. Оно юзабельно?
yopp
привет всем, камрады, проясните идеологию, монго хранит документы и обесепечивает "транзакцию" в рамках одного документа, т.е. если его меняем, то целиком.
Как там хранить иерархические данные, например, машины определённой организации? Всю инфу писать в одном документе или делать коллекцию организаций, коллекцию машин и коллекцию связей?
Как этим правильно пользоваться?
Надо хранить так, как ты будешь потом читать.
Если машины как сущность без организации не используются, то проще хранить в одном документе. Если машины отдельно от организаций отлично существуют, то вероятно проще хранить из в отдельной коллекции.
Ruslan
как раз продумываю структуру
CC-BY-SA-4.0/Docker-ce30.0
DBRef на практике ни где еще не встречал. Оно юзабельно?
Вполне, у нас юзается.
yopp
А по поводу «менять целиком», это не совсем так.
Изменять значения атрибутов документов можно и без передачи в запросе всего документа.
История с атомарностью это про изоляцию: несколько одновременно выполняющихся запросов, которые меняют одинаковые документы.
Монга гарантирует что изменения будут атомарными а рамках одного документа, а не всех документов попадающих под запросы.
Yury
Я с DbRef я только познакомился в скопе MongoLime :D
yopp
Тогда как в реляционных базах изоляция обычно на уровне всех сущностей попадающих в запрос по принципу «все или ничего». Т.е. если какое-то обновление завершилось ошибкой, изменения в других сущностях не будут применены. И как следствие другие запросы будут видеть только конечный результат выполнения соседнего запроса для всех сущностей (или вообще не видеть результата, если запрос ещё выполняется), а не промежуточный результат когда только часть сущностей обновилась.
В монге соседний запрос будет видеть как множество документы обновляются по одному, но при этом гарантированно будет видеть «цельное» представление конкретного документа. Т.е. неполностью обновлённый документ никто не увидит. Эт конечно капитанство, но некоторые историю про атомарность очень странно интерпретируют.
Aleksey
это хорошее капитанство
yopp
Плюс реализация целиком на совести драйвера.
yopp
Индексировать тяжелее
yopp
covered query уже не выйдет как минимум
yopp
Ребзя, подскажите.
show dbs выдает мне базу 32 гб
Я не уверен что оно должно показывать физический размер бд. Там же вроде сумма collection size
yopp
Который размер до компрессии
David
у меня много инфы с неопределёнными полями, поэтому смотрю на монго, на реляционке делать сложнее, но с монгой только начал разбираться
Если есть критичные для целостоности данные, то лучше использовать реляционную ДБ. В postgres давно уже можно хранить json для документов с неопределенными полями. По этим данным можно писать запросы
yopp
yopp
Мы тут не про пг, а про монгу. Про пг есть тематические каналы, на которых это оценят.
Ruslan
да я понимаю, общался с одним админом, в телецвае он работал, он зуб давал, что если делать всё правильно, кластер монги не убить, говорил, что однажды потеряли сторадж и работали только на памяти, пока заметили
CC-BY-SA-4.0/Docker-ce30.0
Сложный сервис для работы с тесно связанными сущностями и сложной иерархией моделей.
David
Последнее китайское
прошу прощения. вопрос значит не в тему был. В таком случае стоит задавать вопросы о пригодности монги для тех или иных нужд
Ruslan
сделаю два варианта, посмотрим 🙂
CC-BY-SA-4.0/Docker-ce30.0
Чтото типа циндер у опенстека.
CC-BY-SA-4.0/Docker-ce30.0
И в этом сервисе монга не является боттлнеком
yopp
прошу прощения. вопрос значит не в тему был. В таком случае стоит задавать вопросы о пригодности монги для тех или иных нужд
В монге все нормально с целостностью. В монге нет транзакционности, но это нужно вообще далеко не всем. Есть множество подходов который работают с изоляцией на уровне одного документа.
yopp
David
yopp
Мы в своё время спокойно слепили биллинг, который работал и без транзакций. Обеспечили индемпотентность операций и всё.
yopp
Сломалось? Retry до успеха.
Aleksey
а вот человека который придумал у ключа --authenticationDatabase не должно быть короткого аналога я хотел бы сжечь .
yopp
:))))))
Aleksey
доктор это нормально ?
yopp
Добро пожаловать в клуб
Aleksey
мне бы хотя бы 10-15 молекул от этого доброго человека.
yopp
Мне вообще за реализацию аутентификации хочется нанести тяжкие телесные. X509 это вообще феерия
Alex
это дааа
yopp
Её писали какие на всю голову интерпрацзнутые люди. Но не xml конфигурация в два мегабайта и хорошо уже
David
Мы в своё время спокойно слепили биллинг, который работал и без транзакций. Обеспечили индемпотентность операций и всё.
Биллинг работал в кластере? и для всех критичных мест вели что-то вроде лога транзакции?
Ruslan
Мне вообще за реализацию аутентификации хочется нанести тяжкие телесные. X509 это вообще феерия
а какие варианты для двухсторонней аутентификации ещё есть?
Aleksey
а вот человека который придумал у ключа --authenticationDatabase не должно быть короткого аналога я хотел бы сжечь .
зато я теперь знаю как это слово пишется. раз гдето на 152 раз мне надоело делать —help и копипастить.
раз гдето на 210 я перестал делать ошибки.
yopp
Мы делали сервис подписок с хитрым распределением денег.
Подписка была ограничена 7 днями, внутри каждой подписки хранился массив «оплаченных» событий.
«Оплата» гарантировалась нужным write concern (комит в журнал). Даже если на одну сущность приходило несколько конкурентных транзакций, addToSet гарантировал уникальность.
Остальная математика, например выплаты, была построена на статических временных периодах (тоже 7 дней), как следствие тоже была индемпотентной. Можно любой отчёт о выплате генерировать сколько угодно раз, будет всегда одно и тоже.
yopp
а какие варианты для двухсторонней аутентификации ещё есть?
Внутри кластера — keyfile. Для клиентов — password.
yopp
509 просто того не стоит.
Ruslan
password ничего не гарантирует
yopp
509 тоже :)