собственно это и есть ответ - зачем

ну мнение на последнюю ссылку - автор имеет личное предпочтение и я вообще удивлен что он хотя бы в ввыодах описал основные плюсы

а так монго использую именно из-за вот всего перечисленного: горизонтальное масштабирование и производительность

я думаю ты обратил внимание вот на это да?

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

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

гоняй свои тесты. вкури подход к данным в монго.

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

это старые статьи. и монга со старым движком. с WiredTiger ситуация уже совсем другая.

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

Эти цифры — бутафория

С таким-же успехом можно верить в гороскопы

это старые статьи. и монга со старым движком. с WiredTiger ситуация уже совсем другая.

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

Все эти пузомерки для сферических урановых коней во ртути не имеют никакого физического смысла и являются развлекательным контентом

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

Я вам могу посоветовать тогда кости бросать

А теперь посчитайте TCO

на горизонт года три

^ самая смешная статья из всех

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

Ага. Включая скорости развертывания, поддержку, восстановление после сбоя и т.п.

для этого tco и надо считать

Ага. Включая скорости развертывания, поддержку, восстановление после сбоя и т.п.

обязательно надо учитывать все эти факторы

но это все имеет смысл считать если это не pet project а бюджеты хотя бы несколько k в год

на саму инфраструктуру

Я и говорю. Причем, для каждого юзкейса со своими весами.

к теме postgre vs mongo - https://www.theguardian.com/info/2018/nov/30/bye-bye-mongo-hello-postgres

интересный пример когда решение было мотивировано странно

мы же это уже в соседнем чяте обсуждали

это переписуны классические

Привет. В монгус схеме указываю дефолтное значение, если ничего не указано, и энумератор, чтоб проверить, что попытались указать. Стоит ли включать в энумератор дефолтное значение?

Привет. подскажите можно ли востоновить из файлов ? collection-7-5540247958378524942.wt

О надо будет исходники глянуть чего они там сделали

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

А ещё прикольно там попробовали сделать ngram https://github.com/percona/percona-server-mongodb/blob/v4.0/src/mongo/db/fts/ngram-tokenizer.md

Чисто.... заменили способ токенизации

Мда

а есть чатик про редис?

а есть чатик про редис?

Найдешь, сообщи, пожалуйста

@dd_bb ты все руби в лес послал?

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

ну а что с мемкешем происходило когда ты его выключал? :)

тоже самое и тут — данным хана

@dd_bb ты все руби в лес послал?

в смысле?

в смысле?

Ну ты ведь раньше мембером канала pro.ruby был или это другой yopp, ещё какие-то обучающие курсы клепал по рубям

pro.ruby нет, был другой руби канал, да

Так на руби и разрабатываешь?

если че можно просто свой трешак удалять

Попытка испольнить: something: { $push: { $cond: { if: { "tags": { $in: ["tag_name"] } }, then: true, else: false } } } выдаёт ошибку, ссылаясь на недостаточное количество элементов в $in, но я полагаю проблема в чём-то ещё...

как вообще реализовать нечто подобное?

это часть аггрегационного запроса

верный синтаксис: if: { $in: ["tag_name", "$tags"] },

@yatoba ban?

Чел ты выбрал не тот чат что б тешить своё чсв

О уже удалили:)

Стоит ли хранит картинки в поле mongodb?

Стоит ли хранит картинки в поле mongodb?

Нет

А как лучше?

А как лучше?

Если ты именно в монге хочешь, то посмотри в сторону GridFS

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

*где

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

Я реализовал так что в монго храниться картинка типа Buffer и написал отдельный роут который даёт эти картинки по id продукта

При загрузке картинки он переводится в тип Buffer

Я реализовал так что в монго храниться картинка типа Buffer и написал отдельный роут который даёт эти картинки по id продукта

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

А можно ли реализовать это со многими картинками

?

А можно ли реализовать это со многими картинками

Не совсем понятен вопрос. Что именно реализовать?

Как сохранить несколько картинок в монге?

Именно картинок

Картинке хранятся на сервере В бд ссылки на картинки

Так правильней

Ок, спасибо

Картинке хранятся на сервере В бд ссылки на картинки

В gridfs тоже можно, если кэширующий слой нормальный повесить. В этом случае (я по своему опыту сужу) сильно удобней всякие мета-атрибуты вешать и искать по ним. Но с файликами да, это каноничный вариант.

Спасибо вам

А как реализовать этот метод с файлами в REST api

Есть фронт энд на react и он запрашивает api

Как можно предоствить картинки

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

Использую Гугл сторедж. В монго храню путь к паблик урл в сторедже

В итоге из монго отдаю путь который уже в фронте рендерю