Подскажите, что оптимальней использовать монго или другую базу для хранения вершин древовидного графа one to many, храню каждую вершину как json

https://docs.mongodb.com/manual/tutorial/model-tree-structures-with-materialized-paths/

выборки по path like '%SOME_NAME%'

А как он будет выглядеть примерно этот path?

по ссылке выше от yopp гляньте, там хорошие простые примеры

Как мне кажется проще и быстрей будет на обычном SQL. Две таблички - одну для хранения информации об узлах. А вторую для организации связи между узлами. Задача классическая и вроде бы все подводные камни известны.

Не надо свои предубеждения на других проецировать. Если вы советуете реляционное табличное хранилище, будьте добры аргументировать.

по ссылке выше от yopp гляньте, там хорошие простые примеры

Вижу, почитаю конечно, спасибо

Почитайте весь раздел: https://docs.mongodb.com/manual/applications/data-models-tree-structures

Почитайте весь раздел: https://docs.mongodb.com/manual/applications/data-models-tree-structures

Окей, я с монго вообще не работала до этого времени. Так что не только это надо)

Окей, я с монго вообще не работала до этого времени. Так что не только это надо)

А почему сейчас решили?

А почему сейчас решили?

Подумала графы хранить удобнее документом

Да и в целом монго интересен, nosql решения, редис и тд

Не надо свои предубеждения на других проецировать. Если вы советуете реляционное табличное хранилище, будьте добры аргументировать.

Давай-те аргументировать. Задача про деревья известна давно. Сильно раньше всяких SQL и тем более NoSQL. Отсюда вывод что на SQL ее решали сильно раньше и есть большие наработки и танцы на граблях. А значит возможно найти даже уже готовое решение. Отсюда и второй аргумент. Насколько я понимаю SQL более знаком чем NoSQL. Т.е. решать задачу на незнакомом языке явно будет дольше чем на знакомом. А какой-то специфики NoSQL я в этой задаче не вижу. Кроме разве "хранить в JSON"

А какие аргументы будут в пользу NoSQL?

Давай-те аргументировать. Задача про деревья известна давно. Сильно раньше всяких SQL и тем более NoSQL. Отсюда вывод что на SQL ее решали сильно раньше и есть большие наработки и танцы на граблях. А значит возможно найти даже уже готовое решение. Отсюда и второй аргумент. Насколько я понимаю SQL более знаком чем NoSQL. Т.е. решать задачу на незнакомом языке явно будет дольше чем на знакомом. А какой-то специфики NoSQL я в этой задаче не вижу. Кроме разве "хранить в JSON"

Для начала SQL это язык запросов, а не тип хранилища.

Если вы про диалект, то пожалуйста, приведите пример SQL выражений специально для деревьев, если он есть.

Вместе с примерами «граблей»

Если вы про реляционные табличные хранилища, то объясните, чем табличное представление деревьев выигрывает у документного.

Для начала SQL это язык запросов, а не тип хранилища.

Спасибо, кэп. А что такое тогда NoSQL ?

NoSQL это маркетинговый термин, не имеющий вообще никакого смысла.

Спасибо, кэп. А что такое тогда NoSQL ?

Отсутствие языка запросов, очевидно же!

NoSQL это маркетинговый термин, не имеющий вообще никакого смысла.

Странно. Я вот како-то больше привык таким образом разделять две больших группы баз данных.

Базы надо разделять по модели данных и свойствам.

Блочные, Key/Value, документные, табличные, графовые и т.д.

Табличные тоже разные бывают: строковые и колончатые.

Замечательно. Я тоже учился в университете.

Но вы так и не привели аргументов почему документная база данных лучше табличной для решения данной задачи.

Вы находитесь в группе про документное хранилище и это вы начали рекомендовать другую модель. Бремя доказательства «проще» лежит на вас.

Единственное логичное объяснение — имеющийся опыт.

Все остальные приведённые вами аргументы не выдерживают критики.

Все остальные приведённые вами аргументы не выдерживают критики.

Хорошо. Вот вам задача - написать рассказ "Как я провел лето". На выбор два языка русский и латынь. На котором будет проще написать рассказ?

С таким уровнем аргументации, вам в @ru_dba.

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

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

Угу. Втаскиваешь ты монгу в стек и в команду разработки где о ней никто не слышал и в руках не держал. И все такие ...

У нас как бы разговор не о сферических конях в вакууме. А о конкретной задаче и конкретном исполнителе этой задачи. Хорошо если это какой стартап или хоумпроект. А если промышленная разработка - то человеку надо будет еще аргументировать зачем нужна монга и почему нельзя это же сделать на имеющейся базе.

Угу. Втаскиваешь ты монгу в стек и в команду разработки где о ней никто не слышал и в руках не держал. И все такие ...

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

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

Угу. А кто-то очень хочет соскочить уже. ибо не хочет переучитваться.

без этого никак) лень она такая)))

Вы свой опыт проецируете на тысячу человек. Мне вот без разницы, что SQL, что монговский протокол. Более того, aggregation pipeline мне нравится гораздо больше огромных вложенных SQL выражений. Плюс он лучше читается и его проще поддерживать. Монга с 4.0 в вопросах поддержки целостности данных уже почти сравнялась с «SQL» хранилищами. Глобально не хватает только нативной поддержки foreign keys, но я практически на 100% уверен что к 5.0 и это тоже завезут.

Порог входа в монгу ниже чем в «SQL», её специально делали для разработчиков

Не надо покупать талмуд в две тысячи страниц про SQL

Операционно на рынке вообще аналогов нет. Монга работает по принципу «включил и забыл до первого терабайта»

Монга огонь. без вопросов

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

😂

а никто не видал конвертер синтаксиса AF в SQL?

Операционно на рынке вообще аналогов нет. Монга работает по принципу «включил и забыл до первого терабайта»

Верю. У нас вспомнили после 100 Гб. И админы завопили что надо уходить на постгрес, который они знают.

а потом на 1тб они завопили что места мало?)

а потом на 1тб они завопили что места мало?)

Нет. А сейчас оно на 300 Гб, практически не работает. ибо изначально проектировщики "монго это просто" налажали. И сейчас это уже практически не выгрести.

не выгрести 300гб?

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

но как обычно, стоит поглубже копнуть и там будет какой-то неудачный опыт

231.3 GB если быть точно.

Нет. А сейчас оно на 300 Гб, практически не работает. ибо изначально проектировщики "монго это просто" налажали. И сейчас это уже практически не выгрести.

покупайте подписку на https://db-ai.co/ и я вам помогу посчитать экономику и выгрести. невыгребаемого не бывает.

231гб данных это очень мало

но как обычно, стоит поглубже копнуть и там будет какой-то неудачный опыт

Опыт не очень удачный. Просто лет 7 назад одни к криками "это серебрянная пуля" пропихнули монгу. Другие с криками "мы это не будем поддерживать" уже лет 5 противятся какому-либо обновлению или еще чему-то. Они даже реплики поднять не могут.

так видите, 7 лет работает

)))

нет ничего более постоянного чем временное

вам стало больно, но при этом данные выросли в два раза и оно продолжает работать

в 2.313 если быть точно

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

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

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

ребят, подскажите работаю через драйвер mongo-go-driver потребовались сессии и транзакции: сделал реплика сет, из оболочки все работает, из кода падает с ошибкой server selection timeout куда копать?

проверить что connection uri правильно задан

и что у реплики реально есть праймари

и что все ноды видны из того места откуда соединяетесь

сделал пока только одну ноду она же primary, connection string не менял (порт телнетом открывается)

а.. когда когда делаем rs.initiate видимо нужно внешний адрес хоста указывать а не имя сервиса (в терминологии docker)?

то есть members:[{ ... "host":"mongo:27017" }] не покатит, правильно понимаю?

при условии, что тестовая программа пока стучится из вне (не находится в docker сети)

если хост докер контейнера не резолвится в сети приложения, то используйте адрес

@dd_bb да, заработало, спасибо, поставил пока внешний адрес

привет ребята внезапно появилась такая штука: 2|web | 2019-1-9 16:49:51 Query for DB: { '$where': 'this.following > this.followers / 2', 2|web | parsed: true, 2|web | taskIds: 5c33508094a60624baf2cf06 } 2|web | { MongoError: $where is not allowed in this context 2|web | at queryCallback (/root/bentogram/node_modules/mongodb-core/lib/cursor.js:248:25) 2|web | at /root/bentogram/node_modules/mongodb-core/lib/connection/pool.js:532:18 2|web | at args.(anonymous function) (/usr/lib/node_modules/pm2/node_modules/event-loop-inspector/index.js:138:29) 2|web | at _combinedTickCallback (internal/process/next_tick.js:132:7) 2|web | at process._tickDomainCallback (internal/process/next_tick.js:219:9) 2|web | ok: 0, 2|web | errmsg: '$where is not allowed in this context', 2|web | code: 2, 2|web | codeName: 'BadValue', 2|web | name: 'MongoError', 2|web | [Symbol(mongoErrorContextSymbol)]: {} }

почему ему вдруг перестало нравится $where?

npm модуль mongoose-paginate-v2 не давал

mongoose-paginate дает :(

Всем привет. http://dpaste.com/1TG876Y В чем может быть проблема? В 1 случае я поле is_subscription_active выношу в операции группировки и результатов нет, а во 2ом - я его добавляю в $addFields и выдает 1 запись.

В обоих вариантах в консоли is_subscription_active: true (boolean)

значит у вас $subscription.active = false

нет, я это проверял