LINUX.ORG.RU

ORM vs SQL

 ,


0

3

Регулярно читаю на форумах (в том числе и тут подобное встречаю), что ORM юзать не надо, что это оверхед, что Go без ORM отлично живёт, Gorm не нужен - и так про любой язык программирования.

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

Но приведу пример. У меня есть API-эндпоинт, возвращающий список некоторых сущностей. Там есть вариантов сортировки штук 10, штук 20-30 вариантов опциональной фильтрации и пагинация. Причём для некоторых вариантов фильтрации нужно делать дополнительные JOIN или подзапросы. Я это реализовал через Doctrine DBAL - и получилось довольно удобно и вполне читабельно. Генерируемый SQL-запрос оптимальный и вполне шустро работает.

Но вот чего понять не могу, неужели вы (при разработке без ORM и квери-билдеров) руками конкатенируете строку запроса? Если да, то как вы потом эту адскую лапшу кода разбираете и как контролируете, чтобы запрос не получился невалидным (где-то пробел забыли и т.п.)?

Хотелось бы услышать противников использования ORM и квери билдеров, как вы решаете такие задачи? И на что маппите результаты запросов? На обычные массивы, не на объекты?

Ответ на: комментарий от no-such-file

Если ты получаешь полный набор данных в один заход сложным запросом с кучей джойнов, а у тебя изменилось одно единственное поле (ник одного пользователя), то ты замахаешься делать логику изменения запроса так, чтобы получить только это поле без получения всего датасета. С ORM ты можешь вытянуть только то, что реально изменилось

Я прямо сейчас занимаюсь проектом, который очень близкую функцию выполняет. Одно из первых применений, которое я ему пророчу — это тот самый кэш объектов, который ты описываешь. Проблему с доступом к read-only хранилищам уже решила plasma, которая на Apache Arrow.

Основная проблема в сценарии, который ты описываешь — это толстый интерфейс между кодом, генерирующим конечный контент, и базой данных. Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД. Предлагаю тебе придумать, как ты будешь организовывать эффективное обнаружение изменений, если пользователей много и они достаточно часто меняют ники. То есть, тысячи пользователей, из которых десятки в день меняют ники. Тот же Youtube очень просто решил эту проблему, то есть — никак. Пользователям показывается тухлая инфа, которая когда-нибудь обновится.

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.

Получение полного датасета каждый раз - это долго. Даже если тебе нужно выполнить сложный запрос который не укладывается в ORM, лучше получить только ID (т.е. только данные из индекса) и потом через ORM вытянуть собственно нужные данные закэшировав объекты. (И есть шанс, что что-то уже будет в кэше, возможно даже всё)

А отдать данные с полного датасета пользователю в виде HTML — это типа быстро, что ли? Сделать «Select first 10...» намного быстрее напрямую из базы, чем ворошить кэш, например.

Если же у тебя большая часть обработки делается на бизнес-логике, а пользователю отдается малая доля инфы — то у тебя и основная база должна быть в бизнес-логике.

Без кэша объектов в каком-то виде получение объектов не имеет особого смысла. В десктоп приложениях объекты живут всё время его работы. Для веба нужно чтобы объекты выживали между http запросами всё время взаимодействия пользователей с приложением. Иначе не совсем понятно, чем плох обычный map по датасету

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

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД

Только на чтение.

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

Обновление выполняется через ORM же, т.е. ей всегда известно какая сущность обновилась и нужно перечитать (либо продублировать обновление в кэше).

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.

Можно и так, но чем это отменяет полезность ORM?

Сделать «Select first 10…» намного быстрее напрямую из базы, чем ворошить кэш, например

Если это быстрее, то тут скорее вопросы к реализации кэша.

no-such-file ★★★★★
()
Ответ на: комментарий от WitcherGeralt

Если набор данных является связной сущностью (объектом, стрцктурой), которая именно так и используется у тебя в бизнес-логике, то ты используешь ORM

Как по мне, то ORM проваливается сразу на элементарных вещах. Вот взять банальный select из одной таблицы. А что он собственно может вернуть? Да что угодно. Там может быть произвольный набор атрибутов, в том числе вычисляемых, под произвольными именами. Т.е. каждый запрос отображается в свой уникальный тип. И получается, что заранее спроектировать все классы на уровне декларативного описания таблиц и связей невозможно. А можно только натягивать сову на глобус с кучей ограничений. Поэтому ормы особо процветают в динамических языках, где можно как угодно вертеть типы на этомсамом. Но это все профанация.

bread
()
Ответ на: комментарий от byko3y

А отдать данные с полного датасета пользователю в виде HTML — это типа быстро, что ли?

Раз уж пошла такая пьянка, то ORM в принципе позволяет организовать отдачу только изменившегося контента.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Хэш-таблица, хранящая твои кэшированные объекты — это та же база данных. Ты просто создал вторую базу данных, как я уже написал, и делаешь запросы к ней, а не к основной СУБД

Только на чтение

Какое ж «только на чтение», если чуть ниже ты пишешь «Обновление выполняется через ORM»? Инвалидация кэша — это, по сути, замаскированное обновление.

С таким же успехом систему можно развернуть наоборот: сделать основное хранилище в памяти бизнес-логики, а реляционная база будет вспомогательынм хранилищем, обеспечивающим persistence. И тогда проблема с обновлением исчезает, потому что все обновления прежде всего проходят через бизнес логику.

Можно и так, но чем это отменяет полезность ORM?

Тем, что ORM становится второстепенным игроком. Я не могу ответить, почему ORM в таком случае бесполезна, но и пользы особой я тоже от нее не вижу.

Сделать «Select first 10…» намного быстрее напрямую из базы, чем ворошить кэш, например

Если это быстрее, то тут скорее вопросы к реализации кэша

Ну да, ты пишешь собственную СУБД на коленке.

Раз уж пошла такая пьянка, то ORM в принципе позволяет организовать отдачу только изменившегося контента

И как это будет масштабироваться? Я не спорю, что это возможно, но я думаю, что там уже на второй план отойдет и ORM, и готовые СУБД — настолько нестандартным будет полученное решение.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

А причём тут ссылка? /items?id-from=1234 давай и всё.

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

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)
Ответ на: комментарий от Legioner

А причём тут ссылка? /items?it-from=1234 давай и всё

Красивое решение, но... как это показать пользователю? Вот посмотри на LOR — здесь проблема никак не решена и тред бьется на равные страницы. Это сомнительное решение в плане удобства, но простое и понятное для пользователя: если сообщения были удалены, то тред уедет вверх, но чаще всего новые сообщения просто добавляются в конец.

Теперь мы перекраиваем ЛОР на страницы по датам. То есть, внизу для нашего треду будут кнопки:

[04 ноября 13:22 -- 18:01]  [04 ноября 18:13 -- 05 ноября 09:08] [05 ноября 09:26 -- ...] 

либо та же самая функция, но с надписями 1, 2, 3 — что вызовет неожиданное для пользователя поведение. На крайняк, даты можно поставить во всплывающие подсказки, а на самих кнопках будет 1,2,3.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

но и пользы особой я тоже от нее не вижу

А синхронизировать с БД всё это кто будет?

пишешь собственную СУБД на коленке

Скорее NUMA на коленке. А что есть готовые решения для веба?

И как это будет масштабироваться?

Гораздо лучше чем отдавание всего набора на каждый чих. Внезапно, но http имеет встроенные возможности кэширования get запросов.

настолько нестандартным будет полученное решение

Ну дык, стандартное индусы пишут. Сам знаешь, что получается.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

А синхронизировать с БД всё это кто будет?

Ты хочешь сказать, что какая-то там готовая ORM позволяет решить задачу такой синхронизации? Я не спорю, что формально это ORM, поскольку ORM — это вообще всё, что связывает объекты с реляционной базой. Правда, база под задачу в итоге может оказаться нереляционной, и тогда ORM уходит лесом.

пишешь собственную СУБД на коленке

Скорее NUMA на коленке

Не знаю, при чем тут NUMA.

А что есть готовые решения для веба?

В 2020 году на бэкэнд (не фулстэк) отправляют самых бездарных разрабов. Потому питон так популярен, потому популярны фреймворки, которые хотя бы как-то позволят заставить систему работать, даже если эту систему написала горилла Коко с IQ 70-95.

Решить задачу оптимальным способом, за минимальное время и с гарантиями надежности? Забей, этим никто не будет париться. Нет спроса — нет предложения.

Гораздо лучше чем отдавание всего набора на каждый чих. Внезапно, но http имеет встроенные возможности кэширования get запросов

Я никак не пойму, зачем тебе отдавать весь набор на каждый чих? Я уже написал, что мне кажется, что ты описываешь проблемы одного конкретного фреймворка, которых больше нигде нет. Например, на LOR-е никогда не нужно отдавать весь набор сразу: по запросу пользователь видит либо отдельно новости, либо раздел форума, либо тред (зачастую не весь тред, а только его часть), либо комменты/темы пользователя, либо результаты поиска. Где здесь нужно запрашивать все сущности? Где здесь пространство для оптимизации? Пользователей кэшировать? Так они уже в кэше базы, и их немного. Если выполнять запрос через JOIN, выдающий имя пользователя и аватар в одной строке с сообщением, то вся обработка произойдет внутри СУБД, с минимальными накладными расходами.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Если выполнять запрос через JOIN, выдающий имя пользователя и аватар в одной строке с сообщением

Чот слишком сложно. Лучше пусть орм сам что-нибудь придумает. Например, вытащит всех пользователей и все сообщения, а потом отфильтрует этот миллион объектов по id. Беспокоиться здесь не о чем, ведь есть же КЭШ!

anonymous
()
Ответ на: комментарий от dimuska139

В 2020 году на бэкэнд (не фулстэк) отправляют самых бездарных разрабов

Спасибо, дружище

Ты смеешься, а тем временем макаки из vk.com слили в интернет базу пользователей с паролями в plain text, и в числе слитых акков был мой. Назови мне проект, в котором на бэкэнде работают не полнейшие бездарности. Яндекс? Да. Рамблер? Вполне возможно. Кто еще?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Не в курсе) Просто я бэкендер и полнейшей бездарностью себя не считаю. А ты сам в чём специализируешься?

dimuska139 ★★
() автор топика
Ответ на: комментарий от dimuska139

Просто я бэкендер и полнейшей бездарностью себя не считаю

Может быть ты исключение. А может быть и нет. Я пока что не видел бездарностей, которые бы признавали, что они — бездарности. Как раз наоборот: чем ниже квалификация, тем выше самооценка.

А ты сам в чём специализируешься?

Ни на чем не специализируюсь, jack of all trades, master of none. Хотя на текущий момент кушать себе зарабатываю фронтендом.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Теперь вернемся к разбору сказанного по частям. Нахрена тебе кэш, если в одном сисколе от тебя лежит файловый кэш ОС с твоей базой? Ты же понимаешь, что ты создаешь вторую БД поверх основной?

Это когда такое было что база и сервис на одной физической машине?

anonymous
()
Ответ на: комментарий от byko3y

Как раз наоборот: чем ниже квалификация, тем выше самооценка.

Лол ;)

anonymous
()
Ответ на: комментарий от anonymous

Это когда такое было что база и сервис на одной физической машине?

О, бигтата потихоньку подключается к обсуждению. Что там, сколько у вас миллиардов пользователей в системе?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

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

В нереляционной базе и вообще в приложении всё равно есть какие-то логические отношения между сущностями. То что база не поддерживает реляционные запросы дело десятое. Более того, как раз претензии к «кривости» ORM часто в том, что запросы-де не оптимальные ибо вместо join оно лепит 100500 селектов по ID. Так, ска, это так специально и задумано, чтобы ORM не использовала реляционные запросы. Отношения между объектами реализуются уже после того как объекты получены в самой логике приложения. Хотите реляционные запросы к данным - делайте через билдер получение отчётов. ORM не для этого.

Где здесь нужно запрашивать все сущности

На странице у меня до 500 сообщений в которых т.ч. есть ники пользователей, аватары. На других форумах может быть ещё карма, лайки и 100500 всяких сущностей.

Если выполнять запрос через JOIN, выдающий имя пользователя и аватар в одной строке с сообщением, то вся обработка произойдет внутри СУБД, с минимальными накладными расходами

Блажен, кто верует, ага. А тебе говорю, что запросить один изменившийся ник по ID всегда будет быстрее чем гонять каждый раз запрос с джойном на 500 записей. Даже без кэша, а из той же базы.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от byko3y

Что там, сколько у вас миллиардов пользователей в системе?

Да любая компания, у нее база отдельно стоит.

На той же машине база может стоят если это только единичное приложение в одном экземпляре. Т.е. никакого fault tolerance.

В большинстве компаний база одна а окружающих сервисов много. Если бы какой сервис был бы на той же машине то он мог утилизировать все ресурсы и база перестала бы откликаться. Это бы парализовало работу всех сотрудников. А так даже круды запускаются в нескольких экземплярах для того чтоб разгрузить нагрузку, используется лоад балансер и рабочие места раскидываются по инстансам.

anonymous
()
Ответ на: комментарий от byko3y

Ну вот ты пишешь «В 2020 году на бэкэнд (не фулстэк) отправляют самых бездарных разрабов». А, между тем, ты ж не будешь спорить с тем, что опытный фронтендер или опытный бэкендер в своей отрасли будут в большинстве случаев более опытными, чем фулстек. Потому что, будучи фулстеком, невозможно уделить должное внимание и бэку, и фронту, т.к. эти направления довольно активно развиваются. Просто времени и сил не хватит уделять должное внимание и тому, и другому.

dimuska139 ★★
() автор топика
Ответ на: комментарий от no-such-file

претензии к «кривости» ORM часто в том, что запросы-де не оптимальные ибо вместо join оно лепит 100500 селектов по ID. Так, ска, это так специально и задумано, чтобы ORM не использовала реляционные запросы. Отношения между объектами реализуются уже после того как объекты получены в самой логике приложения

А, так вот оно что. Я же думла, что там, как в джанге и рельсах, есть инструменты для описания связей. А оказывается, что простые пути нам не нужны.

Но расскажи мне все-таки, как у вас там на современных технологиях работают с сырыми выдачами, в которых миллионы сущностей? Или все-таки переносят логику на сервер, ограничивая кол-во выдаваемых записей во всех запросах?

На странице у меня до 500 сообщений в которых т.ч. есть ники пользователей, аватары. На других форумах может быть ещё карма, лайки и 100500 всяких сущностей

Не знаю других, если хочешь о каком-то поговорить — называй конкретно. На лоре есть аватар с достаточно простым ID, есть логин, есть карма. Это очень малое кол-во информации по сравнению с текстом самого треда. Самые частоиспользуемые сущности СУБД кэширует, а это пользователи и популярные треды, потому никаких проблем с производительностью при запросе этих сущностей на стороне БД не будет.

byko3y ★★★★
()
Ответ на: комментарий от anonymous

Да любая компания, у нее база отдельно стоит

ФСЕ ТАК ДЕЛАЮТ Я ТОЖЕ ДЕЛАТЬ БУДУ.

На той же машине база может стоят если это только единичное приложение в одном экземпляре. Т.е. никакого fault tolerance

Пф-ф-ф, делай зеркало.

В большинстве компаний база одна а окружающих сервисов много. Если бы какой сервис был бы на той же машине то он мог утилизировать все ресурсы и база перестала бы откликаться

Да, такое бывает, что админ/разрабы вчера линукс первый раз себе поставили, а сегодня на нем крупный сервис обслуживает. Я присутствовал при таком лично, там очередь положила сервак.

byko3y ★★★★
()
Ответ на: комментарий от no-such-file

Блажен, кто верует, ага. А тебе говорю, что запросить один изменившийся ник по ID всегда будет быстрее чем гонять каждый раз запрос с джойном на 500 записей. Даже без кэша, а из той же базы.

Специально сейчас проверил на небольшой таблице с 600к строчками. Выборка с джойном на 1000 записей отработала за 4мс, а выборка одной записи из второй таблицы по id связи - за 0.06 мс . Стало быть, так и есть. Правда если кеш чист, а запросы к базе синхронные, то хз, как там будет.

dimuska139 ★★
() автор топика
Ответ на: комментарий от byko3y

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

Именно что есть инструмент отдельный от базы. Т.о. реляционность базы на самом деле для ORM не важна. Она нужна только для того, чтобы извлечь такие связи автоматически, но можно и руками описать отношения сущностей. В т.ч. используя более сложную логику чем просто реляции. Поэтому

может оказаться нереляционной, и тогда ORM уходит лесом

лесом идёшь ты.

Это очень малое кол-во информации по сравнению с текстом самого треда

А как ты получишь отдельно ник без текста и без ненужных строк, если у тебя один рукописный (пусть даже через билдер) запрос с джойнами на всё вместе?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от dimuska139

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

Бездарная макака, даже имея 5 лет опыта за плечами, будет клепать говно 5 лет спустя. Даже прочитав гору книжек и освоив кучу паттернов программирования. Я просто охренел однажды, когда «опытный бэкендер» с удивлением посмотрел на ответ DNS, и спросил «а чойта?». Он годами месил говно в своей узкой специализации, чтобы по щелчку хлыста выдавать что-то более-менее работоспособное, при этом он не способен ни шагу сделать в сторону, не может изучить ничего над и под.

Потому что, будучи фулстеком, невозможно уделить должное внимание и бэку, и фронту, т.к. эти направления довольно активно развиваются. Просто времени и сил не хватит уделять должное внимание и тому, и другому

Да, при прочих равных нельзя изучить обе стороны так же хорошо, как одну, за то же время. С другой стороны, отдельные персонажи настолько бездарны, что даже если им дашь половину сервера под разработку — они выдадут результат хуже, чем грамотный фуллстэк.

byko3y ★★★★
()
Ответ на: комментарий от dimuska139

Стало быть, так и есть

Это как бы очевидно. Просто потому что объём передаваемых данных отличается в разы.

Правда если кеш чист, а запросы к базе синхронные, то хз, как там будет

Всё также будет. Потому что базе тоже проще кэшировать 1000 одинаковых элементарных запросов с одинаковыми параметрами, чем 10 разных запросов с меняющимися данными.

no-such-file ★★★★★
()
Ответ на: комментарий от dimuska139

Выборка с джойном на 1000 записей отработала за 4мс, а выборка одной записи из второй таблицы по id связи - за 0.06 мс . Стало быть, так и есть. Правда если кеш чист, а запросы к базе синхронные, то хз, как там будет

Ты здесь не учитываешь времени работы кэша бизнес-логики. Запрос по join не требует никакой дальнейшей обработки вообще.

byko3y ★★★★
()
Ответ на: комментарий от no-such-file

Именно что есть инструмент отдельный от базы

Это инструменты для описания формируемых запросов. Foreign key, таблица для связей many-to-many — вот это всё там есть.

может оказаться нереляционной, и тогда ORM уходит лесом

лесом идёшь ты

По условиям сервер БД теряет функцию центрального хранилища, потому ему не обязательно быть реляционным.

А как ты получишь отдельно ник без текста и без ненужных строк, если у тебя один рукописный (пусть даже через билдер) запрос с джойнами на всё вместе?

Почему один запрос, и зачем один ник?

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Запрос по join не требует никакой дальнейшей обработки вообще

Запрос тупо по id тоже не требует никакой обработки на сервере. Отдаём клиенту объект, пусть рендерит как хочет.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Запрос тупо по id тоже не требует никакой обработки на сервере. Отдаём клиенту объект, пусть рендерит как хочет

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

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Это инструменты для описания формируемых запросов

Это инструменты описания отношений. Запросы можно разные генерировать.

таблица для связей many-to-many

А что в nosql запрещено делать документы someid<->otherid?

Почему один запрос, и зачем один ник?

Почему ты включаешь дурачка?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Это инструменты для описания формируемых запросов

Это инструменты описания отношений. Запросы можно разные генерировать

Скриптовые языки работают сильно медленнее СУБД. Можно руками наговнокодить связь, но штатные инструменты фреймворков превращают связи именно в запросы с join.

А что в nosql запрещено делать документы someid<->otherid?

Нет. А я что, спорю? Это я, между прочим, первым начал писать о том, что SQL СУБД не обязательна.

Почему один запрос, и зачем один ник?

Почему ты включаешь дурачка?

Еще раз: мне кажется, что ты знаешь единственный фреймворк и через него смотришь на веб разработку. Из-за чего очевидные и однозначные для тебя вещи мне ни разу не очевидны и не однозначны.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Да любая компания, у нее база отдельно стоит ФСЕ ТАК ДЕЛАЮТ Я ТОЖЕ ДЕЛАТЬ БУДУ.

А ты не догадаешься почему всем наплевать на unix сокеты и многих устраивать tcp оверхед на loopback?

Зеркало будет всегда не актуально, а база у средних компаний одна, она является single point of truth для всех приложений. Переключишь на зеркало и привет исчезновение записей, дубликаты после попытки синхронизировать последние изменения.

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

У тебя нет опыта работы в обычной компании для которой база это часть бизнес процесса.

anonymous
()
Ответ на: комментарий от byko3y

штатные инструменты фреймворков превращают связи именно в запросы с join

Нет. Только если специально об этом попросить. По-умолчанию любой нормальный фреймворк делает отдельные селекты. И каждый раз макаки-школьники высирают кирпичи по этому поводу «ниэффикивна!».

Из-за чего очевидные и однозначные для тебя вещи мне ни разу не очевидны и не однозначны

Это из-за того, что у тебя нет целостной картины и понимания как всё устроено. Все веб-фреймворки +- вид сбоку, так что претензия странная.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

По-умолчанию любой нормальный фреймворк делает отдельные селекты

Ну да, а потом мартыхи бегают как усратые решая проблему N+1. Ты гладко стелишь делая вид, что объекты в твоем скриптовом язычке бесплатные. А между тем фонтанирующий объектами орм это как раз главный источник тормозов и выжирания памяти на бэкенде.

anonymous
()
Ответ на: комментарий от anonymous

решая проблему N+1

С дуру можно и хер сломать.

гладко стелишь делая вид, что объекты в твоем скриптовом язычке бесплатные

Гораздо более «бесплатные», чем в нескриптовом. Просто потому что в скриптовом всё что угодно - жирное, забоксенное и неявный объект.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

anonymous
()
Ответ на: комментарий от anonymous

А ты не догадаешься почему всем наплевать на unix сокеты и многих устраивать tcp оверхед на loopback?

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

Зеркало будет всегда не актуально, а база у средних компаний одна, она является single point of truth для всех приложений. Переключишь на зеркало и привет исчезновение записей, дубликаты после попытки синхронизировать последние изменения

Сейчас бы не знать про синхронную репликацию.

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

Когда макакины поделки сталкиваются с серьезными сбоями и необходимостью восстанавливать базу из бэкапа, потому что какой-то багованный сервис за полдня испортил терабайт данных, то их 24/7 ложится на несколько дней, в лучшем случае переходя на read-only доступ, потому что у них нет возможности переноса базы в онлайне. Реально надежные и бесперебойные сервисы имеют единицы компаний в мире, в число которых входит фейсбук, нетфликс, яндекс, и еще несколько. Всё остальное — это карго культ, аборигены, измазанные в краске, марширующие вокруг соломенных самолетов в подражании белым людям с материка.

У тебя нет опыта работы в обычной компании для которой база это часть бизнес процесса

И еще я живу на марсе. Вроде всё перечислили.

byko3y ★★★★
()
Ответ на: комментарий от no-such-file

Нет. Только если специально об этом попросить. По-умолчанию любой нормальный фреймворк делает отдельные селекты. И каждый раз макаки-школьники высирают кирпичи по этому поводу «ниэффикивна!»

Да, это правда, как минимум для джанги:

https://docs.djangoproject.com/en/3.1/topics/db/optimization/#retrieve-everyt...

Это из-за того, что у тебя нет целостной картины и понимания как всё устроено. Все веб-фреймворки +- вид сбоку, так что претензия странная

И поэтому тебе можно уходить от ответа?

byko3y ★★★★
()
Ответ на: комментарий от anonymous

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

Шаришь, анон. Давай создадим два блога: я буду рассказывать в своем, как ты крут, а ты будешь рассказывать в своем, как я крут. Успех обеспечен — топ индусов с апворка так и работают.

Единственное, с чем я не готов согласиться — это что реляционки не нужны. Все-таки реляционки, зачастую — это самая эффективная для переиспользования модель. Даже если у тебя key-value хранилище. Та же монга в итоге на реляционной WiredTiger бегает. Не нужен именно SQL, поскольку в большинстве случаев этот интерфейс не подходит для задачи.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Сейчас бы не знать про синхронную репликацию.

Итак wiki:

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

У тебя транзакция пройдет только после того как данные попадут на другой инстанс базы, это тот же самый оверхед что и доступ к базе по сети, даже больше. Ну уж теперь то нам нужен кеш объектов товарищ «Архитектор»? :)

anonymous
()
Ответ на: комментарий от anonymous

У тебя транзакция пройдет только после того как данные попадут на другой инстанс базы, это тот же самый оверхед что и доступ к базе по сети, даже больше. Ну уж теперь то нам нужен кеш объектов товарищ «Архитектор»?

У тебя цена записи как при доступе на удаленный сервер, а цена чтения — как на локалхост. Как правило, в веб сервисах чтений больше, чем записей.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

У тебя цена записи как при доступе на удаленный сервер, а цена чтения — как на локалхост. Как правило, в веб сервисах чтений больше, чем записей.

Интересный подход. Я не задумался в отношении реляционных баз. Но если взять mongo то очень похожее можно получить почти из коробки.

Не помню чтоб реляционных СУБД такое поддерживали, тут я пасс, не имею компенсаций. Я бы просто взял монго. Мне правда по работе такое не нужно, тут в базу пишут интенсивно.

anonymous
()
Ответ на: комментарий от anonymous

s/компенсаций/компетенций/g

anonymous
()
Ответ на: комментарий от anonymous

Я бы просто взял монго. Мне правда по работе такое не нужно, тут в базу пишут интенсивно

Смысл монги заключается в том, что мы сваливаем сырые данные в кучу, чтобы потом когда-нибудь их обработать, то есть, добавить индексы или прямо во время сложного запроса на чтение перелопатить всю базу по заданному критерию. Очевидная проблема — за быструю запись расплачивается читатель. И да, это может быть удобно, когда записей много, а чтений — мало.

Однако, как правило, монгу берут те, кто ничего не понимает в СУБД и веб разработке — тупо за то, что она не требует проектирования структуры БД. Мол «по ходу дела разберемся — удобно, молодежно, agil-но». Им невдомек, что с базой без определенной структуры работать сложнее, чем при наличии этой самой структуры.

Сейчас, правда, хайп пошел на спад и намного меньше проектов стартует на монге.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

, добавить индексы или прямо во время сложного запроса на чтение перелопатить всю базу по заданному критерию. Очевидная проблема — за быструю запись расплачивается читатель.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Да, это она и есть. Проблема только в том, что когда ты включаешь подобный режим, то в итоге твоя БД мало чем отличается от реляционных SQL баз. Тот же постгрес умеет быть очень близким по поведению и интерфейсу к монге.

byko3y ★★★★
()

Для попытки выбрать из альтернативных решений с разными сильными сторонами одно для всех случаев есть название - профнепригодность. Ты привёл подходящий кейс для ORM. Есть кейсы где ORM сливает. Используй ORM для первых, не используй для вторых. Это слишком сложная мысль?

slovazap ★★★★★
()
Ответ на: комментарий от byko3y

Я подумал и таки да, идя с синхронной репликой базы и сервисом на одной машине интересная, используем unix сокеты и вообще смысл кеша объектов уходит.
Для условной «доски объявлений», магазина, или любого сервиса где приходится чаще отдавать данные чем принимать это будет работать и фактически мы получаем high availability сервис.

Но… я не помню чтоб где-то рассказывалось как постгрис подготовить быть репликой на горячую. Ведь перед отправкой изменений в новую реплику она уже должна быть синхронизирована. По-моему это очень сложно проделать.

Если взять какую-нибудь модную БД, та же mongodb, она умеет синхронизировать инстансы самостоятельно, с ней управлять синхронной репликой будет наверно значительно проще.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.