Alexey
так место не резиновое...не очень понятно сколько реально данных и когда оно опять начнет расти
yopp
Очень даже понятно
yopp
Монга вам в статистике коллекций всё показывает, включая свободное место внутри выделенного под wt хранилища
yopp
Если у вас нет задачи снять лишние диски, то вам ничего не надо делать.
Alexey
угу. ясно. Но если в теории, то ресинк реплики зальет данных именно столько сколько есть?
yopp
yopp
Но я считаю это пустой тратой времени и денег
yopp
У вас есть в collStats все необходимое, включая свободное место в хранилище (см block-manager / file bytes available for reuse)
Alexey
ок. понятно. А вот добавил я, скажем, новый шард. Туда отбалансировались коллекции, все поровну. Места значительно меньше чем, на старых. Я так понимаю, это и есть примерно реальное количество данных?
yopp
Не понимаю вопроса
yopp
Что значит «реальное количество данных»?
yopp
Есть сами документы. Есть их размер в несжатом виде и в сжатом виде. Есть индексы и их размер. Есть размер файла в котором хранятся индексы и документы
Alexey
ну есть два шарда. скажем, каждый по 2,5 тб. добавляется третий, начинается балансировка. Закончилась балансировка. чанки все поровну на третьем оказалось 1,5 тб. Хотя колво чанков одинаковое. Т. е. эти 1,5 тб - это и есть место равное объем - available for reuse ?
yopp
И ещё раз спрошу: какой из размеров вы сейчас указываете?
Alexey
размер файла
Alexey
на фс
yopp
Это плохой способ мерять размер данных
yopp
У вас внутри монги уже есть инструменты же
yopp
https://docs.mongodb.com/manual/reference/method/db.collection.getShardDistribution/
yopp
Вот например
yopp
Более того, чанки обычно разных размеров и равномерное распределение по числу чанков не гарантирует равномерного распределения по размеру
Alexey
кароче, если заресинкать все реплики на всех шардах, то свободного места на станет примерно столько, сколько на самых свежих шардах. И да..данные не удаляются, только растут.
yopp
Наверное вам нужно лучше сформулировать проблему, потому что я совсем не понимаю в чём она
yopp
Размер файлов вас не должен вообще беспокоить, кроме тревоги по недостаточному месту на блочном хранилище.
yopp
Монга сама неплохо справляется с управлением местом. Если вы ничего кроме монги не эксплуатируете на этом железе, то забудьте вообще про эту метрику.
yopp
Если там ещё что-то кроме монги, но это надо унести с этой железки
yopp
Остальное вам нужно смотреть внутри монги
Alexey
ну проблема состоит в том, что я не вижу прогноза когда пора добавлять новый шард. т. е. я не очень понимаю когда опять файлы начнут расти, а место на фс умньшаться. Я понял, что можно ходить в stat коллекции и считать вручную, не самый быстрый и очевидный путь, как мне кажется, особенно если автоматизировать это в мониторинге
yopp
Считать из stats самый правильный и очевидный путь
Alexey
я понял. спасибо.
еще вопрос при операции delete место wt обратно тоже не возвращает?
yopp
Не думаю что wt вообще возвращает место.
Alexey
ясно. понятно, спасибо
yopp
Какой в этом смысл? Copy on write будет дальшеь использовтаь освобождённые страницы
yopp
Единственный резонный сценарий, когда вы удалили очень много данных из коллекции и их столько уже никогда не будет.
yopp
Возьмите https://github.com/db-ai/mongo_collection_exporter
Alexey
ну было бы удобно...удалил часть данных - сразу видно на фс места меньше стало, никуда ходить не надо, ни в какие статистики, json парсить там, вот это все...
yopp
Не вижу ничего удобного. Вы пытаетесь по размеру чёрного ящика сделать какие-то выводы о происходящем внутри.
yopp
Вам нужно observability внутри монги
yopp
Иначе у вас потечёт место, а вы даже не узнаете почему
yopp
Плюс в чём смысл отдать место, если оно практически сразу потребуется обратно
yopp
https://docs.mongodb.com/manual/faq/storage/#how-do-i-reclaim-disk-space-in-wiredtiger
Alexey
тогда мне не очень понятно формула, по которой считается доступное место...
available for reuse по каждой коллекции + что?
yopp
Wt при создании коллекции просит фс выделить ему файл с каким-то размером. Это файл делится на страницы.
Когда монга записывает данные, она использует пустую страницу и помечает её как занятую.
Когда монга обновляет данные, она использует пустую страницу для сохранения изменённой копии, помечает ее как занятую. Старая страница с оригинальными данными помечается как освобожденная когда все «сессии» в WT использующие эту страницу будут завершены.
Когда монга удаляет данные, она помечает страницу как свободную когда все «сессии» будут завершены.
Занятое место внутри файла равно сумме размеров занятых страниц. Свободное место внутри файла равно сумме размеров свободных страниц.
Когда в файле заканчиваются свободные страницы, WT просит фс увеличить размер файла.
yopp
Смотрите на хранилище как на heap with reference counting GC
Alexey
ага. Значит, при апдейте тоже самое происходит, что и при удалени. Записывается фактически новая страница...
yopp
Это и есть Copy on Write.
Alexey
ясно. спасибо. Значит, итого, реально свободное место равно семме пустых страниц во всех коллекциях + свободное место на ФС. Правильно я понимаю?
Alexey
точнее не сумме, а свободного места на этих страницах
yopp
Alexey
ок. пойду парсить джейсон
yopp
Но учитывайте что свободное место внутри коллекции может быть использовано только этой коллекцией. Если reusable например суммарно 50Гб, это не значит что любая коллекция сможет эти 50Гб использовать.
Alexey
ага. это понятно
A
[{'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 прокатит, но нет
Может кто подсказать(гуглил, ничего не нашел)
Yar
> Может кто подсказать(гуглил, ничего не нашел)
-_-
A
https://docs.mongodb.com/manual/reference/method/db.collection.updateMany/
но ведь это не совсем то
Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте
Видимо я неправильно пояснил задачу
Yar
> Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте
??
A
> Тут когда ты в коллекции хочешь у многих записей поменять какое-то поле, а не когда у тебя нв вход в бд идет массив объектов и на основании их айдишников нужно поставить опредленные поля у объектов уже находящихся в базе на основании поля которое находится в передаваемом объекте
??
Есть массив объектов, пример я кинул выше, которые я хочу обновить в базе, а точнее поле у свойства status.
Могу ли я за один раз(а не 20 и тд раз, если у меня 20 объектов) обновить нужные мне записи на основании id и status, которые я передаю в монгу
грубо говоря с одним объектом за раз это выглядит так
mongo.db.collection("emails").update({'accountId': data.accountId, 'symbol': data.symbol,'orders.id': data.id},{$set:{"orders.$.state": "true"}})
A
Но делать кучу запросов в базу в течении пары секунл- это юзлесс
Yar
Есть массив объектов, пример я кинул выше, которые я хочу обновить в базе, а точнее поле у свойства status.
Могу ли я за один раз(а не 20 и тд раз, если у меня 20 объектов) обновить нужные мне записи на основании id и status, которые я передаю в монгу
грубо говоря с одним объектом за раз это выглядит так
mongo.db.collection("emails").update({'accountId': data.accountId, 'symbol': data.symbol,'orders.id': data.id},{$set:{"orders.$.state": "true"}})
если нужно апдейтить на разные значения, то не встречал.
A
ну вот походу так нельзя и надо делать чутка по-другому
yopp
Но делать кучу запросов в базу в течении пары секунл- это юзлесс
Порекомендую ещё раз: не пытайтесь оптимизировать с самого начала.
yopp
Оптимизировать надо когда у вас уже есть настоящие бутылочные горлышки
Stepan
Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?
Yar
Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?
ибо будешь бесконечно оптимизировать
yopp
Но если с самого начала можно спланировать так, чтоб горлышок было поменьше, то почему нет?
Потому что ты никогда не угадаешь где оно будет.
yopp
Предварительная оптимизация — деньги на ветер
Timur
Это прям Цель Голдратт и теория ограничений)
yopp
Проектов которые можно эффективно оптимизировать с самого начала практически не существует. Выгоднее вложить силы в инструменты, которые позволят видеть бутылочные горлышки и быстро выкатывать изменения.
Anonymous
Подскажите, когда Mongos перегружаю , какие нибудь опасности?
Anonymous
а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?
yopp
а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?
Да, конечно. Но если вам это важно, клиенты должны использовать соотвествующий writeConcern https://docs.mongodb.com/manual/reference/write-concern/
yopp
а может быть такое что, что от клиента пришли данные, но монгос не успел их отдать шарде?
Вы отправляете монгосу сигнал на завершение, а клиент в это время положил в монгос insert, который монгос не успел передать в шард
Anonymous
да, именно. почитаю, спасибоЯ!
yopp
Сколько лет уже висит: https://jira.mongodb.org/browse/SERVER-4274
Anonymous
неужели так сложно
yopp
https://docs.mongodb.com/manual/reference/method/db.shutdownServer/
Пишут что clean and graceful но я бы проверил на тестовом стенде
Anonymous
Товарищи, посоветуйте как решить задачу. Я получаю по API кучу товаров из магазина. Записываю их как документы в коллекцию. Периодически я хочу обновлять этот список, получая данные с магазина. Как это лучше всего сделать?
Anonymous
(товары могут добавиться, удалиться, а так же может измениться информация о них)