Если вы выбираете по пользователю. Если просто ордера по тикеру то два отдельных индекса: id и symbol

И по возможности не используйте просто id как имя ключа

Укажите что это за id

Если вы выбираете по пользователю. Если просто ордера по тикеру то два отдельных индекса: id и symbol

в том и дело, что мне не нужно будет доставать только по тикеру) А всегда пользователь-тикер) Окей, с id понял, спасибо)

Всем привет. Заметил странность...При добавлении нового шарда и окончании баллансировки, на старых занятое место не уменьшается, а просто перестает расти. Так и должно быть?

Всем привет. Заметил странность...При добавлении нового шарда и окончании баллансировки, на старых занятое место не уменьшается, а просто перестает расти. Так и должно быть?

Да, емнип, wt не уменьшает размер файла хранилища

В смысле не отдаёт освободившееся место назад фс

Можно в stats посмотреть сколько свободного места осталось внутри файла

а чего делать-то? resync?

Зависит от желаемого результата

Новые данные будут использовать освободившееся место

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

Да. Но зачем?

так место не резиновое...не очень понятно сколько реально данных и когда оно опять начнет расти

Очень даже понятно

Монга вам в статистике коллекций всё показывает, включая свободное место внутри выделенного под wt хранилища

Если у вас нет задачи снять лишние диски, то вам ничего не надо делать.

угу. ясно. Но если в теории, то ресинк реплики зальет данных именно столько сколько есть?

угу. ясно. Но если в теории, то ресинк реплики зальет данных именно столько сколько есть?

Примерно, да.

Но я считаю это пустой тратой времени и денег

У вас есть в collStats все необходимое, включая свободное место в хранилище (см block-manager / file bytes available for reuse)

ок. понятно. А вот добавил я, скажем, новый шард. Туда отбалансировались коллекции, все поровну. Места значительно меньше чем, на старых. Я так понимаю, это и есть примерно реальное количество данных?

Не понимаю вопроса

Что значит «реальное количество данных»?

Есть сами документы. Есть их размер в несжатом виде и в сжатом виде. Есть индексы и их размер. Есть размер файла в котором хранятся индексы и документы

ну есть два шарда. скажем, каждый по 2,5 тб. добавляется третий, начинается балансировка. Закончилась балансировка. чанки все поровну на третьем оказалось 1,5 тб. Хотя колво чанков одинаковое. Т. е. эти 1,5 тб - это и есть место равное объем - available for reuse ?

И ещё раз спрошу: какой из размеров вы сейчас указываете?

размер файла

на фс

Это плохой способ мерять размер данных

У вас внутри монги уже есть инструменты же

https://docs.mongodb.com/manual/reference/method/db.collection.getShardDistribution/

Вот например

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

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

Наверное вам нужно лучше сформулировать проблему, потому что я совсем не понимаю в чём она

Размер файлов вас не должен вообще беспокоить, кроме тревоги по недостаточному месту на блочном хранилище.

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

Если там ещё что-то кроме монги, но это надо унести с этой железки

Остальное вам нужно смотреть внутри монги

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

Считать из stats самый правильный и очевидный путь

я понял. спасибо. еще вопрос при операции delete место wt обратно тоже не возвращает?

Не думаю что wt вообще возвращает место.

ясно. понятно, спасибо

Какой в этом смысл? Copy on write будет дальшеь использовтаь освобождённые страницы

Единственный резонный сценарий, когда вы удалили очень много данных из коллекции и их столько уже никогда не будет.

Возьмите https://github.com/db-ai/mongo_collection_exporter

ну было бы удобно...удалил часть данных - сразу видно на фс места меньше стало, никуда ходить не надо, ни в какие статистики, json парсить там, вот это все...

Не вижу ничего удобного. Вы пытаетесь по размеру чёрного ящика сделать какие-то выводы о происходящем внутри.

Вам нужно observability внутри монги

Иначе у вас потечёт место, а вы даже не узнаете почему

Плюс в чём смысл отдать место, если оно практически сразу потребуется обратно

https://docs.mongodb.com/manual/faq/storage/#how-do-i-reclaim-disk-space-in-wiredtiger

тогда мне не очень понятно формула, по которой считается доступное место... available for reuse по каждой коллекции + что?

Wt при создании коллекции просит фс выделить ему файл с каким-то размером. Это файл делится на страницы. Когда монга записывает данные, она использует пустую страницу и помечает её как занятую. Когда монга обновляет данные, она использует пустую страницу для сохранения изменённой копии, помечает ее как занятую. Старая страница с оригинальными данными помечается как освобожденная когда все «сессии» в WT использующие эту страницу будут завершены. Когда монга удаляет данные, она помечает страницу как свободную когда все «сессии» будут завершены. Занятое место внутри файла равно сумме размеров занятых страниц. Свободное место внутри файла равно сумме размеров свободных страниц. Когда в файле заканчиваются свободные страницы, WT просит фс увеличить размер файла.

Смотрите на хранилище как на heap with reference counting GC

ага. Значит, при апдейте тоже самое происходит, что и при удалени. Записывается фактически новая страница...

Это и есть Copy on Write.

ясно. спасибо. Значит, итого, реально свободное место равно семме пустых страниц во всех коллекциях + свободное место на ФС. Правильно я понимаю?

точнее не сумме, а свободного места на этих страницах

ясно. спасибо. Значит, итого, реально свободное место равно семме пустых страниц во всех коллекциях + свободное место на ФС. Правильно я понимаю?

Примерно, да

ок. пойду парсить джейсон

Но учитывайте что свободное место внутри коллекции может быть использовано только этой коллекцией. Если reusable например суммарно 50Гб, это не значит что любая коллекция сможет эти 50Гб использовать.

ага. это понятно

[{'accountId':'12345@var', 'symbol':'ABC', 'id':'hoba3', 'status': '123123' }, {'accountId':'12345@var', 'symbol':'AAPL', 'id':'hoba5', 'status': 'mixed' }, {'accountId':'12322245@var', 'symbol':'ABC', 'id':'hoba1', 'status': 'executed' }, {'accountId':'12345@var', 'symbol':'ABC', 'id':'hoba3', 'status': 'afwfesfsefsef' }, {'accountId':'12322245@var', 'symbol':'AAPL', 'id':'hoba2', 'status': 'kisooda' }, {'accountId':'12322245@var', 'symbol':'AAPL', 'id':'hoba4', 'status': 'car' }] Допустим у меня есть массив объектов, я ведь могу одним апдейтом монги их все обновить? Думал, что через $in прокатит, но нет Может кто подсказать(гуглил, ничего не нашел)

[{'accountId':'12345@var', 'symbol':'ABC', 'id':'hoba3', 'status': '123123' }, {'accountId':'12345@var', 'symbol':'AAPL', 'id':'hoba5', 'status': 'mixed' }, {'accountId':'12322245@var', 'symbol':'ABC', 'id':'hoba1', 'status': 'executed' }, {'accountId':'12345@var', 'symbol':'ABC', 'id':'hoba3', 'status': 'afwfesfsefsef' }, {'accountId':'12322245@var', 'symbol':'AAPL', 'id':'hoba2', 'status': 'kisooda' }, {'accountId':'12322245@var', 'symbol':'AAPL', 'id':'hoba4', 'status': 'car' }] Допустим у меня есть массив объектов, я ведь могу одним апдейтом монги их все обновить? Думал, что через $in прокатит, но нет Может кто подсказать(гуглил, ничего не нашел)

https://docs.mongodb.com/manual/reference/method/db.collection.updateMany/

> Может кто подсказать(гуглил, ничего не нашел) -_-

https://docs.mongodb.com/manual/reference/method/db.collection.updateMany/

но ведь это не совсем то Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте Видимо я неправильно пояснил задачу

> Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте ??

> Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте ??

Есть массив объектов, пример я кинул выше, которые я хочу обновить в базе, а точнее поле у свойства status. Могу ли я за один раз(а не 20 и тд раз, если у меня 20 объектов) обновить нужные мне записи на основании id и status, которые я передаю в монгу грубо говоря с одним объектом за раз это выглядит так mongo.db.collection("emails").update({'accountId': data.accountId, 'symbol': data.symbol,'orders.id': data.id},{$set:{"orders.$.state": "true"}})

Но делать кучу запросов в базу в течении пары секунл- это юзлесс

Есть массив объектов, пример я кинул выше, которые я хочу обновить в базе, а точнее поле у свойства status. Могу ли я за один раз(а не 20 и тд раз, если у меня 20 объектов) обновить нужные мне записи на основании id и status, которые я передаю в монгу грубо говоря с одним объектом за раз это выглядит так mongo.db.collection("emails").update({'accountId': data.accountId, 'symbol': data.symbol,'orders.id': data.id},{$set:{"orders.$.state": "true"}})

если нужно апдейтить на разные значения, то не встречал.

ну вот походу так нельзя и надо делать чутка по-другому

Но делать кучу запросов в базу в течении пары секунл- это юзлесс

Порекомендую ещё раз: не пытайтесь оптимизировать с самого начала.

Оптимизировать надо когда у вас уже есть настоящие бутылочные горлышки

Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?

Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?

ибо будешь бесконечно оптимизировать

Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?

Потому что ты никогда не угадаешь где оно будет.

Предварительная оптимизация — деньги на ветер

Это прям Цель Голдратт и теория ограничений)

Проектов которые можно эффективно оптимизировать с самого начала практически не существует. Выгоднее вложить силы в инструменты, которые позволят видеть бутылочные горлышки и быстро выкатывать изменения.

Подскажите, когда Mongos перегружаю , какие нибудь опасности?

Подскажите, когда Mongos перегружаю , какие нибудь опасности?

Подключённые клиенты отвалятся

а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?

а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?

Да, конечно. Но если вам это важно, клиенты должны использовать соотвествующий writeConcern https://docs.mongodb.com/manual/reference/write-concern/

а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?

Вы отправляете монгосу сигнал на завершение, а клиент в это время положил в монгос insert, который монгос не успел передать в шард

да, именно. почитаю, спасибоЯ!

Сколько лет уже висит: https://jira.mongodb.org/browse/SERVER-4274

неужели так сложно

https://docs.mongodb.com/manual/reference/method/db.shutdownServer/ Пишут что clean and graceful но я бы проверил на тестовом стенде

Товарищи, посоветуйте как решить задачу. Я получаю по API кучу товаров из магазина. Записываю их как документы в коллекцию. Периодически я хочу обновлять этот список, получая данные с магазина. Как это лучше всего сделать?

(товары могут добавиться, удалиться, а так же может измениться информация о них)

Джоб сделайте, который будет периодически обновлять

В том то и вопрос - как сопоставить ту коллекцию, что у нас в базе с той инфой, что у нас пришла.

Это задача синхронизации данных. Тут нет каких-то универсальных рецептов

?

Вы можете делать или полную замену или вычислять дельты