Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
 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
Сообщений: 67534
Блог
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
Сообщений: 7008
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
Сообщений: 7008
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
Сообщений: 67534
Блог
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
Сообщений: 7008
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
Сообщений: 7008
К моему предыдущему посту - ни одна из описанных операций не блокирует работу других коннектов.
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
Сообщений: 67534
Блог
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
Сообщений: 7008
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
Сообщений: 67534
Блог
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
Сообщений: 7008
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
Сообщений: 7008
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
Сообщений: 67534
Блог
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
Сообщений: 67534
Блог
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
Сообщений: 67534
Блог
dimitr
Сортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа.

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

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

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

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

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


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

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


Согласен. Чисто теоретически можно не сортировать битмап при хинте FIRST_ROWS, а выдавать адреса записей конвейерно. Вот только нету хинтов в IB ;-)
17 янв 05, 17:36    [1250980]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить