Nick
добавляете поле версия и причина изменения и каждый раз сохраняете с новой версией
Nick
при доступе берете самый новый
Nick
точнее с самой большой версией
Lev
Хм... хотел сказать про ветвление... но... тогда я не буду знать по какой ветке идти
Bohdan
а почему ивент сорсинг не вариант? например паттерн cqrs + хранение конкретных изменений в объекте ивента решает эту проблему
Bohdan
работал с такой архитектурой на стэке .net framework + ncqrs
Bohdan
прикольная штука
Lev
Ну, прям вот сейчас переходить на ивент сорсинг я точно не смогу.. времени нет
Lev
Да, штука прикольная
Lev
Тут получается ивентсорчинг в пределах одного документа. И с полной копией на каждом шагу
Bohdan
а, ну тогда понятно, там не на пять минут работы конечно
S
Парни не могли бы направить меня насчет этой задачи? Не понимаю как сделать неделю уникальной чтобы я мог вбивать в бд коллекцию с этой неделей
Nick
Парни не могли бы направить меня насчет этой задачи? Не понимаю как сделать неделю уникальной чтобы я мог вбивать в бд коллекцию с этой неделей
самый простой - связка год-номернедели - удобно для агрегаций, просто сделать, нельзя нормальные выборки по датам делать по сложнее и позапутаннее - дата понедельника - удобно для угрегаций, сложнее контролировать, можно выбрать по датам с ренжами - время начала недели-время окончания недели - сложная агрегация, но удобство по временным выборкам полных недель между датами можно комбинировать в агрегации использовать группировку по номеру недели или первой дате недели
Bohdan
heeelp 🙏
посмотри как работает агрегация в монге
Dmitry
https://docs.mongodb.com/manual/core/map-reduce/ а этим решить можно?
Dmitry
может кто примером подсказать, пожалуйста
Nick
может кто примером подсказать, пожалуйста
Мап редьюс имеет смысл использовать только если у вас крайне сложная логика обработки данных, которую на аггрегациях не получится сделать. При этом мапредьюс однопоточен и имеет ещё ряд ограничений. Вообще не желательно его использовать
Fess
Всем привет! Коллеги, подскажите, монга 4-я упала после копировария БД из одной в другую, при попытке рестарта, спустя минуту пишет: 1983), o: { createIndexes: "users", v: 2, unique: true, key: { login: 1 }, name: "login_1", sparse: true } }, took 15215ms 2019-11-12T15:51:30.886+0300 I INDEX [repl writer worker 4] build index on: vs_prod.users properties: { v: 2, unique: true, key: { email: 1 }, name: "email_1", sparse: true, ns: "vs_prod.users" } 2019-11-12T15:51:30.886+0300 I INDEX [repl writer worker 4] building index using bulk method; build may temporarily use up to 7000 megabytes of RAM 2019-11-12T15:51:33.001+0300 I - [repl writer worker 4] Index Build: 2534900/18979557 13% 2019-11-12T15:51:36.001+0300 I - [repl writer worker 4] Index Build: 6356200/18979557 33% 2019-11-12T15:51:39.001+0300 I - [repl writer worker 4] Index Build: 9352000/18979557 49% 2019-11-12T15:51:42.001+0300 I - [repl writer worker 4] Index Build: 12072700/18979557 63% 2019-11-12T15:51:45.001+0300 I - [repl writer worker 4] Index Build: 14808300/18979557 78% 2019-11-12T15:51:48.001+0300 I - [repl writer worker 4] Index Build: 17662500/18979557 93%
Fess
что можно сделать, плиз
Fess
отключил в конфиге replica set, завелось
yopp
Скорее всего вам подойдёт паттерн «бакет». Экспериментально подберите размер бакета, который позволяет не выбирать лишнего. https://www.mongodb.com/blog/post/building-with-patterns-the-bucket-pattern https://www.mongodb.com/blog/post/paging-with-the-bucket-pattern--part-1 как пример
yopp
И если основные шарды на ssd, делать реплики на hdd - выстрел в ногу из-за лага или прокатит, зависит от нагрузки?
Почти всегда — выстрел в ногу. Если вы хотите реальной отказоустойчивости, а не видимости, то вам необходимо чтоб все участники реплики могли стать праймари в случае отказа. Если у вас будут неравномерные ресурсы, то выборы реплики с меньшими ресурсами чем у предыдущего праймари, может привести к отказу уже по ресурсам
Bohdan
Всем привет! Коллеги, подскажите, монга 4-я упала после копировария БД из одной в другую, при попытке рестарта, спустя минуту пишет: 1983), o: { createIndexes: "users", v: 2, unique: true, key: { login: 1 }, name: "login_1", sparse: true } }, took 15215ms 2019-11-12T15:51:30.886+0300 I INDEX [repl writer worker 4] build index on: vs_prod.users properties: { v: 2, unique: true, key: { email: 1 }, name: "email_1", sparse: true, ns: "vs_prod.users" } 2019-11-12T15:51:30.886+0300 I INDEX [repl writer worker 4] building index using bulk method; build may temporarily use up to 7000 megabytes of RAM 2019-11-12T15:51:33.001+0300 I - [repl writer worker 4] Index Build: 2534900/18979557 13% 2019-11-12T15:51:36.001+0300 I - [repl writer worker 4] Index Build: 6356200/18979557 33% 2019-11-12T15:51:39.001+0300 I - [repl writer worker 4] Index Build: 9352000/18979557 49% 2019-11-12T15:51:42.001+0300 I - [repl writer worker 4] Index Build: 12072700/18979557 63% 2019-11-12T15:51:45.001+0300 I - [repl writer worker 4] Index Build: 14808300/18979557 78% 2019-11-12T15:51:48.001+0300 I - [repl writer worker 4] Index Build: 17662500/18979557 93%
так а ошибка где? тут написано что она продолжает строить индексы и что весь твой билд может занять до 7гб оперативки
Bohdan
лучше глянь лог почему она упала, а не этот
Askhat
Ребят, всем привет. Вопрос. Я использую Mongo Atlas. Есть такой график connections. Это нормально, что у него 38 подключений и бывает под 50? Или софт как-то некорректно подключается, например забывает там соединение разрывать если сервер остановился?
yopp
Ребят, всем привет. Как такое фиксить? в Mongo Atlas появилось Disk I/O % utilization on Data Partition has gone above 90 on nvme1n1 <shard_url>
Искать какие запросы у вас привели к такой ситуации. Смотрите в slow queries
yopp
slow queries пустой
проверьте что профайлер включен
yopp
не помню как называется график теперь, там должно быть что-то про query selectivity, где показывают сколько документов возвращается на запрос
Askhat
проверьте что профайлер включен
Он включен. Сейчас начал скачивать логи на всех шардах чтобы глянуть проблему
yopp
но вообще посмотрите не увеличился ли у вас qps
yopp
если запросов стало больше, то вполне может так быть что вы упёрлись в лимит iops для вашего плана
Lev
Есть аудит в Enterprise версии
Мы санкционные, нам никто не продаст
Yaroslav
Почему это проблема?
ну както не очень чтобы сервер прогибался под таким
yopp
Скорее всего :)
yopp
Можем обсудить
Yaroslav
2к записей в секунду
Max
3 это не оправда, это минимально необходимо, так как реплики без голосующего кворума не работают. А 1 нода это нандёжно
недавно пришел на проект, на данный момент тут вообще router-config-shard на одном серваке в трех докер контейнерах. место кончается, разрабы запросили добавить шард. я начал раскуривать маны (до этого особо с монгой не работал) и понеслось) в итоге делаю 3 vpc для конфиг серверов, второй шард на dedicated с ssd (аналогично первому шарду) и возник овпрос с репликами. говорят за 1,5 года всего один раз падало, и это мол не страшно.
Askhat
но вообще посмотрите не увеличился ли у вас qps
Там был такой момент в логах, что primary сервер рестартнулся и после этого посыпались такого вида ошибки: Error receiving request from client: SSLHandshakeFailed: The server is configured to only allow SSL connections. Ending connection from <ip_address>:<port> (connection id: 6) Это было в 8:30 по UTC
Askhat
Ну и secondary уже начали отправлять Error in heartbeat ошибки
Askhat
Мой ли это косяк =/
Askhat
ip_address вашего приложения?
Это ip адрес скорее всего secondary серверов
yopp
У вас сервера в атласе сами?
Askhat
У вас сервера в атласе сами?
БД на атласе, Сервера на AWS EC2 Оба в одном регионе
Fess
Спасибо!
Askhat
У меня подозрение, что Disk I/O упёрся потому что рестартнулся primary бд Там был пик 138, а ограничение 100
Max
@dd_bb еще пара вопросов сейчас стоит версия 3.6 1. при добавлении нового шарда потребуется ли дополнительное место, доп чанки в процессе? там уже 95% занято( 2. можете на вскидку сказать, какие грабли вероятны при апгрейде 3.6 > 4.2 или дать линк на ман, если есть такой. и вообще, простым апгрейдом пакетов обойдется или нужно шаманить какие-то процедуры? сейчас разворачиваю тестовый кластер для проверки настроек и процедуры добавления шарда, апгрейда версии
yopp
?
Я seed партнёр
Askhat
yopp
Во-во. Как быть теперь то
Ну вы на графики посмотрите
yopp
Там есть размер кеша и read in/read out
yopp
Во-во. Как быть теперь то
Если появились ошибки в логах, напишите в поддержку
Lev
Я seed партнёр
Что за seed? Я просто не знаю
yopp
Что за seed? Я просто не знаю
Да не важно. Я в россии продаю лицензии :)
Max
Да не важно. Я в россии продаю лицензии :)
о! какой порядок цен на enterprise?
Max
5k$-10k$ per server это серьезно?)
yopp
@dd_bb еще пара вопросов сейчас стоит версия 3.6 1. при добавлении нового шарда потребуется ли дополнительное место, доп чанки в процессе? там уже 95% занято( 2. можете на вскидку сказать, какие грабли вероятны при апгрейде 3.6 > 4.2 или дать линк на ман, если есть такой. и вообще, простым апгрейдом пакетов обойдется или нужно шаманить какие-то процедуры? сейчас разворачиваю тестовый кластер для проверки настроек и процедуры добавления шарда, апгрейда версии
1) Нет, не должно понадобиться, если вы не уперлись в ограничения intial sharding size https://docs.mongodb.com/manual/reference/limits/#Sharding-Existing-Collection-Data-Size 2) Надо будет rolling upgrade делать через все поинт релизы: 3.6 -> 4.0.x -> 4.2.x Документация для каждой версии тут: https://docs.mongodb.com/v4.0/release-notes/4.0-upgrade-replica-set/ https://docs.mongodb.com/v4.0/release-notes/4.0-upgrade-sharded-cluster/ Рекомендую сначала обновить, а потом шардировать
yopp
5k$-10k$ per server это серьезно?)
Без скидки за объём 1,3 млн рублей в год за 1 сервер с данными. Второй вариант это лицензирования по RAM блоками по 128 гб, без ограничения по числу серверов. Цена за блок такая-же. Это с поддержкой и всем остальным. Если покупать у нас, то мы в лицензию включаем ещё нашу собственную поддержку на руском языке в дополнение к ангоязычной монговской. Ну и торговаться можно конечно :) Главное напишите мне
yopp
благодарю! насчет рекомендации - почему?
потому что банально меньше обновлять :)