Да забързаме "остарялата" firebird база

Отговори
Потребителски аватар
stoar08
Мнения: 1548
Регистриран: 09-11-2004 08:15
Име: Стоян Арабаджиев
Местоположение: Самоков

Да забързаме "остарялата" firebird база

Мнение от stoar08 » 11-05-2007 17:53

С времето базите ни ще нарастнат, което ще ги забави. Но дали ударът в/у производителността е толкова внушителен само заради обема данни?
За хората, които не изпитват огромно влечение към документацията на firebird ще го кажа по 2 начина (кратък и не толкова кратък:) ).

Краткия е - един backup/restore цикъл може да влее доста живот в базата (при база 170MB съм достигал разлика от рода на 5 пъти в изпълнението на някои операции).

За по-любознателните ще дам маалко повече обяснения за това какво се случва при този процес :
1 При backup се изтриват всички ненужни неща по базата и се свива чисто физическият обем на файла. За пример мога да дам база, която от 550MB пада до 510MB без допълнитени процедури. Въпросната база е в обект, който работи от преди официалното излизане на firebird 1.0 (по онова време имаше отворен interbase).

Възниква естествено въпроса - Защо чак тогава?

Дали сте забелязали, че един 4GB файл от NTFS изчезва преди да натиснете OK, но копирането му там е отнело доста повече време :) ? Firebird също НЕ трие ... в "клишето" на всеки запис има флагове дали той е действащ, дали е "интересна транзакция", дали е изпълнен (commited) или върнат (rollbacked) и т.н. За това всички тези операции са бързи - реално се променят няколко байта на запис, и с информацията по твърдия диск почти нищо не се прави. На теория от време на време сървъра чисти тези записи сам ...но на практика не е точно така.
При backup всичкия този "боклук" се събира.

2 Данните физически се дефрагментират. При нормална операция firebird заделя определено место. Използва го докато не остане опредлен свободен %, и заделя отново. В целия този процес малко или много се губи "плавността на потока".

3 При всяка преработка на поле в базата данни НЕ се променят.
"Това е абсурд?!?!" нали? Я си представете базата от 550(510) MB и ми кажете колко време ще трябва за физическото пренареждане при създаване/изтриване на колона? И аз така си мислех ...МНОГО :) => данните се пазят в оригинален вид и минават N на брой етапа до необходимия вид при работа (N е броя на корекциите от създаването/последния restore).

Реален ефект съм виждал с очите си до 5 пъти на 170MB база ...на по-големи нямам време да опитам :)
Моля ви, като прочетете тема пишете по едно мнение да не ви търся по icq/телефон после ...

Потребителски аватар
stoar08
Мнения: 1548
Регистриран: 09-11-2004 08:15
Име: Стоян Арабаджиев
Местоположение: Самоков

Мнение от stoar08 » 08-10-2007 19:19

А ето и как стоят нещата към момента с база от Aton.
В 1 хранителен магазин пуснах автоматичното коригиране на излишъци и около 3 часа преизчислявах текущите продукти. В следствие на цялото преизчисление базата скочи от 105 на 202 MB. След backup/restore цикъл базата се върна до доста по-разумните 125 MB.

Оставям на вас да прецените колко излишно време отнема на firebird ~33% излишна информация в базата :) (да, правилно - оптимизиран е и не се ускорява с 33%, но защо да си мъчим сървъра с излишна работа?)
Моля ви, като прочетете тема пишете по едно мнение да не ви търся по icq/телефон после ...

Отговори