|
Миграция с Oracle на Postgres
|
||
|---|---|---|
Участник
Откуда: г. Кишинёв, Республика Молдова
Сообщения: 3 167 |
||
| 01.03.2016, 17:56 |
|
|
|
|
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonСергей Арсеньевпропущено... Забавно, но NULLы можно заставить хранить и ORACLE в составном индексе. Как и в PG добавить в индекс where ... not null и получить как в Oracle. Спор по этому поводу яйца выеденного не стоит. NULL-s можно заменить на свою волшебную константу и использовать через NVL. При этом мы получим как бонус индексирование. Но я-бы предложил другой подход. Как известно (ох как я люблю эту фразу!) или "есть общепризнанный факт" что индекс эффективен когда объём выборки не превышает 7%. Или еще меньше. Я уж не помню. В разные времена эта цифира была разной. И чем больше становились базы - тем меньше была эта пропорция. И вобщем-то принудительное индексирование NULL тяготеет к переосмыслению этого принципа. Мы должны индексировать ПОЛЕЗНОЕ. А пустота - это бесполезное.если оно бесполезное - зачем же его используют? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2016, 18:10 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
SergSuperесли оно бесполезное - зачем же его используют? Это вопрос к архитектору. Возможно поиск WHERE field IS NULL следовало-бы переделать WHERE field = 'somevalue' и тогда вопрос звучал бы по другому. Но кто-то упорно делает ставку на ценность пустых полей в кортеже. Вобщем... я признаю что поиск WHERE field IS NULL имеет место быть. Как анализ. Или агрегация чего-то.. Но как вы себе представляете OLTP транзакцию с таким поиском? Априори я напоминаю что NULL неуникален и запрос может вернуть много полей для нашей OLTP транзакции. И зачем нам нужна OLTP транзакция с неуникальной селективностью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2016, 18:34 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonАприори я напоминаю что NULL неуникален и запрос может вернуть много полей для нашей OLTP транзакции. Ты не поверишь, но для не-уникального индекса любое значение не уникально и запрос на равенство ему может вернуть много записей. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2016, 18:49 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonВобщем... я признаю что поиск WHERE field IS NULL имеет место быть. Как анализ. Или агрегация чего-то..вот мне как-то пришлось мигрировать с одной схему в другую практически все таблицы, ключи использовались составные естественные, где nullов было порядочно. Например [код+дата окончания действия] таблиц порядка 4000, вручную делать новые индексы нереально вот меня сильно тогда подвела неиндексированность nullов авторАприори я напоминаю что NULL неуникален и запрос может вернуть много полей для нашей OLTP транзакции.не только первичные ключи индексируются ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.02.2016, 19:13 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonSergSuperесли оно бесполезное - зачем же его используют? Это вопрос к архитектору. Возможно поиск WHERE field IS NULL следовало-бы переделать WHERE field = 'somevalue' и тогда вопрос звучал бы по другому. Но согласись хранить somevalue вместо пустоты там где не введены данные - это тот еще архитектурный подход. А для того, чтобы найти строки, в которых до сих пор не заполнили определенное поле. Вполне себе осмысленная и не бесполезная операция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 11:47 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Я просто продавливаю свой аргумент в пользу CRUD/OLTP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 12:08 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Коллеги. Давайте немного отвлечемся и вспомним SQL и основы проектирования БД. Вспомним картинку. Нарисована таблица. Где часть полей - ключевые. Инстанциированы. Часть полей REQURED (NOT NULL). И часть полей - NULLABLE. Опциональные поля. Таких полей может быть много. Яркий пример - географические справочники и классификаторы. Там вечно - вакуум. И еще много подобных generic-примеров. Незаполненные анкеты физлиц. e.t.c. Что такое есть NULL с точки зрения реляционной алгебры? Это не константа. Не ноль. Не false. Это дырка. Выколотое значение. В таблицах иногда его обозначают как прочерк. Общая суть - пустое значение элемента в кортеже. Неинициализированное. Базы данных еще на этапе создания предполагают что не все поля могут быть инстанциированы. Это разумно. Данных нет. И таких дырок может быть ... ну 25% от общего количества. А то и больше. Всё зависит от рода информации. С точки зрения системы хранения NULL-s - это вакуум. Его можно наделять разными поисковыми смыслами, но в первую очередь, исходя из принципов Реляционной алгебры это полное отсутствие информации. Разумеется storage-engines могут учитывать эту особенность или нет. ЕМНИП Oracle не резеревирует место в db_blocks в таблицах для пустых значений. И это разумно. Давайте зададим вопрос. Разумно-ли аллоцировать место в индексах для NULL's? Особенно беря в расчёт процент пустых значений. Представьте себе константу которая "лупит" по B+Tree, порождая только листовые значения со ссылкой на data_rows. Давайте зададим другой вопрос. Индекс строиться для очень быстрых операций извлечения инфы. Какой смысл очень быстро извлекать пачку NULL-s? Может это неверный дизайн и эти загадочне NULL-s rows имеет смысл положить в таблицу-отстойник? Напоследок хочу сказать что опция VIRTUAL COLUMN в Oracle позволяет трансформировать любое значение для индексации. Но оно того стоит? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 13:41 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonИ таких дырок может быть ... ну 25% от общего количества. А то и больше. Дальше можно не читать. Так любому значению можно от балды назначить любой удобный процент распределения и объявить, что его включение в индекс бессмысленно. Причём с тех же самых доводов. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 13:51 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonДавайте зададим вопрос. Разумно-ли аллоцировать место в индексах для NULL's? не смотря на то, что NULL это отсутствие значения, в компьютере как-то все же приходится хранить, есть значение или его нет (null). Для этого используются индикаторы. Например некий бит = 0 - значение есть. бит = 1 - значения нет, т.е. null. Так что хранить хотя бы 1 бит на null все же приходится. Кроме того, сам null точно так же равноправен, как и другие значения, например 1, 2, 3. Представьте себе миллион записей с равномерным распределением значений 1,2, 3. Создание индекса по этим значением вас не напрягает? А поиск where field = 1 ? А теперь добавим к 1, 2, 3 так же равномерно распределенное null (т.е. получается по 25% на каждое значение - 1, 2, 3 и null). Чем null провинился, что мы его выкинем из индекса? Чем отличается where field = 1 от where field is null ? По-моему, оба этих условия поиска равноправны. Но в итоге что - для field = 1 индекс будет использоваться оптимизатором, а для field is null поедет фуллскан? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 14:04 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
А какие DBMS индексируют null by default. Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 14:43 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonА какие DBMS индексируют null by default. Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий. MS SQL ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 17:35 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Ivan DurakmaytonА какие DBMS индексируют null by default. Дайте мне список pls. Я просто хочу владеть информацией хотя-бы на уровне названий. MS SQL да и DB2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 17:41 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Firebird ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 17:43 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonА какие DBMS индексируют null by default. Caché (в некоторых случаях в индексе значение маркера для NULL может быть другим). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 17:56 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Ок. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании индекса. Верно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 18:00 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Почитал оракловый форум. Workarounds. Здесь - предлагают partitioning http://www.sql.ru/forum/1102209/indeksirovanie-tolko-zapisey-s-null Тоже интересно. При биткартовый индекс и прочее. http://www.sql.ru/forum/105511/indeks-i-null-znachenie Пишет к сож. ныне покойный Андрей Криушин. Царствие ему... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 18:10 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonЧто такое есть NULL с точки зрения реляционной алгебры? Это не константа. Не ноль. Не false. Это дырка. Выколотое значение.тем не менее это информация ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.03.2016, 19:35 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
daunito Еще слишком много запросов выполняется лишних. Там где можно было передать один ID и запросом вытащить всю необходимую инфу, выполняется 30 маленьких запросов, где каждый вытаскивает кусочек информации. Например, методы getUserLastName, getUserFirstName, getUserBirthDate, getUserDocID, getDocSerialNumberById... чтобы собрать информацию о пользователе. Я такое безумие уже видел (в приложении "Аэ..." фирмы U) - и, быть может даже, что это те же самые люди делали. Когда-то я ругал (и до сих пор ругаю) пару фирм (H и I) за их любовь к хранимым процедурам и курсорам. Потом оказалось, что они ещё молодцы по сравнению с фирмой L с их базоданново-агностическим приложением на JBoss'е, которые на малейший чих тянут данные внутрь app-сервера и манипулируют ими там. Но в "Аэ%" оказалось нечто особенное. К примеру, когда в Hybernate люди пытались сделать вид, будто никакой базы данных не существует и они чисто с Java работают, в "Аэ%" люди делали вид, что они работают... с диалектом Объектного Паскаля a la Delphi. Изобразили внутри базы тотальную иерархию наподобие TObject, от которого всё прямо или косвенно наследуется, каждый класс - дополнительная таблица, пара (!) пакетов на подкласс, каждое изменение - отдельный апдейт (т.е. вместа update xxx set firstname=x, lastname=y where id=z надо выполнить setfirstname и затем setlastname (после прохождения цепочки вызовов будут выполнены два update - даже Hybernate так не поступает)). Быстро такое работать в принципе не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 15:23 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonVictor Metelitsa, автор также пишет ......Основной упор идет на то, что кривой оптимизатор запарывает всю производительность, приходится использовать кучи хинтов в запросах, а на постгресе этой проблемы быть не должно из-за более умного оптимизатора.... Помню я где-то читал что PG использует генетические алгоритмы для отбора наилучших планов. Возможно это и есть так козырная карта о которой пишет т.н. "руководство". Пусть "автор" прочитает Cost Base Oracle Fundamentals. Jonathan Lewis Troubleshooting Oracle Performance (second edition). Christian Antognini а потом говорит про более умный оптимизатор PG. Проблемы такие, что скорее можно говорить про более глупых разработчиков PG. Подумать только, хинты им реализовывать западло. Вот IBM от такой глупости отказалась. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 15:33 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
maytonОк. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании индекса. Верно? Не совсем. DB2 NULL'ы всегда индексировала, но когда решили взять курс на попытку переманивания ораклистов, реализовали, в том числе, и возможность неиндексирования NULL'ов. В самом деле, бывают случаи, когда выгодно NULL'ы индексировать, и бывают случая, когда выгодно, чтобы NULL'ов не было. Если выбирать одно из двух, то сложно сказать, что предпочесть. И хорошо, когда есть обе возможности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 15:42 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Victor MetelitsamaytonОк. Спасибо. Почитал про DB2. Насколько я понял, индексация NULL - это опция про создании индекса. Верно? Не совсем. DB2 NULL'ы всегда индексировала, но когда решили взять курс на попытку переманивания ораклистов, реализовали, в том числе, и возможность неиндексирования NULL'ов. В самом деле, бывают случаи, когда выгодно NULL'ы индексировать, и бывают случая, когда выгодно, чтобы NULL'ов не было. Если выбирать одно из двух, то сложно сказать, что предпочесть. И хорошо, когда есть обе возможности.на самом деле корень тут в том, что оракл предпочитает вообще NULL'ы не хранить и если последние поля в конце строки(row) то их и не хранят,т.е. не занимают вообще места. Поэтому если зная это размещать опциональные nullable поля последними, то и размер базы уменьшается и нагрузка на процессор снижается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 16:20 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
xtenderесли зная это размещать опциональные nullable поля последними, то и размер базы уменьшается и нагрузка на процессор снижается. Ну да, на каждый NULL же тратится целый бит. Или всё ещё байт?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 16:28 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov, ты меня про MS SQL спрашиваешь? Не знаешь сколько там тратится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 16:29 |
|
||
|
Миграция с Oracle на Postgres
|
|||
|---|---|---|---|
|
#18+
А вообще этот вопрос не стоит и выеденного яйца - захочешь индексировать null'ы - сможешь, оракл дает несколько возможностей. А в целом, вопрос этот чисто архитектурный и никоим образом не является минусом. Он очень схож с архитектурным подходом с EAV - хранить ли NULL в EAV и при каких условиях, т.е. заводить ли лишнюю строку в EAV-таблице если value является null: иногда выбирают что надо, иногда - нет... зависит от... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.03.2016, 16:33 |
|
||
|
|
start [/forum/topic.php?fid=35&startmsg=39181762&tid=1552283]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
| others: | 11ms |
| total: | 157ms |
| 0 / 0 |
