Nikita
Ну да. Тут вопрос в том, чтобы познакомиться с MongoDB. Т.к. проект простой, и его можно реализовать и на MongoDB и на MySQL например.
Aleksandr
бери монго, не пожалеешь
Aleksandr
🌚
yopp
С такой постановкой задачи — практически гарантированно
Aleksandr
ну, опыт-то полезный все-равно
Aleksandr
опыт отрицательный не бывает имхо
Nikita
Так а как я могу ставить задачу по MongoDB, если я с ней не работал до этого? Собственно, поэтому и задаю вопросы в этом чате.
yopp
Так а как я могу ставить задачу по MongoDB, если я с ней не работал до этого? Собственно, поэтому и задаю вопросы в этом чате.
Не надо ставить задачу «по MongoDB»,определитесь с результатом который вы хотите получить
Aleksandr
походу задача стоит "разобраться с mongodb"
Dmitriy
Так а как я могу ставить задачу по MongoDB, если я с ней не работал до этого? Собственно, поэтому и задаю вопросы в этом чате.
монга в постановке задачи не играет роли - монга в данном случае это просто хранилище данных. задача в данном случае может выглядеть так: "разработать новостную ленту, с возможностью комментирования и проставления лайков"
Egor
Так а как я могу ставить задачу по MongoDB, если я с ней не работал до этого? Собственно, поэтому и задаю вопросы в этом чате.
в гугле тоже много инфы, такие вопросы как ты каждый второй задает, тебе говорят - конкректнее вопрос поставишь - конкректнее ответят)
Egor
мне кажется в таких чатах нужен иисус - ему задешь вопрос - он отвечает постоянно да - и все - никаких больше холиваров и споров
а конкректные вопросы уже потом будут по ходу дела задаваться во время разработки
Aleksandr
лично я вообще перестал понимать что за задачи требуют именно SQL-базу типа mysql/postgress так меня от монго прет
Nikita
Ну, начнём с того, что при постановки задачи, я столкнулся с вопросом миграций, и спросил здесь про них. + Спросил, какой инструмент (ODM), зарекомендовал себя. То что миграции не нужны, это уже следствие вашего ответа. В моём понимании нужны, хоть и в ограниченном виде. Вопроса про выборку данных я не задавал.
Nikita
В моей задаче не должно быть проблем связанных с отсутствием SQL. С форматом хранения данных тоже не должно быть проблем.
Egor
В моей задаче не должно быть проблем связанных с отсутствием SQL. С форматом хранения данных тоже не должно быть проблем.
да, бери монгу, благославляю, у тебя все получится, все будет хорошо!
yopp
Ну, начнём с того, что при постановки задачи, я столкнулся с вопросом миграций, и спросил здесь про них. + Спросил, какой инструмент (ODM), зарекомендовал себя. То что миграции не нужны, это уже следствие вашего ответа. В моём понимании нужны, хоть и в ограниченном виде. Вопроса про выборку данных я не задавал.
Даже если это игрушечный проект, если у вас нет четко зафиксированный проблемы которую он должен решать, и стратегии её решения, то вам рано выбирать технологию.
yopp
Вы не хотите услышать что ваша проблема не в технологии, а в постановке задачи
yopp
По этому вам дают советы котроые вас не устраивают
Nikita
yopp
И вам не дадут нормальны советов, потому что нет чётко ограниченного проблемного поля.
Nikita
По этому вам дают советы котроые вас не устраивают
Просто вы сильно перевели всё в теорию. Есть кейс, где нужны миграции. Кстати ранее прислали пару ссылок на подходящие инструменты.
yopp
Просто вы сильно перевели всё в теорию. Есть кейс, где нужны миграции. Кстати ранее прислали пару ссылок на подходящие инструменты.
Это не теория. Это суровая практика
Egor
Просто вы сильно перевели всё в теорию. Есть кейс, где нужны миграции. Кстати ранее прислали пару ссылок на подходящие инструменты.
напиши пару жс скриптов для миграций, в чем проблема
Egor
зачем какие-то го либы еще тащить, бред блин
yopp
Но вы не хотите слушать, смысла продолжать эту беседу нет
yopp
Not invented here, очень страшный синдром
Alexander
Как обычно, проблема в мышлении. В монге миграции схемы данных, какие есть в табличных базах, действительно не нужны. Тут всегда миграции самих данных, которые не получается нормально автоматизировать. Но для людей, которые с этим не работали, это кажется дикостью. Потому и рассказывает человек о том, что без мигрций жизни нет и он не знает, как без них начать проект, не слыша тех, кто говорит, что они не нужны. Но и обратное тоже верно, если вы понимаете о чём я.
yopp
а, да ну не
даже не намекал на это
«Зачем тащить библиотеку, лучше написать» эт оно и есть
Nikita
Как обычно, проблема в мышлении. В монге миграции схемы данных, какие есть в табличных базах, действительно не нужны. Тут всегда миграции самих данных, которые не получается нормально автоматизировать. Но для людей, которые с этим не работали, это кажется дикостью. Потому и рассказывает человек о том, что без мигрций жизни нет и он не знает, как без них начать проект, не слыша тех, кто говорит, что они не нужны. Но и обратное тоже верно, если вы понимаете о чём я.
Но разве плохо, если такой инструмент будет существовать (на всяких случай), а если он не понадобится, то и норм? Теоретически кейс ведь возможен. С тем же MVP, когда сделано на коленке, и нужно перегнать данные в другую структуру.
Egor
«Зачем тащить библиотеку, лучше написать» эт оно и есть
ну типа поддерживать еще + 1 инструмент в его случае - это норм типа?
Egor
он если даже с бд опередилться не может
Egor
а если ему еще в стек доп инструментов добавить, то он никогда не зарелизиться
Dmitriy
ну типа поддерживать еще + 1 инструмент в его случае - это норм типа?
ребят, вы не в ту степь ушли, человек с ЯП тоже пока не определился, а вы уже обсуждаете стек
Alexander
Но разве плохо, если такой инструмент будет существовать (на всяких случай), а если он не понадобится, то и норм? Теоретически кейс ведь возможен. С тем же MVP, когда сделано на коленке, и нужно перегнать данные в другую структуру.
В том-то и дело, что такие инструмент в реальной жизни не нужен. Ни разу с монгой я не подумал о том, что он бы мне пригодился. Потому и советую забить на это с высокой башни.
Dmitriy
Но разве плохо, если такой инструмент будет существовать (на всяких случай), а если он не понадобится, то и норм? Теоретически кейс ведь возможен. С тем же MVP, когда сделано на коленке, и нужно перегнать данные в другую структуру.
у вас коллекция в монге не имеет четкой схемы, поэтому вы можете начать писать свою структуру в любую коллекцию по своему усмотрению в любой момент. единственное для чего может понадобится миграция в монге - это подготовка коллекций, индексов в ней и первичное наполнение данными.
но опять же в вашем случае для тестового проекта это не нужно сразу разбирать, поймите сначала как вообще устроена работа с БД, а потом уже вникайте в детали
Dmitriy
но для этого как вам уже все выше сказали вам сначала надо определиться с самой постановкой задачи
Алексей
лично я вообще перестал понимать что за задачи требуют именно SQL-базу типа mysql/postgress так меня от монго прет
А как же связь между сущностями, и необходимость построения сложных запросов по этим сущностям?
Nikita
Задача - есть приложение, которое установлено на разных серверах (не связанных). Используется MongoDB. Если я руками перегоню базу в новый формат на одном сервере, и обновлю приложение, на версию, которое работает с новой структурой БД, это одно дело. Но если к примеру всего 100 серверов? В моём понимании, в данном кейсе нужна версионность.
Если что, это не про приложение, которое планируется реализовать, а просто пример.
Egor
А как же связь между сущностями, и необходимость построения сложных запросов по этим сущностям?
по индексу ищешь и вообще норм получается 👌
Алексей
по индексу ищешь и вообще норм получается 👌
В десятке коллекций, каким-то образом аггрегируя данные
И выясняется, что в реляционной базе такого плана запрос отработает на порядок быстрее
Aleksandr
А как же связь между сущностями, и необходимость построения сложных запросов по этим сущностям?
можно в монге агрегейты писать + на сервере приложений данные из нескольких запросов объединять - если бд небольшая, то выигрыша sql в производительности не даст, а если бд огромная, то sql все-равно пососет в итоге
Dmitriy
Задача - есть приложение, которое установлено на разных серверах (не связанных). Используется MongoDB. Если я руками перегоню базу в новый формат на одном сервере, и обновлю приложение, на версию, которое работает с новой структурой БД, это одно дело. Но если к примеру всего 100 серверов? В моём понимании, в данном кейсе нужна версионность.
Если что, это не про приложение, которое планируется реализовать, а просто пример.
тут у меня возникает вопрос, почему ваши 100 нод приложения не работают с репликасетом монги или шардом, а каждая нода использует отдельное подключение к БД?
Egor
Nikita
тут у меня возникает вопрос, почему ваши 100 нод приложения не работают с репликасетом монги или шардом, а каждая нода использует отдельное подключение к БД?
Речь про несвязанные инстансы. Есть 100 разных сайтов, например, использующих одну и ту же кодовую базу.
Egor
какие вам тесты нужны если монга не умеет так в принципе?
так а зачем тогда натягивать сову на глобус
Dmitriy
так а зачем тогда натягивать сову на глобус
потому что это реальная задача, которая периодически требуется для сложной агрегации
Dmitriy
например финансовая отчетность по мсфо
Алексей
можно в монге агрегейты писать + на сервере приложений данные из нескольких запросов объединять - если бд небольшая, то выигрыша sql в производительности не даст, а если бд огромная, то sql все-равно пососет в итоге
Ну даст же
Если ты хочешь всасывать десять коллекций в сервер приложений, и объединять данные там, это очевидно просадка по сравнению с одним sql запросом
Ну и по слухам на чтение данных из больших таблиц/коллекций (действительно больших, гигабайты) монга уступает sql
Другое дело что при записи всё ровно наоборот, писать в сиквел базу больно, а монга на коне
yopp
На «слухи»
Egor
например финансовая отчетность по мсфо
ну типа в другую бд это все с помощью оплога монги выгружать и норм вроде как получается
они что ли каждую секунду генерятся эти отчеты что нужно прям с моногой аггрегировать
yopp
Dmitriy
ну типа в другую бд это все с помощью оплога монги выгружать и норм вроде как получается
они что ли каждую секунду генерятся эти отчеты что нужно прям с моногой аггрегировать
да, я же не спорю, варианты решения есть. но они не гарантируют консистентность данных. ее надо обеспечивать на уровне приложения
yopp
Есть фундаментальное правило очередности создания чего угодно, от скрепки и хелловорлдов до заводов и аналитических бэкендов: make it work, make it right, make it scale
yopp
«100 серверов» это из make it scale. Это последний этап, когда у вас уже есть
а) работающая
2) корректно решенная бизнес-задача
Egor
Ну даст же
Если ты хочешь всасывать десять коллекций в сервер приложений, и объединять данные там, это очевидно просадка по сравнению с одним sql запросом
Ну и по слухам на чтение данных из больших таблиц/коллекций (действительно больших, гигабайты) монга уступает sql
Другое дело что при записи всё ровно наоборот, писать в сиквел базу больно, а монга на коне
в sql тоже можно быстро писать, если индексы уберешь, к примеру
yopp
🤦♂️
Egor
👆
это была шутка, конечно проще всего сделать UNLOGGED таблицу и перф на запись улучишиться раз в 10, с некоторыми поправкками кхм 😏
Yuri
Всем привет, подскажите можно ли написать такой запрос:
есть поле date.
Хочу сделать выборку всех записей у которых date+ nMillis меньше заданной даты
Nikita
у вас коллекция в монге не имеет четкой схемы, поэтому вы можете начать писать свою структуру в любую коллекцию по своему усмотрению в любой момент. единственное для чего может понадобится миграция в монге - это подготовка коллекций, индексов в ней и первичное наполнение данными.
но опять же в вашем случае для тестового проекта это не нужно сразу разбирать, поймите сначала как вообще устроена работа с БД, а потом уже вникайте в детали
Насколько частый кейс, на практике, когда в коллекции "разношёрстные" данные?
Dmitriy
Насколько частый кейс, на практике, когда в коллекции "разношёрстные" данные?
Что значит разношерстные?
Nikita
"писать свою структуру в любую коллекцию по своему усмотрению в любой момент"
Nikita
В десятке коллекций, каким-то образом аггрегируя данные
И выясняется, что в реляционной базе такого плана запрос отработает на порядок быстрее
Но в реляционной СУБД, гораздо сложнее вопрос горизонтального масштабирования. Т.е. всё зависит от кейса. А здесь кто-то знаком с wide column store?
Dmitriy
"писать свою структуру в любую коллекцию по своему усмотрению в любой момент"
На практике такого не бывает, т.к. вы четко должны понимать какую логическую единицу обслуживает ваша таблица (коллекция в контексте монго)
Но т.к. в монго нет схемы данных вы в любой момент можете добавить в существующую коллекцию новые поля и они будут автоматически вставлены (а список полей коллекции расширен) при операции вставки или обновления (с удалением несколько сложнее, т.к. поле то удалится, но нельзя забывать об операции перестройки индекса)
Nikita
На практике такого не бывает, т.к. вы четко должны понимать какую логическую единицу обслуживает ваша таблица (коллекция в контексте монго)
Но т.к. в монго нет схемы данных вы в любой момент можете добавить в существующую коллекцию новые поля и они будут автоматически вставлены (а список полей коллекции расширен) при операции вставки или обновления (с удалением несколько сложнее, т.к. поле то удалится, но нельзя забывать об операции перестройки индекса)
В MongoDB тоже есть операция удаления поля? Или нужно удалить это поле у всех элементов вручную?
Dmitriy
В MongoDB тоже есть операция удаления поля? Или нужно удалить это поле у всех элементов вручную?
Если поле присутствует хотя бы в одном документе коллекции, то оно присутствует как поле коллекции)
Dmitriy
Т.е. полностью удалить у всех документов
Aleksandr
В MongoDB тоже есть операция удаления поля? Или нужно удалить это поле у всех элементов вручную?
db.collection.updateMany({}, { $unset: { fieldName: '' }})
Aleksandr
удлалит поле fieldName из всех документов collection
Nikita
Ну даст же
Если ты хочешь всасывать десять коллекций в сервер приложений, и объединять данные там, это очевидно просадка по сравнению с одним sql запросом
Ну и по слухам на чтение данных из больших таблиц/коллекций (действительно больших, гигабайты) монга уступает sql
Другое дело что при записи всё ровно наоборот, писать в сиквел базу больно, а монга на коне
От кейса зависит, но всё таки чтение по дефолту более частая операция.