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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

Откуда:
Сообщений: 1058
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

Откуда: Москва
Сообщений: 814
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

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


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


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


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

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

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

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

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

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

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


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

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

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

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

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

Откуда:
Сообщений: 1058
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

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

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


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

Откуда: никем не победимая, самая любимая
Сообщений: 2331
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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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


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

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


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

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

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

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

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

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

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

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

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


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

Откуда:
Сообщений: 1058
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]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

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

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

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

Nitro_Junkie
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+ лет опыта, который не умеет систематизировать информацию и составлять общую картину. И бизнесу нужны люди умеющие решать проблемы, а не с длинным резюме.

Помойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не?
nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет.
React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается.
а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я.
фтопку такого разраба.
21 авг 19, 09:54    [21954009]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
andy st
Но, в любом случае, когда презенуют очередную "серебряную пулю" для "универсального мгновенного и экстраординарного улучшения" продуктов, в которые вложено на несколько порядков больше ресурсов возникает только одна мысль - подозрение. Подозрение, что впаривают дичь, что разработчики слегонца так "чрезмерно самоуверены" ну и т.п...

Ну вы же понимаете, что вложение ресурсов очень часто слабо коррелированно с результатом. То есть алгоритм со сложностью O(n) даже на моем компьютере обгонит алгоритм со сложностью O(n!) на суперкомпьютере. Или другими словами знание куда бежать важнее скорости бега.

Хотя подозрение вполне нормальная реакция на все новое. Но как и у любой инновации есть две претензии:
1. Это уже было в продукте X. Тут все проще даже ничего проверять не надо, достаточно привести пример этого X. Но именно для этого на сайте сделано сравнение с существующими технологиями, и сейчас делаются дополнительные статьи (вот одна про SQL была).
2. Это не заработает. Вот тут сложнее, можно конечно предложить приехать на экскурсию, но мало кто согласится. В любом случае преодолеть это сомнение вопрос времени.

andy st
Помойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не?
nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет.
React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается.
а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я.
фтопку такого разраба.


Еще раз, я сказал то что для настоящего разработчика технологии это не более чем инструмент. Его мозги куда важнее. Если они есть , разработчик сможет пользоваться любым инструментом. И экскаватором, даже если он никогда его в глаза не видел, выкопает яму быстрее чем лопатой.
21 авг 19, 10:09    [21954023]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

Откуда:
Сообщений: 763
Nitro_Junkie
andy st
Но, в любом случае, когда презенуют очередную "серебряную пулю" для "универсального мгновенного и экстраординарного улучшения" продуктов, в которые вложено на несколько порядков больше ресурсов возникает только одна мысль - подозрение. Подозрение, что впаривают дичь, что разработчики слегонца так "чрезмерно самоуверены" ну и т.п...

Ну вы же понимаете, что вложение ресурсов очень часто слабо коррелированно с результатом. То есть алгоритм со сложностью O(n) даже на моем компьютере обгонит алгоритм со сложностью O(n!) на суперкомпьютере. Или другими словами знание куда бежать важнее скорости бега.

Вообще не понимаю.
Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу.
Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше.
Nitro_Junkie
Хотя подозрение вполне нормальная реакция на все новое. Но как и у любой инновации есть две претензии:
1. Это уже было в продукте X. Тут все проще даже ничего проверять не надо, достаточно привести пример этого X. Но именно для этого на сайте сделано сравнение с существующими технологиями, и сейчас делаются дополнительные статьи (вот одна про SQL была).
2. Это не заработает. Вот тут сложнее, можно конечно предложить приехать на экскурсию, но мало кто согласится. В любом случае преодолеть это сомнение вопрос времени.

Нужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения.
А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно.

Nitro_Junkie
andy st
Помойму 5 пукнтов + еще "с пяток фреймворков" - это и есть немного длинное резюме? не?
nosql было до sql *дцать лет назад, называл только каждый разработчик как хотел. То, что кучу разных технологий назвали одним словом несколько лет назад означает лишь то, что кто-то сумел приписать no к sql. Больше никаких заслуг тут нет.
React - это очень частный случай в сфере разработки ПО и его знание в других случаях вообще никуда не упирается.
а так: "я знаю каратэ. дзюдо, самбо и еще много других страшных слов" (с) не я.
фтопку такого разраба.

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

мозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом.
ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел.
21 авг 19, 10:41    [21954076]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28223
Nitro_Junkie
И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись.

гм, вот это поворот! А оптимизатор Firebird прекрасно с этим справляется. Если есть 4 одиночных индекса, то он просто строит битовые маски по каждому условию, а затем склеивает их теми самыми битовыми операциями запроса.
И работает, это, прости господи, уже лет 25 точно.
21 авг 19, 10:53    [21954096]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
andy st
Вообще не понимаю.
Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу.
Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше.

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

andy st
Нужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения.
А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно.

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

И на lsFusion уже больше 40 проектов, в том числе в России (некоторые достаточно публичные и их нельзя называть без согласования с их ИТ). Причем большинство этих проектов с более чем 500 одновременных пользователей и террабайтными базами (в которых, например, все чеки с детализацией онлайн сразу с распределением по партиям принимаются и это на паре серверов стоимостью 10к максимум). Собственно проектов всего 40 потому как с мелочевкой как 1С пока предпочитаем не связываться, но зато стараемся брать проекты из разных областей (от ERP до BPM и ECM)

andy st
мозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом.
ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел.

Вы передергиваете. Я как раз и говорю что знание технологий - пыль. Умение думать makes difference.

Ну если вы не умеете учиться - то да запаришься. А если есть мозги, то можно легко обучиться чему угодно .
21 авг 19, 10:54    [21954097]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
kdv
Nitro_Junkie
И там нужны именно индексы по двум полям, индексами по одному полю там никак не обойтись.

гм, вот это поворот! А оптимизатор Firebird прекрасно с этим справляется. Если есть 4 одиночных индекса, то он просто строит битовые маски по каждому условию, а затем склеивает их теми самыми битовыми операциями запроса.
И работает, это, прости господи, уже лет 25 точно.


Не поверите, но ms sql и oracle это тоже делают, но это все равно на порядок медленнее, чем использовать индексы по двум полям (см. статью).
21 авг 19, 11:00    [21954109]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

Откуда:
Сообщений: 763
Nitro_Junkie
andy st
Вообще не понимаю.
Не путайте плз вычислительные ресурсы - аналог ресурса кодировщиков уровня говнокода, и интеллектуальные. Суперкомп может за затратить время на анализ и выбор аналогичного алгоритма с O(1). Тогда ваш комп убудет в дупу.
Думаю, людей, "знающих куда бежать" в том же MS или Oracle существенно больше и "знают" они существенно лучше.

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

"Знают" они однозначно лучше. Иначе бы вы свою субд запилили, с блекджеком и т.п. И язык программирования свой тоже...
Ну и ждем, когда вас купят MS. Ну или вы купите MS...
Nitro_Junkie
andy st
Нужно найти жертву для success story, запилить там реальный проект (желательно чуть толще, чем "АРМ продавца билетов в туалет") и уж тогда что-то писать на техническом ресурсе. Точнее не что-то, а описать проект, его объемы, процесс внедрения, эффект от внедрения.
А пока единственный шанс это впарить - найти не совсем вменяемого топа, у которого подчиненные не смогут обосновать нецелесообразность внедрения этого продукта :) А потом молиться, чтобы не подсунули проект, который реализовать на продукте будет либо очень сложно, либо вообще невозможно.

Вы наверное комменты к статям не читали и даже не гуглили. Мы уже подмяли под себя больше половину крупной розницы в Беларуси, и сейчас начинаем на российский рынок выходить.
И на lsFusion уже больше 40 проектов, в том числе в России (некоторые достаточно публичные и их нельзя называть без согласования с их ИТ). Причем большинство этих проектов с более чем 500 одновременных пользователей и террабайтными базами (в которых, например, все чеки с детализацией онлайн сразу с распределением по партиям принимаются и это на паре серверов стоимостью 10к максимум). Собственно проектов всего 40 потому как с мелочевкой как 1С пока предпочитаем не связываться, но зато стараемся брать проекты из разных областей (от ERP до BPM и ECM)

а хде финики?
в смысле то, что я там выше написал: описание проекта и т.п...
и хреново видать с розницей в Беларуси, что 40+ проектов - это половина рынка.
1С - мелочевка... ERP на ММК пилят... суровые у вас масштабы. Основные конкуренты, я так понимаю - SAP ?
А комменты читать на хабре - чур меня, не заставите в эту канализацию нырять.
Nitro_Junkie
andy st
мозги важнее, но не показатель "знаю много страшных слов", т.е. пробежался по 100500 технологиям по верхам и стал мегаспецом.
ps.: запаришся копать экскаватором, если ни разу до этого за рычагами не сидел.

Вы передергиваете. Я как раз и говорю что знание технологий - пыль. Умение думать makes difference.
Ну если вы не умеете учиться - то да запаришься. А если есть мозги, то можно легко обучиться чему угодно .

если вы все такие умные, то почему строем не ходите (с) не я
термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой"
чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат.
21 авг 19, 11:19    [21954136]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28223
Nitro_Junkie
но это все равно на порядок медленнее, чем использовать индексы по двум полям

никакого "порядка" в разнице производительности здесь не будет.
21 авг 19, 11:34    [21954152]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
andy st
"Знают" они однозначно лучше. Иначе бы вы свою субд запилили, с блекджеком и т.п. И язык программирования свой тоже...

Точно также как Microsoft запилил бы свой поисковик, Google свою соцсеть, Facebook свой инстаграм, Фольксваген свой электромобиль и так далее.
andy st
в смысле то, что я там выше написал: описание проекта и т.п...

А что вы там хотите увидеть? Я собственно уже написал про параметры. Описание технологии и сравнение - на сайте / хабре. Сделали быстро / бесшовно / под заказчика людьми без опыта в IT (кроме одного).
andy st
и хреново видать с розницей в Беларуси, что 40+ проектов - это половина рынка.

Я специально уточнил крупной розницей. То есть топ-30 сетей.
andy st
1С - мелочевка... ERP на ММК пилят... суровые у вас масштабы. Основные конкуренты, я так понимаю - SAP ?

Я не писал, что 1С не связывается с крупняками, я писал, что он связывается с мелочевкой. SAP нам такой же конкурент, как фольксваген эмбраеру, у нас фундаментально разные технологии. Хотя да мы оба "перевозим людей из точки А в точку Б".
andy st
А комменты читать на хабре - чур меня, не заставите в эту канализацию нырять.

А здесь прямо сплошные интеллигенты и ни одного тролля.
andy st
если вы все такие умные, то почему строем не ходите (с) не я
термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой"
чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат.

Ну я например легко обучаюсь, сверху приводил список недавних языков / технологий. Скажут завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее, чем человек с 10 летним опытом, но с ограниченными умственными способностями / кругозором.
21 авг 19, 14:08    [21954418]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
kdv
Nitro_Junkie
но это все равно на порядок медленнее, чем использовать индексы по двум полям

никакого "порядка" в разнице производительности здесь не будет.


Будет. Проверено. Собственно вам в примере из статьи надо будет пробежаться по 100к записям, а с двумя индексами по 1к записям.
21 авг 19, 14:09    [21954420]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

Откуда:
Сообщений: 763
Nitro_Junkie
andy st
в смысле то, что я там выше написал: описание проекта и т.п...

А что вы там хотите увидеть? Я собственно уже написал про параметры. Описание технологии и сравнение - на сайте / хабре. Сделали быстро / бесшовно / под заказчика людьми без опыта в IT (кроме одного).

Что было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием.
"..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями.

Nitro_Junkie
andy st
А комменты читать на хабре - чур меня, не заставите в эту канализацию нырять.

А здесь прямо сплошные интеллигенты и ни одного тролля.

контингент адекватнее
Nitro_Junkie
andy st
если вы все такие умные, то почему строем не ходите (с) не я
термин "легко обучиться" больше подходит как раз для "копать лопатой, не копать лопатой"
чему-то более серьезному легко не обучиться и с мегамозгом. Хотя копать ковшем экскаватора, как лопатой в рамках "побыстрому обучился" тоже можно... тяжко только. И хреновый результат.

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

наверно хорошо быть таким оптимистом, но в данном случае "можно нинада"?
слишком дохрена уже таких "...завтра еще одну освою за пару дней, а через пару месяцев буду использовать ее эффективнее...", которых через 2.5 месяца просят свалить, ибо кругозором работу делать сложно, а серьезных знаний не насобиралось.
21 авг 19, 15:00    [21954488]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
andy st
Что было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием.

А вы поверите? Такого маркетинг буллшита каждый вендор тоннами генерит. Эффект гербалайф, как я его называю.
andy st
"..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями.

Ну все вроде работает, по несколько задач в день закрывается этими же людьми в FMCG рознице с глубиной автоматизации - глубже некуда. Но вы же все равно не поверите.
andy st
контингент адекватнее

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

Ну или платформа делает все за вас. В любом случае пока проблем таких не возникало.
21 авг 19, 15:35    [21954541]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
andy st
Member

Откуда:
Сообщений: 763
Nitro_Junkie
andy st
Что было, что стало, какие затраты времени/денег. Технические подробности систем. Восхищенные отзывы пользователей... и всё в статье тут или на том же хабре. Дабы можно было проникнуться величием.

А вы поверите? Такого маркетинг буллшита каждый вендор тоннами генерит. Эффект гербалайф, как я его называю.

А такого и не надо. Надо технические подробности. Типа: крутилось на фокспро, сервер на pentium 2, 1 гиг памяти. Всё работало чётко, но мы качественно обработали барина и запустили аналог на ..., сервер на xeon phi 7210... на пиках тормозит...
:)
Было, проблемы, причины, принятое решение, обоснование, внедрение, результаты.
И без рукалицо-буллшита, как в сравнениях на сайте, и чтобы было читать приятно.
Nitro_Junkie
andy st
"..людьми без опыта в IT..." уже проходили. купил фотоаппарат - фотограф, купил лопату - строитель, купил скальпель - хирург... с соотв. последствиями.

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

Пишите статью, подумаю. Пока выглядит как очередная наколенная поделка с претензией на мировое господство.
Nitro_Junkie
andy st
контингент адекватнее

Да прям таки. Особенно по второму комменту темы заметно.

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

Ну или платформа делает все за вас. В любом случае пока проблем таких не возникало.

С ростом сложности проектов будет всё сложнее и сложнее убеждать заказчика в ненужности различных фишек, которые он где-то видел и хотел бы видеть у себя. А как быть, если платформу такое делать не научили заранее...
21 авг 19, 16:11    [21954571]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28223
Nitro_Junkie
Будет. Проверено. Собственно вам в примере из статьи надо будет пробежаться по 100к записям, а с двумя индексами по 1к записям.

я проверил. Firebird 3.
При абсолютном соответствии тесту, оптимизатор взял индексы только AD и BD, точно так же как PostgreSQL.
+
Select Expression
-> Aggregate
-> Filter
-> Table "MYTABLE" Access By ID
-> Bitmap Or
-> Bitmap
-> Index "AD" Range Scan (partial match: 1/2)
-> Bitmap
-> Index "BD" Range Scan (partial match: 1/2)

Execute time = 1s 420ms
Reads from disk to cache = 128 438
Fetches from cache = 327 305

Выполним запрос, который "ДНФ":
Тут да, план использует все 4 индекса
+
Select Expression
-> Aggregate
-> Filter
-> Table "MYTABLE" Access By ID
-> Bitmap Or
-> Bitmap Or
-> Bitmap Or
-> Bitmap
-> Index "AC" Range Scan (full match)
-> Bitmap
-> Index "BC" Range Scan (full match)
-> Bitmap
-> Index "AD" Range Scan (full match)
-> Bitmap
-> Index "BD" Range Scan (full match)

Execute time = 47ms
Reads from disk to cache = 4 084
Fetches from cache = 7 731

Быстрее? Намного! Однако, запрос "прикручен" к использованию этих самых композитных индексов.

Теперь убираем эти 4 композитных индекса, и строим 4 отдельных индекса по каждому столбцу (по 1 столбцу).
Типа "create index bya on mytable(a)" ...
План первого запроса
+
Select Expression
-> Aggregate
-> Filter
-> Table "MYTABLE" Access By ID
-> Bitmap And
-> Bitmap Or
-> Bitmap
-> Index "BYA" Range Scan (full match)
-> Bitmap
-> Index "BYB" Range Scan (full match)
-> Bitmap Or
-> Bitmap
-> Index "BYC" Range Scan (full match)
-> Bitmap
-> Index "BYD" Range Scan (full match)

Результат:
Execute time = 109ms
Reads from disk to cache = 4 575
Fetches from cache = 8 222

Запрос ДНФ, с такими индексами использует некоторые индексы лишний раз
+
Select Expression
-> Aggregate
-> Filter
-> Table "MYTABLE" Access By ID
-> Bitmap Or
-> Bitmap Or
-> Bitmap Or
-> Bitmap And
-> Bitmap
-> Index "BYC" Range Scan (full match)
-> Bitmap
-> Index "BYA" Range Scan (full match)
-> Bitmap And
-> Bitmap
-> Index "BYC" Range Scan (full match)
-> Bitmap
-> Index "BYB" Range Scan (full match)
-> Bitmap And
-> Bitmap
-> Index "BYD" Range Scan (full match)
-> Bitmap
-> Index "BYA" Range Scan (full match)
-> Bitmap And
-> Bitmap
-> Index "BYD" Range Scan (full match)
-> Bitmap
-> Index "BYB" Range Scan (full match)

Execute time = 141ms
Reads from disk to cache = 4 575
Fetches from cache = 8 775

получилось на 41% дольше, чем исходный запрос (понятно почему, лишние битмапы и их слияние).

Я напомню ваше высказывание:
"но это все равно на порядок медленнее, чем использовать индексы по двум полям"
Получается наоборот - 4 отдельных индекса по одиночным столбцам - на порядок быстрее чем 2 индекса по двум полям,
и в 2 раза медленнее чем 4 индекса по двум полям при весьма выкрученом запросе (ДНФ).
Так что в общем случае надо бы строить именно 4 отдельных одиночных индекса (и не крутить запрос), а не 4 композита, как привиделось автору статьи.
22 авг 19, 13:51    [21955444]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
У вас как-то очень малая разница в reads / fetches. Тока что еще раз протестил на PostgreSQL с одиночными индексами:

"Aggregate  (cost=21166.32..21166.33 rows=1 width=8) (actual time=87.265..87.266 rows=1 loops=1)"
"  Output: count(*)"
"  Buffers: shared hit=4885"
"  ->  Bitmap Heap Scan on public.mytable  (cost=7599.68..21155.90 rows=4166 width=0) (actual time=80.274..86.811 rows=3890 loops=1)"
"        Recheck Cond: (((mytable.c = 3) OR (mytable.d = 4)) AND ((mytable.a = 1) OR (mytable.b = 2)))"
"        Heap Blocks: exact=3782"
"        Buffers: shared hit=4885"
"        ->  BitmapAnd  (cost=7599.68..7599.68 rows=4209 width=0) (actual time=78.628..78.628 rows=0 loops=1)"
"              Buffers: shared hit=1103"
"              ->  BitmapOr  (cost=3796.47..3796.47 rows=205002 width=0) (actual time=42.314..42.314 rows=0 loops=1)"
"                    Buffers: shared hit=551"
"                    ->  Bitmap Index Scan on c  (cost=0.00..1856.94 rows=100334 width=0) (actual time=30.602..30.602 rows=99580 loops=1)"
"                          Index Cond: (mytable.c = 3)"
"                          Buffers: shared hit=275"
"                    ->  Bitmap Index Scan on d  (cost=0.00..1937.44 rows=104668 width=0) (actual time=11.707..11.707 rows=99981 loops=1)"
"                          Index Cond: (mytable.d = 4)"
"                          Buffers: shared hit=276"
"              ->  BitmapOr  (cost=3802.97..3802.97 rows=205335 width=0) (actual time=30.455..30.455 rows=0 loops=1)"
"                    Buffers: shared hit=552"
"                    ->  Bitmap Index Scan on a  (cost=0.00..1937.44 rows=104668 width=0) (actual time=17.524..17.524 rows=99931 loops=1)"
"                          Index Cond: (mytable.a = 1)"
"                          Buffers: shared hit=276"
"                    ->  Bitmap Index Scan on b  (cost=0.00..1863.44 rows=100667 width=0) (actual time=12.923..12.923 rows=99923 loops=1)"
"                          Index Cond: (mytable.b = 2)"
"                          Buffers: shared hit=276"
"Planning Time: 0.240 ms"
"Execution Time: 87.358 ms"


С двойными индексами:

"Aggregate  (cost=13454.71..13454.72 rows=1 width=8) (actual time=8.351..8.352 rows=1 loops=1)"
"  Output: count(*)"
"  Buffers: shared hit=3804"
"  ->  Bitmap Heap Scan on public.mytable  (cost=99.04..13444.41 rows=4118 width=0) (actual time=1.440..7.945 rows=3890 loops=1)"
"        Recheck Cond: (((mytable.a = 1) AND (mytable.c = 3)) OR ((mytable.b = 2) AND (mytable.c = 3)) OR ((mytable.a = 1) AND (mytable.d = 4)) OR ((mytable.b = 2) AND (mytable.d = 4)))"
"        Heap Blocks: exact=3782"
"        Buffers: shared hit=3804"
"        ->  BitmapOr  (cost=99.04..99.04 rows=4119 width=0) (actual time=0.897..0.897 rows=0 loops=1)"
"              Buffers: shared hit=22"
"              ->  Bitmap Index Scan on ac  (cost=0.00..21.59 rows=916 width=0) (actual time=0.223..0.223 rows=998 loops=1)"
"                    Index Cond: ((mytable.a = 1) AND (mytable.c = 3))"
"                    Buffers: shared hit=6"
"              ->  Bitmap Index Scan on bc  (cost=0.00..22.11 rows=967 width=0) (actual time=0.211..0.211 rows=980 loops=1)"
"                    Index Cond: ((mytable.b = 2) AND (mytable.c = 3))"
"                    Buffers: shared hit=5"
"              ->  Bitmap Index Scan on ad  (cost=0.00..23.30 rows=1087 width=0) (actual time=0.136..0.136 rows=963 loops=1)"
"                    Index Cond: ((mytable.a = 1) AND (mytable.d = 4))"
"                    Buffers: shared hit=5"
"              ->  Bitmap Index Scan on bd  (cost=0.00..27.91 rows=1148 width=0) (actual time=0.325..0.325 rows=978 loops=1)"
"                    Index Cond: ((mytable.b = 2) AND (mytable.d = 4))"
"                    Buffers: shared hit=6"
"Planning Time: 0.209 ms"
"Execution Time: 8.434 ms"


Разница 10 раз, а план точно такой же как в Firebird. И разница в Buffers и actual rows адекватная. Вы точно на тех же данных тестировали?
22 авг 19, 14:15    [21955492]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

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

Хотя тут скорее вопрос почему у вас Firebird на ДНФ запросе так тупит. А можно более детальный план?
22 авг 19, 14:20    [21955506]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28223
Nitro_Junkie,

в тесте было 10млн записей, так? Я ошибся на -1 запись, думаю это несущественно.
У базы размер страницы 4к, кэш 2048 страниц, данные таблицы:
+
MYTABLE (139)
Primary pointer page: 336, Index root page: 337
Total formats: 1, used formats: 1
Average record length: 41.87, total records: 9999999
Average version length: 0.00, total versions: 0, max versions: 0
Average fragment length: 0.00, total fragments: 0, max fragments: 0
Average unpacked length: 426.00, compression ratio: 10.17
Pointer pages: 253, data page slots: 204064
Data pages: 204064, average fill: 71%
Primary pages: 204064, secondary pages: 0, swept pages: 0
Empty pages: 3, full pages: 204060
Fill distribution:
0 - 19% = 3
20 - 39% = 0
40 - 59% = 1
60 - 79% = 204060
80 - 99% = 0


Я не знаю, почему у PG на одиночных индексах настолько хуже. У ФБ разница в 2 раза (между обычным запросом и одиночными индексами и ДНФ запросом с композитами).
22 авг 19, 14:25    [21955513]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
kdv
Nitro_Junkie,

в тесте было 10млн записей, так? Я ошибся на -1 запись, думаю это несущественно.
У базы размер страницы 4к, кэш 2048 страниц, данные таблицы:
+
MYTABLE (139)
Primary pointer page: 336, Index root page: 337
Total formats: 1, used formats: 1
Average record length: 41.87, total records: 9999999
Average version length: 0.00, total versions: 0, max versions: 0
Average fragment length: 0.00, total fragments: 0, max fragments: 0
Average unpacked length: 426.00, compression ratio: 10.17
Pointer pages: 253, data page slots: 204064
Data pages: 204064, average fill: 71%
Primary pages: 204064, secondary pages: 0, swept pages: 0
Empty pages: 3, full pages: 204060
Fill distribution:
0 - 19% = 3
20 - 39% = 0
40 - 59% = 1
60 - 79% = 204060
80 - 99% = 0


Я не знаю, почему у PG на одиночных индексах настолько хуже. У ФБ разница в 2 раза (между обычным запросом и одиночными индексами и ДНФ запросом с композитами).


У PG на одиночных индексах как раз также как у Firebird. Вопрос почему у Firebird так тупит на двойных индексов (45 мс вместо 8мс у postgres).

Собственно в плане PG видно, что сами записи он находит за 0.8мс против 78мс с одиночными индексами. Но так как ему еще нужно достать данные, накидывается 12 мс. И разница становится всего 10 раз (иначе было бы 100 раз). На самом деле если уменьшить выборку , чтобы в результате было не 1000 а 10 записей (и СУБД перейдет на Index scan) или замедлить диск разница по идее будет еще больше. Сейчас проверю.
22 авг 19, 14:44    [21955560]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
Nitro_Junkie,

Собственно да, если увеличить количество разновидностей в 10 раз (в скрипте генерации вместо *100, написать *1000), разница становится еще ощутимее:

Одиночные индексы.
Aggregate  (cost=906.77..906.78 rows=1 width=8) (actual time=16.878..16.879 rows=1 loops=1)
  Output: count(*)
  Buffers: shared hit=166
  ->  Bitmap Heap Scan on public.mytable  (cost=748.67..906.67 rows=40 width=0) (actual time=16.728..16.863 rows=46 loops=1)
        Recheck Cond: (((mytable.a = 1) OR (mytable.b = 2)) AND ((mytable.c = 3) OR (mytable.d = 4)))
        Heap Blocks: exact=46
        Buffers: shared hit=166
        ->  BitmapAnd  (cost=748.67..748.67 rows=40 width=0) (actual time=16.524..16.524 rows=0 loops=1)
              Buffers: shared hit=120
              ->  BitmapOr  (cost=374.15..374.15 rows=19901 width=0) (actual time=7.290..7.290 rows=0 loops=1)
                    Buffers: shared hit=60
                    ->  Bitmap Index Scan on a  (cost=0.00..187.02 rows=9945 width=0) (actual time=3.577..3.577 rows=10083 loops=1)
                          Index Cond: (mytable.a = 1)
                          Buffers: shared hit=30
                    ->  Bitmap Index Scan on b  (cost=0.00..187.11 rows=9956 width=0) (actual time=3.709..3.709 rows=9963 loops=1)
                          Index Cond: (mytable.b = 2)
                          Buffers: shared hit=30
              ->  BitmapOr  (cost=374.27..374.27 rows=19918 width=0) (actual time=7.196..7.196 rows=0 loops=1)
                    Buffers: shared hit=60
                    ->  Bitmap Index Scan on c  (cost=0.00..187.17 rows=9965 width=0) (actual time=3.748..3.748 rows=9915 loops=1)
                          Index Cond: (mytable.c = 3)
                          Buffers: shared hit=30
                    ->  Bitmap Index Scan on d  (cost=0.00..187.08 rows=9953 width=0) (actual time=3.444..3.445 rows=9945 loops=1)
                          Index Cond: (mytable.d = 4)
                          Buffers: shared hit=30
Planning Time: 0.206 ms
Execution Time: 16.949 ms


Двойные индексы:

Aggregate  (cost=176.68..176.69 rows=1 width=8) (actual time=0.334..0.335 rows=1 loops=1)	
  Output: count(*)	
  Buffers: shared hit=58	
  ->  Bitmap Heap Scan on public.mytable  (cost=18.18..176.58 rows=40 width=0) (actual time=0.161..0.315 rows=46 loops=1)	
        Recheck Cond: (((mytable.a = 1) AND (mytable.c = 3)) OR ((mytable.b = 2) AND (mytable.c = 3)) OR ((mytable.a = 1) AND (mytable.d = 4)) OR ((mytable.b = 2) AND (mytable.d = 4)))	
        Heap Blocks: exact=46	
        Buffers: shared hit=58	
        ->  BitmapOr  (cost=18.18..18.18 rows=40 width=0) (actual time=0.138..0.138 rows=0 loops=1)	
              Buffers: shared hit=12	
              ->  Bitmap Index Scan on ac  (cost=0.00..4.53 rows=10 width=0) (actual time=0.039..0.040 rows=11 loops=1)	
                    Index Cond: ((mytable.a = 1) AND (mytable.c = 3))	
                    Buffers: shared hit=3	
              ->  Bitmap Index Scan on bc  (cost=0.00..4.53 rows=10 width=0) (actual time=0.023..0.023 rows=10 loops=1)	
                    Index Cond: ((mytable.b = 2) AND (mytable.c = 3))	
                    Buffers: shared hit=3	
              ->  Bitmap Index Scan on ad  (cost=0.00..4.53 rows=10 width=0) (actual time=0.057..0.057 rows=11 loops=1)	
                    Index Cond: ((mytable.a = 1) AND (mytable.d = 4))	
                    Buffers: shared hit=3	
              ->  Bitmap Index Scan on bd  (cost=0.00..4.53 rows=10 width=0) (actual time=0.016..0.016 rows=14 loops=1)	
                    Index Cond: ((mytable.b = 2) AND (mytable.d = 4))	
                    Buffers: shared hit=3	
Planning Time: 0.363 ms	
Execution Time: 0.410 ms	


То есть в 32 раза разница.

А в Firebird есть планы по каждой вершине с количеством рядов и временем выполнения? Можете сюда скинуть?
22 авг 19, 15:04    [21955589]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 28223
Nitro_Junkie
А в Firebird есть планы по каждой вершине с количеством рядов и временем выполнения?

нет такого (некоторые цифры для плана есть только в тестовых сборках). и гистограмм в индексах тоже нет.
Кроме того, в ИБ и ФБ план вычисляется только на этапе prepare, до выполнения запроса.
23 авг 19, 00:57    [21956120]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Siemargl
Member

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


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

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


Вообще статья как раз про это, и про то как обходить проблемы, чтобы система нормально работала на всех СУБД.
Только при этом она работает только поверх Постгрес....


Нет, там есть адаптеры и под MS SQL и под Oracle. Но пока только в коммерческой версии.
28 авг 19, 08:49    [21958755]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3083
Nitro_Junkie

Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист.

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


т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит"
2 сен 19, 10:43    [21961676]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Nitro_Junkie
Member

Откуда:
Сообщений: 1058
Ролг Хупин
Nitro_Junkie
Вообще в современном мире где пять лет назад никто не слышал про React и NoSQL, а технологии меняются раз в 3 года, умение разбираться в них по сути единственный важный навык программиста. И человек, который не умеет этого делать а сфокусирован на конкретных технологиях - херовый программист.

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


т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит"


Ну не совсем в глаза, все-таки общение, тестовые задания и т.п. Но вообще в те же гуглы / фейсбуки также набирают, там всем наплевать на опыт и знания, не бодишоп же.
2 сен 19, 11:50    [21961745]     Ответить | Цитировать Сообщить модератору
 Re: Интересный взгляд на проблему сравнения  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 3083
Nitro_Junkie
Ролг Хупин
пропущено...


т.е. не смотрим ни на опыт, ни на знания, а только в глаза - видим мозг и понимаем, что "этот решит"


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


данунах... не чудите, нас могут читать молодые девелоперы с подвижной психикой
17 сен 19, 16:43    [21972699]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Сравнение СУБД Ответить