Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Интересный взгляд на проблему сравнения  [new]
Andrey Sribnyak
Member

Откуда: Киев
Сообщений: 592
https://habr.com/ru/company/lsfusion/blog/463095/
19 авг 19, 15:50    [21952626]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48441

Типичный хабаровский бред.

Posted via ActualForum NNTP Server 1.5

19 авг 19, 16:11    [21952637]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28212
Dimitry Sibiryakov,

гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут".
20 авг 19, 00:57    [21952998]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
kdv
Dimitry Sibiryakov,

гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут".


Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)?
20 авг 19, 09:37    [21953070]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
KreatorXXI
Member

Откуда: Москва
Сообщений: 812
Nitro_Junkie
kdv
Dimitry Sibiryakov,

гм, в разделе "Плохая оптимизация OR" - сначала он строит 4 странных композитных индекса, которые, как ему кажется, "должны работать" (вместо четырех одиночных по столбцам a, b, c, d), а потом удивляется, почему оптимизаторы "их не берут".


Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)?


Только его запрос не про это. Это передёргивание. Есть запрос и есть индексы, которые запрос не использует. А виноват сервер.
Я думаю, программисты, занимающие планировщиком SQL-запросов сервера, делают всё возможное. Но человек, который создаёт схему данных и т.д., должен же себе отдавать отчёт, что он хочет.
20 авг 19, 10:08    [21953085]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
KreatorXXI
Nitro_Junkie
пропущено...


Чем четыре одиночных индекса по столбцам тут должны помочь? Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при двух индексах (a) и (b)?


Только его запрос не про это. Это передёргивание. Есть запрос и есть индексы, которые запрос не использует. А виноват сервер.
Я думаю, программисты, занимающие планировщиком SQL-запросов сервера, делают всё возможное. Но человек, который создаёт схему данных и т.д., должен же себе отдавать отчёт, что он хочет.


Там достаточно простой тезис. SQL сервера выполняют логические условия как есть, не пытаясь особо их оптимизировать. То есть как и в остальных пунктах перекладывая задачу оптимизации на разработчика, тем самым повышая трудозатраты и порог вхождения. А заодно и риск выстрелить себе в ногу.
20 авг 19, 10:13    [21953091]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10025
Nitro_Junkie,

вовсе не обязательно. Они пытаются сделать всё что можно.

З.Ы. Читал статью. Такое ощущение что автор старается сделать себе больно специально. Те кто понимают как работает конкретная СУБД никогда не будут писать так как описано в статье. Да это может сделать нечаянно некая ORM, но никак не вменяемый разработчик пишущий прямые SQL запросы.
20 авг 19, 11:59    [21953260]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
Симонов Денис
Nitro_Junkie,

вовсе не обязательно. Они пытаются сделать всё что можно.

З.Ы. Читал статью. Такое ощущение что автор старается сделать себе больно специально. Те кто понимают как работает конкретная СУБД никогда не будут писать так как описано в статье. Да это может сделать нечаянно некая ORM, но никак не вменяемый разработчик пишущий прямые SQL запросы.


Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит.
20 авг 19, 12:10    [21953280]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48441

Nitro_Junkie
Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при
двух индексах (a) и (b)?

А Вы понимаете, что AND и OR это две очень большие разницы?

Posted via ActualForum NNTP Server 1.5

20 авг 19, 12:49    [21953346]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Vladimir Baskakov
Member

Откуда:
Сообщений: 1991
автор
При этом речь в статье пойдет не о «вкусах и цветах фломастеров». Все затрагиваемые проблемы носят фундаментальный характер: присутствуют при разработке практически любой информационной системы и не ограничиваются «красотой кода», а в той или иной степени приводят либо к критическому падению производительности, либо к существенному росту порога вхождения, либо к значительным трудозатратам со стороны разработчика..


ну, я я как то не дочитал, а там альтернатива, в которой фундаментальных проблем меньше, представлена? То есть не этих нет, а во всех отношениях лучше и удобнее?
20 авг 19, 12:56    [21953356]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
witte
Member

Откуда:
Сообщений: 325
Nitro_Junkie
Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит.

Если это была попытка набросить на вентилятор - то Ок, принимается :-)
А если сказано всерьез, то гнать такого разработчика нужно несвежими носками подальше от сервера СУБД. Во всяком случае от продуктивной среды.
20 авг 19, 13:48    [21953434]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10025
Vladimir Baskakov,

ну в статье явного указания на альтернативу нет, но если присмотреться, то они пиарят некий lsFusion
20 авг 19, 13:54    [21953445]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
Dimitry Sibiryakov
Nitro_Junkie
Вы же понимаете что найти a=5 AND b=6 при индексе по (a,b) можно гораздо быстрее, чем при
двух индексах (a) и (b)?

А Вы понимаете, что AND и OR это две очень большие разницы?


К чему вы это? Там в разделе достаточно подробно расписано, как запрос надо оптимизировать, чтобы он быстро выполнялся. И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись.
20 авг 19, 14:33    [21953484]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
witte
Nitro_Junkie
Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит.

Если это была попытка набросить на вентилятор - то Ок, принимается :-)
А если сказано всерьез, то гнать такого разработчика нужно несвежими носками подальше от сервера СУБД. Во всяком случае от продуктивной среды.


Где же вы столько "правильных" разработчиков найдете? Не, я понимаю если вы работаете по найму, дефицит разработчиков может быть выгоден, но если вы заказчик или подрядчик, все с точностью наоборот.
20 авг 19, 14:39    [21953490]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Бумбараш
Member [заблокирован]

Откуда: никем не победимая, самая любимая
Сообщений: 2320
Dimitry Sibiryakov
Типичный хабаровский бред.


сказал человек с форума где 90% тем это "как мне правильно сделать Merge"
20 авг 19, 15:40    [21953565]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34512
Dimitry Sibiryakov
Типичный хабаровский бред.



Это же "Блог компании lsFusion", его пишут чтобы поднять статус компании, получить известность.

Статья действительно ну...как бы бесполезная, не чтобы прочиьать, а чтобы НАПИСАТЬ.
20 авг 19, 16:34    [21953637]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34512
Бумбараш
Dimitry Sibiryakov
Типичный хабаровский бред.


сказал человек с форума где 90% тем это "как мне правильно сделать Merge"


Гы, он-то чем виноват, что он с этого форума?

Дмитрий в общем -- хороший специалист, грамотный.
20 авг 19, 16:36    [21953640]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 48441

MasterZiv
он-то чем виноват, что он с этого форума?

Меня больше заинтересовал вопрос какой именно из обитаемых мною форумов Бумбараш посчитал
так, что 90% топиков получилось про Merge. bid 3?..

Posted via ActualForum NNTP Server 1.5

20 авг 19, 16:45    [21953653]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
Dimitry Sibiryakov
MasterZiv
он-то чем виноват, что он с этого форума?

Меня больше заинтересовал вопрос какой именно из обитаемых мною форумов Бумбараш посчитал
так, что 90% топиков получилось про Merge. bid 3?..


Да ладно. Тут большую часть топиков почитаешь, так люди nested loop join от hash join'а не отличают, какой нафиг join predicate push down.
20 авг 19, 17:10    [21953681]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10025
Nitro_Junkie
Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит.


Если ты разрабатываешь под конкретную СУБД, то должен знать её хотя бы на среднем уровне.
В конце концов запросы проверяются, можно посмотреть планы, переписать запросы, создать индексы и т.д.
В целом ещё не было ни одного случая, чтобы не находилось решения которое устраивает по быстродействию.
И кстати nested loop join это не всегда плохо.

Если делаешь сразу под несколько СУБД что-то сложное, то скорее всего нормально не будет работать ни в одной.
20 авг 19, 21:57    [21953834]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Бумбараш
Member [заблокирован]

Откуда: никем не победимая, самая любимая
Сообщений: 2320
Симонов Денис
И кстати nested loop join это не всегда плохо.

А вы, кстати, зачем это сказали?
21 авг 19, 00:57    [21953899]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Симонов Денис
Member

Откуда: Рязань
Сообщений: 10025
Бумбараш,

статью что читал?
21 авг 19, 06:50    [21953920]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

Откуда:
Сообщений: 761
Nitro_Junkie
Так откуда разработчик должен знать что умеет оптимизировать конкретная СУБД или нет. Во-первых, это параметр изменяющийся во времени, а во-вторых, весь смысл оптимизаторов в том, чтобы не знать как они работают. Иначе нахрена они нужны, если я захочу все сделать руками, я сделаю это на ассемблере. Правда только совсем глупый работодатель это оплатит.

В теме по MS SQL посоветовали материализацию count(*) на млрд записях, ранее заявленную как круто работающую, сделать в пару слегка неадекватных прыжков. Откуда разработчик должен знать о том, как работает данных фреймворк и что надо так глумиться над ним?
И вооще, фреймворки/ОРМ - штука на порядок более распространенная ввиду того, что множество неосиливших SQL огромно и почти каждый из этого множества считает своим долгом запилить свой мегафреймворк для "вааще любой СУБД". А раз распространенная, значит и существенно чаще утилизируемая.
А вот работодателю интересно подсадить работника на уникальный с минимальным количеством вакансий фреймворк, чтобы он потом не сбежал куда, где кормят лучше. Ибо нахрен не нужен спец, который хорошо знает что-то никому никуда не упирающееся...
21 авг 19, 07:54    [21953937]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
Симонов Денис
Если делаешь сразу под несколько СУБД что-то сложное, то скорее всего нормально не будет работать ни в одной.


Вообще статья как раз про это, и про то как обходить проблемы, чтобы система нормально работала на всех СУБД.
21 авг 19, 08:48    [21953965]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1057
andy st
В теме по MS SQL посоветовали материализацию count(*) на млрд записях, ранее заявленную как круто работающую, сделать в пару слегка неадекватных прыжков. Откуда разработчик должен знать о том, как работает данных фреймворк и что надо так глумиться над ним?


Тут вообще-то не две крайности, все руками и все автоматически. Есть полутона. Хотя конечно если бы платформа сама умела разбивать материализации на неконкурентные, и вообще сама умела бы их создавать было бы гораздо круче. Но лучшее как известно враг хорошего.

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


Я, например, за последние 5 лет работал с :
1. Groovy под Jenkins
2. Java - бэкенд, десктоп
3. JavaScript + React, Java + GWT - фронтенд
4. NSIS - инсталлятор
5. ANTLR, GrammarKit + IDEA - работа с языками интерпретаторы, IDE
6. PHP + October CMS - когда на сайт надо было подключить сложную функциональность, которую отдавать разработчикам сайтов себе дороже

и явно упустил еще с пяток фреймворков и языков.

Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист. Я например в резюме на предыдущий опыт вообще не смотрю, потому как хорошо знаю, что человек с мозгами вообще без опыта в технологии через 3 месяца может быть гораздо полезнее на проекте, чем человек с 10+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме.
21 авг 19, 08:58    [21953975]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить