ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Целостность vs Быстродействие. Переносить ли в архивную таблицу?
9 сообщений из 34, страница 2 из 2
  2  все
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415918
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
>dimitr
>Это все сочинительство...
Спасибо что поправили. Это было всего лишь предположение.

А позвольте тогда вопрос. Ведь одна запись может иметь несколько версий. И в каждой версии ключевые значения могут быть разные. И на каждую такую версию должна быть ссылка на странице индекса (пусть индекс ссылается на элемент из Pointer Page не так важно). Тоесть фактически в индексе хрянятся ссылки на все версии, в том числе и давно устаревшие.

Пример: когда-то была одна версия записи Id=1. Потом в результате update появилась новая версия Id=2, и стала актуальной (commit). Сейчас когда я делаю select Id from ... where Id=1 сервер вынужден читать страницу на которой когда-то была версия Id=1.

Я понимяю что это нужно для очистки мусора. Но может быть лучше было бы отказатся от такой политики очистки мусора и с целью ускорения поиска по индексу в элементы индекса добавить tra_number? Понятно что это некоторая избыточность, но это значительно ускорит поиск по индексу, а значит и общую производительность.

Если так уж нужна чистка при select то можно будет по tra_number в индексе определить устарела ли версия на которую указывает этот элемент. В таком случае всеравно получаем выиграш за счет того что ненадо читать страници с немусорными записями (ведь мы уже при чтении индекса знаем что они не мусор).

P.S. Вы извините если я глупости давно понятные говорю. Просто проявляю любопытство.
...
Рейтинг: 0 / 0
19.02.2004, 17:20
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415931
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
авторПример: когда-то была одна версия записи Id=1. Потом в результате update появилась новая версия Id=2, и стала актуальной (commit). Сейчас когда я делаю select Id from ... where Id=1 сервер вынужден читать страницу на которой когда-то была версия Id=1.

Угу, все приблизительно так и происходит.

авторЯ понимяю что это нужно для очистки мусора. Но может быть лучше было бы отказатся от такой политики очистки мусора и с целью ускорения поиска по индексу в элементы индекса добавить tra_number? Понятно что это некоторая избыточность, но это значительно ускорит поиск по индексу, а значит и общую производительность.


Это не некоторая, а вполне конкретная избыточность. Ибо теперь придется хранить в индексе все версии ключа, включая неизмененные . Т.е. в индексе будет (1, 1, 1, 2, 3, 2, 2, 2 и т.п.) вместо текущих (1, 2, 3). Т.е. индекс распухнет и его чтение обойдется дороже, чем чтение страниц с данными.
...
Рейтинг: 0 / 0
19.02.2004, 17:27
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415959
dao+
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dao+
Гость
Andrey_
Вы сами себе противоречите, а как же state<=9 :)

А вот и не фига :-)))) state <=9 обрабатывается также глупо как и state >1 и state = 10.
Почему и говорю что неочевидно и без тестов не обойтись.

dimitr
Все зависит от желания разобраться.
...
Угу, есть такая негативная особенность. Хотя с неочевидностью я бы поспорил ;-)


Я согласен с тем, что разработчик должен хорошо знать особенности СУБД. Но не всегда возможно охватить тонкости весего спектра требуемых по ТЗ поддерживаемых СУБД.
...
Рейтинг: 0 / 0
19.02.2004, 17:46
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32415979
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
>dimitr
Хм... из статьи в котокой сказано "IB читает все записи таблицы в их естественном порядке собирая пары из ключевого значени и идентификатора записи (так называемого db-key). Затем этот набор сортируется по ключевому значению и создается нижняя часть индекса, со сжатием дубликатов ключевых значений ." мне показало что должно существовать промежуточное звено через которое устанавливается ссответствие "в каких записях были версии с таким ключевым значением".
Аналогия: как промежуточная таблица в отношение могие-ко-многим между "набором сжатых дубликатов ключевых значений" и "записями в таблице"

Вот в элементах этого звена я и предлогал разместить tra_number.

Иначе как установлена связь между "набором сжатых дубликатов ключевых значений" и "записями в таблице"?


>dao+
Стоп секунду. Есть таблица в которой 10001000 записей. 10000000 из них Status=10 у остальных Status<10. При выборке select count(*) where Status<10 сервер действительно замирает на какое-то время. А выборка select count(*) where Status<=9 отрабатывает почти мгновенно. Отсюда можно сделать вывод что я непонимаю термина fullscan который вы привели.
...
Рейтинг: 0 / 0
19.02.2004, 17:55
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416112
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Andrey_Иначе как установлена связь между "набором сжатых дубликатов ключевых значений" и "записями в таблице"?

"asdf" -> <сжатый ключ 1> + rec_number 1
"qwerty" -> <сжатый ключ 2> + rec_number 2

Т.е. каждая запись (все ее версии) представлена одним ключом индекса. Скорее всего, тебя ввела в замешательство фраза про "набор сжатых дубликатов ключевых значений". Это не единое целое, а набор отдельных ключей - т.е. значения ключа в неуникальном индексе дублируются. Просто сжимаются они инкрементно, с общим префиксом и динамическим суффиксом. Это позволяет сэкономить на хранении и в то же время обеспечить первую фазу поиска в b-tree без необходимости декомпрессии.
...
Рейтинг: 0 / 0
19.02.2004, 19:54
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416151
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
Мда... Лоханулся я немного :)

Но тогда всеравно непонимаю почему это приведет к распуханию индекса. Ведь элементы индекса нижнего уровня итак содержат динамический суффикс+указатели на PointerPage (минимум 4 байта) и наверняка на элемент врутри PP (минимум 1, а скорее 2 байта). А идентификатор транзакции состоит из 4 байт. Тоесть в лучшем случае мы имеем элемент размером 6 байтов, а в худшем 6+полная длина ключа (если нельзя выделить общий префикс). Думаю лишних 4 байта (идентификатор транзакции) небудут лишними и погоды не сделают.

Хотя... Скорее всего я где-то ошибаюсь... Ведь наверняка не я первый такое придумал :)
...
Рейтинг: 0 / 0
19.02.2004, 20:54
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32416933
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
авторНо тогда всеравно непонимаю почему это приведет к распуханию индекса. Ведь элементы индекса нижнего уровня итак содержат динамический суффикс+указатели на PointerPage (минимум 4 байта) и наверняка на элемент врутри PP (минимум 1, а скорее 2 байта). А идентификатор транзакции состоит из 4 байт. Тоесть в лучшем случае мы имеем элемент размером 6 байтов, а в худшем 6+полная длина ключа (если нельзя выделить общий префикс). Думаю лишних 4 байта (идентификатор транзакции) небудут лишними и погоды не сделают.

50% прирост среднего размера индекса ты считаешь незначительным? ;-) Но на самом деле, проблема-то в другом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
start transaction  1 ;
insert into my_table (fld) values ( 1 );
commit;
start transaction  2 ;
update my_table set fld =  1  where fld =  1 ;
commit;
start transaction  3 ;
update my_table set fld =  2  where fld =  1 ;
commit;


Сейчас:
<key1><rec_number1>
<key2><rec_number1>

Будет:
<key1><rec_number1><tra_number1>
<key1><rec_number1><tra_number2>
<key2><rec_number1><tra_number3>

Где key >=1 байта, rec_number = tra_number = 4 байта.

Разница понятна?
...
Рейтинг: 0 / 0
20.02.2004, 13:57
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32417125
Andrey_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey_
Гость
dimitrСейчас:
<key1><rec_number1>
<key2><rec_number1>

Будет:
<key1><rec_number1><tra_number1>
<key1><rec_number1><tra_number2>
<key2><rec_number1><tra_number3>

Где key >=1 байта, rec_number = tra_number = 4 байта.

Вы меня убили :) Все понятно, слов нет... туплю по черному...

P.S. Спасибо за объяснения.



Все ниженаписаное было придумано и написано до э...озарения :)

dimitr50% прирост среднего размера индекса ты считаешь незначительным?
Хм...
rec_number=4 байта
Key=минимум 3 байта (почему 3: минимум 1 байт на значение и 2 байта на длинну значения. Почему на длинну 2 а не 1: потому что как я слышал в FB2 будет снято ограничени на длинну ключа в 256 байт)

Тоесть уже один элемент имеет минимальную длинну 7 байт. + 4 байта на tra_number будет 11. Тоесть в худшем случае размер индекса увеличится на ~70% от первоначального. Если на ключ приходится 2 байта то на 50%.

Мда... многовато... Хотя увеличение размера страници... Нет! Много... Да еще и если учесть, что худший случай (на ключ 1 байт) случается при индексировании уникальных полей (Id например)... Совсем плохо...

Хотя конечно это тема отдельного исследования, и повышение производительности может покрыть расходы HDD и RAM...

Кстати, сейчас ведь чтение осуществляется так как сказано в стаье . Если да то пример:

Есть база с размером страници 4096.
Есть индекс с глубиной 3.
Сейчас чтение: Индекс(L2)->Индекс(L1)->Индекс(L0)->PP->DP =4096*5=20480 байт

Таже база с размером страници 8192 и с tra_number в индексе.
Чтение: Индекс(L2)->Индекс(L1)->Индекс(L0) =8192*3=24576 байт

Тоесть при глубеине индекса 3 объем чтения увеличится на 20% от начального, при глубине 4 (я такого ниразу не встречал) на ~33%.
...
Рейтинг: 0 / 0
20.02.2004, 15:29
| Ответить | Цитировать | Написать  
Целостность vs Быстродействие. Переносить ли в архивную таблицу?
    #32420442
Vladimir_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vladimir_
Участник
в любом случае гибридная система никогда не даст преимуществ по отношению к каждой составляющей в отдельности. Каждая система имеет свои методы решения и настройки. Я бы выбрал ORACLE и рассматривал решение задачи только в рамках его возможностей
...
Рейтинг: 0 / 0
25.02.2004, 11:14
| Ответить | Цитировать | Написать  
9 сообщений из 34, страница 2 из 2
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Целостность vs Быстродействие. Переносить ли в архивную таблицу?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=32415979&tid=1579154]:
 0ms
get settings:
 7ms
get forum list:
 15ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 58ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 44ms
get tp. blocked users:
 1ms
others: 204ms
total:  345ms
созд. / загр.: 345ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]