Так а зачем всё это мероприятие? Всё плохо в MongoDB Inc.?

Что стоит конкурентам форкнуть старую версию, которая под AGPL? По мне так смена лицензии, это проявление слабости компании.

Амазон форкнул, только там апи неполный и старый как говно мамонта.

Так сообщество о MongoDB в целом.

Вам как разработчику совершенно фиолетово

Если у вас есть какие-то конкретные вопросы — задавайте. Обсуждать что вы думаете про лицензирование тут не стоит.

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

Вопрос такой - не станет ли MongoDB полностью платной, через пару лет? Т.к. смена лицензии - тревожный звонок.

Это к психотерапевту

Не умрёте ли вы от рака через пару лет?

Да ты болен на голову. Печально, что здесь такой админ.

товарищ @dd_bb, посоветуй чем экспортить данные профайлинга из монги в прометей? (желательно с уже готовым пресетом для дашборда)

добрый день. подскажите пожалуйста, есть монга, сохранение в нее 100к записей происходит за ~60c (в самой базе в этой таблице уже порядке 100м записей). можно ли как-то затюнить это, или пора шардировать? (и с какого момента вообще пора начинать шардировать ее)?

Вопрос больше по нереляционным БД чем по монге. Я слышал мнение, что те кто хотели мультидокументные транзакции в монгодб просто не понимают как правильно денормализовывать данные и пользоваться ими. Вопрос как пользуюясь только single document acid достигается консистентность системы? Вы сохраняете типа изменение в документе и какой-то event, который потом обработается в другой транзакции типа eventual consistency? Или как то по другому?

Смотреть во что упирается монга. Вероятно в диск, 1600 записей в секунду на вставку это не очень много. У вас там нжмд?

ссд

Смотреть во что упирается монга. Вероятно в диск, 1600 записей в секунду на вставку это не очень много. У вас там нжмд?

Большие документы?

2 phase commit для связанных изменения и идемпотентность операций. Больше особо вариантов нет. Транзакции это просто инструмент, который в ряде случаев ощутимо упрощает жизнь. С ними денормализация сложных документов стала более доступной опцией, так как при наличии требований к изоляции связанных изменений теперь не надо придумывать извращений. В целом, не так много задач когда гарантии целостности абсолютно критичны.

кол-записей влияет. пока их было мало, писало со скоростью 10к/с

> В целом, не так много задач когда гарантии целостности абсолютно критичны. У меня почти все такие задачи) Но по идее еще возможно eventual consistency? Сохранили одно изменение, передали дальше другим, которые обработают в других транзакциях, типа Saga

А что у вас за задачи?

Корпоративные бизнес-приложения

Мб тогда индексы?

Добрый день коллеги Есть вопрос, может кто сталкивался с этим. У клиента 5 монгосов в шардированном кластере. 3 монгоса на одном ДатаЦентре и 2 на другом. Но как только приложения переключаются на 5 монгосов, то падает перфоманс и выпадают шоюки в лог монгоса что на 2 Датацентре Error sending response to client: HostUnreachable: Connection was closed. Ending connection from <IP>:32940 (connection id: 158) А в логе приложения 2019-09-09 13:04:03.039 [-,e*******][http-nio-11040-exec-2] ERROR r.l.o.p.web.error.RestErrorHandler - Exception receiving message; nested exception is com.mongodb.MongoSocketReadException: Exception receiving message ..... Caused by: javax.net.ssl.SSLException: Invalid TLS padding data ..... Caused by: javax.crypto.BadPaddingException: Invalid TLS padding data

Добрый день коллеги Есть вопрос, может кто сталкивался с этим. У клиента 5 монгосов в шардированном кластере. 3 монгоса на одном ДатаЦентре и 2 на другом. Но как только приложения переключаются на 5 монгосов, то падает перфоманс и выпадают шоюки в лог монгоса что на 2 Датацентре Error sending response to client: HostUnreachable: Connection was closed. Ending connection from <IP>:32940 (connection id: 158) А в логе приложения 2019-09-09 13:04:03.039 [-,e*******][http-nio-11040-exec-2] ERROR r.l.o.p.web.error.RestErrorHandler - Exception receiving message; nested exception is com.mongodb.MongoSocketReadException: Exception receiving message ..... Caused by: javax.net.ssl.SSLException: Invalid TLS padding data ..... Caused by: javax.crypto.BadPaddingException: Invalid TLS padding data

Проверьте что TLS на всех монгосах корректно настроен и что между монгосами и приложениями нет сетевых ошибок

Между многосами все ок. Приложения крутятся в докер контейнерах на других серверах. Самое забавное что при тех же конфигурациях и 3Цодовости все работает на Препрод среде

Могут ли два $project идти подряд и так, чтобы один юзал результат другого

Мб тогда индексы?

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

Да, влияют. Индекс по _id есть всегда. Это «первичный» уникальный индекс, который связывает записи в document storage со значениями поля _id через внутренний recordId Любой индекс это ещё одно KV хранилище. Как следствие добавляя индекс на одну вставку надо будет добавлять больше ключей, а это больше транзакций в память и больше дисковых операций.

смотри, у меня сейчас индексов нет никаких, но при возрастании кол-ва записей в БД увеличивается время вставки. при 1м сущевствующих записей вставка 100к за 15с, при 100м - за 60с

Как вы делаете вставку?

В разница во времени вставки 4 раза, а в количестве документов в 1000 раз. Вставка это примерно O(logN), log(100k) = 3, log(100m) = 8, 8/3 = 2,66. Это без учёта коэффициента по io timing. В принципе в пределах нормы.

😐

Привет. Подскажите. Есть коллекция с комментариями. У комментов есть поле parent, которое либо null - коммент первого уровня, либо равен id родитесльского коммента. Можно ли одним запросом получить db.find({ parent: null }) и к каждому комменту посчитать, количество его детей (ответов). Или сделать это как-то иначе, чем пройтись циклом и для каждого сделать запрос db.countDocuments({ parent: comment._id }).

parent pattern для деревьев коментариев не эффективнен. поменяйте на matherialized path и тогда можно будет легко считать covered query по префиксу

Монгосы между собой никак не взаимодействуют. Они чекинятся в CSRS и устанавливают соединения с другими data bearing нодами в кластере