PgProE таки круче MS SQL...

[.05]

Замени урл на https://www.postgresql.org/docs/9.5/static/sql-cluster.html и получи ссылку на оригинальную документацию.

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

[shurutov]

.05, ну нет в мире счастья, а в жЫзни совершенства. Страдай, пАтАмуШтА импортозамещение! 

Updated: 23 June 2017, 11:29:56
Ну и второе, кластерный индекс на версионнике - чегой-то я как-то вот так вот даже и задач не придумаю, чтобы был оправдан. Кроме, разве что только при работе на таблице, у которой кластерный индекс по монотонно возрастающему (убывающему) полю.

[.05]

Иными словами Сова был прав, когда говорил, что кластерного индекса в постгри нет, да?

Вот и славненько

[airdwarf]

CLUSTER

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

Компании 1С и лично Борису Нуралиеву много "радости" и "счастья" за "замечательный" инструмент, позволяющий не просто отстрелить себе башку, но сделать это весьма витиевато-вычурным способом.
О, блядь. таки 1С - это клиническое уебанство:

Это надо просто посмотреть. Проведение одного документа в 1С вырождается в огромное количество последовательных запросов. Пользователь нажал одну кнопку, а сервер приложений сформировал много служебных вызовов на уровне СУБД. Это важно понимать, потому что там могут неожиданно создаваться временные таблицы, хотя ты их не создавал кодом. Может произойти массовая вставка, тут же распухание. То есть при записи одного документа сразу сработает bloat. Вакуум не отработает – не успеет. Он тут же запишет, следующую итерацию начнет читать. Прямо видно, как происходит фактически версионирование записей на 1С. Будет расти распухание таблиц. Автовакуум нужен, но он не всегда отрабатывает под высокой нагрузкой 1С. Это воспроизводимо визуально.

Простейшая логика подсказывает, что раз ни у MSSQL, ни у Oracle, ни у DB2, ни даже у файловой базы таких проблем нет (а работа с ними строится одним и тем же движком SDBL), то это проблема слоника. 

Лустин, кстати, тот еще энтузиаст. Единственная реально востребованная его разработка - внешняя компонента интеграции 1С с RabbitMQ.
Поэтому он ее продает с закрытым кодом, мало того, что за деньги, так еще и с индивидуальными клиентскими маркерами.
 

Updated: 23 June 2017, 13:13:34

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

В одной известной коммерческой СУБД (не будем показывать пальцем) кластерный индекс представляет собой всегда физически упорядоченную по индексным полям таблицу, у которой нет кучи. Т.е. данные неиндексных полей содержатся в ней же. Выгоды, надеюсь, объяснять не надо?

[shurutov]

В одной известной коммерческой СУБД (не будем показывать пальцем)

Я коммерческих три штуки знаю, и ни с одной не доводилось работать (год с оракел 8.0.5 в 2001-м не в счёт, давно это было, и я толком внутреннее устройство не могу сказать, что вот так вот изучил). Так что покажи, пожалуйста.

Выгоды, надеюсь, объяснять не надо?

На чтение по индексным полям - нет, понятно. А вот на вставку... Что-то мне подсказывает, что всё не так однозначно, особенно при наличии у таблицы более одного индекса.

Oracle... DB2

А 1С разве с этими СУБД работает?!
Я тут одну книжку (запрос гуглю: Architecture of a Database System) умную просматривал вполглаза. Таки у 1С будут проблемы с производительностью и на Оракле, и на ДиБи2, если эти две не пилить специально под 1С. Ну просто по факту архитектуры 1С.

файловой базы

На скольких пользователях?

Лустин, кстати, тот еще энтузиаст.

Последний абзац материала об этом говорит более, чем красноречиво. Лучше бы таких "популяризаторов" не было.

[airdwarf]

shurutov, речь о MSSQL. Кстати, в силу такой реализации кластерный индекс там бывает только один. А с других индексов делается кей_лукап, который в силу физической упорядоченности дешевле, чем лукап в кучу.

Oracle... DB2
А 1С разве с этими СУБД работает?!

Вообще-то давно и неплохо.

Я тут одну книжку (запрос гуглю: Architecture of a Database System) умную просматривал вполглаза. Таки у 1С будут проблемы с производительностью и на Оракле, и на ДиБи2, если эти две не пилить специально под 1С. Ну просто по факту архитектуры 1С.

Специализированная БД в сорокпоследней растоптатой нормальной форме будет быстрее и на MSSQL, 1С - это все же фреймворк, причем без возможности формировать индексы произвольного состава. Зато по цене разработки и гибкости продукта она эти специализированные БД уделывает, как Бивис и Батхед Америку.
Однако каких-то принципиальных проблем наподобие блоатинга нет.

файловой базы
На скольких пользователях?

На адын.
А что, постгря на одном юзере не блоатится? 



Updated: 23 June 2017, 14:22:29
Кстати, понятно, почему в обсуждаемом тесте постгря в проц уперлась: она же SOS_SHEDULER не умеет. 

[shurutov]

в силу такой реализации кластерный индекс там бывает только один.

Насколько я могу судить по доступной инфе, кластерный индекс по определению может быть только один на таблицу.
У нативного слоника есть некоторое ненормальное поведение с временными таблицами. Дык вот это поведение в ПгПроЕ помножено на ноль. Т.е. в ПгПроЕ с временными таблицами, в отличие от, всё в порядке на данный момент, и уже в версии 1.5 было в порядке.

1С - это все же фреймворк, причем без возможности формировать индексы произвольного состава.

Эммм... А вот это что:

Принято считать, что MS SQL стабилен для 1С. В целом, это, наверное, так. Его оптимизатор запросов начинает справляться, и не показывает ошибки в проектировании таблиц и связей между ними. Логически ошибочный проект на 1С в связке с MS SQL, запускаемый на каком-то минимальном объеме данных, начинает сбоить только после определенных порогов. А в Postgres эти ошибки выявляются еще на начальном этапе старта информационной системы – логические ошибки в структуре СУБД сразу вылетают, ты тут же видишь непонятки, все работает медленно.

Я понимаю данное утверждение так, что разраб конфы 1С может нарисовать произвольную структуру данных с произвольными же индексами. Или данный товарищ врёт и не краснеет?

две не пилить специально под 1С.

Я таки прошу пардону, имел в виду настройку под 1С. А не просто так: взял, поставил и забыл. Что-то мне подсказывает, что и Оракел, и ДиБи2 надо таки настраивать.

Updated: 23 June 2017, 14:39:17

постгря на одном юзере не блоатится?

С блоатингом у ПГ да, есть некоторые проблемы. Увы и ах.

[.05]

Я понимаю данное утверждение так, что разраб конфы 1С может нарисовать произвольную структуру данных с произвольными же индексами. Или данный товарищ врёт и не краснеет?

Разраб конфы "декларирует" структуру данных и некоторые индексы относительно набора метаданных конфигурации. Конечное создание физической структуры иб предоставлено платформе. Логическая целостность опять же не определяется СУБД, аопределяется платформой относительно конфигурации

[shurutov]

.05, ну то есть я всё правильно понял.
1С - фтопку. Впрочем, как и упомянутых популяризаторов слоника с хабра...

[.05]

.05, ну то есть я всё правильно понял.

[airdwarf]

У нативного слоника есть некоторое ненормальное поведение с временными таблицами. Дык вот это поведение в ПгПроЕ помножено на ноль.

Не некоторое, а вполне понятное - он не делает по ним статистики. Причина - в ущербности подхода с выносом построения статистик в автовакуум, а так поведение очень даже нормальное и ожидаемое. Но неприемлемое. Пришлось Сигаеву делать online_analyse.
Ну и в старых (это до 8.3.9 - 8.3.10) версиях 1С пула временных таблиц не всегда хватало.

Updated: 23 June 2017, 15:34:01

Что-то мне подсказывает, что и Оракел, и ДиБи2 надо таки настраивать

Ты не поверишь, но mssql тоже для существенных нагрузок нужно настраивать. Он, конечно, из коробки неплохо работает, однако.

[shs]

А разве в случае с MSSQL создание кластерного индекса не означает физическую сортировку таблицы?

[airdwarf]

А разве в случае с MSSQL создание кластерного индекса не означает физическую сортировку таблицы?

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

[shs]

А разве в случае с MSSQL создание кластерного индекса не означает физическую сортировку таблицы?

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

Тогда отчего так бомбит от нижеследующего?

https://www.postgresql.org/docs/9.5/static/sql-cluster.html

[airdwarf]

shs, потому, что в PG

Clustering is a one-time operation: when the table is subsequently updated, the changes are not clustered

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