NI
Так я и прошу привести пример, где Mongo не хуже (я, кстати, даже знаю несколько очень важных плюсов монги - но про них что-то никто даже и не заикнулся)
А о каких плюсах вы знаете?
Size: a a a
2021 March 09
PD
Зачем - если есть аппаратные платформы, затягивающие чуть ни 1TB RAM и там строящие свои представления в 2,3 и прочие N-модели., ну совсем отличающиеся от реляционных Как с утра закачали с диска в оперативку, а вечером выгрузили обратно на диск. А надежность поддерживается аппаратными средствами. Есть еще и спецпроцессора, которые могут обрабатывать данные IoT "на лету" - без отправки в ЦОД - типа процессоры на нейросетях. Там уже можно вкорячить в инферно весь imagenet и обсчитывать любые обьекты на каком то ResNet18 со скоростью 50 fps в разрешении 4K - а в СУБД скидывать уже ФИО и фото попавшегося "счастличвчика"..
Я про СУБД говорил, не про программно-аппаратные платформы (я про них практически ничего не знаю, увы)
KK
Ну, для стартапов - наверно да. Когда сразу делается на выброс, когда квалификация всех разработчиков мало отлична от нуля и ничего хорошего все равно сделано не будет - то все равно, что брать.
вот мне монга обычно в таких проектах и доставалась) чаще всего в чатах.
PD
вот мне монга обычно в таких проектах и доставалась) чаще всего в чатах.
Ага. Но, увы, после MVP никто ее не выкидывает и все это легаси так и продолжает существовать.
Хотя это был выбор "от бедности и глупости", а не под задачу.
Хотя это был выбор "от бедности и глупости", а не под задачу.
PD
Nikita Ilin
А о каких плюсах вы знаете?
Ну, например, монга гораздо лучше сочетается с многопоточностью в стиле корутин или реактивного программирования. У PG все еще не очень нормальный асинхронный драйвер, да и вообще транзакции плохо сочетаются с многопоточностью.
Впрочем, у большинства key-value с многопоточностью тоже очень неплохо.
Впрочем, у большинства key-value с многопоточностью тоже очень неплохо.
KK
Ага. Но, увы, после MVP никто ее не выкидывает и все это легаси так и продолжает существовать.
Хотя это был выбор "от бедности и глупости", а не под задачу.
Хотя это был выбор "от бедности и глупости", а не под задачу.
да, потом с этим жить, переходить в Mongo Enterprise.
Но иногда находишь там свои прелести. Вроде Mongo Watch - как подписаться на события кластера чтобы сервисы могли подслушивать обновления БД, а не пинать друг-друга. Это есть и в других БД, но не везде.
Но иногда находишь там свои прелести. Вроде Mongo Watch - как подписаться на события кластера чтобы сервисы могли подслушивать обновления БД, а не пинать друг-друга. Это есть и в других БД, но не везде.
МГ
у нас, кстати, MongoDB досталась "по наследству". Но сейчас нормально используется, и во многом она удобнее реляционок.
МГ
разобрались с хвостами которые оставались "по наследству"
МГ
а новое делаем нормально)
GK
по мне так Redis и Mongo прекрасны попсовостью. Надеюсь я больше не попаду в стартапы, но вот для них это самое то. Все что умеет лаять и мяукать, заодно знает Redis и MongoDB. Причем кроме разработки, еще и Ops-часть. Это очень простые решения, очень документированные и предсказуемые на сегодня. Они мало потребляют ресурсов, это удобно для dev-задач особенно (запустить локально CouhBase в кластерном режиме - ну такое себе...). Прекрасно подходят для проектов где не думают. Где нет денег на архитектора, где СТО назвал себя так сам или его назвал так основатель бизнеса, хотя до этого СТО сайты делал.
По мне - это идеальная ниша данных решений.
По мне - это идеальная ниша данных решений.
Поддерживаю
KK
Есть еще железная связка в MeteorJS - Mongo+MiniMongo на фронте. И протокол DDP для связи. Это подход когда изменения сначала происходят в клиенте, а потом асинхронно в фоне уходят на бэк. паттер "придет к нужному состоянию позже". Позволяет делать офлайн режим и иллюзию реактивной работы UI. Там как раз удобно использовать подписки на данные с бэка и иметь одинаковую структуру данных, а протокол DDP - своя реализация подобия WebSocket.
Этот фреймворк строго для MVP и не лучший пример. Но это пример технического решения, на нем работает http://sdelements.github.io/lets-chat/
Этот фреймворк строго для MVP и не лучший пример. Но это пример технического решения, на нем работает http://sdelements.github.io/lets-chat/
S
"Дилетантство" - это не мое мнение. По поводу мусора - это мнение многих ученых от таких как Де Вааль до Дробышевского. Природа не так совершенна. Насколько помню, если это выкинуть, то человек похудеет на 10кг :)
А еще обясните что у человека хромосом (21) меньше чем у картошки (48).. Они нами управляют, а мы не замечаем 😉 Dark DNA - тема ближайший "нобелевок", читайте матчасть. https://www.newscientist.com/article/mg23731680-200-dark-dna-the-missing-matter-at-the-heart-of-nature/ а ваш Дробышевский - лжегенетик - только кандидатскую смог написать 😉
МГ
важные факторы для нас в монге:
1. отсутствие схемы как плюс, что 20ти разработчикам не нужно делать миграции на каждое поле
2. документоориентированность. Достаточно сложная структура данных, в реляционке это было бы 10 таблиц, в монге это одна коллекция
3. отсутствие схемы позволяет на лету формировать структуру данных. У нас в конфиге компаний указываются какие поля есть в разных сущностях. В монге это хранится в поле с типом BsonDocument, нативно поддерживается
4. запросы человеческие, без дополнительных ORM и плясок
1. отсутствие схемы как плюс, что 20ти разработчикам не нужно делать миграции на каждое поле
2. документоориентированность. Достаточно сложная структура данных, в реляционке это было бы 10 таблиц, в монге это одна коллекция
3. отсутствие схемы позволяет на лету формировать структуру данных. У нас в конфиге компаний указываются какие поля есть в разных сущностях. В монге это хранится в поле с типом BsonDocument, нативно поддерживается
4. запросы человеческие, без дополнительных ORM и плясок
VR
А в этих решениях нет потребности в арх.решении по выбору persistance, там все тривиально и реализуется на чем угодно.
Но так как они простые, то ORM там тоже скорее будет мешать, нежели помогать.
Но так как они простые, то ORM там тоже скорее будет мешать, нежели помогать.
Хорошая ORM (типа Entity Framework) дает строгую статическую типизацию для исходного кода, которая никакому проекту не помешает
AM
Я бы сказал, что этот совет относится к любым решениям, не только к СУБД и не только к PG.
Обновление мажорных версий без останова - очень больная тема (
Обновление мажорных версий без останова - очень больная тема (
Нужно просто трясти вендора, даже сайбас имел чёткие ответы на вопросы, дб2 и оракл подавна. А вот кого спрашивать о пг - хз. там в WAL такое тварится от версии к версии что мама не горюй.
МГ
у нас на уровне MergeRequests проверяется схема
PD
важные факторы для нас в монге:
1. отсутствие схемы как плюс, что 20ти разработчикам не нужно делать миграции на каждое поле
2. документоориентированность. Достаточно сложная структура данных, в реляционке это было бы 10 таблиц, в монге это одна коллекция
3. отсутствие схемы позволяет на лету формировать структуру данных. У нас в конфиге компаний указываются какие поля есть в разных сущностях. В монге это хранится в поле с типом BsonDocument, нативно поддерживается
4. запросы человеческие, без дополнительных ORM и плясок
1. отсутствие схемы как плюс, что 20ти разработчикам не нужно делать миграции на каждое поле
2. документоориентированность. Достаточно сложная структура данных, в реляционке это было бы 10 таблиц, в монге это одна коллекция
3. отсутствие схемы позволяет на лету формировать структуру данных. У нас в конфиге компаний указываются какие поля есть в разных сущностях. В монге это хранится в поле с типом BsonDocument, нативно поддерживается
4. запросы человеческие, без дополнительных ORM и плясок
1. Это страшно, миграции все равно нужны. Но, как я уже говорил, schemaless есть почти всюду, это уже не плюс.
2. Аналогично, можно упаковать в одну таблицу, если есть поддержка json/jsonb (а она в каком-то виде уже почти всюду есть)
3. Аналогично, вполне реализуемо почти всюду в РСУБД (ну, кроме Оракла)
4. Так и для реляционок не надо ORM использовать.
2. Аналогично, можно упаковать в одну таблицу, если есть поддержка json/jsonb (а она в каком-то виде уже почти всюду есть)
3. Аналогично, вполне реализуемо почти всюду в РСУБД (ну, кроме Оракла)
4. Так и для реляционок не надо ORM использовать.
PD
Vladimir Romanko
Хорошая ORM (типа Entity Framework) дает строгую статическую типизацию для исходного кода, которая никакому проекту не помешает
Это странное утверждение. Типизация происходит только до границы обращения к БД и это верно не только для ORM, но и для любого слоя работы с СУБД.
МГ
4. Так и для реляционок не надо ORM использовать. — какие альтернативы? Запросы в тексте?)
АЛ
Vladimir Romanko
Хорошая ORM (типа Entity Framework) дает строгую статическую типизацию для исходного кода, которая никакому проекту не помешает
а потом кто-то пытается сериализовать Entity и вытягивает через него всю базу. ORM - надо очень сильно ограничивать, чтобы первый же залетеший дятел не разрушил цивилизацию :) Последние несколько лет в .Net пользовались Dapper