Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 17   вперед  Ctrl
 Re: Российские СУБД  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3069
Andy_OLAP
Ну и два основных минуса PostgreSQL - это самая кривая реализация MVCC, которую только можно представить, и отсутствие упреждающего чтения крупными блоками, что ставит крест на попытках использовать эту забавную БД в качестве DWH. Это помимо двойного кэширования, если я ничего не путаю, но это уже "вишенка на торте".

Отличные на ней DWH. Например, greenplum. Сам с такой работаю. Кроме того есть Postgre-XL, ну и на просто Postgre люди делают отличные DWH.
23 дек 18, 04:41    [21771280]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
Бумбараш
Eleanor
нет хинтов запросов

Так это плюс, а не минус.

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

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

К тому же, что мы видим в ближайших планах разработки? Это же один из видов хинтов, plan guid-ы.
Postgres-у по большому счету требуется только щедрое финансирование, множество разработчиков, чтобы копировать наработки лидеров, и постепенно их нагнать.
23 дек 18, 12:46    [21771347]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
PgSQLanonymous3
Eleanor
Отдельные отзывы коллег, которые работают с Postgres, всё сразу не вспомню:

А почему Вы думаете, что их отзывы вообще что-то значат (кроме того, что они не знают, о чём говорят)?

Понимаю, разработчики часто относятся к бизнесу со стойким пофигизмом. Это же реальная работа боевой системы.
Представьте, что система падает. Руководство получает такое объяснение:
виноват сломавшийся параллелизм запросов. Его убрали, теперь всё отлично. Баг странный, потому что
разработчики Postgres его якобы уже исправили несколько месяцев назад. На тестовой системе не проявился.

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

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

И хорошо, если есть возможность проработать в таком режиме пол года, собрать все грабли, запомнить о них, и больше не использовать неработающие вещи.
23 дек 18, 13:27    [21771364]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Ожидаемый комментарий: мол многие люди злоупотребляют хинтами, не умеют "готовить" запросы и т.д.

Не "мол", а да, так и есть! Впрочем, обоснования того, почему проект "не хочет" такие hints, какие обычно используются, на wiki есть (ссылку я давал, кажется).

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

Если для кого-то проблема заставить запрос использовать какой-то план в тестовой среде --- это "пляски с бубном", то может быть, следует просто этому научиться? Или, например, проблема на самом деле с критериями оценки эффективности или настройками сервера, а вовсе не с конкретным планом?

Eleanor
К тому же, что мы видим в ближайших планах разработки? Это же один из видов хинтов, plan guid-ы.

Какое отношение планы Postgres pro (yet another fork) имеют к планам vanilla PostgreSQL? Т.е. это просто мимо.

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

Сообществу нужно копировать "наработки" так называемых "лидеров" примерно так же, как Python-у (или другому современному языку высокого уровня) нужно копировать "наработки" COBOL-а. Т.е. спасибо, но нет.
Кстати, когда эти упомянутые "лидеры" нагонят PostgreSQL и реализуют десятки features, которые в нём есть?
А то попытки что-то в них разрабатывать иногда начинают напоминать использование ассемблера... в 2018 году!
23 дек 18, 13:47    [21771378]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
PgSQLanonymous3
Eleanor
- совсем нет хинтов запросов

Во-первых, это принципиальная позиция проекта (https://wiki.postgresql.org/wiki/OptimizerHintsDiscussion ).
Во-вторых, это не совсем так (посоветуйте им погуглить).

Субд, у которых есть развитая система хинтов, очевидно, имеют такие же принципы:
"Внимание!
Так как оптимизатор запросов SQL Server обычно выбирает наилучший план выполнения для запроса, рекомендуется использовать указания <join_hint>, <query_hint> и <table_hint> в последнюю очередь и только опытным разработчикам и администраторам баз данных."
23 дек 18, 13:48    [21771380]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Понимаю, разработчики часто относятся к бизнесу со стойким пофигизмом. Это же реальная работа боевой системы.

Что-что, простите? О чём конкретно речь?

Eleanor
Представьте, что...

А теперь представьте, что всё, Вами изложенное, можно написать про любую другую СУБД, просто заменив конкретные проблемы на какие-то другие:

Представьте, что система падает.

Руководство получает такое объяснение:
виноват сломавшийся X. Его убрали, теперь всё отлично. Баг странный, потому что разработчики Oracle / MS SQL / DB2 его якобы уже исправили несколько месяцев назад. На тестовой системе не проявился.

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

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

И хорошо, если есть возможность проработать в таком режиме пол года, собрать все грабли, запомнить о них, и больше не использовать неработающие вещи.

Т.е. мы тут прослушали типичный FUD, мне кажется.
23 дек 18, 13:53    [21771387]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
PgSQLanonymous3
Eleanor
- параллелизм появился недавно (а для реляционок-лидеров это уже прошлый век). Причем, неделю назад его пришлось на проекте полностью отключить из-за проявившихся багов

Да, отчасти это так. К счастью, для OLTP исполнение запроса на нескольких CPU обычно не принципиально.

Да, здесь это уже указывали: интернет магазин, или сайт визитка фирмы, или форум такой субд вполне по силам.
Как-то натыкалась на статью, где основную массу субд отделяли от развитых именно по наличию параллелизма, как сложной в реализации фичи.
23 дек 18, 14:00    [21771391]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

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

Субд, у которых есть развитая система хинтов, очевидно, имеют такие же принципы:
"Внимание!
Так как оптимизатор запросов SQL Server обычно выбирает наилучший план выполнения для запроса, рекомендуется использовать указания <join_hint>, <query_hint> и <table_hint> в последнюю очередь и только опытным разработчикам и администраторам баз данных."

Что как бы намекает нам, что "развитая система хинтов" --- это legacy (с тех времён, когда оптимизатор запросов недостаточно часто "выбирал наилучший план выполнения для запроса"), использование которого не рекомендуется. ;)
И основная причина того, что она там есть (и будет) теперь --- backward compatibility.
Подобных "features" наверняка немало во всех современных СУБД, включая PostgreSQL, кстати.
23 дек 18, 14:00    [21771393]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

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

Eleanor
Представьте, что система падает. Руководство получает такое объяснение:
виноват сломавшийся параллелизм запросов. Его убрали, теперь всё отлично. Баг странный,
потому что разработчики Postgres его якобы уже исправили несколько месяцев назад. На
тестовой системе не проявился.

Замените в этой тираде Postgres на Oracle и получите точное описание всем известного
инцидента в Сбербанке. Только там убирание параллелизма не помогло и "всё отлично" не стало.

Posted via ActualForum NNTP Server 1.5

23 дек 18, 14:01    [21771395]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Да, здесь это уже указывали: интернет магазин, или сайт визитка фирмы, или форум такой субд вполне по силам.

Не вижу никакой логической связи... т.е. это опять похоже на FUD.
Или же Вы утверждаете, что все БД, которые "круче" (что бы это ни значило ;) ), чем вышеуказанные, просто обязаны нарушать основные принципы проектирования и реализации OLTP?

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

И что? Параллелизм --- это DWH feature, и в этой области PostgreSQL ещё есть куда развиваться, конечно.
Кстати, использовать для масштабного / сложного DWH СУБД общего назначения, наверное, не стоит (если считать деньги, конечно).
23 дек 18, 14:08    [21771398]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
PgSQLanonymous3
Eleanor
- история, как Postgres попытался оценить свои достижения по производительности, используя тесты TPC. Тесты полностью провалил и возмущенно написал, что это просто все читеры, их результаты подкручены, а он не будет в этом цирке участвовать

Это уж и вовсе бредятина и FUD. Или попросите у них конкретные ссылки.

Видите результаты Postgres на www.tpc.org? Нет. Оправдывают они это очень незамысловато: https://wiki.postgresql.org/wiki/TPC-H
Тест TPC они попытались пройти уже давно, лет 10 назад. Больше не пытаются.

Пока кроме размытых рассуждений, а-ля: Postgres лучше лидеров, потому что за лицензию платить не надо, и за это его много кто использует, здесь ничего не было.
Кто же спорит - это очень большой плюс.
23 дек 18, 14:12    [21771400]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

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

Кстати, где можно посмотреть на пример "развитого средства высокой доступности"?
А то вот смотрю я на Оракула и вижу:
РАК с единой точкой отказа
ДатаГвард который всего лишь фронт-енд к репликации
ГолденГейт который и есть всего лишь репликация

Почему такая очень раскрученная вещь имеет только огрызки вместо реального ХА?

Posted via ActualForum NNTP Server 1.5

23 дек 18, 14:18    [21771402]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

Откуда:
Сообщений: 3597
PgSQLanonymous3
Что как бы намекает нам, что "развитая система хинтов" --- это legacy (с тех времён, когда оптимизатор запросов недостаточно часто "выбирал наилучший план выполнения для запроса"), использование которого не рекомендуется. ;)

Не легаси, потому что уже указывала на экономию времени на проверку гипотез с использованием хинтов.
Такие вещи относят к категории productivity tool - дают возможность значительно ускорить работу, не выполняя нудные действия.
23 дек 18, 14:24    [21771406]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Dimitry Sibiryakov
Member

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

Eleanor
Такие вещи относят к категории productivity tool - дают возможность значительно ускорить
работу, не выполняя нудные действия.

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

Posted via ActualForum NNTP Server 1.5

23 дек 18, 14:39    [21771413]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3069
Если запрсы обвешаны хинтами как соплями, то это говорит о слабрости оптимизатора базы. В оракле явно написано, что хинты использовать не рекомендуется. В базах с которыми я работал и где нет хинтов - их отсутствие - это плюс, по сравнению с тем же ораклом. У них просто лучше работает оптимизатор. А хинты это и есть танцы с бубеом и увеличение времени разработки и поддержки.
23 дек 18, 15:29    [21771436]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Eleanor
Видите результаты Postgres на www.tpc.org? Нет.

Сейчас --- не вижу.
Кстати, те, кто непременно хочет их там увидеть, не разбираются ни в opensource development, ни в PostgreSQL, ни в тестах TPC.
Вы понимаете, что PostgreSQL --- это проект, а не чей-то продукт?!
Вы думаете, каждый член сообщества PostgreSQL должен заплатить из личных средств за эту бесполезную (для них, конкретных людей) рекламу?

Eleanor
Оправдывают они это очень незамысловато: https://wiki.postgresql.org/wiki/TPC-H

Не "оправдывают", а объясняют.
Не могли бы Вы засунуть свои попытки применения демагогических приёмов туда, откуда Вы их взяли?
И воздержаться от таковых в дальнейшем...

Eleanor
Тест TPC они попытались пройти уже давно, лет 10 назад. Больше не пытаются.

Тесты TPC не "проходят", а просто выполняют и публикуют результаты.
И не "они", а какая-то компания "тестировала" PostgreSQL (в рекламных целях, вероятно).

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

Тут (в форумах, в смысле) много чего было, кроме этого, поищите.
23 дек 18, 16:41    [21771469]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Не могли бы Вы засунуть свои попытки применения демагогических приёмов

Как грубо. И в адрес дамы. Ай-яй-яй, я таки Вас не узнаю - такой приличный молодой человек и такой выпад.
24 дек 18, 00:49    [21771681]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6642
Dimitry Sibiryakov
Кстати, где можно посмотреть на пример "развитого средства высокой доступности"?
А то вот смотрю я на Оракула и вижу:
РАК с единой точкой отказа
ДатаГвард который всего лишь фронт-енд к репликации
ГолденГейт который и есть всего лишь репликация

Почему такая очень раскрученная вещь имеет только огрызки вместо реального ХА?

Ок, а где лучше?

PgSQLanonymous3, лучше не пиши. Бреда и без тебя достаточно.
24 дек 18, 00:57    [21771682]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
Бумбараш
Andy_OLAP
Ну и два основных минуса PostgreSQL - это самая кривая реализация MVCC, которую только можно представить, и отсутствие упреждающего чтения крупными блоками, что ставит крест на попытках использовать эту забавную БД в качестве DWH. Это помимо двойного кэширования, если я ничего не путаю, но это уже "вишенка на торте".

Отличные на ней DWH. Например, greenplum. Сам с такой работаю.

Через ODBC, но не через JDBC?
24 дек 18, 01:02    [21771685]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3069
чего? jdbc есть у неё. или что ты хотел сказать
24 дек 18, 02:28    [21771698]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Siemargl
PgSQLanonymous3, лучше не пиши. Бреда и без тебя достаточно.
Лучше не хами, а напиши конкретно, что из написанного мной --- бред.
24 дек 18, 09:51    [21771777]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
PgSQLanonymous3
Member

Откуда:
Сообщений: 121
Andy_OLAP
Как грубо. И в адрес дамы. Ай-яй-яй, я таки Вас не узнаю - такой приличный молодой человек и такой выпад.

Ах да, к "дамам" же применимы другие моральные критерии, они же "выше" людей, как это я забыл... ;(
Вы, кстати, могли бы что-нибудь пояснить по своим предыдущим высказываниям (про MVCC и упреждающее чтение крупными блоками)?
24 дек 18, 09:54    [21771782]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Alexander A. Sak
Member

Откуда: Омск
Сообщений: 1228
Помнится, в начале века читал про IBM DB2, что у них нет хинтов, потому что оптимизатор мегапродуманный.
Есть тут спецы по DB2? Как там сейчас ситуация с хинтами?
24 дек 18, 09:59    [21771786]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Eleanor
Member

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

Платить не должны, тест TPC можно пройти бесплатно. Возможностей сейчас много: производители даже бесплатно сервера дают погонять.
Oracle, Sybase, Teradata, Sql Server, DB2 и многие другие спокойно эти тесты прошли и выложили результаты. Postgres также неоднократно тестировали, но указывали, что результаты публиковать не будут, т.к. это дискредитирует продукт и его фанатов.

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

Зато у продуктов, которые отказываются проходить тесты производительности, хватает наглости заявлять, что продукты, эти тесты прошедшие, работают в 2 раза медленнее - так сделал когда-то Greenplum (на основе Postgres) в отношении Teradata.

По большому счету обсуждать минусы Postgres - это заново подробно обсудить известный документ Почему PostgreSQL не является аналогом СУБД Oracle.
24 дек 18, 11:47    [21771860]     Ответить | Цитировать Сообщить модератору
 Re: Российские СУБД  [new]
Andy_OLAP
Member

Откуда: я знаю, что Хапоэль Беэр-Шева - чемпион
Сообщений: 3151
PgSQLanonymous3
Вы, кстати, могли бы что-нибудь пояснить по своим предыдущим высказываниям (про MVCC и упреждающее чтение крупными блоками)?

А зачем? Вы не согласны с общим выводом "это не применимо для построения DWH" (гринплан в тинькофф выведем за скобки, это все-таки не postgresql)?
24 дек 18, 11:49    [21771862]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 3 4 5 6 7 [8] 9 10 11 12 .. 17   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить