Artem там где name может быть все что угодно, каждое перечислять это нереально

Не перечисляйте

db.collection.find({},{“name”:1})

Спасибо, это действительно то

Помогите пожалуйста

Помогите пожалуйста

это не mongodb 😐

mysql?

Помогите пожалуйста

Тебе всё сказали а чате по MySQL

Тебе всё сказали а чате по MySQL

Как решать

В чем проблема?

гуглить и решать

гуглить и решать

🤦‍♂

Зачем группа тогда?

это группа по mongodb для начала

это группа по mongodb для начала

Извините

а по вопросу ничего не мешает вбить все это в гугл и уверен что первый результат вам поможет

а по вопросу ничего не мешает вбить все это в гугл и уверен что первый результат вам поможет

Все посмотрел пробовал

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

Подскажите, какой вариант лучше использовать с точки зрения оптимизации монго, много мелких документов или в 20 раз меньшее кол-во больших документов? Еесть условно твиты, их около 100к, изначально они разбиты по дням. Поиск сконцентрирован в первую очередь по этим твитам. (подсчет различных полей, аналитика, агрегация и.т.п.) 1) Хранить документы Day(ид, дата) с вложенными туда твитами (ид, дата, твит) 2) Хранить документы Twit (ид, дата, твит, ид дня, дата дня)

Подскажите, какой вариант лучше использовать с точки зрения оптимизации монго, много мелких документов или в 20 раз меньшее кол-во больших документов? Еесть условно твиты, их около 100к, изначально они разбиты по дням. Поиск сконцентрирован в первую очередь по этим твитам. (подсчет различных полей, аналитика, агрегация и.т.п.) 1) Хранить документы Day(ид, дата) с вложенными туда твитами (ид, дата, твит) 2) Хранить документы Twit (ид, дата, твит, ид дня, дата дня)

зачем тебе id дня???

Dmitriy ну, этот момент можно опустить. суть вопроса в том что лучше - много маленьких документов или меньшее кол-во больших.

Dmitriy ну, этот момент можно опустить. суть вопроса в том что лучше - много маленьких документов или меньшее кол-во больших.

Тут нужно определиться что есть "большой". Это много ключей или много данных в value. В любом случае, если документы не предполагается раздувать и их размер будет фиксированный, то лучше все держать в оной коллекции. Так будет меньше запросов к БД. Ну и, конечно же, индексы нужно повесить грамотно

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

Вы учтите тот факт, что монга в любом случае при работе читает документ целиком

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

День с вложенными твитами хранить рискованно. Так как размер документа будет очень непостоянным. Лучше хранить твит с полем 'день'.

спасибо большое за помощь!

такой вопрос. Есть объем информации, который приходит единым блоком. В среднем по1 500 000 документов. Мне нужно просматривать предыдущею хранящуюся в базе версию и вностить изменения в соответвии с новым пришедшим блоком. Чего нет, удалить, что есть добавить. В коллекции есть четыре индекса, один из них полнотекстовый. Я правильно понимаю, что быстрее будет просто новый блок добавить, как новую коллецию и заново пересоздать индесы, а старый удалить? Или все таки быстрее будето частичное обновление? Процесс происходит в среднем раз в час.

мне кажется проще пересоздать коллекцию

500000 - не такая уж большая цифра

там варьируеться число. От 500 000 до 3 500 000 документов на коллекцию. Я вот тоже думаю, что сканирование коллекции, добавление и удаление кажого документа, плюс перестроение индексов...

будет более ресурсоемким процессом

там варьируеться число. От 500 000 до 3 500 000 документов на коллекцию. Я вот тоже думаю, что сканирование коллекции, добавление и удаление кажого документа, плюс перестроение индексов...

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

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

целиком все за раз и старые удалить

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

ну я думал, можно сделать так. Сначала добавить новую коллекцию, если все ок, то старую удалать и новую переименовать в старую

не забывай что транзакций нету, лучше писать все эти данные в какую то очередь, а после ее разбирать балками, по 50к документов, например, и делать bulk upsert

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

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

ну я думал, можно сделать так. Сначала добавить новую коллекцию, если все ок, то старую удалать и новую переименовать в старую

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

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

то есть я не могу ему отдать не доконца обновленные данные

вот вы и ответили на вопрос, тогда просто пересоздаете коллекцию

спасибо

хотел посоветоваться

а то малоли, я еще далеко не спец в монго)))

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

Подскажите, какой вариант лучше использовать с точки зрения оптимизации монго, много мелких документов или в 20 раз меньшее кол-во больших документов? Еесть условно твиты, их около 100к, изначально они разбиты по дням. Поиск сконцентрирован в первую очередь по этим твитам. (подсчет различных полей, аналитика, агрегация и.т.п.) 1) Хранить документы Day(ид, дата) с вложенными туда твитами (ид, дата, твит) 2) Хранить документы Twit (ид, дата, твит, ид дня, дата дня)

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

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

если по пользователю, то по времени и пользователю

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

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

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

большое количество мелких документов, когда много индексов — очень плохо

больше == миллиарды

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

https://docs.mongodb.com/ecosystem/use-cases/storing-comments/

Товарищи кто какие практики/патерны/подходы/npm модули использует чобы гарантировать выполнение нескольких операций create/update с роллбэком. либо все либо ничего так сказать. пример двухфазного комита читал. интересно что у людей на практике с этим

Товарищи кто какие практики/патерны/подходы/npm модули использует чобы гарантировать выполнение нескольких операций create/update с роллбэком. либо все либо ничего так сказать. пример двухфазного комита читал. интересно что у людей на практике с этим

если ты про транзакции в монге - потерпи немного. Скоро будут )

Ну мне прям совсем ACID не нужен. И я да. мотрел там их анонс. Что то там в примерах нет NodeJS и помоему неспроста это

https://stackoverflow.com/questions/23830385/how-do-acid-transactions-with-nodejs-tokumx-mongodb-any-mongodb-driver-for

Я так подозреваю что все пилят собственный велик на jobs/queue

хотя вот нашел такую оберточку еще https://github.com/e-oj/Fawn

Ну мне прям совсем ACID не нужен. И я да. мотрел там их анонс. Что то там в примерах нет NodeJS и помоему неспроста это

Драйвера доделают к релизу. Могут и позже

Товарищи кто какие практики/патерны/подходы/npm модули использует чобы гарантировать выполнение нескольких операций create/update с роллбэком. либо все либо ничего так сказать. пример двухфазного комита читал. интересно что у людей на практике с этим

Пересмотреть в сторону индемпотентных операций

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

Ну у меня есть документ который будет гарантированно создан или изменен. но иногда мне нужно вместе с этим создавать / менять документ в другой коллекции

только две коллекции получается должны быть консистентны

Это техническое описание проблемы

У вас денормализованные данные?

Вы обновляете связи?

Какой физический смысл этих операций?

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

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

Всем привет. расскажите плз, как справлятся без монгуса? есть ощущение что юзать монгус зашквар

Всем привет. расскажите плз, как справлятся без монгуса? есть ощущение что юзать монгус зашквар

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

То есть монгус это топ?

То есть монгус это топ?

Монгус это одм

Кстати, какая есть хорошая литература по монго? Кроме официальных доков

Я скидывал ссыль, но там версия 2.6