MP
там у него базы разные
Size: a a a
2019 May 31
IG
ну, если базы, тогда да.
MP
У меня, кстати, есть древний кейс как раз с такой ситуацией - в постгресе были юзера, потом их перетащили в монгу, но теперь при апдейтах приходится править и в постгресе тже, те поля которые там джойнятся 10 лет уже :)
MP
ну как бы да - немного гемора.
MP
Для всех, кто начинает юзать монгу, совет -
не увлекайтесь там использованием ObjectID
не увлекайтесь там использованием ObjectID
IG
По крайней мере на кложурных коллекциях клеить легче. Помню, на питоне такой же фигней страдали
MP
Да, еще полезно бывает помнить, что у компьютеров сейчас ОЗУ довольно дофига, и всяких там юзеров можно вообще всегда в памяти держать :)
MP
то есть весь подобный ворксет заведомо хорошо умещается в большой мапе.
MP
Если я правильно помню, то в свое время LinkedIn весь свой граф держал на большой машине в ОЗУ, чтобы считалось побыстрее.
Н
Да, еще полезно бывает помнить, что у компьютеров сейчас ОЗУ довольно дофига, и всяких там юзеров можно вообще всегда в памяти держать :)
VoltDB так и работает
IG
В одном проекте на серваке было 400 гиг памяти, в нем весь постгрес лежал.
IG
Скорость сумашедшая выходит, плюс привычный язык запросов
MP
ага, прикольно.
OR
первым вариантом. Джоины по айди очень, очень быстрые. В других вариантах будет 2 запроса, плюс ручная склейка данных. И еще базы не любят, когда в оператор in прилетает 1000 айдишников.
Это легко исправляется.
AB
Если стащить людей с Haskell или Scala на Go или Clojure, то у них несколько месяцев идёт ломка из-за того, что паззлы отобрали, приходится переучиваться получать удовольствие от настоящих результатов.
нет никакого "настоящего результата" у разработки.
любое удовольствие в процессе будет результатом той или иной игры.
любое удовольствие в процессе будет результатом той или иной игры.
AŽ
есть результат, есть система которая выполняет нужные функции
DB
Как смотрите на такой вариант организации запросов к бд на связанные между собой данные.
Самый простой пример: есть продукт с айди, названием, и айди пользователя. У пользователя есть имя. Необходимо вывести список продуктов в виде названое продукта - имя продавца.
Есть два очевидных варианта - делать джоин по юзер айди, либо же денонмализировать и хранить имя пользователя в таблице продуктов (понятно что в этом примере это не совсем уместно, но допустим что у нас много джоинов происходит)
И есть третий вариант, который я недавно услышал: сначала делать запрос на список продуктов, потом из этого списка выбрать айдишники пользователей и сделать второй запрос с этим списком айди на получение пользователей
Насколько третий вариант хорош, и какие могут быть с ним проблемы?
Самый простой пример: есть продукт с айди, названием, и айди пользователя. У пользователя есть имя. Необходимо вывести список продуктов в виде названое продукта - имя продавца.
Есть два очевидных варианта - делать джоин по юзер айди, либо же денонмализировать и хранить имя пользователя в таблице продуктов (понятно что в этом примере это не совсем уместно, но допустим что у нас много джоинов происходит)
И есть третий вариант, который я недавно услышал: сначала делать запрос на список продуктов, потом из этого списка выбрать айдишники пользователей и сделать второй запрос с этим списком айди на получение пользователей
Насколько третий вариант хорош, и какие могут быть с ним проблемы?
Все зависит от ситуации от размера данных. Если в обеих таблицах большое количество данных, да join будет очень тяжелый.
DB
Если очень много продуктов но мало пользователей, проще сделать join
DB
запрос по id за долесекунды будет выполнятьня. Если в обейх таблицах большое количество данных, подходит 3-вариант. Потому-что если пагинацией вытащить 100 продуктов, и сделать 100 запросов по айди на пользователей не займет много времени.
MP
Все зависит от ситуации от размера данных. Если в обеих таблицах большое количество данных, да join будет очень тяжелый.
я тут не понял, что означает "тяжелый джоин"?
как измеряется его тяжесть и по отношению к чему?
как измеряется его тяжесть и по отношению к чему?