Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
to dimitr Пусть меня поправят, но RANGE SCAN - обычно выбирается либо UNIQUE SCAN и либо HASH JOIN. вроде как разные вещи, первое это метод доступа к данным, а второе способ объединения таблиц??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 14:01 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 14:07 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarer- В первую очередь, проблемы долгого rollback-а относительно неважны. То есть я не видел систем, где был бы удобен регулярный rollback - и я бы назвал такое неправильным дизайном даже в отрыве от архитектуры конкретной БД. Согласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент. softwarer- изменение ключа и соответствующее перелопачивание - имхо, операция относительно редкая. Конечно, все зависит от профиля операций, но делать IOT, вынося в ключ, тем более в первые поля часто модифицируемое поле вряд ли разумно. Тоже согласен. softwarer- перелопачивать index organized table или просто индекс - хм, не такая уж принципиальная разница. Единственно что IOT скорее всего в среднем значительно шире - но вопрос, какую роль это играет (я не помню сходу, делаются ли там "цепочки" или переносится полная запись). Если цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая. softwarer- Перестраивать индекс при изменении данных все равно необходимо. Когда делать это - то ли при изменении данных, то ли при commit-е - вряд ли принципиально с точки зрения производительности именно этой операции. Зато версионный индекс может крайне ускорить работу, а IOT - как минимум, существенно экономит место и чтения. Если ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Насчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис. softwarerИтог: разумеется, при неудачном использовании будут тормоза. Сделать вроде как можно, и использовать во благо - тоже. Это относится почти к любой фиче любого сервера ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 14:11 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 14:28 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
dimitrДа и насчет обычных индексов есть неприятные ограничения. Сейчас хранится один ключ индекса на все версии записи (ID транзакции в ключ не входит). Отсюда невозможность index-only scan, ибо для каждого выбранного ключа придется читать запись с диска и определять видимость для текущей транзакции."Невозможность index-only scan" имеет место и в постгресе. :( А как в FB производится сборка мусора, статистики? Нам в постгресе пршлось запускать ежедневно 1) vacuum (помечает удаленные и измененные строки, как пригодные к повторному использованию), 2) vacuum analyze (сбор статистики), еженедельно - 3) reindex (перестраивает индексы), 4) vacuum full (удаляет из db-файла удаленные/измененные строки). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 14:38 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
dimitrСогласен. Но мусор может накопиться не только от роллбеков. А его сборка - самый неприятный момент. Пожалуй, я не готов предметно рассуждать о мусоре в Oracle без консультации с документацией. Насколько я помню, основной фактор мусора - пометки о блокировках в блоках (независимо от того, блоки ли это таблицы, IOT итп), и их очистка сделана максимально плавно - так, чтобы она не тормозила транзакцию, но сколь возможно выполнялась в фоне. dimitrЕсли цепочек нет, то объем I/O при изменении IOT значительно больше, чем в случае изменения листа b-tree. Даже если ширина IOT небольшая. Можно пояснить поподробнее? dimitrЕсли ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает. dimitrНасчет IOT - надо делать и тестить. Но, как уже Влад написал, офигительного преимущества на чтении не ожидается. Отсюда и скепсис. Хм. Насколько я понимаю, "первичный" фактор преимущества IOT - замена двух чтений (индекс + данные) одним. Дело тут не только в кластеризации, но и в элементарном хранении одних и тех же данных в двух экземплярах; в том, что IOT занимает меньше места, нежели table+index. Ожидаемый эффект от этого можно попробовать оценить, хотя я не слишком удивлюсь, если оценка будет "слишком мало, чтобы тратить на это силы". Другой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен. dimitrЭто относится почти к любой фиче любого сервера ;-) На это и намек ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 14:49 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 14:51 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
К моему предыдущему посту - ни одна из описанных операций не блокирует работу других коннектов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 14:54 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 14:55 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
А какие-такие улучшения есть в FB 2 ? Также мне не понятно будут ли в FB 2 двунаправленные индексы. Ещё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:08 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarer dimitrЕсли ключевое поле не менялось, то IB/FB индексы не перестраивает. А для версионного индекса это придется делать всегда. Боюсь, снова не понял. Если ключевое поле не меняется - я не вижу никаких причин перестраивать индекс. Если хотите - могу вечером провести эксперимент, но почти уверен, что Oracle такого не делает.Данные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс. softwarerДругой момент - IOT/кластеризация избравляет от необходимости постоянно сортировать индекс в памяти. Полагаю, это не такая уж дешевая операция; по поводу выигрыша в этом месте я более оптимистичен.Индекс не сортируется в памяти - он отсортирован на диске ;) На самом деле строится битовая карта физических номеров записей. Она по-определению упорядоченна, занимает относительно немного места (разреженный битмап) и достаточно дёшево строится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:15 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
GoldА какие-такие улучшения есть в FB 2 ? Всяческие ;) imho, здесь это оффтоп ;) GoldТакже мне не понятно будут ли в FB 2 двунаправленные индексы.Нет GoldЕщё интересно узнать по поводу внедрения аналогичных улучшений, которые в IB 7 или 7.1 сильно ускоряют массовые удаления. Будет ли такое в 2.0 ?Да, и даже лучше ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:20 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
dimitrЯ правила не рискну формулировать, уж шибко много факторов. Это были наблюдения. Даже при выборке из одной большой таблицы, оракл очень часто выбирает FULL SCAN вместо INDEX RANGE SCAN, даже для относительно неплохой селективности индекса и наличия менее десятка искомых значений в индексе (статистика свежая). При этом стоило выбрать значение из уникального поля, как сразу появлялся INDEX UNIQUE SCAN. Т.е. разница в 10-20 логических чтений уже заметно меняет картину. Полагаю, именно UNIQUE тут малосущественно - что собственно видно в приведенном ниже примере. CLUSTERING_FACTOR же - действительная существенная в Oracle причина неиспользования индексов. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:25 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 15:28 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс. Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу. Исходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс. hvladНа самом деле строится битовая карта физических номеров записей. Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:36 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarer hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс.Это совершенно не обязательно. То есть я вполне верю, что IB работает именно так, но глобальной необходимости в этом я не вижу.Как раз IB так не работает, т.к. нет такого понятия, как версионный индекс softwarerИсходные данные - у нас есть индекс, в котором хранится некий "адрес записи". Запись изменилась. В результате у нас где-то есть старая версия записи, где-то есть новая версия записи. Как минимум одна из этих записей лежит по старому адресу (иное глупо). Таким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс.Не понято. В индексе хранятся ключи + указатели на записи. "Адрес" записи при редактировании не меняется. Что такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно. softwarer hvladНа самом деле строится битовая карта физических номеров записей. Это и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах.Нет! Данные индекса (ключи записей) не сортируются. "Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, разве что поиск (двоичный) в массиве (р-р которого меньше, чем кол-во эл-тов в нём ;). Цена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 15:56 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
hvladПерестройка индексов - никогда, а зачем ? ;) REINDEX в PostgreSQL 7.4 , REINDEX в PostgreSQL 7.3 . По прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется. hvladЕсли кто-нибудь даст ссылку на документацию PostgreSQL'а о внутренних механизмахВот дока по версии 7.4 . "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 16:09 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarerТаким образом, достаточно иметь операцию "получить версию записи X, соответствующую контексту Y", чтобы не нуждаться во включении контекста - "версионного ключа" в индекс. Эта информация лежит в версиях записей ;-) Т.е. либо приходим к тому, с чего начали (надо читать сами записи), либо осознаем необходимость дополнительно кешировать цепочку backversions вместо с их txn ID. softwarerЭто и есть сортировка - индекс, отсортированный по данным, пересортировывается в порядке адресов. Относительная цена этой операции - непростой вопрос, который вряд ли можно оценить на пальцах. Сортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа. Полагаю, что IOT действительно покажет себя лучше на больших выборках. Вот только насколько велик процент задач с большим объемом данных и неуникальными выборками только по кластерному ключу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 16:21 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
LeXa NalBatПо прошествии примерно года эксплуатации системы на PostgreSQL 7.3 (без регулярного reindex-а), объемы файлов некоторых индексов стали занимать в сотни раз больше места, чем требуется. Чудно как-то. Скорее всего, имеется недоработка в PG. LeXa NalBatВот дока по версии 7.4 . "Внутренние механизмы", которые обсуждались в этом топике, и раздел доки "VII. Internals" наверное коррелируют, но не совпадают. :) Немного там описано. Впрочем, официальная дока по IB содержит еще меньше информации ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 16:34 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 16:38 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
hvladДанные полей записи не изменились, но версионная метка (например номер тр-ции) - другая. Значит версионный ключ другой и его нужно вставить в индекс hvladЧто такое "версионный ключ" и "версионный индекс" мне (и IB\FB) неизвестно. Вы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :) hvlad"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, Битовая карта - это стандартный алгоритм сортировки :) hvladЦена, по сравнению с затратами на собственно сканирование индекса, - весьма невелика Сканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 17:10 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
dimitrСортируются только адреса. Цена может стать заметной на определенном (весьма немаленьком) размере битмапа. Или на большом количестве обращений, требующих этой операции. А кэшировать результаты сортировки вряд ли удастся - они транзакционно-зависимы. dimitrПолагаю, что IOT действительно покажет себя лучше на больших выборках. Вот только насколько велик процент задач с большим объемом данных и неуникальными выборками только по кластерному ключу? Сложно сказать. Снова возвращаемся к уже сказанному "слишком много факторов, чтобы оценивать на пальцах". Но я не об этом. Я не собираюсь утверждать, что IOT будут полезны IB - местным виднее. Я скорее обратил внимание на эту сортировку как на потенциальное узкое место. IOT + несортируемые индексы дают возможность управлять этим моментом, хотя, бесспорно, управление грубовато. Оправданно ли более тонкое - не знаю; тут я послушал бы специалистов покруче себя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 17:22 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
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.01.2005, 17:30 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarerВы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :)Нет такой терминологии, её в этом обсуждении придумали и тут же показали её минусы softwarer hvlad"Сортируются" только номера записей. Строго говоря самой сортировки при этом не происходит, Битовая карта - это стандартный алгоритм сортировки :)Ну, если так, то - да, есть сортировка ;) softwarer hvladЦена, по сравнению с затратами на собственно сканирование индекса, - весьма невеликаСканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу.Здесь - да, FB не умеет выдавать записи по ходу сканирования индекса, т.е. FIRST_ROWS оптимизации в нём нет softwarerЗдесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи.Строго говоря, всё не совсем так. Сначала читается индекс и по-ходу сортируются полученные номера записей (сортировка здесь очень дешёвая операция), затем записи посещаются и выдаются клиенту. Но не все, а по мере фетча. Думаю, с этим вопросом уже все разобрались :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 17:35 |
|
||
|
FireBird 1.5.2 vs PostgreSQL 7.4
|
|||
|---|---|---|---|
|
#18+
softwarerВы уж выберите что-нибудь одно :) А то я стараюсь подладиться под Вашу терминологию - а оказывается, что Вы сами ее не знаете :) Просто мы говорим о том, чего в IB нет, но типа могло бы быть ;-) softwarerСканирование индекса - это "поточная" операция. Она не тормозит выполнение в целом; сервер может сканировать индекс и одновременно возвращать клиенту данные по уже прочитанному индексу. Здесь же требуется сначала целиком прочитать, потом отсортировать, и только потом можно возвращать записи. Согласен. Чисто теоретически можно не сортировать битмап при хинте FIRST_ROWS, а выдавать адреса записей конвейерно. Вот только нету хинтов в IB ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 17:36 |
|
||
|
|

start [/forum/topic.php?fid=35&startmsg=32867798&tid=1553954]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
34ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 178ms |
| total: | 327ms |

| 0 / 0 |
