но часто никто не может оценить ущерб от простоя

особенно в госконторе

или вообще от потери данных, если вдруг помимо реплики ещё и на бекапах решили сэкономить

аххаахах

радует одно за эти данные не расстреляют никого)

не факт)

за те что у меня похерились не расстреляют

за те что у меня похерились не расстреляют

попробуй подмену файла

и потом repairDatabase

имя коллекции не важно? или нужно то же указывать

думаю что нет, не важно

попробуй на маленькой коллекции сначала

ок, спасибо. Попробую

и на бекапе файла, не оригинале :)

в WiredTiger.wt вроде как метаданные и хранятся

тоесть надо взять исходную колекцию и индекс и переименовать . я правильно понял?

угу

затем подменить

берёшь из .stats() новой коллекции WiredTiger.uri

там будет имя базы

и имя коллекции на диске

это я и называю базой. хранилище физическое

а понял

и тоже самое с индексом по _id

делать с выключенной монгой, стартанут, посмотреть в коллекцию. если данные не появились сделать repairDatabase

если и потом не появятся, то ты можешь попробовать тот-же метод что и с WiredTiger.wt

той читалкой попробовать поковырять таблицу

я думаю что обойти таблицу и достать bson блобы не очень сложно будет

хм, ну да)

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

а вот если они сами страницами управляют, тогда может быть сложно

https://emptysqua.re/blog/driver-features-for-mongodb-3-6/

Now it’s time for dessert! MongoDB 3.6 will have a new event notification API.

cursor = client.my_db.my_collection.changes([ {'$match': { 'operationType': {'$in': ['insert', 'replace']} }}, {'$match': { 'newDocument.n': {'$gte': 1} }} ]) # Loops forever. for change in cursor: print(change['newDocument'])

ого

вот это очень круто

интересно, как оно с concurrency работает.

(97% что никак, скорее всего это обёртка над оплогом)

там отличный документ всплывает: https://emptysqua.re/blog/how-to-write-resilient-mongodb-applications/ хороший пример как мыслить за пределами тразакций

indempotent queries это один из самых слабообсуждаемых моментов, потому что если у тебя или сами данные индемпотентны или ты изначально проектируешь запросы особым образом — в 99% случаев можно обойтись без транзакций, сохранив огромную пропускную способность

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

мы делали платную подписку на контент, по модели fair share, когда фиксированная подписка распределяется между всеми авторами, чей контент ты потреблял, пропорционально количеству потреблённого контента. мы специально сделали биллиг цикл в 7 дней (бизнес-процесс позволял и так даже удобнее было) и продавали подписку по несколько недель (от 4 и выше) на каждую покупу внутри системы выставлялся заказ. внутри заказа поддокументами хранилась история действий (это была стейтмашина по сути, хранились переходы). на заказ создавалась оплата (тоже стейт машина с поддокументами), которая асинхронного могла менять свои состояния по триггерам из гейта и по необходимости меняла состояние заказа. когда оплата переходила в состояние «оплачена», она дергала заказ, который в свою очередь тупо генерировал ещё X записей в коллекции с неделями. а уже активация недель была делом техники, потому что они всегда активируются в одном порядке, так что два конкурентных запроса всегда схватят одну и ту-же неделю это отлично закрывало кейс, когда пользователь открыл браузер, у него восстановилось 10 вкладок с нашим контентом, но подписка истекла и все 10 запросов одновременно пытаются активировать новую неделю)

https://emptysqua.re/blog/driver-features-for-mongodb-3-6/

круто

это как ответ на вопрос: КАК ЖЕ ДЕНЬГИ БЕЗ ТРАНЗАКЦИЙ ТАААА

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

хм, я чета даже захотел 3.6 с таким драйвером. кстати там было упоминание что This winter, we’ll release MongoDB 3.6 это так и ожидается?

это они так планируют, а выйдет она скорее всего к весне :)

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

ждем пускаем слюни

там ещё explain для аггрегаций будет

это самый сок

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

Дамп бинарный

Импорт нет

Ищем сотрудника в нашу команду - администратора БД MongoDB !!!!!! https://hh.ru/vacancy/20635690

Ищем сотрудника в нашу команду - администратора БД MongoDB !!!!!! https://hh.ru/vacancy/20635690

Если у вас есть какие-то конкретные задачи, вы можете нанять нас

Но на будущее, не надо ставить столько восклицательных знаков — никто в серьёз не будет воспринимать

Если у вас есть какие-то конкретные задачи, вы можете нанять нас

молодец :)

М?

Здрасьте. Вопрос по mongoose: с другой sql orm было так: брался коннект из пула, использовался для всех операций для данного http запроса, а в конце запроса возвращался обратно. Насколько это правильно в целом и в контексте mongodb? и как такое сделать, используя mongoose?

монга сама разруливает пул и коннекты

монга сама разруливает пул и коннекты

Монга ничего не разруливает. Но в отличии от RDBM ей не требуется хранить «представление» соединения, как следствие монга может держать много соединений с минимальным оверхедом.

Здрасьте. Вопрос по mongoose: с другой sql orm было так: брался коннект из пула, использовался для всех операций для данного http запроса, а в конце запроса возвращался обратно. Насколько это правильно в целом и в контексте mongodb? и как такое сделать, используя mongoose?

Драйвер должен решать этот вопрос. AFAIK монгус не официальный клиент, читайте доку. Скорее всего пул уже в драйвере есть и отдельно ничего делать не надо.

Драйвер должен решать этот вопрос. AFAIK монгус не официальный клиент, читайте доку. Скорее всего пул уже в драйвере есть и отдельно ничего делать не надо.

да, пул есть. надо его привязать к http запросу.

Это к нодовцам лучше адресовать

А смысл в привязке? Монгус сам разруливает это дело

как проверить, работает сжатие или нет? db.runCommand({getCmdLineOpts: 1}) показывает, что опция включена, но хотелось бы посмотреть на какую-нибудь статистику https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-networkmessagecompressors

как проверить, работает сжатие или нет? db.runCommand({getCmdLineOpts: 1}) показывает, что опция включена, но хотелось бы посмотреть на какую-нибудь статистику https://docs.mongodb.com/manual/reference/program/mongod/#cmdoption-networkmessagecompressors

Статистику чего?

Драйвера пока сжатие не поддерживают и до 3.6 судя по всему не будут

AFAIK, сейчас эта опция пока влияет только на трафик между нодами

а толку от компрессии?

ноды рядом, смысл, только cpu будет кушать лишнее.

а толку от компрессии?

Для драйвера: полно.

Весь wire protocol на голом bson построен

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

А про cpu это бабка надое сказала. Snappy на фоне всего остального не заметен

ну сеть-то асинхронно написана 100%, на саму монгу не повлияет, а вот cpu гроши, но считать будет

Между нодами куча трафика. Например если большой поток оплога, сжатие может увеличить пропускную способность. Гигабит оплога не так сложно в пике получить

Плюс initial sync

у нас было такое несколько раз, кстати =)