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

Откуда:
Сообщений: 98
Ну вот, решился на свой первый топик на этом сайте. Итак.
Стою сейчас на распутье перед началом нового своего проекта - дошёл до выбора БД. Поэтому необходима помощь людей имеющих опыт работы в указанных в сабже системах.
Будущая база будет заточена в основном на работу с матетматикой. Каждая транзакция - статистический (несложный но большой по объёму данных - матожидание, СКО, и т.д.) анализ по уже накопленным данным - вычисление некоего ответа и добавление небольшого объёма по результатам вычислений. Будут, понятно, и другие типы - более пространные отчёты, затейливые выборки - но время их выполнения некритично.
Точную структуру описать не готов, но примерно в части, критичной ко времени обработки - не более десятка таблиц. Данные - в большинстве своём числовые типа int. В каждой таблице не более миллиона записей, полей - не более 5.
Пользование услугами данной системы будет платное (это важно) поэтому вопрос по стоимости лицензионной чистоты тоже важен. То есть сколько денег будет стоить лицензия с правом коммерческого использования.
Пиковая нагрузка - не более 5 запросов в секунду.
Итак, интересует у кого выше/лучше:
-устойчивость
-производительность при описанных условиях
-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)
-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

Да работать будет под Linux при разработке и под FreBSD (возможно) после запуска
заранее спасибо за ответы. если чего не написал - спрашивайте
14 янв 05, 13:08    [1244933]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, mef!
Ты пишешь:

mef
m> Пиковая нагрузка - не более 5 запросов в секунду.
m> Итак, интересует у кого выше/лучше:
m> -устойчивость
достаточная
mef
m> -производительность при описанных условиях
тут сложно что-либо сказать,
ибо ты привёл мало информации.
Если исходить из размеров таблиц, то вполне.
mef
m> -масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа -
m> на 500 ниток, если надо 600 - докупаем ещё
m> один сервак, регистрируем в системе - и вперёд)
Это кластер.
Ни PostgreSQL, ни FireBird, кластеры не поддерживают.
У FireBird есть 2 архитектурных варианта: CS и SS.
SS - многопоточный, но однопроцессный.
CS - для каждого коннекта порождает отдельный процесс.
Тебе больше подходит вариант CS.
Он почти линейно масштабируется на SMP.
mef
m> -удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

IBExpert. Для юзеров ExUSSR, у которых локаль 1251, он бесплатен.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 13:36    [1245083]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
1. FB это rule based оптимизатор, postgres - cost based
2. FB не гарантирует атомарность транзакции даже в пределах запроса, postgres помоему подерживает все уровни изолированости транзакций, кроме dirty read (sql92)
отсюда:

-устойчивость
у FB обещают инкрементный бэкап в 2.0, что у postgres незнаю.

-производительность при описанных условиях

см оптимизатор + в postgres можно нормально раскидывать нагрузку по файлам/дискам, так что все зависит скорее от ручек. у FB с этим (раскидыванием) кажется проблема. условия не жестокие думаю современный сервер такое легко вытянет.

-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)

это вам не oracle RAC, хотя наверно можно в организовать репликацию и на уровне апп-сервера балонсировать нагрузку. в postgres репликация отдельная, платная фича.

-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

ХЗ
14 янв 05, 13:38    [1245094]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Yo!!
Ты пишешь:

Yo!
FB не гарантирует атомарность транзакции даже в пределах запроса
Не 3.14зди

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 13:44    [1245122]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
Мимопроходящий и Yo - спасибо за быстрый ответ!
Насколько я понял, по Вашему мнению, приописанных мной условиях особой разницы между постгресом и firebird не будет, так как задачка незатейливая. Но вот замечание о транзакциях в FB меня насторожила - почитаю доки.
Тип лицензии мне больше нравится у postgreSQL, у FB я так и не понял - надо им платить или нет при комм использовании - надо подробнее изучить на досуге. Ситуация со средой разработки у Poastres меня приводит в уныние, так как лет 10 пишу под форточками. Видимо со временем пристрадаюсь.
Ещё раз спасибо всем
14 янв 05, 13:52    [1245157]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, mef!
Ты пишешь:

mef
m> Насколько я понял, по Вашему мнению, приописанных мной условиях особой разницы между постгресом и firebird не будет,
так как
m> задачка незатейливая. Но вот замечание о транзакциях в FB меня насторожила - почитаю доки.

Больше слушай бредни этого "специалиста".
mef
m> Тип лицензии мне больше нравится у postgreSQL, у FB я так и не понял -
m>надо им платить или нет при комм использовании - надо подробнее изучить на досуге.

Не надо никому ничего платить. FB полностью бесплатен для любого использования.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 13:56    [1245173]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
а IBExpert - онт только под Windows? на http://www.ibexpert.com/ только виндовая версия доступна ...
14 янв 05, 14:08    [1245225]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
>Не 3.14зди

типа не пизди и не пиздим будешь :)

http://rsdn.ru/Forum/?mid=573511

>Ситуация со средой разработки у Poastres меня приводит в уныние, так как лет 10 пишу под форточками.

сурово :) т.е. слабость оптимизатора, проблемы транзакций, невозможность нормально использовать >1 проца, существенная разница в возможностях sql и stored процедур на вас производит меньшее впечатление ?
14 янв 05, 14:10    [1245235]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, mef!
Ты пишешь:

mef
m> а IBExpert - онт только под Windows?
m> на http://www.ibexpert.com/ только виндовая версия доступна ...

Да. Качай оттуда полный триал. http://www.ibexpert.com/download/ibet_2004.12.14.1_full.exe
А почему спросил про Windows?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:11    [1245238]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Yo!!
Ты пишешь:

Yo!
Y> типа не пизди и не пиздим будешь :)
Y> http://rsdn.ru/Forum/?mid=573511

И что?
Ты в суть дискуссии то вник, или выдернул только одну фразу?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:15    [1245256]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?
14 янв 05, 14:17    [1245267]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
Yo!
>
сурово :) т.е. слабость оптимизатора, проблемы транзакций, невозможность нормально использовать >1 проца, существенная разница в возможностях sql и stored процедур на вас производит меньшее впечатление ?

Я не совсем понял, кто на ком стоял :) Эти ужасы Вы про постгрес или про FB написали?
14 янв 05, 14:22    [1245285]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Yo!!
Ты пишешь:

Yo!
Y> просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?

Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.

Иди и дальше ори Оракл-форева.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:27    [1245317]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
про FB, но вообще вы сами должны бы сравнить, я просто указываю на что стоит обратить особое внимание при сравнении ...

ЗЫ. если, что FB это опен соурс interbase 6.5 с небольшими дополнениями.
14 янв 05, 14:27    [1245318]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Yo!!
Ты пишешь:

Yo!
ЗЫ. если, что FB это опен соурс interbase 6.5 с небольшими дополнениями.

Если что, то хорошо бы знать предмет о котором высказываешься.
Опять триндишь.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:28    [1245327]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
Мимопроходящий


Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.


прием тут delete ? вы уважаемый в курсе что такое ACID ?
14 янв 05, 14:33    [1245358]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Yo!!
Ты пишешь:

Yo!
Мимопроходящий

Y> Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Y> Ты же заявляешь вообще про атомарность транзакций.

Y> прием тут delete ? вы уважаемый в курсе что такое ACID ?

От тока не надо в позу становиться.
Повторяю для упёртых. Это известный косяк IB/FB.
Ты можешь указать другой?

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:41    [1245399]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Мимопроходящий
Повторяю для упёртых. Это известный косяк IB/FB.
Ты можешь указать другой?

Ничего себе косяк. Честно говоря я в шоке от такого косяка.
14 янв 05, 14:43    [1245409]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, ASCRUS!
Ты пишешь:

ASCRUS
A> Ничего себе косяк. Честно говоря я в шоке от такого косяка.

Не ты один
Разработчики FB тоже.
Но таково уж наследство IB.
Приходится обходить, пока не пофиксили.

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

14 янв 05, 14:45    [1245425]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Мимопроходящий

Привет, Yo!!
Ты пишешь:

Yo!
Y> просвети :) какая суть может оравдать зависимость ответа от порядка подзапрса в sql ?

Речь идёт он конкретном, известном косяке DELETE FROM T WHERE IN (SELECT FROM T).
Ты же заявляешь вообще про атомарность транзакций.


Совсем утрированые примеры:

Неатомарность update:

UPDATE table_name
SET a=b, b=a
(кстати, четко регламентировано в ANSI - значения после "=" вычисляются ДО внесения любых изменений)

Неатомарность INSERT:

INSERT INTO table_name
SELECT * FROM table_name
14 янв 05, 14:57    [1245499]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 601


Не ты один
Разработчики FB тоже.
Но таково уж наследство IB.
Приходится обходить, пока не пофиксили.


Это не косяк, а фича. Как сказал dimitr: "as designed" особенность сервера. Если знать про это то такой функционал даже полезен.

to Yo!
Оракле конечно форева, но там тоже косяков достаточно.
Просто привычка к определённому серверу провоцирует определённое мышление и когда в других серверах что-то не так начинается истерика и крики: отстой, сакс и т.д.

Просто мыслите категориями сервера и всё будет ОК.

to mef
По классу эти сервера примерно одинаковы. Однака PstgreSQL под винду вроде как работает только через Жопу, так что если сервер виндовый, то однозначно FB, если линух то ХЗ.
PS to ALL: Учите матчасть и относитесь к всему филосовски.





Posted via ActualForum NNTP Server 1.1

14 янв 05, 15:15    [1245583]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
AAron
Member

Откуда: Москва
Сообщений: 4324
я удивлен тем, что используется RBO, INSERT/UPDATE/DELETE - просто в шоке.
14 янв 05, 15:19    [1245604]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
protector
PS to ALL: Учите матчасть и относитесь к всему филосовски.

Давайте возьмем неисправный калькулятор и будет филосовски относиться к тому, что выдает 2+2=5. Есть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать. Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем, если СУБД до сих пор не в состоянии обзавестить нормальным стоимостным оптимизатором и народ ручками впихивает планы запросов ... не знаю, может быть для примитивных задач ее и можно использовать, но я пожалуй и в таких случаях уж лучше возьму Access MDB - там во всяком случае все работает так, как описано стандартом.
14 янв 05, 15:30    [1245654]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
2 protector
Сервер точно будет крутиться под линуксом или юниксом. И писАть тоже буду под ними. Правда, составлять запросы в командной строке или текстовом редакторе меня ломает (но не сильно) так что буду искать приемлимый для себя вариант с GUI
Из сред разработки нарыл пока только knoda - на досуге попробую, и напишу.
Плюс напишу, если не лень будет, историю установки для новичков типа меня - может кому потом пригодится.
14 янв 05, 15:42    [1245728]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
2All
Может у кого ещё другие варианты решений будут, чтобы потом мне локти не кусать? Если не трудно, конечно...
14 янв 05, 15:45    [1245748]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
слушайте я в этом топике кул как те слоны и указывал на конкретные технические фичи, хотя очень хотелось перейти на личности. ;)

автор

Просто привычка к определённому серверу провоцирует определённое мышление и когда в других серверах что-то не так начинается истерика и крики: отстой, сакс и т.д.


по теме - я полностью согласен с ASCRUS, уж лучше никак, чем отлаливать такие финты в коде своих сотрудников. ладно я про это знаю и запомню но как контролировать других ? а главное ради чего ?

P.S. вроде в течении месяца зщыепкуы должны выпустить 8рку, она вроде должна работать прямо под вынь.
14 янв 05, 15:49    [1245777]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 601

ASCRUS

Давайте возьмем неисправный калькулятор и будет филосовски относиться к тому, что выдает 2+2=5.

Давайте возьмём С++
for(i=0;i <10;i++) i--;

ASCRUS

Есть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать.

СУБД заявлять ничего не может - она вещь неодушевлённая. Заявлять могут люди. Кто такое сказал? В той или иной мере соответствует, здесь не соответствует. Ни одна из известных мне СУБД стандарта строго не придерживается, так уж повелось, что тут поделать.

ASCRUS

Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем,

Осторожнее с курсорами, а то как ораклоиды набегут.
Не разу не наблюдал в FB чтобы курсор в ХП был быстрее селекта. Всегда пользовался советом Кайта:
"пишите в ХП только то, что нельзя сделать запросом". Хотя увлечение ХП с сервером не связано. Это скорее сдвиг фазы у разработчика начём бы он не писал...

ASCRUS

если СУБД до сих пор не в состоянии обзавестить нормальным стоимостным оптимизатором и народ ручками впихивает планы запросов ...

Никогда таким онанизмом как написание планов руками не занимался. Хотя есть грех, планы не всегда оптимальны. Тут соглашусь.

ASCRUS

не знаю, может быть для примитивных задач ее и можно использовать, но я пожалуй и в таких случаях уж лучше возьму Access MDB - там во всяком случае все работает так, как описано стандартом.

Это каким же таким стандартом? Вы сами дано на Акцесе писали? Не смешите меня...
К тому же я Вам не запрещаю брать Акцесс: пользуйтесь на здоровье, только как же Вы без любимой Sybase ASA? Ломка не начнётся?

Posted via ActualForum NNTP Server 1.1

14 янв 05, 15:53    [1245799]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
Я с постгресом не работал реально, но способности его себе представляю.
В совокупности серверные возможности постгреса шире чем FB, причё значительно.
По всяким клиентским библиотекам и инструментам разработчика всё наоборот.
Для меня у FB есть огромное преимущество: костяк его разработчиков - "наши" люди, т.е. с простор СНГ. Поэтому получить квалифицированную помощь или ускорить фиксинье бага намного проще - в этом я уже убеждался неоднократно.

Что касается RAD-средств средств разработки под иксы - выбор не велик. Из OpenSource наиболее продвинутый lazarus (клон дельфи). Есть компоненты UIB, позволяющие работать с FB. Для постгреса нормальных не видил.

PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?
14 янв 05, 15:57    [1245810]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Тяжелый случай. СУБД не соблюдает релляционную алгебру и меня тут пытаются убедить, что это вполне нормально.

автор
Это каким же таким стандартом? Вы сами дано на Акцесе писали? Не смешите меня...
К тому же я Вам не запрещаю брать Акцесс: пользуйтесь на здоровье, только как же Вы без любимой Sybase ASA? Ломка не начнётся?

Не так эмоционально пожалуйста. Для того круга задач, где я использую она ASA - она супер-любимая моя. Для случаев, где будет достаточно примитивной, но бесплатной СУБД спокойно можно использовать проверенные MySQL, Access, MSDE, но уж явно не Interbase при таких раскладах. Я слишком стар для таких приколов.
14 янв 05, 16:01    [1245838]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
автор

PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?


cost based опирается на статистику и раставляет cost для каждой операции, далее выбирает запрос у которого наименьший cost. rule based просто по зашитым правилам пашет. если коротко, то в оракле есть RBO но его не юзают как только появился CBO (кажется в 7.3), разница в поведении просто огромна, если интересно есть туча подробностей в оракловой ветке.
14 янв 05, 16:05    [1245859]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Gold
PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?

Если сказать примитивно, то rule действует по принципу - если в запросе есть поля, на которые построены индексы, то используем их, иначе используем перебор таблицы.

Cost оптимизаторы ведут статистику по таблицам и индексам, и при построении плана запроса интеллектуально рассматривают в зависимости от значений данных по статистике, нагрузке сервера, доступности свободного кэша, наличия разнообразных индексов множество вариантов построения плана запроса, учитывая различные алгоритмы соединений, фильтров и группировок и такие различные характеристики, как время доступа к накопителю, памяти, кол-во чтений, записей и т.д., фактически присваивая каждой операции стоимость и в итоге выбирают тот план запроса, который имеет наименьшую стоимость и соотвествующе наиболее выгоден для выполнения запроса. В итоге оптимизатор адекватно реагирует на запросы и в зависимости от ситуации спокойно может генерить при выполнении различные планы запросов для одного и того же запроса, наиболее выгодные на момент его выполнения.
14 янв 05, 16:09    [1245877]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
Gold
PS А чем отличаются rule based оптимизатор и cost based. Какие преимущества и недостатки кратко?

Кратко - rule based оптимизатор опирается на структуру данных. Cost based оптимизатор опирается на данные.

Посмотрите простой пример - consistent gets, которые я оставил в статистике - это логические чтения. В данном случае они идут из памяти, поскольку таблица только создана - но значения показывают пропорцию потенциальных дисковых операций.

Cost-based оптимизатор гибко реагирует, подстраиваясь к разным значениям параметра. Rule-based оптимизатор покажет ту же стоимость в хорошем случае, но выбранный им план неудачен для второго запроса - тот нагрузит сервер в полтора раза больше.

Можно привести и более яркие примеры, но я попытался сделать максимально простой, максимально рядовой случай.

SQL> create table stat (i integer, j integer, k integer);

Table created.

SQL> insert into stat select rownum, rownum, rownum
  2  from dba_objects, dba_objects where rownum <= 1000000;

1000000 rows created.

SQL> create index stat_i on stat (i);

Index created.

SQL> select max(j) from stat where i<=10;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1 Bytes=10)            
   1    0   SORT (AGGREGATE)                                                    
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'STAT' (Cost=4 Card=10           
          Bytes=100)                                                            
                                                                                
   3    2       INDEX (RANGE SCAN) OF 'STAT_I' (NON-UNIQUE) (Cost=3 Ca          
          rd=10)                                                                

Statistics
----------------------------------------------------------                      
          4  consistent gets                                                    

SQL> select max(j) from stat where i<=900000;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE (Cost=169 Card=1 Bytes=10)          
   1    0   SORT (AGGREGATE)                                                    
   2    1     TABLE ACCESS (FULL) OF 'STAT' (Cost=169 Card=900001 Byte          
          s=9000010)                                                            
                                                                                
Statistics
----------------------------------------------------------                      
       2753  consistent gets                                                    

SQL> select /*+ RULE */ max(j) from stat where i<=900000;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=HINT: RULE                                 
   1    0   SORT (AGGREGATE)                                                    
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'STAT'                           
   3    2       INDEX (RANGE SCAN) OF 'STAT_I' (NON-UNIQUE)                     

Statistics
----------------------------------------------------------                      
       4477  consistent gets                                                    
14 янв 05, 16:16    [1245908]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Gold
Member

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


Ну многое из вышеперечисленного FB также использует.

Тогда получается что если Postgres и другие серверы учитывают все вышеперечисленные показатели, то подготовка запросов сильно тормозит в этих серверах? Также не понятно мне с кэшированием команд. Как кэширование команд увязывается с генерированием разных планов на каждую команду?

PS Не всё так плохо в FB как может показаться из этого обсуждения. :-)
14 янв 05, 16:20    [1245927]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
В общем по оптимизатору FB я не спец. Может кто-то из гуру FB или разработчиков замолви слово за оптимизатор? Он в FB какой?
14 янв 05, 16:27    [1245970]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
В IB\FB оптимизатор комбинированный. Изначально был чисто стоимостный, но в Борланде его перехерили.
14 янв 05, 16:27    [1245974]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
спецам по FB: а как там лог транзакций выглядет, как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ? еще есть ли репликация? если да то двунаправленая или только в одну сторону ?
14 янв 05, 16:33    [1246002]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
Самое начало никто из присутствующих уже не помнит, допустим. Но мои наблюдения показывают, что он всегда был смешанным. Только за последние годы в борланде его "смешали" еще сильнее ;-)
14 янв 05, 16:33    [1246004]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 601

ASCRUS

Тяжелый случай. СУБД не соблюдает релляционную алгебру и меня тут пытаются убедить, что это вполне нормально.

СУБД это не мат модель, а реальная система хранения данных. Тут уже неоднократно возникали такие споры реляцинные СУБД на самом деле или нет. Толку от этого никакого. СУБД в первую очередь должна справляться с посталенными задачами, а не соблюдать абстрактную РА, которая кстати и так не соблюдаются. А как же ваш любимый WITH RECURSIVE в ASA или CONNECT BY в Оракуле? Их нет в реляционной алгебре. Индексы вообще какое отношение имеют к РА? Навигационный метод, который так любят ораклоиды вообще к математике никакого отношения не имеет?
Я не пытаюсь Вас убедить, убедить можно не каждого, просто треплюсь по теме.
Да считаю такое положение вполне нормальным. Пока сервер справляется с поставленными задачами и удовлетворяет заказчика, то пусть хоть вместо SQL у него будет матерная брань. а вместо таблиц кубики 3X3.

ASCRUS

Не так эмоционально пожалуйста.

NP всё в порядке. Спасибо, что так волнуетесь о моём душевном сосотоянии...

ASCRUS
Для того круга задач, где я использую она ASA - она супер-любимая моя.

"Любимая"?.... хм... значит Вы признаёте, что не объективны?

ASCRUS

Для случаев, где будет достаточно примитивной, но бесплатной СУБД спокойно можно использовать проверенные MySQL, Access, MSDE, но уж явно не Interbase при таких раскладах.

Во первых Акцесс не бесплатен - это раз. Если Вы проверяли MySQL и MSDE и они подходят для таких случаев, опять же повторю: пользуйтесь на здоровье. К сожалению, когда я выбирал СУБД не удосужился сравнить MSDE с FireBird. Отпугнула непереносимость на Linux. Но ничего, выберу время сравню. Если MSDE действительно лучше то что мешает взять манатки и махнуть туда.
ASCRUS

Я слишком стар для таких приколов.

Юмор продлевает жизнь! (c)
А может на пенсию? А? Отдохнёте, подлечитесь...

Posted via ActualForum NNTP Server 1.1

14 янв 05, 16:36    [1246017]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
protector
Юмор продлевает жизнь! (c)
А может на пенсию? А? Отдохнёте, подлечитесь...

Ну как вот появиться достойная замена, пойду на пенсию :)
14 янв 05, 16:49    [1246082]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ЛП
Guest
2 protector
Во первых Акцесс не бесплатен - это раз.

Не пи***те чего не знаете. Как БД - вполне себе бесплатен.
Это во первых.

Во-вторых. Никто не запрещает поддерживать какие-либо расширения стандартного SQL (всякие там Connect By и прочее). С ограниченной поддержкой стандарта также приходится мириться, действительно в полной мере никто не поддерживает. Но реализовывать что-то неправильно - это уже полная жопа. Уж лучше пусть калькулятор не будет уметь умножать и делить, чем будет бред выдавать.
14 янв 05, 16:53    [1246095]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mozheyko_d
Member

Откуда: Мутноводск
Сообщений: 489
Кстати тема была Postgre vs Firebird.

Я тут пару недель назад тоже пришёл к этой вилке, пока ещё не выбрал, но судя обилию ругани в адрес ЖарПтицы и отсутствию в адрес Постгре, начинаю склоняться к последнему.
Или кто-то может поругаться на него ?
14 янв 05, 16:56    [1246119]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
Yo!
спецам по FB: а как там лог транзакций выглядет, как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ? еще есть ли репликация? если да то двунаправленая или только в одну сторону ?
Парень, ты вообще в курсе - что такое FB и как он работает ?
Сильно вопросы твои пахнут... как твои же утверждения в этом топике выше ;)

Лог никак не выглядит - нет его. Читай про версионность.
Соответственно защищать\дублировать нечего ;)
Бекап - до FB 2 только полный онлайн бекап. В FB2 - ещё и инкрементный страничный.
Рековери - если ты про накат лога после сбоя, то такого процесса нет, т.к. см выше
Репликация - встроенной нет. Есть отдельные продукты, её обеспечивающие
14 янв 05, 17:00    [1246157]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
ASCRUS
Есть стандарт SQL и если СУБД заявляет что она его поддерживает, то она должна его поддерживать. Если же она не поддерживает такие примитивные вещи, если ее разработчики называют "это" косяком и в оправдание говорят: типа зачем это нужно, мы все равно все в циклах (курсорах) гоняем...


Честно говоря, я с трудом представляю, что делать производителю СУБД, выпускающему несколько лет продукт, когда появляется некий "стандарт" (или очередная его итерация), который все должны поддержать. Вот все и плодят всякие диалекты и ключики, что есть гемор. Но деваться некуда. Тут можно не отвечать, это риторика ;-)

Насчет DELETE (впрочем, и INSERT тоже) - это косяк, заложенный в движок изначально. Нет в IB/FB поддержки statement stability. Впрочем, тут некоторые ругались на тему ACID и кривой поддержки уровней изоляции... это оставляю на их совести. Насчет UPDATE - затрудняюсь сказать. Вроде есть спецификация, но ИМХО когда-то это запросто могло быть vendor defined. Самое страшное, что на обе багофичи завязаны народные массы. Ну, чтож, значит опять ключики :-(

А насчет запоминать такие "страшные" вещи - это проблема для мигрантов и мультисерверников. Ты ведь в своем ASA знаешь почти все "от и до"... вот и в IB точно также помнят про эти грабли и не наступают... ибо жить они практически не мешают.

Закончу тем, что "разработчики" эти проблемы не особо и оправдывали. И не вижу ничего плохого в том, чтобы называть известные проблемы "косяками" ;-)
14 янв 05, 17:05    [1246183]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Yo!
Guest
>Или кто-то может поругаться на него ?

поругать ? да легко :)
1. главная фишка что его нельза поставить по дефолту и начать работать, придется почитать мануал и хотябы одэкватно настроить память и привыкать к command line.
2. нет человеческого админского тула, зато есть некая RedHat database это тот же postgres но с графической тулзой для администрирования. дают ее вместе с RHEL, но на меня она произвела удручающее впечатление уж лучше command line.
14 янв 05, 17:07    [1246190]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Yo!
спецам по FB: а как там лог транзакций выглядет,

Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком.
И при этом придумывают протоколирования действий на триггерах,
какие-то исскуственные схемы для реализации наката.
(см http://www.ibase.ru/devinfo/doc_calford_1.htm)
Yo!

как можно ли его защитить (продублировать) и как выглядет бэкап и рековери ?

Есть утилита для бэкапа gbak. Делает только полный бэкап. При этом крайне рекомендуется после
бэкапа сделать контрольное восстановление, ибо в FB есть такое понятие, как
Невосстановимый бэкап
(sic!)


Инкрементальный бэкап будет только в FB 2.
Yo!

еще есть ли репликация? если да то двунаправленая или только в одну сторону ?


Штатных средств репликации нет. Есть великое множество сторонних репликаторов, но количество не означает качество.

Для более подробной информации рекомендую
http://ibase.ru
- главный российский сайт по IB/FB/Ya
14 янв 05, 17:10    [1246205]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ЛП
Guest
hvlad
Лог никак не выглядит - нет его. Читай про версионность.

А если есть лог - то это блокировочник что-ли получается?
Мои поздравления ораклоидам

Александр Гoлдун
Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком.

Мдя... Ну и многим фанатам IB тоже поздравления
14 янв 05, 17:13    [1246223]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mozheyko_d
Member

Откуда: Мутноводск
Сообщений: 489
Yo!
1. главная фишка что его нельза поставить по дефолту и начать работать, придется почитать мануал и хотябы одэкватно настроить память


Ну это IMHO относится ко всем СУБД. Особенно к хвалёному Oracle.

Yo!
и привыкать к command line.
2. нет человеческого админского тула, зато есть некая RedHat database это тот же postgres но с графической тулзой для администрирования. дают ее вместе с RHEL, но на меня она произвела удручающее впечатление уж лучше command line.


Ну это не пугает. Кстати FB тоже GUI встроенного не имеет. IBExpert под Линух не видел, а все найденные под Линух тулзы это слёзы.
14 янв 05, 17:14    [1246224]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
mozheyko_d
судя обилию ругани в адрес ЖарПтицы и отсутствию в адрес Постгре, начинаю склоняться к последнему. Или кто-то может поругаться на него ?


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

Если объективно, то самым серъезным недостатком Постгреса является отсутствие до недавнего времени родного win32-порта. В 8-ке он вроде наконец-то сделан, но релиза пока нет. В остальном неплох. Раньше про него много дурного писали, но вроде в различных подверсиях 7-ки потихоньку грабли правятся.

С FB можно отлично жить, если его умеешь готовить. У меня ни один проект не был загублен из-за "гиперстрашных косяков" или обилия ругани ;-)
14 янв 05, 17:21    [1246246]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Да жить можно с чем угодно, если знать что это и как бороться. Но вот зачем человеку рекомендовать то, что заведомо ему неподходит (возвращаясь к теме топика) и который судя по всему не знает как бороться с "косяками" (раз поднял такую тему) - я не понимаю. Это отдает фанатизмом, а не здравым смыслом.
14 янв 05, 17:26    [1246270]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mozheyko_d
Member

Откуда: Мутноводск
Сообщений: 489
dimitr

Если объективно, то самым серъезным недостатком Постгреса является отсутствие до недавнего времени родного win32-порта. В 8-ке он вроде наконец-то сделан, но релиза пока нет.


Windows не интересует.

dimitr
В остальном неплох. Раньше про него много дурного писали, но вроде в различных подверсиях 7-ки потихоньку грабли правятся.


А чё за грабли?
14 янв 05, 17:28    [1246277]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Но вот зачем человеку рекомендовать то, что заведомо ему неподходит
Уверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS
14 янв 05, 17:31    [1246291]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
Александр Гoлдун
Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.


Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.
14 янв 05, 17:36    [1246308]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
hvlad
ASCRUS
Но вот зачем человеку рекомендовать то, что заведомо ему неподходит
Уверен ?
"Это отдает фанатизмом, а не здравым смыслом" (c) ASCRUS

Во первых мы на "ТЫ" вроде как не переходили. Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии). В третьих полностью уверен благодаря приведенным в данном топике примерам. В четвертых цитировать кого либо мало - необходимо вдумываться. Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял, всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы, откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
14 янв 05, 17:52    [1246393]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
dimitr
Александр Гoлдун
Никак!!! Его просто нет! Причем многие фанаты IB считают это достоинством, а не недостатком. И при этом придумывают протоколирования действий на триггерах, какие-то исскуственные схемы для реализации наката.


Саш, ну ты-то хоть не путай народ. Ты ведь говоришь про redo log, а фанаты - про undo. Необходимость второго в версионнике - нонсенс. А вот первый весьма бы не помешал для incremental recovery. И с этим никто не спорит, собственно.


Сам прочитал и ужаснулся, как сгустил краски ;)))

Да, я про redo, а не undo. Но undo - это чисто технический момент и он меня, как пользователя сервера БД, не очень интересует, как он откатит транзакцию - лишь бы откатил. А вот без практического потребительского использования redo жить не могу.

IMHO у FB главное преимущество - местное сообщество его пользователей и свои же родные разработчики, с которыми можно тут же пообщаться, как вот с тобой, например ;) И которые, как ни странно, наиболее критично из всего FB-сообщества относятся к этому серверу.
Но это в первую очередь потенциал на будущее. А пока FB еще есть куда расти.

Кстати, вопрос: в FB2 уже будет распараллеливание запросов при общем кэше?
14 янв 05, 17:57    [1246418]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Во первых мы на "ТЫ" вроде как не переходили.
imho это общепринято, ок, будем на Вы (если вообще будем)

ASCRUS
Во вторых переход на личности осуществляется участниками за недостатком аргументов (это к слову о предыдущих на меня выступлениям по поводу пенсии).
Это Вы про что ?

ASCRUS
В третьих полностью уверен благодаря приведенным в данном топике примерам.
Ок

ASCRUS
В четвертых цитировать кого либо мало - необходимо вдумываться.
Так же как и вдумываться в смысл\отсутствие смысла тех самых "примеров"

ASCRUS
Ну и в последних - я не очень понимаю, чего так реагировать, вроде как никто интербейсников в ущербности продукта не обвинял
Мне что - опять цитировать ? ;)
И где с моей стороны "такая" реакция ?

ASCRUS
всего лишь перечислили факты и каждый для себя сделал соотвествующие выводы
Фактов практически не было

ASCRUS
откуда такой возник комплекс неполноценности лично у Вас - ведь другие специалисты Interbase в этом топике вроде как адекватно реагируют на все высказывания, признают недостатки и подчеркивают его достоинства.
У Вас ещё и диплом психоаналитика ?

Все вопросы - риторические, можно не отвечать
14 янв 05, 18:12    [1246496]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
Страшен пятничный флейм, бессмысленный и беспощадный (с)

ЗЫ. Это я вместо финала ;-) Хотя шибко сомневаюсь, что автору топика мы сильно помогли...
14 янв 05, 20:36    [1246760]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
А почему выбор именно между FireBird 1.5.2 и PostgreSQL 7.4?

mef

Пользование услугами данной системы будет платное (это важно) поэтому вопрос по стоимости лицензионной чистоты тоже важен. То есть сколько денег будет стоить лицензия с правом коммерческого использования.


Оба упомянутых сервера бесплатны. Но если проект коммерческий, то может есть смысл не ограничиваться этими серверами, а расмотреть еще и коммерческие и все тщательно взвесить?
В моей личной практике в большинстве проектов стоимость сервера компенсировалась с лихвой уменьшением стоимости разработки и сопровождения по сравнению с использованием бесплатных серверов.
14 янв 05, 21:08    [1246788]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Рыжий Кот
Member

Откуда: Мягкий Диван; [забанен] Рустамом; [разбанен] П02;
Сообщений: 21678
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

Картинка с другого сайта.
15 янв 05, 00:43    [1247146]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Рыжий Кот
Странно, почему-то Sad Spirit отсутствует :), тема самая что ни на есть его! (наверное после праздников все никак не отойдет)

Спасибо за трогательную заботу о моём здоровье. ;)

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

Gold

Тогда получается что если Postgres и другие серверы учитывают все вышеперечисленные показатели, то подготовка запросов сильно тормозит в этих серверах? Также не понятно мне с кэшированием команд. Как кэширование команд увязывается с генерированием разных планов на каждую команду?

Угу, подготовка "тормозит", зато выполнение ускоряется. ;) А с кэшированием действительно могут быть проблемы, если для разных значений, подставляемых в закэшированный запрос, сильно отличается распределение данных, про это в доках написано

dimitr

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

Слова насчёт процента заюзанности неплохо бы подтвержать ссылками на какую-никакую статистику. В коммерческой сфере: PostgreSQL сейчас поддерживают Red Hat, Fujitsu и совсем недавно Pervasive. Про фанатиков --- чистая правда: как в интернете не устроят опрос про "любимую OpenSource СУБД" --- с большим отрывом выигрывает Firebird. ;)

mozheyko_d

А чё за грабли?

Была куча всяких неприятных ограничений: из-за отсутствия лога транзакций данные в таблицу принудительно скидывались после каждого COMMIT'а, размер строки был ограничен 8кб, операция сборки мусора полностью блокировала таблицу. Где-то с версии 7.3 таких ограничений уже не было и продукт стал вполне пригоден к весьма серьёзной эксплуатации. Версия 7.3 вышла в конце 2002, оставим вопрос "а где тогда были остальные OpenSource СУБД" в качестве упражнения для читателей.

к исходному вопросу, скажу за PostgreSQL:
mef

-устойчивость
-производительность при описанных условиях

судя по имеющемуся описанию, на нормальном железе всё это будет работать вполне нормально.


-масштабируемость (обработка нитями - грубо говоря типовая конфигурация железа - на 500 ниток, если надо 600 - докупаем ещё один сервак, регистрируем в системе - и вперёд)

полноценной multi-master репликации нету и вряд ли будет до версии 8.1.
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.


-удобство разработки (в идеале - визуальные среды разработки запросов и ХП)

Это вряд ли. :)

Кроме того, я где-то что-то слышал про процедурный язык pl/r для PostgreSQL, он вроде бы специально приспособлен для такой обработки, о которой шла речь в исходном сообщении.
15 янв 05, 12:59    [1247423]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
nik_x
Member

Откуда:
Сообщений: 1887
[quot Sad Spirit]
...
Но вертикальная масштабируемость хорошая, так что можно просто поставить более мощный сервер.

[quot ]

А что, уже выпустили Embedded Posgres, такой как в FB?
15 янв 05, 14:03    [1247467]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mv
Member

Откуда:
Сообщений: 8876
Уважаемый mef !
Описанные в начале ветви требования эмулируются с вполне допустимыми трудозатратами.
Впрочем, может быть, спросивший mef больше интересуется психоанализом, чем техническими особенностями выбираемого инструментального средства.

Я активно использовал совсем немного СУБД - FoxPro (ну, не СУБД, но очень похоже), Access, InterBase и MS SQL. Несмотря на сегодняшнюю мою приверженность к InterBase не могу сказать, что хотя бы одна из перечисленных система не удовлетворяла моих потребностей на момент ее использования.

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

Более того, если здесь Вы спросите по поводу того, что один из результатолв тестов не удовлетворяют Вас в чем-то, то здесь Вы моментально получите совет и рекомендацию. Только спрашивать об InterBase нужно в разделе InterBase, а о MS SQL - в разделе MS SQL.
16 янв 05, 20:35    [1248292]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
16 янв 05, 22:55    [1248384]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, Cat2!
Ты пишешь:

Cat2
C> На SQL.ru принято обращаться на "Вы".
За исключением форумов Просто Треп и AREA-51.

Опять, Кот, самодурствуешь?!
Где это в правилах?!
Нету?
Ну и нех!

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

17 янв 05, 10:53    [1248908]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
Cat2
hvlad.
+++++++++++++++++++++++++
На SQL.ru принято обращаться на "Вы". За исключением форумов Просто Треп и AREA-51.
Это не отражено в правилах форума, посему каждый выбирает форму обращения по своему разумению.
Если собеседник возражает, это его право. Ничего оскорбительного я в этом не вижу.
17 янв 05, 10:55    [1248921]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

Я понимаю версионность Оракла в том плане, что она позволяет во время изменения записи читателям работать с ее оригинальной версией, но писатели там друг друга блокируют (что есть правильно). Но вот зачем делать версионность писателей и из за этого получать такую сложную модель физической реализации движка я понять не могу. Буду очень признателен, если просветите по этому вопросу или же поправите меня там, где я ошибаюсь. Как говорится учиться ни когда не вредно, во всяком случае меня интересуют различные модели реализации поддержки уровней изоляции в блокировочниках и версионниках, их механизмы работы и достоинства и недостатки. Пока вот для меня модель версионности Interbase загадка, хотя я честно почитал на эту тему различную литературу, выложенную на ibase.ru и вроде как чего то понял.
17 янв 05, 11:06    [1248983]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32997

Привет, ASCRUS!
Ты пишешь:

ASCRUS
A> Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я
понял, что
A> версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки, то есть поддерживается версионность для
A> изменений записи ? Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?

http://www.ibase.ru/devinfo/versions.htm

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.1

17 янв 05, 11:13    [1249021]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Кстати хотелось бы задать вопрос для знатоков Interbase чисто из за познавательных побуждений - правильно ли я понял, что версионность в нем означает, что на DML команды нет понятия эклюзивной блокировки
В том смысле, как в MS - нет такого понятия, ибо оно не нужно.

ASCRUS
то есть поддерживается версионность для изменений записи ?
Нет.

ASCRUS
Если это так, то зачем это сделано - ведь логического смысла в такой версионности нет ?
Ага

В любой момент времени может быть не более одной активной версии записи. Версия активна, если создавшая её тр-ция не находится в состоянии commited. Каждая версия каждой записи помечена номером создавшей её тр-ции. Движок знает о состоянии всех тр-ций в любой момент времени.

Если кто-то пытается создать вторую активную версию записи, то он либо ждёт завершения конкурирующей активной тр-ции, либо сразу получает ошибку lock conflict on no wait transaction. Это зависит от пар-ра wait\no wait тр-ции.

Штатно можно зарезервировать (заблокировать) всю таблицу от чтения и\или записи.
Запись можно "заблокировать" от изменений, просто проапдейтив её. "Блокировка" будет снята после завершения тр-ции.
В FB1.5 ввели спец. конструкцию SELECT .. WITH LOCK, делающую холостой апдейт записи в момент её фетча и не приводящий к срабатыванию триггеров.

PS Ничего, что я цитирую ? ;)
17 янв 05, 11:51    [1249184]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
PS Ничего, что я цитирую ? ;)

Наоборот, спасибо. Приведенную выше ссылку я уже читал, но решил, что лучше уточнить, чем делать выводы исходя из того, что понял :) Все таки тяжеловатый механизм - версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
17 янв 05, 12:10    [1249253]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
ASCRUS
версионность индексов это конечно круто, кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?

Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment. А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.
17 янв 05, 12:20    [1249294]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
Кластерный индексов действительно нет и их действительно сделать затруднительно. Да и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции. Можно сделать полную версионность в индексе, введя в ключ txn ID, но это приведет к модификации всех индексов при каждом изменении записи, даже если затронуты неиндексированные поля. Пока считается, что это слишком большая цена. Да и последующая сборка мусора в таком "загаженном" индексе будет заметно тяжелее, чем сейчас. Вот такова селяви насчет индексов в версионнике.
17 янв 05, 12:24    [1249307]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
ASCRUS
Все таки тяжеловатый механизм - версионность индексов это конечно круто
А кто тут говорил про версионность индексов ? ;)
Индексы - отдельная песня. Версий там нет. Когда появляется новый ключ (insert\update ключевых полей), он вставляется в b-tree. И всё.
Любой индексный метод доступа должен, после построения списка номеров записей-кандидатов, посетить запись и убедиться что она все ещё удовлетворяет критерию отбора и может быть видна читающей тр-ции.

На перый взгляд это снижает полезность индексов. Но такое построение, вместе с префиксным сжатием ключа, позволяет очень компактно хранить индексы на диске. Я как-то сравнивал с MS - выигрыш был в 2-3 раза на одних и тех же данных. Это значительно снижает потребность в дисковых операциях.

Единственный минус - невозможность использования индексного покрытия.

ASCRUS
кстати - я так понимаю кластерных индексов в IB нет (во всяком случае я не представляю себе, как их можно было бы реализовать при такой архитектуре) ?
Их нет потому что они не дадут столь большого выигрыша в призводительности, как у других серверов.
В FB любой индексный метод доступа сначала сканирует индекс, а потом читает таблицу. Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.
17 янв 05, 12:51    [1249420]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Хм. Боюсь, я не очень понимаю, в чем разница. Разница с архитектурой Oracle, судя по указанной статье - "старая версия записи" пишется куда-то в data file, в то время как Oracle использует rollback segment.


Оракл хранит не версии записей, а версии блоков, насколько я в курсе. Вот в Юконе версионность ближе к IB/FB, но и там версии лежат в tempdb, а не в основной базе.

softwarer
А Oracle спокойно использует "кластерные индексы" - соответственно, механизм работает. Как именно - сходу не скажу, надо смотреть доки.


Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...
17 янв 05, 12:55    [1249444]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
hvlad
Причём таблица читается в порядке номеров страниц, т.е. как кластерная таблица у MS.


Кстати, этот нюанс - вроде как один из плюсов IB/FB против Оракла. Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит. Сканирование с INDEX-планом на неуникальном индексе FB выполняет в два-три раза быстрее (при неполном кешировании данных сервером, есс-но), чем оракловый RANGE INDEX SCAN. Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN. Возможно, кто-либо здесь подтвердит или опровергнет это наблюдение.
17 янв 05, 13:03    [1249487]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Оракл хранит не версии записей, а версии блоков, насколько я в курсе.

Это так. Но я не вижу тут идеологически существенной разницы - имхо это технический момент. Плюс такого подхода, по моим представлениям, в том, что версионность получается как бы автоматической для всех объектов данных - ну и еще в том, что когда-то, до знакомства с Oracle, я писал движок на том же принципе :) Но версионность по записям вроде бы не мешает сделать то же.

dimitr
Мне кажется, тут проблема в производительности. Перелопачивать index organized table при каждом незакоммиченном изменении ключа... а потом перелопачивать обратно при сборке мусора после роллбека...

Хм. Я бы отметил так:

- В первую очередь, проблемы долгого rollback-а относительно неважны. То есть я не видел систем, где был бы удобен регулярный rollback - и я бы назвал такое неправильным дизайном даже в отрыве от архитектуры конкретной БД.

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

- перелопачивать index organized table или просто индекс - хм, не такая уж принципиальная разница. Единственно что IOT скорее всего в среднем значительно шире - но вопрос, какую роль это играет (я не помню сходу, делаются ли там "цепочки" или переносится полная запись).

- Перестраивать индекс при изменении данных все равно необходимо. Когда делать это - то ли при изменении данных, то ли при commit-е - вряд ли принципиально с точки зрения производительности именно этой операции. Зато версионный индекс может крайне ускорить работу, а IOT - как минимум, существенно экономит место и чтения.

Итог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.
17 янв 05, 13:38    [1249646]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Я специально делал замеры и вышел на вывод, что сортировку битмапа с DBKEY-кандидатами Оракл не производит.

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

dimitr
Возможно, отсюда сильная нелюбовь ораклового оптимизатора к RANGE SCAN - обычно выбирается либо UNIQUE SCAN (при возможности), либо HASH JOIN.

Хм. Это зависит от настроек и статистики, вряд ли возможно сформулировать такие простые и четкие правила. Если говорить об OLTP - RANGE SCAN лично я видел куда чаще, нежели HASH JOIN - возможно, из-за того, что последний потребляет относительно много памяти.

RANGE SCAN - операция, более тяготеющая к оптимизации FIRST_ROWS, HASH/MERGE JOIN - более тяготеющая к ALL_ROWS. С точки зрения FIRST_ROWS нежелание сортировать индекс полностью понятно, как понятно и нежелание тратить на это память. Нужен ли механизм доступа по rowid-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.
17 янв 05, 13:53    [1249724]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
DimaR
Member

Откуда:
Сообщений: 1570
to dimitr
Пусть меня поправят, но

RANGE SCAN - обычно выбирается либо UNIQUE SCAN
и
либо HASH JOIN.

вроде как разные вещи, первое это метод доступа к данным,
а второе способ объединения таблиц???
17 янв 05, 14:01    [1249747]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
DimaR
вроде как разные вещи, первое это метод доступа к данным,
а второе способ объединения таблиц???

Имеется в виду следующее: A JOIN B может быть выполнено как FULL TABLE SCAN (A) -> INDEX RANGE/UNIQUE SCAN (a->b) -> TABLE SCAN BY INDEX ROWID (B), а может - как FULL TABLE SCAN (A) -> HASH/MERGE JOIN <- FULL TABLE SCAN (B).
17 янв 05, 14:07    [1249779]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
- В первую очередь, проблемы долгого rollback-а относительно неважны. То есть я не видел систем, где был бы удобен регулярный rollback - и я бы назвал такое неправильным дизайном даже в отрыве от архитектуры конкретной БД.


Согласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент.

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


Тоже согласен.

softwarer
- перелопачивать index organized table или просто индекс - хм, не такая уж принципиальная разница. Единственно что IOT скорее всего в среднем значительно шире - но вопрос, какую роль это играет (я не помню сходу, делаются ли там "цепочки" или переносится полная запись).


Если цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.

softwarer
- Перестраивать индекс при изменении данных все равно необходимо. Когда делать это - то ли при изменении данных, то ли при commit-е - вряд ли принципиально с точки зрения производительности именно этой операции. Зато версионный индекс может крайне ускорить работу, а IOT - как минимум, существенно экономит место и чтения.


Если ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Насчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис.

softwarer
Итог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже.


Это относится почти к любой фиче любого сервера ;-)
17 янв 05, 14:11    [1249796]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
В Oracle довольно много написано по поводу CLUSTERING_FACTOR - полагаю, это именно то, что Вы искали. Так и есть - документация подчеркивает, что индексный доступ может привести к многократному чтению одного блока таблицы.


Да, это оно. IB/FB всегда читает каждый блок только один раз. Плюс читает их всегда в порядке физического расположения. Отсюда и разница в производительности этой отдельной взятой операции. Очевидным исключением является сортировка по индексу, есс-но.

softwarer
Хм. Это зависит от настроек и статистики, вряд ли возможно сформулировать такие простые и четкие правила. Если говорить об OLTP - RANGE SCAN лично я видел куда чаще, нежели HASH JOIN - возможно, из-за того, что последний потребляет относительно много памяти.


Я правила не рискну формулировать, уж шибко много факторов. Это были наблюдения. Даже при выборке из одной большой таблицы, оракл очень часто выбирает FULL SCAN вместо INDEX RANGE SCAN, даже для относительно неплохой селективности индекса и наличия менее десятка искомых значений в индексе (статистика свежая). При этом стоило выбрать значение из уникального поля, как сразу появлялся INDEX UNIQUE SCAN. Т.е. разница в 10-20 логических чтений уже заметно меняет картину.

softwarer
Нужен ли механизм доступа по rowid-сортировке в дополнение к существующим - не знаю и сходу не вижу способа найти однозначный ответ.


Тут я тоже не знаю ответа. Все таки у Оракла много альтернативных методов доступа к данным и вероятность подобрать более-менее хороший вариант довольно высока. У IB/FB с этим много хуже, поэтому качество индексного сканирования имеет бОльшее значение.
17 янв 05, 14:28    [1249881]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
dimitr
Да и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции.
"Невозможность index-only scan" имеет место и в постгресе. :(

А как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).
17 янв 05, 14:38    [1249937]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Согласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент.

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

dimitr
Если цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.

Можно пояснить поподробнее?

dimitr
Если ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда.

Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.

dimitr
Насчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис.

Хм. Насколько я понимаю, "первичный" фактор преимущества IOT - замена двух чтений (индекс + данные) одним. Дело тут не только в кластеризации, но и в элементарном хранении одних и тех же данных в двух экземплярах; в том, что IOT занимает меньше места, нежели table+index. Ожидаемый эффект от этого можно попробовать оценить, хотя я не слишком удивлюсь, если оценка будет "слишком мало, чтобы тратить на это силы".

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

dimitr
Это относится почти к любой фиче любого сервера ;-)

На это и намек ;-)
17 янв 05, 14:49    [1249995]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
LeXa NalBat
А как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).


Сборка мусорных версий происходит автоматически - либо во время чтения цепочки версий, либо отложенно (в фоне). Если слот на странице данных освободился (мусорные версии удалены), это место сразу помечается как свободное (доступное к новой записи). Т.е. никаких ручных операций выполнять не надо. Единственное исключение - глобальная сборка всего мусора в базе и продвижение состояния транзакций в TIP (transacton inventory page) - может выполняться или автоматом по мере замусоривания (порог настраивается для каждой базы) или вручную, отдельной программой (ночью, например).

Сбор статистики выполняется отдельной SQL-командой. Перестройка индексов возможна тоже через SQL, но на практике применяется крайне редко.

Реальное уменьшение размера базы (shrink/compact в терминологии других СУБД, т.е. перепаковка данных на страницах) не выполняется никогда. Единственный путь - полный backup/restore.
17 янв 05, 14:51    [1250006]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
К моему предыдущему посту - ни одна из описанных операций не блокирует работу других коннектов.
17 янв 05, 14:54    [1250023]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
LeXa NalBat
А как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки).
Сборка мусора выполняется (вкратце)
- в фоне самим сервером или при чтении "удалённых" записей (зависит от архитектуры сервера SS\CS, механизм не очень эффективен, в FB2 есть улучшения)
- Принудительно, по желанию пользователя - sweep

Рекомендуется делать ежедневный sweep, это 1) + 4) в вышеназванных терминах, если я их правильно понял.

Сбор статистики - по желанию. SET STATISTICS INDEX <index_name>

Перестройка индексов - никогда, а зачем ? ;)
Обычно, если БД сильно фрагментирована физически, делают бекап\рестор. Не чаще чем раз в 6-12 месяцев. Естественно, это зависит от интенсивности работы с БД.

Если кто-нибудь даст ссылку на документацию PostgreSQL'а о внутренних механизмах (или приведёт сюда русскоговорящего разработчика ;), можно будет сравнивать более предметно.
17 янв 05, 14:55    [1250030]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
Gold
Member

Откуда: Харьков
Сообщений: 2947
А какие-такие улучшения есть в FB 2 ?
Также мне не понятно будут ли в FB 2 двунаправленные индексы.
Ещё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ?
17 янв 05, 15:08    [1250114]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
softwarer
dimitr
Если ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда.
Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.
Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.

softwarer
Другой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен.
Индекс не сортируется в памяти - он отсортирован на диске ;) На самом деле строится битовая карта физических номеров записей. Она по-определению упорядоченна, занимает относительно немного места (разреженный битмап) и достаточно дёшево строится
17 янв 05, 15:15    [1250142]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
Gold
А какие-такие улучшения есть в FB 2 ?
Всяческие ;) imho, здесь это оффтоп ;)

Gold
Также мне не понятно будут ли в FB 2 двунаправленные индексы.
Нет

Gold
Ещё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ?
Да, и даже лучше ;)
17 янв 05, 15:20    [1250169]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Я правила не рискну формулировать, уж шибко много факторов. Это были наблюдения. Даже при выборке из одной большой таблицы, оракл очень часто выбирает FULL SCAN вместо INDEX RANGE SCAN, даже для относительно неплохой селективности индекса и наличия менее десятка искомых значений в индексе (статистика свежая). При этом стоило выбрать значение из уникального поля, как сразу появлялся INDEX UNIQUE SCAN. Т.е. разница в 10-20 логических чтений уже заметно меняет картину.

Полагаю, именно UNIQUE тут малосущественно - что собственно видно в приведенном ниже примере. CLUSTERING_FACTOR же - действительная существенная в Oracle причина неиспользования индексов.

SQL> create table clustered as select rownum a, rownum b, rownum c
  2  from dba_objects ;

SQL> create index clustered_i on clustered (a);

SQL> create table badclustered as select rownum a, rownum b, rownum c
  2  from dba_objects order by dbms_utility.get_hash_value(rownum,0,65536);

SQL> create index badclustered_i on badclustered (a);

SQL> select index_name, clustering_factor 
  2  from dba_indexes
  3  where owner = 'TEST' and index_name like '%CLUSTER%';

INDEX_NAME                     CLUSTERING_FACTOR
------------------------------ -----------------
BADCLUSTERED_I                             47520
CLUSTERED_I                                  129

SQL> select * from clustered where a between 0 and 1500;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (FULL) OF 'CLUSTERED'

Statistics
----------------------------------------------------------                      
        233  consistent gets                                                    
       1500  rows processed                                                     

SQL> select * from clustered where a between 0 and 1200;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'CLUSTERED' 
   2    1     INDEX (RANGE SCAN) OF 'CLUSTERED_I' (NON-UNIQUE)

Statistics
----------------------------------------------------------                      
        167  consistent gets                                                    
       1200  rows processed                                                     

SQL> select * from badclustered where a between 0 and 5;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE 
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'BADCLUSTERED'  
   2    1     INDEX (RANGE SCAN) OF 'BADCLUSTERED_I' (NON-UNIQUE)

Statistics
----------------------------------------------------------                      
          8  consistent gets                                                    
          5  rows processed                                                     

SQL> select * from badclustered where a between 0 and 8;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE  
   1    0   TABLE ACCESS (FULL) OF 'BADCLUSTERED' 

Statistics
----------------------------------------------------------                      
        134  consistent gets                                                    
          8  rows processed                                                     

SQL> drop index badclustered_i;

SQL> create unique index badclustered_i2 on badclustered (a);

SQL> select * from badclustered where a between 0 and 8;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE  
   1    0   TABLE ACCESS (FULL) OF 'BADCLUSTERED'              
                                                                                
Statistics
----------------------------------------------------------                      
        134  consistent gets                                                    
          8  rows processed                                                     

SQL> select * from badclustered where a between 0 and 5;

Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=CHOOSE 
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'BADCLUSTERED' 
   2    1     INDEX (RANGE SCAN) OF 'BADCLUSTERED_I2' (UNIQUE)

Statistics
----------------------------------------------------------                      
          8  consistent gets                                                    
          5  rows processed                                                     
17 янв 05, 15:25    [1250193]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Пожалуй, я не готов предметно рассуждать о мусоре в Oracle без консультации с документацией.


Я тем более не готов, применительно к Ораклу ;-) Хотя было бы познавательно.

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

softwarer
dimitr
Если цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая.

Можно пояснить поподробнее?


Свои слова про "значительно" беру обратно. Зависимость существует только от ширины IOT. Я почему-то сначала подумал не про b-tree хранение, а про непосредственное (последовательное) физическое упорядочивание данных в блоках.

softwarer
Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.


Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи. Отсюда вывод - если меняется запись другой транзакцией даже без изменения ключевых полей, то нужно добавить ключ во все существующие индексы - со старым значением и новым txn ID. Иначе поиск будет бессмысленным.

Я не сомневаюсь, что Оракл этого не делает ;-) У него все же заметно другая схема версионности.

softwarer
Хм. Насколько я понимаю, "первичный" фактор преимущества IOT - замена двух чтений (индекс + данные) одним. Дело тут не только в кластеризации, но и в элементарном хранении одних и тех же данных в двух экземплярах; в том, что IOT занимает меньше места, нежели table+index. Ожидаемый эффект от этого можно попробовать оценить, хотя я не слишком удивлюсь, если оценка будет "слишком мало, чтобы тратить на это силы".


Согласен.

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


Хммм. Теперь я прошу пояснить, что есть "постоянная сортировка индекса в памяти" и для чего это надо.
17 янв 05, 15:28    [1250218]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
hvlad
Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.

Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу.

Исходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.

hvlad
На самом деле строится битовая карта физических номеров записей.

Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.
17 янв 05, 15:36    [1250267]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
softwarer
hvlad
Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.
Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу.
Как раз IB так не работает, т.к. нет такого понятия, как версионный индекс

softwarer
Исходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.
Не понято. В индексе хранятся ключи + указатели на записи. "Адрес" записи при редактировании не меняется.
Что такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно.

softwarer
hvlad
На самом деле строится битовая карта физических номеров записей.

Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.
Нет! Данные индекса (ключи записей) не сортируются. "Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, разве что поиск (двоичный) в массиве (р-р которого меньше, чем кол-во эл-тов в нём ;). Цена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика
17 янв 05, 15:56    [1250362]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
hvlad
Перестройка индексов - никогда, а зачем ? ;)
REINDEX в PostgreSQL 7.4, REINDEX в PostgreSQL 7.3. По прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется.

hvlad
Если кто-нибудь даст ссылку на документацию PostgreSQL'а о внутренних механизмах
Вот дока по версии 7.4. "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :)
17 янв 05, 16:09    [1250426]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.


Эта информация лежит в версиях записей ;-) Т.е. либо приходим к тому, с чего начали (надо читать сами записи), либо осознаем необходимость дополнительно кешировать цепочку backversions вместо с их txn ID.

softwarer
Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.


Сортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа. Полагаю, что IOT действительно покажет себя лучше на больших выборках. Вот только насколько велик процент задач с большим объемом данных и неуникальными выборками только по кластерному ключу?
17 янв 05, 16:21    [1250504]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
LeXa NalBat
По прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется.


Чудно как-то. Скорее всего, имеется недоработка в PG.

LeXa NalBat
Вот дока по версии 7.4. "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :)


Немного там описано. Впрочем, официальная дока по IB содержит еще меньше информации ;-)
17 янв 05, 16:34    [1250610]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Причем после коммита нашей транзакции старая версия остается на диске, ибо ее может читать конкурирующая snapshot-транзакция, например. И убрать эту версию как мусор можно только по завершении всех заинтересованных транзакций.

Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment. При завершении транзакции блок становится "мусорным" - id транзакции позволяет другой транзакции перезаписать этот блок, когда ей потребуется место в RB. Другие транзакции могут читать этот блок до тех пор, пока он не будет перекрыт другой транзакцией; после этого попытка прочитать старый блок приведет к ошибке "snapshot too old" (по ней также легко найти много материала).

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

dimitr
Мы говорили про "чисто версионный индекс", который бы позволил index-only scan. Для этого в ключ индекса надо внести transaction ID, который бы позволил определить видимость данной записи без чтения самой записи.

Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.

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

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

dimitr
Хммм. Теперь я прошу пояснить, что есть "постоянная сортировка индекса в памяти" и для чего это надо.

Полагаю, ответ уже стал ясен. Насколько я понимаю, IB работает следующим образом

- получает из индекса адреса необходимых записей
- сортирует их (упоминалась битовая карта)
- забирает записи.

Вот это, полагаю, и есть неприятный момент при оптимизации FIRST_ROWS.
17 янв 05, 16:38    [1250633]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
hvlad
Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс


hvlad
Что такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно.

Вы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)

hvlad
"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит,

Битовая карта - это стандартный алгоритм сортировки :)

hvlad
Цена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика

Сканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.
17 янв 05, 17:10    [1250831]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Сортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа.

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

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

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

Но я не об этом. Я не собираюсь утверждать, что IOT будут полезны IB - местным виднее. Я скорее обратил внимание на эту сортировку как на потенциальное узкое место. IOT + несортируемые индексы дают возможность управлять этим моментом, хотя, бесспорно, управление грубовато. Оправданно ли более тонкое - не знаю; тут я послушал бы специалистов покруче себя.
17 янв 05, 17:22    [1250914]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment. При завершении транзакции блок становится "мусорным" - id транзакции позволяет другой транзакции перезаписать этот блок, когда ей потребуется место в RB. Другие транзакции могут читать этот блок до тех пор, пока он не будет перекрыт другой транзакцией; после этого попытка прочитать старый блок приведет к ошибке "snapshot too old" (по ней также легко найти много материала).


В курсе, натыкался я на нее. И не могу сказать, что был рад. В IB же она в принципе не может возникнуть.

К слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS? И еще - размер RS фиксирован админом или может динамически расширяться?

softwarer
То место, где его стоит иметь в виду - очень длинные fetch-и. То есть задание типа "создали курсор - профетчили запись - долго ее обрабатываем - профетчили следующую запись - долго ее обрабатываем - и так всю ночь" имеет реальные шансы напороться на эту ошибку.


Немаленький FOR-цикл с изменением и коммитом внутри - результат гарантирован в течении десятка минут. Для бОльшего размера RS - бОльший цикл.

softwarer
Вот здесь и кроется прелесть ораклового подхода. Индекс ничего не знает про какие-то версии. Механизм блоков просто умеет вернуть версию блока, соответствующую транзакции; соответственно, транзакция получает актуальный для нее индекс практически так же, как получает актуальные для себя данные. Transaction ID же учитывается в более внутренних, нежели индекс, структурах.


С удовольствием бы почитал на эту тему.

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


В текущем варианте хранения и обработки версий от этого отказаться не удастся.

softwarer
Насколько я понимаю, IB работает следующим образом

- получает из индекса адреса необходимых записей
- сортирует их (упоминалась битовая карта)
- забирает записи.

Вот это, полагаю, и есть неприятный момент при оптимизации FIRST_ROWS.


Для выборки в миллионы записей - так точно. В остальных случаях это незаметно.
17 янв 05, 17:30    [1250949]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
hvlad
Guest
softwarer
Вы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)
Нет такой терминологии, её в этом обсуждении придумали и тут же показали её минусы

softwarer
hvlad
"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит,
Битовая карта - это стандартный алгоритм сортировки :)
Ну, если так, то - да, есть сортировка ;)

softwarer
hvlad
Цена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика
Сканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу.
Здесь - да, FB не умеет выдавать записи по ходу сканирования индекса, т.е. FIRST_ROWS оптимизации в нём нет

softwarer
Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.
Строго говоря, всё не совсем так. Сначала читается индекс и по-ходу сортируются полученные номера записей (сортировка здесь очень дешёвая операция), затем записи посещаются и выдаются клиенту. Но не все, а по мере фетча.

Думаю, с этим вопросом уже все разобрались :)
17 янв 05, 17:35    [1250976]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Вы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)


Просто мы говорим о том, чего в IB нет, но типа могло бы быть ;-)

softwarer
Сканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.


Согласен. Чисто теоретически можно не сортировать битмап при хинте FIRST_ROWS, а выдавать адреса записей конвейерно. Вот только нету хинтов в IB ;-)
17 янв 05, 17:36    [1250980]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
К слову - как Оракл определяет, откуда брать блок? Есть какая-то внутренняя таблица txn ID, принадлежащих RS?

Чтобы ответить в деталях - надо искать. Полагаю, оптимальным будет спросить на форуме Оракла - там есть несколько человек, которые постоянно копаются на этом уровне.

dimitr
И еще - размер RS фиксирован админом или может динамически расширяться?

Может. Правда, насколько я в курсе, серьезные админы предпочитают работать руками.

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.

dimitr
Немаленький FOR-цикл с изменением и коммитом внутри - результат гарантирован в течении десятка минут.

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

В общем - это безусловно вещь, которую нужно знать. Но заметных проблем она не доставляет.

dimitr
С удовольствием бы почитал на эту тему.

На уровне технической реализации - увы, не ко мне. Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.
17 янв 05, 18:08    [1251160]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

Откуда: СПб
Сообщений: 19788
2 softwarer
Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO
17 янв 05, 18:28    [1251229]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
tru55

Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO

В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.
17 янв 05, 18:42    [1251275]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

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

Другой момент - начиная с Oracle9, появился некий Automatic Undo Management. Из интересных Вам фич - в этом случае есть возможность зафиксировать время, в течение которого блок не будет повторно использован. Также в этом случае идет полностью динамическое распределение места - в чем, правда, я вижу возможность минусов. В старом варианте я мог выделить транзакции rollback segment и быть уверен, что она отработает до конца; здесь же технически существует возможность проблем в моей супертяжелой транзакции из-за суммарной нагрузки текущих транзакций. Причем написать задание так, чтобы оно "переживало" такую проблему, будет не очень легко.


А

SET TRANSACTION USE ROLLBACK SEGMENT

никто не отменял, вне зависимости от UNDO_MANAGEMENT

К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют
17 янв 05, 18:45    [1251281]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
tru55
Member

Откуда: СПб
Сообщений: 19788
softwarer
tru55

Для этого у Oracle применяется механизм rollback segment-ов - странный на первый взгляд, но хорошо работающий (и полностью соответствующий философии сервера). В момент изменения старая версия блока помещается в rollback segment

Вот здесь как раз не rollback, а UNDO

В первую очередь, UNDO появляется только если выставить Automatic Undo Management, чего делать необязательно. Во-вторых же, UNDO Tablespace - это те же самые rollback segment-ы (их можно увидеть в системных вьюхах); просто их менеджментом (создание и прочее) занимается сервер.


Сорру, поспешил. Вопрос терминологии, просто в 9i используется термин "UNDO" вместо "ROLLBACK", причем вне зависимости от UNDO_MANAGEMENT, просто как понятие
17 янв 05, 18:50    [1251294]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
tru55
SET TRANSACTION USE ROLLBACK SEGMENT
никто не отменял, вне зависимости от UNDO_MANAGEMENT

Вы в этом уверены? ;-)

SQL> select * from v$rollname;

USN NAME
--- ------------------------------
  0 SYSTEM
  1 _SYSSMU1$
  2 _SYSSMU2$
  3 _SYSSMU3$
  4 _SYSSMU4$
  5 _SYSSMU5$
  6 _SYSSMU6$
  7 _SYSSMU7$
  8 _SYSSMU8$
  9 _SYSSMU9$
 10 _SYSSMU10$

11 rows selected

set transaction use rollback segment "_SYSMU10$"

ORA-30019: Illegal rollback Segment operation in Automatic Undo mode

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

tru55
К слову сказать, UNDO_RETENTION ("зафиксировать время") - это рекомендация, а не абсолют

Я не пытался "изнасиловать" этот параметр. Дока, однако, утверждает следующее:

Undo Retention Control

Long-running queries sometimes fail because undo information required for consistent read operations is no longer available. This happens when committed undo blocks are overwritten by active transactions.

Automatic undo management provides a way to explicitly control when undo space can be reused; that is, how long undo information is retained. A database administrator can specify a retention period by using the parameter UNDO_RETENTION. For example, if UNDO_RETENTION is set to 30 minutes, then all committed undo information in the system is retained for at least 30 minutes. This ensures that all queries running for 30 minutes or less, under usual circumstances, do not encounter the OER error, "snapshot too old."
17 янв 05, 19:25    [1251365]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
softwarer
Ключевой момент - именно версионность блоков. Полагаю, прелесть этого понятна - любые, сколь угодно сложные механизмы автоматом учитывают версионность; не надо думать, например, о расщеплении branch-узлов итп. Каждая сессия работает в своем виртуальном пространстве блоков.


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

Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?
17 янв 05, 19:29    [1251370]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
dimitr
Во-первых, смею предположить, что это работает не для всех блоков. Тем же сиквенсам версионность крайне вредна, например. Впрочем, хранятся ли их значения в своих собственных блоках или в системной таблице с инкрементом через блокировку, я не в курсе.

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

В то же время я сейчас убедился в версионности блоков секвенсоров на следующем простом примере:

-- Сессия 1 --
create sequence isolated;
set transaction isolation level serializable;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

-- Сессия 2 --
select isolated.nextval from dba_objects where rownum <= 10

-- Сессия 1 --
select last_number from dba_sequences where sequence_name = 'ISOLATED';
commit;
select last_number from dba_sequences where sequence_name = 'ISOLATED';

dimitr
Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?

Насколько я помню, в RBS хранится undo информация транзакции. К сожалению, эти вопросы не входят в круг моих "повседневных" знаний, поэтому не буду утверждать категорично.
17 янв 05, 20:04    [1251404]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 601

dimitr
Во-вторых, интересен сам механизм. При апдейте двух соседних записей разными транзакциями в RS будет две копии блока? Если да, то не слишком ли эта прелесть накладна с точки зрения ресурсов и объема I/O?

Да две версии. Легко проверить, если создать очень маленький RBS и запустить несколько сессий, изменяющих записи, то экстенты в RBS кончаться намного раньше, чем в случае одной сесси. Я прверял на восьмёрке. На более поздних версиях не пробовал, но не думаю, что там что-то изменилось.
С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?




Posted via ActualForum NNTP Server 1.1

18 янв 05, 12:58    [1252958]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67990
Блог
protector

С другой стороны, если проводить просто вставку, а не изменение записей, то Оракул тоже что-то пишет в RBS. Неужели пустые блоки? Что он собирается откатывать?

Откатывать придется "занятое место" в этих блоках - заново пометить его как свободное.
18 янв 05, 13:24    [1253133]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
RedALIEN
Member

Откуда:
Сообщений: 11
Если для автора топика еще актуален вопрос об GUI-инструментах для PG, могу посоветовать взглянуть сюда: http://www.sqlmanager.net. Есть версии для win и linux, последняя послабее будет. Но этот софт стоит денег после 30 дней :)
27 янв 05, 18:49    [1280046]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
актуален, конечно!
Спасибо за ссылку...
1 фев 05, 17:12    [1291564]     Ответить | Цитировать Сообщить модератору
 Re: FireBird 1.5.2 vs PostgreSQL 7.4  [new]
mef
Member

Откуда:
Сообщений: 98
посмотрел - мне нужно было под линукс, так там какая-то допотопная версия (8.0 уж точно не поддерживает). В принципе у аквы похожая функциональнось, хотя здесь понравилось автодополнение кода при написании SQL.
2 фев 05, 14:34    [1294336]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5      [все]
Все форумы / Сравнение СУБД Ответить