مکانيزم فشرده سازي در اوراکل
در نگارش 11g پايگاه داده اوراکل امکانات متعددي ارائه شده است. اين امکانات براي بهبود کارايي، دسترسي پذيري بيشتر، مديريت آسان تر پايگاه داده، کدنويسي کمتر و کاهش نياز به منابع سخت افزاري نظير رسانه ذخيره سازي و پهناي باند شبکه ارائه شده است. از جمله اين موارد که هم باعث کاهش ميزان نياز به فضاي ذخيره سازي و هم افزايش سرعت مي شود، مکانيزم Advanced Compression است که الگو و الگوريتم فشرده سازي آن در عين کاهش نياز به فضاي ذخيره سازي، به علت سرباره پردازشي کم و کاهش شديد بار I/O مي تواند تاثير بسيار مثبتي در کارايي پايگاه داده داشته باشد. در اين مقاله به بررسي اين مکانيزم جديد مي پردازيم.
جان، به عنوان مدير پايگاه در بانک Acme Bank فعاليت مي کند و در حال حاضر مشغول بررسي نمودارها و صفحات گسترده اي است که توسط گروه تعيين ظرفيت آتي بانک، ارائه شده است. در طول بررسي اين نمودارها مي توان يک پيام ساده را به روشني دريافت کرد، در آينده نه چندان دور حجم پايگاه داده بانک به طور فزاينده اي افزايش پيدا خواهد کرد. اين مسئله از دلايل مختلفي ناشي مي شود، به عنوان مثال، رشد طبيعي کسب و کار بانک، انتقال برنامه هاي کنوني از سيستم هاي مبتني بر دسکتاپ به سيستم هاي سازماني بزرگ و متمرکز، درخواست هاي قانوني به منظور نگهداري داده براي مدت طولاني تر و مجموعه اي از عوامل ديگر. تمام اين موارد به رشد تواني حجم پايگاه داده و در نتيجه آن نياز به ظرفيت پردازشي بالاتر (پردازنده، شبکه، I/O و پهناي باند) منجر مي شود. البته، افزايش نياز به همه اين موارد به يک نسبت نخواهد بود. اين فرآيند به معني در نظر گرفتن فاکتورهاي متعدد در سطح پايگاه داده مي شود که از آن جمله مي توان به اين موارد اشاره کرد:
1- رشد سرسام آور هزينه خريد تجهيزات ذخيره سازي: اين گروه پيشنهاد کرده است تا به منظور کاهش هزينه ها از ادوات ذخيره سازي ارزان تر استفاده شود که منطقاً بر سرعت و کارايي سيستم ها تاثير منفي خواهد داشت.
2- داده بيشتر به معني نياز به فضاي بيشتر براي نگهداري از نسخه هاي پشتيبان: يکي از گزينه ها، براي کاهش اين هزينه ها اين است که تعداد نسخه هاي پشتيباني که تهيه و روي ديسک نگهداري مي شوند، کاهش يابد، که اين کار بهترين روش ممکن نيست، زيرا باعث افزايش زمان مورد نياز براي بازيابي مي شود.
3- اگر ميزان داده اي که از آن پشتيبان تهيه مي شود زياد باشد، زمان مورد نياز براي تهيه آن نيز افزايش مي يابد و در نتيجه ممکن است با ساير jobهاي تهيه نسخه پشتيبان که برنامه ريزي شده است، دچار تداخل شود.
4- افزايش حجم داده، همچنين به معناي افزايش ميزان I/O بين مولفه هاي مختلف سيستم، نظير کارت هاي HBA (سرنام Host Bus Adapter) و رابط هاي متصل به ادوات ذخيره سازي سطح شبکه (NAS) مي شود و اين مسئله نيز بر کارايي سيستم تاثير منفي دارد.
5- داده بيشتر در پايگاه داده، به معني نياز به اختصاص حافظه بيشتر به ناحيه SGA (سرنام System Global Area) است و اختصاص حافظه بيشتر به SGA به معني نياز به تهيه حافظه بيشتر براي سرور است. اگر حافظه بيشتر در اختيار نباشد، ميزان کمتري از داده در SGA به صورت Cache شده نگهداري مي شود و باعث کاهش کارايي مي شود. براي مقابله با اين مسائل، گروه مديران پايگاه داده در Acme Bank ، پيشنهادهاي معمول را ارائه کرده است. اين پيشنهادها عبارتند از: افزودن به ميزان فضاي ديسک، حافظه، ظرفيت شبکه و پهناي باند براي I/O. اما با در نظر گرفتن تاکيد فراوان بر صرفه جويي، اين راهکارها توسط گروه مديران بانک، مورد تاييد قرار نگرفت. جيل که مدير گروه مديران پايگاه داده بانک را بر عهده دارد، اميدوار است که جان بتواند يک راه حل جايگزين براي اين مشکل پيدا کند، به نحوي که با افزايش ميزان داده، کارايي سيستم ها در سطح کنوني آن حفظ شود و در همان حال ميزان ديسک، حافظه، I/O نيز افزايش يابد يا حتي کاهش پيدا کند.
راه حل: فشرده سازي
مکانيزم Oracle Advanced Compression، گزينه جديدي است که در پايگاه داده Oracle 11g Enterprise Edition مطرح شده است و پاسخي به شکل ناشي از رشد حجم داده در Acme Bank است. فشرده سازي در پايگاه داده اوراکل، راه حل جديدي نيست. در Oracle8i براي اولين بار امکان فشرده سازي انديس ها از طريق حذف انديس هاي تکراري در سطح برگ ها فراهم شد. در نگارش دوم از Oracle9i نيز امکانات جديدي براي فشرده سازي جدول ها ارائه شد که نياز به نگهداري مقادير تکراري در جدول ها را برطرف مي کرد. اين نوع جدول ها حتي از عمليات دريافت حجمي داده (Bulk load) پشتيباني مي کردند و در محيط انبار داده، گزينه قدرتمندي به شمار مي آيند.گزينه Oracle Advanced Compression که در Oracle 11g Enterprise Edition ارائه شده، امکانات غني تر و قدرتمندتري دارد که آن را حتي براي محيط هاي OLTP که حساسيت و نياز بالايي به انجام سريع تراکنش ها دارند، نيز به عنوان يک گزينه ايده آل مطرح کرده است.
مراحل فشرده سازي و نياز به ديسک
جدول ACCOUNT_REG نيز با استفاده از همان کد فهرست 1 ايجاد مي شود، با اين تفاوت که نام جدول به ACCOUNT_REG تبديل مي شود و عبارت «Compress Forr All Operations» نيز حذف مي شود. سپس از کد ins_acc.sql استفاده مي کند (کد فهرست 2) تا محيط برنامه هاي بانک ACME را شبيه سازي کرده و رکوردهاي داده اي را در هر دو جدول ثبت کند. بعد از درج داده، جان با استفاده از کد زير تعداد بلاک هاي درج شده در هر جدول را بررسي مي کند:
کد:
select segment_name,blocks,from user_segments where segment_name like 'ACCOUNTS_%
SEGMENT_NAME BLOCKS
--------- -------------------
4096 ACCOUNTS_COMP
11264 ACCOUNTS_REG
البته، جان به اين نکته نيز اشاره کرد که ميزان صرفه جويي در فضاي ديسک، متفاوت است و به ماهيت و نوع داده ذخيره شده، بستگي دارد.
جان همچنين بررسي هايي را انجام داد تا مشخص شود که آيا، ضريب فشرده سازي داده، بعد از ايجاد تغييرات در آن، همان ميزان قبل خواهد بود يا خير. او دوباره کد ins_acc.sql را روي هر دو جدول اجرا کرد و نتيجه حاصل را مورد بررسي قرار داد:
کد:
select segment_name,blocks,from user_segments where segment_name like 'ACCOUNTS_%'
SEGMENT_NAME : BLOCKS
--------- -------------------
ACCOUNTS_COMP : 8192
ACCOUNTS_REG : 22528
((8192/22528)-1)
I/O و حافظه
زمان اجرا به ازاي جدول معمولي، 4/33 ثانيه و به ازاي جدول فشرده شده، 4/24 ثانيه است که معادل با افزايش بيست درصدي در سرعت اجراي کد است. تعداد پردازش هاي از نوع خواندن منطقي (logical read)، علت بهبود در سرعت اجراي کد را مشخص مي کند: در حالي که به ازاي جدول معمولي بايد 11/212 خواندن منطقي صورت گيرد، اين ميزان به ازاي جدول فشرده شده، به 4/122 خواندن منطقي کاهش پيدا مي کند. اين کاهش به صرفه جويي در مولفه CPU_CONSUMED نيز منجر مي شود (عدد ثبت شده براي اين مولفه به ازاي جدول معمولي 354 و به ازاي جدول فشرده شده، 304 است. هرچند که اين ميزان صرفه جويي در مصرف CPU خيلي زياد نيست (و حتي مستندات نشان مي دهد که در بعضي از موارد ميزان مصرف پردازنده به ازاي پرس و جو از جدول فشرده شده، ممکن است بيشتر نيز باشد)، اما ميزان صرفه جويي در استفاده از منابع I/O آن چنان قابل توجه است که به خوبي کاهش زمان پاسخ گويي پرس و جو را مي توان حس کرد. افزايش کارايي سيستم به واسطه استفاده از جدول هاي فشرده شده، به ويژه هنگام پيمايش يا اسکن کل اطلاعات جدول به خوبي نمايان مي شود و اين گونه پردازش ها به طور معمول در فرآيندهاي توليد گزارش و پردازش هايي از نوع گروهي، به دفعات تکرار مي شوند. از آنجا که در اين حالت هر بلاک از جدول فشرده شده، رکوردهاي بيشتري را شامل مي شود، در نتيجه، مي توان با استفاده از يک SGA کوچک تر، به همان ميزان قبل، داده را به صورت Cache شده، در RAM نگهداري کرد و به عبارتي حافظه حال حاضر سيستم مي تواند بلاک هاي بيشتري را در خود نگهداري کند و در نتيجه به علت Cache شدن رکوردهاي بيشتر، احتمال نياز به پيمايش و جست و جوي در سطح ديسک کمتر مي شود و اين کار در مراحل بعدي به بهبود I/O منجر شد و متعاقب آن، کارايي بهتر و سرعت پاسخ گويي کمتري به دست مي آيد.
begin
for 1_acc_no in 1..1000000 loop
insert into accounts_®_or_comp
values
(
no_acc_1,
First Name--
(decode
,))floor(dbms_random.value(1,21
1, 'Alan'
2,'Alan',
3,'Barbara',
4,'Barbara',
5,'Charles',
6,'David',
7,'Ellen',
8,'Ellen',
9,'Ellen',
10,'Frank',
11,'Frank',
12,'Frank',
13,'George',
14,'George',
15,'George',
16,'Hillary',
17,'Iris',
18,'Iris',
19,'Josh',
20,'Josh',
'XXX'
),
Last Name--
)decode
,))floor(dbms_random.value(1,5
1,'Smith',
dbms_random.string))A',dbms_random.value(4,30((,
Account Type--
)decode
floor(dbms_random.value(1,5,((
1, 'S' , 2 , 'C' ,3,'M' , 4, 'D', 'X'
),
Folio ID--
case
when dbms_random.value(1,100)< 51 then null
else
floor(dbms_random.value(1,100))+ 1_acc_no
,end
Sub Acc Type--
case
when dbms_random.value(1,100) <76 then null
else
decode(floor(dbms_random.value(1,6,((
1,'S', 2, 'C', 3,' C', 4, ' C', 5,' C', null)
,end
Acc Opening Date--
sysdate_dbms_random.value(1,500,(
Account Manager ID--
(\decode
floor(dbms_random.value(1,11,))
1,1,2,1,3,1,4,1,5,2,6,3,7,4,8,5,9,5,10,5,0
)
);
;end loop
;commit
;end
انواع فشرده سازي
فشرده سازي جدول هاي OLTP: با استفاده از گزينه فشرده سازي جدول هاي OLTP، فرآيند فشرده سازي در سطح بلاک ها انجام مي شود و داده ها هنگام درج در جدول، فشرده نمي شوند. يعني به جاي فشرده سازي در مرحله درج داده، از يک الگوريتم دروني ايجاد استفاده مي شود تا مشخص شود که چه زماني ميزان داده فشرده نشده در بلاک، به اندازه کافي بوده و آن بلاک، آماده فشرده شدن است. وقتي که بلاک آماده باشد، الگوريتم فشرده سازي، مقداري از يک رکورد را خوانده و ارجاعي به آن مقدار را در جدول نمادها ايجاد مي کند که به هدر بلاک اشاره خواهد کرد، سپس الگوريتم، سعي مي کند مقادير مشابه در بلاک را شناسايي کند و به ازاي هريک از مقادير مشابه يافت شده، آن مقدار را با نماد معادل از جدول نمادها، جايگزين کند. به اين ترتيب فقط داده هاي يک رديف يا ستون خاص فشرده نمي شوند، بلکه داده در هر جاي بلاک که باشد، فشرده سازي مي شود. هر بلاک به طور مستقل، فشرده سازي مي شود و جدول نمادهاي خودش را دارد، در نتيجه، فشرده سازي معمولاً سريع تر از ساير روش هايي است که در سطح پايين تر و خارج از محيط اوراکل، داده ها را فشرده سازي مي کنند، زيرا در اين روش ها معمولاً از يک جدول نماد به ازاي کل داده ها، استفاده مي شود. اين روش مستقل فشرده سازي در سطح بلاک براي داده هاي جديد يا تغيير يافته، نيز قابل تطبيق است. در صورت لزوم مي توان بلاک ها را به منظور به روزرساني جدول نمادها، از حالت فشرده خارج و دوباره فشرده سازي کرد. در حالي که فشرده سازي يک جدول نماد عمومي بدون ايجاد مکانيزم هاي قفل گذاري، خيلي سخت تر است و اين به آن معنا است که الگوريتم هاي فشرده سازي مذکور براي اعمال تغيير ايجاد شده در داده، انطباق پذيري کمي دارند و اين مسئله به مرور زمان، درصد فشرده سازي را نيز کاهش مي دهد. مکانيزم Oracle Advanced Compression، در زمان درج يا تغيير داده اعمال نمي شود، بلکه داده به همان شکل معمولي و فشرده نشده درج شده و زماني که حجم داده به يک ميزان مشخص برسد که به عنوان معيار اجراي الگوريتم فشرده سازي در نظر گرفته مي شود، در اين صورت الگوريتم فشرده سازي کل داده بلاک را به صورت دسته اي دريافت کرده و آن را به روش مذکور فشرده سازي مي کند.
در نتيجه همه تراکنش هاي در سطح آن بلاک، با مسئله استفاده زياد از پردازنده به منظور فشرده سازي بلاک مواجه نيستند و تنها تراکنش هايي که به واسطه آن ها، حجم داده بلاک به ميزان مناسبي مي رسد، باعث اجراي مکانيزم فشرده سازي مي شوند و فقط به ازاي اين تراکنش ها است که با مدت انتظار بيشتري مواجه مي شويم که مقدار آن نيز ناچيز است. اين الگوريتم پردازش دسته اي، سرباره ايجاد شده براي پردازنده به ازاي عمليات هاي DML را به حداقل مي رساند و در نتيجه آن مکانيزم Oracle Advanced Compression را براي استفاده در سيستم هاي OLTP به عنوان يک مکانيزم، ايده آل مطرح مي کند.
فشرده سازي داده هاي بدون ساختار: بانک ACME همچنين مقدار زيادي داده بدون ساختار مي کند، نظير اسنادXML، امضاها (به صورت فايل هاي GIF) و بخش نامه ها (به صورت فايل هاي PDF) را نيز نگهداري به دليل قوانين متعدد دولتي و ساير الزامات و تعهداتي که بانک ملزم به رعايت آن ها است، بايد اين داده هاي بدون ساختار در پايگاه داده نگهداري شود که فضاي بسيار زيادي را اشغال مي کند.
مکانيزم Oracle Advanced Replication فقط براي داده هاي رابطه اي کاربرد ندارد. در پايگاه داده اوراکل 11g، ساير انواع داده را نيز مي توان فشرده سازي کرد، که البته در بعضي موارد کد مورد نياز براي فشرده سازي، به تغييرات کوچکي نياز دارد، به عنوان مثال نوع داده اي به نام Oracle SecureFiles (نسل بعدي اشياء بزرگ يا LOB که براي اولين بار در اوراکل 11g معرفي شده است) از دو تکنيک براي کم کردن نياز به فضاي ذخيره سازي استفاده مي کند. اين دو روش عبارتند از فشرده سازي و حذف تکرارها. جان براي ارائه اطلاعات بيشتر در مورد فشرده سازي در Oracle SecureFiles مقاله اي با نام SecureFiles:The New LOBs را در سايت اوراکل ارائه داده است. او براي نشان دادن مزيت هاي اين نوع داده، يک مثال از Oracle SecureFiles ايجاد مي کند که در آن جدول CONTRACT_SEC تغيير داده مي شود تا در آن، يک ستون فشرده شده از نوع LOB با نام ORIG_FILE وجود داشته باشد:
set serveroutput on size unlimited
alter system flush buffer_cache
/
col value noprint new_value start_cpu
select value
from v$sesstat s,v$statname n
where sid=(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistic#
and n.name in ( 'CPU used by this session')
/
col value noprint new_value start_reads
select value
from v$sesstat s, v$statname n
where sid=(select sid from v$mystat where rownum< 2)
and s.statistic# = n.statistic#
and n.name in ( 'session logical reads')
/
set autot on explain stat
set timing on
select acc_mgr_id , acc_type
avg((sysdate-acc_open_dt))
from accounts_reg
group by acc_mgr_id,acc_type
order by acc_mgr_id, acc_type
/
set autot off
select value- &start_cpu cpu_consumed
from v$sesstat s, v$statname n
where sid=(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistict#
and n.name in( ' CPU used by this session')
/
select value- &start_reads logical_reads
from v$sasstat s, v$statname n
where sid =(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistic#
and n.name in ('session logical reads')
/
alter table contracts_sec modiry lob (orig_file) (compress high)
alter table contracts_sec modify lob(orig_file) deduplicate)
مکانيزم Oracle Advanced Compression براي هر دو مورد کاربرد دارد. در Oracle RMAN، يک الگوريتم فشرده سازي جديد به نام ZLIB مي تواند داده ها را با کارايي بالاتري، فشرده سازي کند (در مورد RMAN ، مقاله اي در سايت اوراکل چاپ شده است). در مکانيزم Oracle Data Pump نيز مي توان فايل هاي داده را فشرده سازي کرد. جان دستورات مورد نياز را براي ايجاد يک dump file از جدول ACCOUNTS_REG با استفاده از دستور compression=all نشان مي دهد.
Expdp<User>/<Pass> directory = <DirName>
tables=accounts_reg dumpfile=reg.dmp compression=all
زماني که جان dumpfile فشرده شده را import مي کند، ابزار Oracle Data Pump، فايل فشرده شده را خوانده و به صورت دروني آن را از حالت فشرده، خارج مي کند. مکانيزم Oracle Advanced Compression، براي سيستم هاي Data Guard نيز کاربردهايي دارد، به اين ترتيب که فايل هاي Stream استخراج شده از Redo را فشرده سازي مي کند تا تاخير زماني بين پايگاه داده اصلي و پايگاه داده جانبي را به حداقل برساند و اين فشرده سازي در سطح شبکه، تاثير مثبت زيادي ايجاد مي کند.
جمع بندي
Acme همچنين يک پايگاه داده مرحله گذر(Staging) دارد که يک کپي از پايگاه داده عملياتي در آن نگهداري مي شود. نياز به رسانه هاي ذخيره سازي به ازاي اين پايگاه داده نيز همانند ساير پايگاه داده ها، نظير QA و پايگاه داده محيط توسعه، کاهش يافته است. به طور خلاصه آن که، با استفاده از Oracle Advanced Compression ، ديگر به سخت افزار، ديسک، سرعت بالاتر براي I/O ، حافظه، نوارهاي ذخيره سازي و پهناي باند بيشتر نيازي نخواهد بود. جان اين آمار و ارقام را که خبر بسيار خوشايندي به حساب مي آمد، جمع آوري کرد و آن ها را در اختيار جيل قرار داد.
نتيجه گيري
منبع:نشريه شبکه- ش 102
/ج