AK
а ещё нужно передавать условия соединения в каждом запросе помимо самих условий
Size: a a a
2020 December 22
W
allter
Суммарная нагрузка на БД в условных попугаях да, больше. Но при джойне в приложении, во-первых, нет большой зависимости от планировщика запроса. Поэтому меньше вероятность того, что под нагрузкой сам запрос начнет выполняться существенно большее время (что при одинаковой нагрузке означает существенно бОльшую единовременную нагрузку на СУБД и накладные расходы). Во-вторых появляется гибкость в размещении связанных данных (например, для них можно реализовать другую стратегию шардирования, реплицировать по-другому и т.д). В пределе это все стремится к NoSQL и т.п.
Простейший джоин планируется где-то в течении 2мс для пг. И планировщик изолирован в вашем процессе. Выполнение запроса детерменированно и на него влияют только внешние факторы (загрузка базы).
В случае если у вас данные все в одной базе джоин надо делать на стороне субд.
Ваше во-вторых говорит о том что вы или не прочитали или не поняли моего поста, так как вы вшли за его рамки и начали капитанить.
В случае если у вас данные все в одной базе джоин надо делать на стороне субд.
Ваше во-вторых говорит о том что вы или не прочитали или не поняли моего поста, так как вы вшли за его рамки и начали капитанить.
a
Простейший джоин планируется где-то в течении 2мс для пг. И планировщик изолирован в вашем процессе. Выполнение запроса детерменированно и на него влияют только внешние факторы (загрузка базы).
В случае если у вас данные все в одной базе джоин надо делать на стороне субд.
Ваше во-вторых говорит о том что вы или не прочитали или не поняли моего поста, так как вы вшли за его рамки и начали капитанить.
В случае если у вас данные все в одной базе джоин надо делать на стороне субд.
Ваше во-вторых говорит о том что вы или не прочитали или не поняли моего поста, так как вы вшли за его рамки и начали капитанить.
A) мы говорили про mysql. Postgresql получше и в использовании индексов.
B) и что, статистика по конкретным данным в этот детерминизм не входит?
C) Денормализацию данных наружу СУБД я сам упомянул в этом треде чуть выше, так что это контекст треда.
B) и что, статистика по конкретным данным в этот детерминизм не входит?
C) Денормализацию данных наружу СУБД я сам упомянул в этом треде чуть выше, так что это контекст треда.
W
А) Согласен. Не селен в планировщике мускуля. Он там вообще есть?..
В) Не входит по идеи. На основании ее план уже построен и она не нужна.
С) И я специально обговорил условия при каких мои аргументы верны. Если вы отбрасываете границы применимости то дискуссия невозможна из-за нарушения правил формальной логики.
В) Не входит по идеи. На основании ее план уже построен и она не нужна.
С) И я специально обговорил условия при каких мои аргументы верны. Если вы отбрасываете границы применимости то дискуссия невозможна из-за нарушения правил формальной логики.
a
A) Есть конечно, но куча нюансов и ограничений, происходящих от ограничения одного индекса на таблицу.
B) Ну, вот, не знаю, как в постгресе планировщик работает, а вот с ораклом я этой идеей наелся. Однажды план решил перестроиться в 2 ночи, в результате забавно (нет) было спросонья пытаться понять, почему на сравнительно небольшом трафике система полностью "легла".
B) Ну, вот, не знаю, как в постгресе планировщик работает, а вот с ораклом я этой идеей наелся. Однажды план решил перестроиться в 2 ночи, в результате забавно (нет) было спросонья пытаться понять, почему на сравнительно небольшом трафике система полностью "легла".
W
Это нормально. Ну то есть нет, но да... В том смысле что статтстика поменялась и план начал строиться по другому
AP
allter
A) Есть конечно, но куча нюансов и ограничений, происходящих от ограничения одного индекса на таблицу.
B) Ну, вот, не знаю, как в постгресе планировщик работает, а вот с ораклом я этой идеей наелся. Однажды план решил перестроиться в 2 ночи, в результате забавно (нет) было спросонья пытаться понять, почему на сравнительно небольшом трафике система полностью "легла".
B) Ну, вот, не знаю, как в постгресе планировщик работает, а вот с ораклом я этой идеей наелся. Однажды план решил перестроиться в 2 ночи, в результате забавно (нет) было спросонья пытаться понять, почему на сравнительно небольшом трафике система полностью "легла".
потому, что статистику надо вовремя обновлять.
AP
у оракла лучший оптимизатор запросов, что я знаю.
AP
у мускуля "простейший" оптимизатор запросов. но он есть и что-то умеет. просто в сложных запросах, когда уже "внутренний вью" создаются, то внезапно у них нет индексов и там начинаются чудеса. впрочем, я уже лет 5 с ним дел не имел
AP
у постгреса что-то среднее между ораклом и мускулем.
AP
у постгреса другие залипухи есть, как то хреновая оптимизация физического доступа, которая у мыскуля как раз получше
a
потому, что статистику надо вовремя обновлять.
Не очень понял, как это поможет. Днём один профиль запросов, ночью немного другой.
Как раз те DBA, которые ратуют за джойны внутри БД, обычно также всячески противятся использованию хинтов (типа, планировщику виднее). Но вот как надёжно при этом избежать ситуации подобной моей, не говорят.
Как раз те DBA, которые ратуют за джойны внутри БД, обычно также всячески противятся использованию хинтов (типа, планировщику виднее). Но вот как надёжно при этом избежать ситуации подобной моей, не говорят.
AP
allter
Не очень понял, как это поможет. Днём один профиль запросов, ночью немного другой.
Как раз те DBA, которые ратуют за джойны внутри БД, обычно также всячески противятся использованию хинтов (типа, планировщику виднее). Но вот как надёжно при этом избежать ситуации подобной моей, не говорят.
Как раз те DBA, которые ратуют за джойны внутри БД, обычно также всячески противятся использованию хинтов (типа, планировщику виднее). Но вот как надёжно при этом избежать ситуации подобной моей, не говорят.
про хинты верно, лучше их избегать, хотя я сам грешен, часто пользовался. лучше настроить статистику правильно, нужные индексы построить и пр пр пр.
AP
на счёт "джойны внутри дб" — это верно. лучше их там и делать. исключения редки, но бывают. типа, когда ты точно знаешь, что часть дб может поместиться в рам и ты сам сделаешь ручную оптимизацию запроса в своём алгоритме, не полагаясь на дб. такое бывает, но редко и в общем случае, скорее, вредно.
АК
Кто-нибудь знает, как работает база данных в облаке Telegram?
Почему есть фильтр по медиа, цепочки ответов (треды), поиск по любым словам где угодно…
Почему есть фильтр по медиа, цепочки ответов (треды), поиск по любым словам где угодно…
a
Почему? Ну, наверное, какие-то программисты реализовали такую логику.
VG
Кто-нибудь знает, как работает база данных в облаке Telegram?
Почему есть фильтр по медиа, цепочки ответов (треды), поиск по любым словам где угодно…
Почему есть фильтр по медиа, цепочки ответов (треды), поиск по любым словам где угодно…
шо значит почему? потому что Дуров поставил таску, очевидно
АК
@nuclight,
ВОТ И ВСЁ
from their main connection
Client apps must not accept updates from CDN DCs (apps should only accept updates from their main connection to the master DC).ВОТ И ВСЁ
from their main connection
VG
@nuclight,
ВОТ И ВСЁ
from their main connection
Client apps must not accept updates from CDN DCs (apps should only accept updates from their main connection to the master DC).ВОТ И ВСЁ
from their main connection
эхой ошибся