"Картина следующая: вот вы тащите миллион записей из таблицы своей mongodb, потом второй миллион из другой таблицы, а потом на клиенте этим вашим джаваскриптом пытаетесь сами, на коленке хоть как-то сделать JOIN.
Во-первых вы гоняете кучу траффика, во-вторых убиваете CPU на клиенте. И главное, в-третьих — вы решаете проблему, с которой в реляционных базах данных блестяще разделались еще в 1980-х годах".
(с)
Replies (12)
-
@thefish, Тот кто это сказал, совершенно не понимает как работать с монгой. Там нет джойна, правда, потому что данные не нормализованы, но можно объявить таблицу как функцию и вызывать её, можно (нужно) использовать оператор агрегации $lookup, или DBRef.
И тот кто использует монгу, когда может использовать постгрес, тоже не понимает, как работать с монгой. Они не взаимозаменяемы./1 · Reply -
@thefish, ну а ты хочешь лампово джойнить потенциально разные по структуре данные и пить смузи?
-
@belsnickel, Я потенциально разные по структуре данные пакую в JSONB, индексирую если надо; а про монгу для хранения относительно важных данных года три как забыл (как про страшный сон).
А вот хипстеры на конференциях получают такие вот отповеди, как в /0 -
@thefish,
а про монгу для хранения относительно важных данных года три как забыл
Сейчас (после 3.6) монга вполне устойчива, штабильна, и шардится/реплицируется как никто больше.
Хотя раньше тоже жить можно было. -
@belsnickel,
шардится/реплицируется как никто больше
вот потому типичный юзкейс для монги — архив media-assets для партнеров, куда постфактум еще записываются всякие бизнес-показатели, типа CTR или времени экспозиции. Чтобы когда очередному менеджеру вздумается "А заебательский ролик у нас был в 2013 в черную пятницу, давайте повторим!" — не приходилось судорожно рыться в архивах почты в поисках видео для преролла.
т.е. быстро пухнущая файлопомойка со вспомогательными тегами, потенциально не влезающая на один сервер — для этого монго вполне ок. Для почти всего остального <strike>реляционная база</strike> postgres лучше. -
@thefish,
. Для почти всего остального <strike>реляционная база</strike> postgres лучше.
Мой кейс начала года: бухгалтерский онлайн-продукт, однотенантный, потому что юзеров овер 90000 — каждому бд не выдашь. Зато каждый юзер хочет кастомные документы и отчёты со своими полями, которые он будет менять как ему вздумается.
Любая реляционная база сразу сосёт. -
@belsnickel, т.е. по факту в базе хранились куски шаблонов для конечных пользователей?
Если их можно представить в JSON, то я бы все равно взял постгрес + прикрутил в коде валидацию и генерацию UI через JSON Schema. Т.к. считаю что целостность для бухгалтерии must have, и реляционнная база справится с этим гораздо лучше.
Но это я. -
@thefish,
т.е. по факту в базе хранились куски шаблонов для конечных пользователей?
Нет. Таблица = документ.
Если их можно представить в JSON, то я бы все равно взял постгрес + прикрутил в коде валидацию и генерацию UI через JSON Schema. Т
Я к Бартунову и Космодемьянскому приставал с json'ом, ДАЖЕ ОНИ не рекомендовали так делать.
-
@belsnickel, сильно зависит от размера шаблона.
Если не влезает в 4кб, емнип, то да, придется чесать репу