Nick
оплог не бесконечен и в него пишутся события всего репликасета а не отдельно взятой коллекции
Lev
Да, я про это думал, но там лплог на 16 мегов, я не думаю что это... произойдет в моем случае. А это базу льется много инфы, но мелкой.
Nick
у вас уже ест ьпромышленная эксплуатация, чтобы поигратсья с оплогом пром сервака?
Lev
Вообще, именно на этой бд мне особо бекапирование не надо. И репликасет будет из одной ноды. Так что.. может и монга не нужна, не спорю. Может и другая бд (я не знаю какая)
Lev
у вас уже ест ьпромышленная эксплуатация, чтобы поигратсья с оплогом пром сервака?
Нет, это ... ну типа стартапа, только дядьки серьезные.
Nick
это уже интереснее, биржа небось?
Lev
Скада для управления районными электросетями сколько то там киловольт. Тут всякие нейросети для поиска аварий по фазорам, эмуляторы электросети. Скада находит где авария и персонально каждому говорит че надо сделать чтобы все починить максимально экономно. Она всех будет за ручку водить.
Lev
Мы до конца не уверены что это вообще возможно (там с математикой какая то засада). Так что... мои проблемы - это наименьшие проблемы)
Lev
А у меня один из головняков - это чтобы скада работала на планшетах в том числе. Интерфейс под каждое приложение пилить не охота, поэтому основа интерфейса одна и та же - что на диспетчера за компом, что на бригаду с планшетом в поле. Есть еще редактор электросети, но чет... очкуют мне его давать.
Lev
Я могу в случае чего оплог увеличить?
Nick
особых проблем тут нет, по вашему сценарию видится следующее:
все есть события, а значит нужно строить все на очередях
какаянить кафка для возможности проиграть сообщения с момента последнего события любым консумером
отдельные подсистемы отслеживающие свои типы событий
они же генерят свои события для пользователей в свои очереди
вам нужно только проработать виды событий и что за данные будут передаваться
Lev
Да... я уже думал про это. Но если я рестартану сервер интерйеса через несколько лет эксплуатации...
Lev
Это че мне года ивентов прогонять?
Lev
Да, я это построил на событиях, правда без кафки.
Nick
зачем? вот тут как раз вам и нужна будет бд
Nick
во первых зачем вам хранит ьвсе время?
Lev
все время?
Lev
я не понял
Nick
1. клиент подклчюается
2. вы создаете для него буфер, который накапливает сообщения пока вы передаете ему состояние
3. передаете ровно те данные, которые ему нужны. и озаботьтесь сразу критериями, за счет которых вы будете отфильтровыва лишнее
4. как только клиент получает все нужные данные перекидываете ему накопленный буфер
5. когда он дочитывает последенее сообщение из буфера цепляете его на общую рассылку событий
Lev
Мне ж надо начальные данные откуда то взять
Lev
За все это время, что вы описали, какая то часть данных может не обновиться
Nick
на 3 этапе
Lev
А... или это 3
Lev
Судя по всему, оплог можно читать сразу с прошлого
Nick
собственно поэтмоу на втором этапе нужно создать буфер
Nick
прошлое достатоочно конечно для оплога
Lev
Ну да... но в моем случае я уверен оплога хватит.
Lev
16 мегов - за глаза
Lev
Это вся база наверно... даже больше (я не уверен)
Lev
так что я пока думаю, что оплога хватит. И вся затея зиждется на утверждении что оплог с прошло некоторое время будет "портить" снапшот настоящего (что не смертельно в случае декларативного интерфейса) и потом, в будущем, снапшот будет соответствовать бд
Nick
вам так же нужно делать буфер, все тоже самое
Nick
только даныне нужно брат ьиз нормальной очереди, а не как у вас
Lev
Дык... а буфер то зачем? После инициализации я оплог запрошу за прошлое - вот и весь буфер
Nick
16мб это всеголишь 1000 событий по 1.5кб
Lev
Я могу оплог увеличить?
yopp
ужас
yopp
стоило пойти жопу покачать
yopp
а у вас уже кафка с буферами
Nick
)))
Lev
то он все придумал!
Nick
Ынтырпрайз со стартап отливом))))
yopp
ппц
Anonymous
Anybody a mongo expert? I want to know how to run a mongo shell method on the server alongside mongod https://docs.mongodb.com/manual/reference/method/
yopp
Anybody a mongo expert? I want to know how to run a mongo shell method on the server alongside mongod https://docs.mongodb.com/manual/reference/method/
Hey. We’ve got the english speaking group: @mongo_db
Anonymous
Hey. We’ve got the english speaking group: @mongo_db
I want russian. Best developers. English don't know shit
Sergey️
That's true 😏
Lev
Хорошо. Я понимаю что вы хотите мне сказать и понимаю, что в реальной бд это не фигня собачья. С другой стороны, в моем случае это inmemory хранилище очень просто и точно не имеет всего функционала монги.
Тогда вот такой вариант ():
1. Замеряю время
2. Читаю данные с бд.
3. Как закончил читать - я запускаю оплог с того времени, что замерял ранее.
Тогда, оплог между 1 и 2 может повторится после снапшота, но конечное состояние не побьет, потому что удалит и так удаленное, создаст и так созданное, изменит и так измененное. А т.к. на этом основан декларативный код - ничего не изменится. ну моргнет там окошко какое нить и все
@dd_bb И все же... вы не ответили, где именно не сработает такой вариант даже без транзакций.
yopp
я не уверен в том, что вы получите, если сделаете find без транзакции, когда в условие вашего запроса попадут изменения пока происходит find
Lev
@dd_bb Документы меняются строго целиком.
yopp
в монге иначе быть и не может
Lev
Я получу часть новых, часть старых
Lev
Так или иначе, любое изменение будет потом перезатерто оплогом
yopp
вы не можете получить неполное изменение, они всегда доступны становятся только целиком
yopp
и остаётся вопрос как узнать где был оплог в момент выполнения запроса
yopp
вероятно через clusterTime как-то
Lev
Дык, я засеку время ДО выполнения инициализации. На приложении
Lev
ну да, ту дырка со временами между базой и приложением... но это всего два компа, справиться можно
yopp
я не уверен что это даст корректные результаты
Nick
вот поэтому и буферы
Lev
Даже проще
yopp
буферы тут ничем не помогут
Lev
Я запускаю оплог, а потом делаю запрос
yopp
запустить можно рыбок в аквариуме
Lev
Нет, это не верно...
Надо сначала запрос, а потом оплог задним числом
Nick
а еще уточнение получается будет множество клиентов (веб морда) и им нужно разное всякое отсылать?
yopp
я же сказал — всё зависит от требуемых вам гарантий
yopp
я на этом пожалуй пойду поотжимаюсь и спать. купите подписку
yopp
и я срадостью с вами вникну в эту проблему
yopp
а так, это best effort чят
yopp
это к вопросу что вам кто-то не ответил
Yʉri 🇺🇦
Можно ли в поддокументах хранить большое количество данных? Или это не рационально и лучше создать новую коллекцию с привязкой по ключу
Ivan
Можно ли в поддокументах хранить большое количество данных? Или это не рационально и лучше создать новую коллекцию с привязкой по ключу
https://docs.mongodb.com/manual/reference/limits/
16MB на 1 документ
А что бы узнать как лучше хранить данные - почитайте MongoDB Data Modeling
Dmitriy
ребят, всем привет! подскажите, пожалуйста, в пользу чего смотреть, чтобы сделать выборку по полю type.$.name? в документах примерно такого вида:
{
"_id": ObjectId("5be2e04501d96d0006740dc0"),
"currency": "USD",
"type" : {
"5be2d0b4b0b30d0007383ce6" : {
"name" : "Bla-bla"
}
}
}
что-то с утра не могу сообразить сам
Viktor
https://docs.mongodb.com/manual/reference/operator/query/elemMatch/ работает только для массивов
Dmitriy
https://docs.mongodb.com/manual/reference/operator/query/elemMatch/ работает только для массивов
Да, про это знаю, но мне удобнее для дальнейшего использования в бизнес логике использовать именно объект
Viktor
Да, про это знаю, но мне удобнее для дальнейшего использования в бизнес логике использовать именно объект
тогда это не будет работать. При поиске в словаре нужно весь путь указывать типа`{ "type.123213213.name": "someValue"}`