OPTIMISASI QUERY PADA SISTEM DATABASE PARALEL

Nama  : Zainal Rizal

Nrp      : 1110511042

  

OPTIMISASI QUERY PADA SISTEM DATABASE PARALEL

ABSTRAKSI

Arsitektur mesin database paralel telah berubah dari penggunaan hardware menjadi penggunaan arsitektur software yang memiliki aliran data secara paralel. Dengan desain yang baru ini ternyata mampu meningkatkan kecepatan proses query pada database. Dalam paper ini akan dijelaskan tentang bagaimana translasi dari query SQL ke paralel execution plan yang efisien untuk mesin database multiprosesor dengan tujuan untuk mengurangi response time dan meningkatkan troughput di lingkungan multiuser.

Kata kunci : database paralel, query

PENDAHULUAN

Kemajuan dari teknologi Database Management System (DBMS) telah mencapai pada penggunaan teknologi multiprosesing. Oleh karena itu penggunaan database management yang mampu menggunakan teknologi multiprosesing sekaligus multiuser sangat diperlukan. Sistem ini telah menjadi tools manajemen data yang dominan pada lingkungan data yang sangat besar.

Integrasi dari lingkungan kerja yang terdistribusi mampu menghasilkan fungsi distribusi yang lebih efisien dimana program aplikasi berjalan pada workstation yang disebut application server, sedangkan fungsi database ditangani oleh dedicated computers yang disebut database server. Sistem ini dibuat dengan menghubungkan kabel jaringan yang terhubung oleh network.

Distributed database technology dapat diimplementasikan menjadi paralel database sistem. Paralel database sistem memanfaatkan paralelism pada manajemen data untuk menghasilkan database server yang memiliki performansi dan availability yang tinggi.

Sebuah paralel DBMS dapat didefinisikan sebagai DBMS yang diimplementasikan pada multiprosesor komputer. DBMS tersebut melakukan query dengan dua cara, yaitu :

·         Inter-query paralelism

Inter-query mampu melakukan eksekusi paralel dengan menggunakan multiple query yang dilakukan oleh transaksi – transaksi yang berjalan secara konkuren.

·         Intra –query paralelism

Mampu menbuat eksekusi paralel berjalan sendiri – sendiri meskipun dengan query yang sama.

Baik inter-query dan intra – query dapat dihasilkan dengan menggunakan data partioning yang mirip dengan fragmentasi horisontal.

Karakteristik paralel DBMS :

1.      Paralel database adalah sebuah database yang file- filenya disimpan di tiap – tiap komputer yang terhubung dengan jaringan. Ini merupakan perbedaan antara distributed database (DDB) dengan sistem berkas terdistribusi. Untuk membuat sebuah DDB, data secara lojik saling berhubungan dimana hubungan tersebut terdefinisi dalam bentuk yang lebih terstruktur.

2.      Sistem tersebut harus memiliki fungsionalitas penuh sebagai sebuah DBMS. Ini tidak sama dengan distributed file system dan transaction processing system. Transaction processing hanya merupakan salah satu fungsi yang disediakan oleh sistem paralel DBMS, dimana fungsi tersebut menyediakan fungsi – fungsi seperti query processing, organisasi data terstruktur dan layanan lain yang tidak dimiliki oleh transaction processing system.

3.      Distribusi data dari multiprosesor tidak terlihat oleh user, ini disebut transparency. Teknologi paralel database memiliki konsep data independence. Pada lingkungan dimana data terdistribusi dan tereplikasi oleh sejumlah mesin ynag terhubung dengan jaringan. Oleh karena itu transparency memiliki bentuk : network/ distribution, replication transparency dan fragmentation transparency. Transparent access berarti user hanya melihat sebuah database meskipun pada kenyataannya database tersebut terdistribusi.

Idealnya sebuah paralel DBMS memiliki dua keuntungan, yaitu :

1.      Linier scaleup

Linier scaleup menyatakan bahwa performansi database bergantung pada ukuran database, processing dan storage power.

1.      Linier speedup

Linier speedup menunjukan bahwa peningkatan performansi untuk sebuah ukuran database yang tetap adalah linear dan peningkatan linear di dalam pemrosesan dan sumber daya.

Karakteristik performansi dari microprocessor dan workstation membuatnya lebih murah ketika diletakkan bersama-sama sebuah sistem dari komputer kecil dengan kekuatan yang sama dari sebuah mesin besar. Banyak DBMS terditribusi yang komersial beroperasi dalam mini komputer dan workstation yang tujuannya untuk mengambil keuntungan dari karakteristik performansinya. Keunggulan dari DBMS terdistribusi dapat berjalan di Wide Area Network (WAN). Di lain pihak, DBMS terdistribusi yang akan datang dapat mendukung struktur hierarki organisasi dimana site-site terdiri dari cluster-cluster dari komunikasi komputer yang melebihi local area network (LAN) dengan kecepatan tinggi.

Teknologi pada Database Terdistribusi dan Paralel

DBMS terdistribusi dan paralel menyediakan fungsionalitas yang sama seperti DBMS terpusat kecuali lingkungannya, dimana data terdistribusi antara site-site dalam sebuah jaringan komputer atau node-node dari sebuah sistem multiprocessor. Seperti yang telah kita diskusikan di atas, user tidak sadar akan data terdistribusi. Oleh karena itu, sistem menyediakan sebuah logically integrated view dari physically database terdistribusi untuk user.

Arsitektur

Dalam database paralel terdapat banyak kemungkinan alternatif distribusi. Saat ini, yang paling banyak digunakan adalah arsitektur client-server dimana sejumlah client mengakses server database tunggal. Dalam sistem yang disebut multiple-client/single-server ini , manajemen database menjadi sangat sederhana sejak database disimpan dalam server tunggal. The pertinent issue berhubungan dengan manajemen dari client-buffer, pengambilan data, dan penguncian. Manajemen data selesai secara terpusat pada server tunggal.

Arsitektur yang lebih terdistribusi dan fleksibel adalah multiple-client/multiple-server dimana database-databasenya didistribusikan melalui multiple server yang harus berkomunikasi dengan sesama untuk merespon query dari user dan mengeksekusi transaksi. Masing-masing client mempunyai sebuah “rumah” server yang digunakan untuk query dari user secara langsung. Komunikasi antar server bersifat transparant terhadap user. Kebanyakan sistem manajemen database mengimplementasikan satu dari tipe arsitektur client-server.

DBMS terdistribusi sebenarnya tidak dibedakan menjadi client dan server. Idealnya, masing-masing dapat menjalankan fungsionalitas dari client dan server. Arsitektur tersebut dinamakan peer-to-peer, membutuhkan protokol-protokol shopisticated untuk mengelola data terdistribusi melalui multiple sites. Kompleksitas dari kebutuhan software telah menunda pemberian dari produk peer-to-peer DBMS terdistribusi.

Arsitektur sistem paralel terbagi menjadi dua, arsitektur shared-nothing dan shared-memory. Point pentingnya adalah arsitektur shared-disk.

Pada shared-nothing, setiap processor mempunyai akses eksklusive ke memory utama dan unit disk. Oleh karena itu, setiap node dapat dilihat sebagai local site (dengan database dan softwarenya sendiri) dalam sebuah sistem database terdistribusi. Perbedaan antar shared-nothing pada DBMS paralel dengan DBMS terdistribusi pada dasarnya satu dari implementasi platform, oleh karena itu kebanyakan desain dari solusi untuk database terdistribusi dapat digunakan kembali di DBMS paralel. Arsitektur shared-nothing memiliki tiga virtues : cost, extensibility, dan availability. Di lain sisi, shared-nothing memiliki kompleksitas yang tinggi dan berpotensi terjadi masalah keseimbangan. Contoh untuk shared-nothing sistem database paralel meliputi Teradata’s DBC dan Tandem’s Non-StopSQL.

Dalam shared-memory, processor manapun memiliki akses ke modul memory atau unit manapun melalui interkoneksi yang cepat. Beberapa contoh desain mainframe yang baru seperti IBM3090 atau Bull’s DPS8, dan symmetric multiprocessors seperti Sequent dan Enricore, mengikuti jenis ini. Shared-memory memiliki dua keunggulan simpel dan seimbang, dan terdapat tiga kerugian : cost, limited extensibility, dan avalaibility yang rendah.

Contoh dari shared-memory paralel database system termasuk XPRS, DBS3, dan Volcano, dan semua RDBMS yang menggunakan shared-memory multiprosesor. Pada dasarnya implementasi dari DB2 pada IBM3090 yang menggunakan 6 prosesor merupakan contoh yang pertama. Seluruh produk shared-memory komersial seperti INGRES dan ORACLE yang sekarang melakukan inter-query paralelism saja.

Pada pendekatan shared-disk , setiap prsesor memiliki akses ke setiap disk melalui interkoneksi tetapi eksklusif (non-shared) akses hanya pada main memory saja. Setiap prosesor dapat melakukan akses halaman – halaman database pada shared-disk dan mengcopynya ke cachenya sendiri. Untuk menghindari konflik pada saat melakukan akses di halaman yang sama global locking protokol melakukan maintanance pada cache koherensi. Shared disk memiliki sejumlah keunggulan seperti cost, ekstensibility, plot balancing, availability, dan kemudahan migrasi dari sistem uniprosesor. Di lain pihak ini memiliki masalah kompleksitas yang tinggi dan performansi.

Contoh – contoh dari DBMS shared-disk paralel termasuk iMS/VS dari IBM yang menggunakan data sharing seperti juga VAX DBMS dari DEC dan produk – produk Rdb. Implementasi oracle pada VAXcluster dan NCUBE komputer juga menggunakan pendekatan shared-disk karena ini menggunakan ekstensi dari RDBMS kernel dengan minimal. Sebagai catatan bahwa semua sistem tadi hanya menggunakan inter-query paralelism saja.

Query processing dan optimasi

Query prosesing adalah sebuah proses dimana deklarasi query di terjemahkan menjadi operasi manipulasi data pada level rendah. SQL adalah bahasa query standar yang dimiliki oleh DBMS pada saat ini. Optimisasi query merujuk pada proses memilih strategi eksekusi query yang terbaik dari beberapa alternative yang diberikan.

Pada DBMS terpusat proses tersebut melibatkan dua langkah:

1. Query dekomposisi

Query dekomposisi mengambil sebuah SQL query dan menterjemahkannya ke dalam aljabar relasional. Pada proses tersebut query dianalisa secara semantiksehingga query yang tidak benar dapat terdeteksi dan dikeluarkan dengan mudah, sedangkan query yang benar dapat diterima. Simplifikasi melibatkan pengeliminasi redundant predicat yang terjadi sebagai akibat modifikasi query yang menggunakan views, penjagaan keamanan, dan control integritas semantic. Query yang sederhana adalah query yang terstruktur berdasarkan aljabar query.

2. Query optimisasi

Jika kita diberikan SQL query maka dimungkinkan ada lebih dari satu query aljabar. Beberapa dari query aljabar ini bisa lebih baik dibandingkan query alajbar yang lain. Kualitas dari query aljabar ditentukan oleh performansi yang terbaik. Prosedur yang tradisional biasanya hanya menterjemahkan predikat-predikat dan statemen target menjadi operasi relasional seperti pada saat query dituliskan. Query tersebut kemudian ditransformasikan menggunakan aturan-aturan transformasi aljabar, menjadi query aljabar yang terbaik nantinya. Aljabar query yang terbaik ini dinilai berdasarkan cost function dengan menghitung cost yang terjadi pada saat eksekusiquery tersebut. Proses inilah yang disebut query optimisasi.

Pada DBMS terdistribusi, selain menggunakan langkan query dekomposisi dan query optimisasi DBMS ini juga menggunakan data lokalisasi dan global query optimisasi.

Masukan dari data lokalisasi didapatkan dari langkah query dekomposisi. Query aljabar ini dispesifikasikan pada global relation irrespective pada fragmentasi atau distribusi.

Tujuan utama dari data localization adalah untuk melokalisasi hasil data query dengan menggunakan informasi data terdistribusi. Pada langkah ini, fragmen-fragmen yang terlibat pada query ditransformasikan menjadi satu fragmen yang menjalankan relasi secara global. Telah disebutkan sebelumnya bahwa fragmentasi diterjemahkan melalui aturan-aturan fragmentasi yang diekspresikan oleh operasi-operasi relasional (horizontal fragmentation by seletion, vertical fragmentation by projection). Sebuah relasi terdistribusi dapat direkonstruksi dengan menerapkan kebalikan aturan-aturan fragmentasi. Inilah yang disebut localization program. Localization program untuk sebuah query-query yang terfragmentasi secara horizontal maupun vertical merupakan union(join) dari fragmen-fragmen. Oleh karenanya pada saat langkan data localization setiap relasi global digantikan oleh localization programnya dan kemudian menghasilkan fragmen query yang lebih sederhana dan terstruktur untuk menghasilkan query yang baik. Simplification dan restructuring mungkin dapat dilakukan sesuai dengan rule yang sama yang digunakan dalam langkah dekomposisi. Seperti pada langkan dekomposisi, fragmen terakhir dari query hasilnya masih jauh dari optimal karena proses ini hanya meng-eliminasi aljabar query-query yang buruk.

Input dari langkah ketiga adalah query fragmen, yang mana merupakan aljabar query dalanm fragmen-fragmen. Tujuan dari query optimisasi dalah untuk menemukan strategi eksekusi untuk query yang paling optimal. Sebuah strategi pengeksekusian untuk query yang terdistribusi dapat dideskripsikan dengan operasi-operasi aljabar relasional dan communication primitive( operasi-operasi pengiriman dan penerimaan) untuk mentransfer data diantara bagian-bagian. Layer-layer sebelumnya telah melakukan optimisasi pada query, sebagai contoh dengan menghilangkan ekspresi-ekspresi yang redundant. Bagaimanapun juga, optimasi ini tidak bergantung pada karakteristik fragmen seperti kardinalitas. Selain itu, operas-operasi komunikasi tidak bersifat spesifik. Dengan mengubah-ubah urutan operasi dengan satu fragmen query bisa ditemukan banyak execution plan query yang ekuivalen. Optimisasi query menemukan sebuah plan terbaik dari beberapa kandidat plan yang telah ditemukan. Query optimizer memiliki tiga komponen yaitu sebuah ruangan/space untuk search(search space), sebuah cost model, dan sebuah search strategy. Search speace adalah himpunan dari alternative execution plans yang merepresentasikan inputan query. Plan-plan tersebut ekuivalen dan memiliki hasil yang sama tetapi memiliki perbedaan urutan eksekusi dari operasi-opersasi dan bagaimana operasi tersebut diimplementasikan. Cost model memprediksi cost dari execution plans yang terbentuk. Cost model harus memiliki pengetahuan yang akurat tentang eksekusi secara parallel. Search strategy menggali search space yang telah dibuat dan memilih plan terbaik.

Pada lingkungan terdistribusi fungsi cost biasanya didefinisikan dengan time units, merujuk pada sumberdaya seperti alokasi ruang disk, I/O disk, buffer space, CPU cost, communication cost, dsb. Cost tersebut merupakan gabungan dari seluruh I/O, CPU dan communication cost. Meskipun begitu sebuah cost diambil dengan mempertimbangkan bahwa communication cost pada DBMS terdistrinusi merupakan vaktor yang paling utama. Ini dapat diterapkan dengan valid untuk wide area network dimana bandwidth yang terbatas membuat communication menjadi lebih mahal dibanding biaya pemrosesan local. Untuk memilih operasi-operasi yang terurut sangat penting dengan memperhitungkan eksekusi cost dari urut-urutan dari kandidatnya. Dengan memperhitungkan cost eksekusi sebelum query dilakukan seperti static optimization didasarkan pada statistic-statistik fragmen dan berbagai formula untuk memperhitungkan kardinalitas hasil operasi-operasi relasional. Oleh karenanya pemilihan optimisasi sangat bergantung pada ketersediaan statistic-statistik dif ragmen. Aspek yang sangat penting dari query optimisasi adalah join ordering, karena permutasi dari join dapat meningkatkan magnitude dari beberapa permintaan-permintaan. Salah satu dari teknik optimisasi yang mendasar adalah sequence distributed join operation menggunakan semi join operator. Keuntungan utama dari semijoin pada sistem terdistribusi adalah untuk mengurangi cost komunikasi pada operan-operan join. Meskipun begitu ada bebrapa teknik-teknik yang mengutamakan cost pemrosesan secara local sama dengan communication cost, oleh karenanya teknik tersebut tidak menggunakan semijoin karena sangat dimungkinkan meningkatkan cost pemrosesan local. Keluaran dari layer query optimization adalah query aljabar yang menggunakan operasi-operasi komunikasi yang terdapat pada fragmen.

Parallel query optimization memiliki kesamaan dengan distributed query processing. Dimana parallel query optimization memiliki keuntungan dari intra operation parallelism dan juga inter-operation parallelism.

Intra-operation parallelism didapatkan dengancara mengeksekusi sebuah operasi yang terdapat pada node-node sebuah mesin multiprosesor. Ini membutuhkan operan-operan yang sebelumnya telah dipartisi, contohnya horizontal fragmentasi, melalui node-node. Cara melakukan partisi pada relasi dasar merupakan masalah pada physical design. Pada dasarnya, proses melakukan partisi dilakukan dengan cara menggunakan fungsi hash pada atribut relasi yang biasanya terjadi pada join atribut. Kumpulan dari node-node ini dimana sebuah relasi disimpan disebut home. Home of an operation adalah sekumpulan node-node yang harus dieksekusi dan ini harus berada pada operan-operan home bertujuan agar operasi dapat melakukan akses ke operannya sendiri. Untuk operasi-operasi biner seperti join dangat dimungkinkan terjadi proses repartisi salah satu operan-operan tersebut. Optimizer mungkin seringkali menemukan bahwa proses repartisi tersebut sangat menguntungkan. Parallel optimization untuk ,menggunakan intra-operation parallelism dapat membuat beberapa teknik dari database-database yang terdistribusi.

Inter-operation parallelism muncul ketika terdapat dua atau lebih operasi-opersai yang dieksekusi secara parallel yang memiliki sebuah dataflow. Kita menggambarkan dataflow parallelism dengan cara menggunakan pipelining. Independent parallelism muncul ketika operasi dieksekusi pada saat yang sama atau terurut permintaan. Independent parallelism mungkin terjadi ketika operasi-operasi tidak menggunakan data yang sama.

Concurrency control

Kapanpun ketika multiple user melakukan akses baik read maupun write pada shared database proses-proses ini harus disingkronisasi terlebih dahulu untuk memastikan konsistensi dari data base.sinkronisasi ini dapat diperoleh dengan menggunakan konkurensi control algoritma yang memiliki criteria kebenaran seperti serializability. User melakukan akses secara terenkapsulasi dimana operasi pada level terendah diset hanya mampu melakukan operasi read dan write pada database. Konkurensi control algoritma memaksa terjadinya isolasi pada eksekusi transaksi dimana state dari akibat transaksi pada database yang telah diisolasi oleh transaksi-transaksi yang lain sampai transaksi awal menyelesaikan eksekusinya.

Konkurensi control algoritma yang sering digunakan adalah locking-based. Sebuah lock ketika pada mode share atau exlusive diletakkan pada unit storage ketika sebuah transaksi ingin mengakses lock tersebut. Lock-lock ini diletakkan menurut aturan-aturan lock kompatibiliti seperti read write, write read, dan write write. Kita telah mengetahui bahwa teorema dari lock menjaga konkurensi transaksi agar mematuhi aturan-aturan yang memastikan serializabillity dari transaksi-transaksi tersebut: “tidak ada transaksi yang dilaksanakan sebelum transaksi sebelumnya melepaskan lock” yang disebut denga two-phase locking. Sejak transaksi berada pada growing phase, ketika transaksi tersebut mendapatkan lock dan menuju shrinking phase pada saat transaksi tersebut melepas lock. Pada umumnya melepaskan lock merupakan fase transaksi yang paling bermasalah. Oleh karena itu locking-based concurrency control algoritm sangat ketat pada saat memegang lock yang dimiliki sampai akhir transaksi.

Pada sistem DBMS tersebar, permasalahan yang harus dihadapi adalah serializability argument dan concurrency control algoritm pada ekseskusi lingkungan terdistribusi. Pada sistem ini operasi-operasi yang diberikan pada transaksi dapat melakukan eksekusi pada multiple site dimana mereka mengakses data. Pada kasus tersebut serializability argument lebih susah dilakukan. Komplikasi yang terjadi akibat dari permintaan serialization pada sejumlah transaksi yang sama dapat saja berbeda disetiap site. Oleh karenanya, kumpulan-kumpulan eksekusi transaksi trdistribusi dapat terjadi serializable jika dan hanya jika

1. Eksekusi dari sekumpulan transaksi pada setiap site adalah serializable

2. Permintaan serialization dari setiap transaksi pada semua site harus identik.

Konkurensi control algoritma terdistribusi memaksa terjadinya global serializability. Pada algoritma locking-based terdapat tiga alternative cara untuk memaksa terjadinya global serializability: centralized locking, primary copy locking, and distributed locking algoritm.

Pada centralize locking ada sebuah single lock table untuk semua distributed database. Lock tabel ini ditaruh, satu pada setiap site, dibawah control sebuah single lock manager. Lock manager bertanggung jawab untuk melakukan setting dan melepaskan lock transaksi. Semenjak semua lock diatur pada sebuah site maka ini harus melakukan centralized concurrency control dan memaksa terjadinya global serializability. Algoritma ini mudah untuk diimplementasikan tetapi memiliki dua masalah. Central site dapat terjadi bottleneck karena jumlah kerja yang diprediksi dan traffic yang terjadi. Oleh karenanya sistem gagal dalam melakukan atau tidak mampu mengatur proses tersebut.

Primary copy locking adalah sebuah algoritma concurrency control yang sangat berguna pada database tereplikasi dimana dimungkinkan terjadinya pengkopian lebih dari sebuah data yang disimpan pada site yang berbeda. Salah satu dari kopian ini dijadikan sebuah primary copy dan copy ini harus dikunci. Kumpulan dari primary copy pada setiap data dikenal oleh setiap semua site pada sistem terdistribusi dan ketika permintaan lock dari transaksi. Jika database terdistribusi tidak terjadi replikasi, copy locking tidak terjadi pada algoritma distributed locking.

Pada locking terdistribusi, tugas dari lock management adalah membagi setiap site pada sistem. Eksekusi transaksi melibatkan partisipasi dan koordinasi lock manager lebih dari satu site. Lock didapatkan pada setiap site dimana pada saat transaksi mencoba mengakses data. Locking algoritma terdistribusi tidak memiliki centralize locking meskipun begitu communication overhead untuk mendapatkan setiap lock dan kompleksitas algoritma sangan besar. Locking algoritma terdistribusi biasanya digunakan pada sistem R* dan nonstop SQL.

Efek samping dari locking based concurrency control algoritma adalah terjadinya deadlock. Proses deteksi dam menejemen deadlock pada sistem terdistribusi sangat sulit. Namun begitu kemudahan dan performansi algoritma locking yang lebih baik membuatnya lebih disukai dibandingkan alternative yang lain sepseti: timestamp-based algorithms atau optimistic concurrency control. Timestamp-based algorithm mengeksekusi operasi-operasi transaksi yang konflik menurut waktu ketika transaksi tersebut diterima.

Reliability protocols

Kita mengidentifikasikan bahwa DBMS terdistribusi lebih berpotensi menjadi reliability karena pada setiap sistem komponen mengeliminasi setiap kegagalan. Ini membutuhkan disain sistem dan implementasi protocol untuk menangani sistem failure dengan baik.

Pada DBMS terdistribusi terdapat empat kegagalan yang mungkin terjadi: transaction failure, system failure, disk failure, dan communication failure. Failure dapat muncul ketika terjadi error yang disebabkan oleh input data. Pendakatan biasanya dilakukan dengan cara melakukan abort, pensetingan ulang data base pada keadaan semula.

System failure terjadi karena adanya hardware failure atau software failure. Efek dari system failure ini adalah hilangnya content main memory. Oleh karenanya proses update pada main memory akan hilang disebabkan terjadinya system failure. Bagaimanapun juga isi data base disimpan pada secondary storage merupakan keputusan yang tepat dan benar. Untuk mencapai ini DBMS melakukan logging protocol seperti write-ahead logging dimana perubahan pada record di database dicatat pada lock tersebut. Dari prespektif eksekusi terdistribusi, system failure sangat penting karena sistem yang gagal tidak dapat melakukan eksekusi transaksi.

Media failure terjadi karena kegagalan secondary storage melakukan penyimpanan di database. Kegagalan ini dialamatkan oleh duplexing secondary storage dan kopi database sebelumnya. Media failure biasanya diakibatkan oleh local sistem dan tidak disimpan oleh mekanisme realibility dari DBMS terdistribusi.

Tiga tipe kegagalan yang digambarkan diatas biasanya terjadi pada centralized dan distributed DBMS. Komunication failure dilain pihak merupakan failure yang unik pada distribusi sistem. Oleh karenanya hanya ada sedikit terjadinya communication failure. Error yang sangat umum terjadi adalah proses pengitiman pesan yang tidak terurut, pesan yang hilang dan line failure. Pada umumnya dua dari kegagalan tesebut merupakan tanggungjawab dari protocol jaringan dan bukan merupakan masalah bagi DBMS terdistribusi. Jika satu sistem menginginkan pesan dari sestem yang lain dan pesan tersebut tidak pernah datang ini dapat disebabkan pesan tersebut hilang, line yang menghubungkan dua sistem tersebut rusak atau sistem tersebut gagal mengirimkan pesan. Oleh karenanya ini site failure dan communication failure tidak dapat disamakan. Salah satu line failure mungkin terjadi network partitioning dimana setiap bentuk group sistem mampu berkomunikasi dengan sesamanya tetapi tidak dapat melakukan komunikasi diluar group. Ini sangat tidak mungkin bagi database untuk melakukan pengaksesan pada saat yang bersamaan database melakukan konsistensi.

Dua property dari transaksi yang dilakukan oleh realibility protocol adalah atomicity dan durability. Atomicity memerlukan bahwa setiap semua operasi dieksekusi semuanya atau tidak samasekali. Oleh karenanya kumpulan operasi terdiri dari sebuah transaksi yang dianggap satu atomic unit. Atomicity dilakukan meskipun menghadapi failure. Durability membutuhkan commit data ketika transaksi selesai.

Pelaksanaan atomicity dan durability membutuhkan implementasi dari atomic commitment protocol dan distributed recovery protocol. Salah satu atomic commitment protocol yang sering digunakan adalah two-phase commit. Recoverability protocol dibangun diatas local recovery protocol yang bergantung pada mode interaksi DBMS dengan operating system.

Two-phase commit adalah protocol yang paling sederhana untuk menjaga commitment atomic dari transaksi trdistribusi. Ini memperlebar efek dari aksi local atomic commit pada transaksi terdistribusi dengan semua site pada saat melkukan eksekusi distribusi setuju untuk melakukan commit sebelum efek tersebut menjadi permanent. Jika seluruh site setuju melakukan commit maka semua aksi dari transaksi terdistribusi baru mendapatkan efek. Jika tidak ada satupun site yang mengkomit operasi tersebut maka semua operasi harus membatalkan transaksi tersebut. Oleh karenanya dasar dari aturan 2PC menyatakan:

1. Jika tidak satupun site yang menyatakan commit maka transaksi dibatalkan.

2. Jika semua site melakukan commit maka transaksi tersebut dijalankan.

Eksekusi sederhana dari 2PC sebagai berikut. Jika ada sebuah proses pada suatu sistem ingin melakukan eksekusi. Proses tersebut mengirimkan pesan kepada semua sistem apakah dia akan dicommit atau tidak. Lalu setiap sistem akan mengirimkan pesan “vote-commit” sedangkan sistem yang tidak mampu melakukan commit mengirimkan pesan “vote-abort” massage.

Jika telah commit,, koordinator mengirimkan pesan “global commit” ke semua partisipan, jika abort koordinator akan mengirimkan pesan “global-abort” ke partisipan yang melakukan commit terlebih dahulu terhadap transaksi. Tidak ada pesan yang yang dikirimkan ke partisipan yang meminta abort, berdasarkan aturan 2PC, transaction akan di abort secara global. Ini dikenal dengan unilateral abort dari partisipan.

Terdapat dua pergantian pesan antara koordinator dengan partisipan,yang disebut dengan protokol 2PC. Terapat beberapa variasi dari 2PC trsebut, seperti linier 2PC dab distributed 2PC, yang tidak banyak ditemukan pada vendor – vrndor DBMS terdistribusi. Dua varian yang paling penting dari 2PC adalah presumed abort2PC dan presumed commit 2PC. Kedua varian itu dianggap penting karena mereka mengurangi pesan dan overhead I/O dari protokol. Presume abort protocol meliputi X/Open XA standar dan telah diadopsi menjadi bagian standar ISO untuk Open Distributed Processing.

Karakteristik yang paling penting dari protokol 2PC adalah blocking nature. Kegagalan bisa terjadi ketika proses commit. Seperti yang telah didiskusikan, satu – satunya jalan untuk mendeteksi kegagalan tersebut adalah jika terjadi time-out ketika proses menunggu pesan. Ketika ini terjadi, proses (meliputi koordinator dan partisipan) yang time-outnya nengikuti termination protocol memutuskan apa yang harus dilakukan terhadap transaksi yang sedang berada di tengah proses commit. Non-blocking commit protocol adalah sebuah termination protocol yang dapat memutskan apa yang harus dilakukan terhadap transaksi yang mengalami kegagalan dibawah circumstance. Di kasus 2PC, jika kegagalan site terjadi pada koordinator site dan salah satu pertisipan site ketika koordinator sedang mengumpulkan votes dari partisipan, partisipan – partisipan tersebut tidak dapat memutuskan transaksi apa yang harus dijalankan pada dirinya sendiri, dan mereka harus di block sampai koordinator atau partisipan yang mengalami kegagalan bisa memperbaikinya. Selama waktu ini, lock yang diberikan kepada transaksi tersebut tidak dapat dijalankan, sehingga mengurangi availability dari database.

Dengan asumsi bahwa timeout dari partisipan terjadi setelah dia mengirimkan commit vote kepada koordinator, tetapi sebelum menerima pilihan final. Dalam kasus ini, partisipan berada dalam status ready, begitu juga yang terjadi pada termination protocol. Pertama, catat partisipan yang tidak bisa unilaterally mencapai keputusan termination. Sejak partisipan berada pada status ready, dia harus melakukan commit terhadap transaksi tersebut. Akan tetapi hal tersebut tidak dapat dirubah dan mengabortnya. Di lain pihak, it tidak dapat unilateracy memutuskan untuk commit transaksi sejak dimungkinkannya partisipant yang lain boleh memvoting untuk membatalkannya. Dalam kasus ini partisipant akan mengeblok sampai it dapat mempelajari dari seseorang (baik itu koordinator atau beberapa partisipant lainnya) the ultimate fate dari transaksi. Jika kita memperhatikan sebuah struktur komunikasi terpusat dimana partisipant tidak dapat berkomunikasi satu sama lain, berati partisipant kehabisan waktu untuk menunggu koordinator untuk melaporkan keputusan akhir dari transaksi. Sejak koordinator mengalami kegagalan, partisipant akan mengingatkan untuk diblok. Dalam kasus ini, tidak ada alasan termination protocol dapat didisain.

Jika partisipan dapat berkomunikasi satu sama lain, sebuah termination protocol terdistribusi dapat terus dikembangkan. Partisipan yang kehabisan waktu dapat meminta dengan mudah partisipan yang lain untuk membantunya mencapai sebuah keputusan. Jika selama termination semua partisipant merealisasikan bahwa hanya koordinator yang telah gagal, mereka dapat memilih koordinator baru yang dapat merestart proses yang dicommit. Akan tetapi, dalam kasus ini dimana partisipan dan koordinator mengalami kegagalan, maka masih mungkin untuk partisipan yang telah gagal menerima keputusan koordinator dan memberhentikan transaksi yang sesuai. Keputusan ini tidak diketahui oleh partisipan yang lain; Jika mereka memilih koordinator baru dan memproses maka lebih bahaya lagi mereka memutuskan transaksi yang berbeda di site yang gagal. Kasus di atas mencotohkan natural blocking dari 2 PC.

Kebalikan dari terminasi adalah recovery. Ketika site tidak bisa merecover dari kegagalan, aksi apa yang harus diambil untuk merecover database pada site untuk menjadi state yang konsisten. Ini adalah domain dari recoveri protokol terdistribusi. Mempertimbangkan sisi recoveri dari masalah yang didiskusikan diatas, koordinator tempat recoveri dan recoveri protokol harus mennentukan apa yang harus dilakukan dengan transaksi terdisitribusi yang eksekusinya telah dikoordinasikan. Kasus dibawah ini mungkin terjadi :

1. Koordinatornya gagal sebelum menginisialisasi porcedure commit. Oleh karena itu, koordinator akan memulai commit prosesnya sebelum recoveri.

2.Koordinator gagal saat statusnya ready. Dalam kasus ini koordinator telah mengirim pesan prepare. Sebelum recovery koordinator akan merestart proses commit untuk transaksi dari awal dengan mengirimkan pesan prepare satu kali. Jika partisipannya sudah menterminasi transaksi, dapat membangun kembali koordinatornya. Jika mereka di blok mereka mengirim ulang pesan sebelumnya, dan meresume proses commit.

3.Koordinatornya gagal setelah ia membangun partisipan untuk masing masing keputusan global dan menterminasi transaksi tersebut. Oleh karena itu sebelum recoveri tidak perlu melakukan apapun.

REPLICA PROTOKOL

Dalam tiruan database terdistribusi, masing-masing data logic memiliki beberapa bagian fisik. Contohnya gaji dari seorang pegawai bisa disimpan di 3 tempat. Issue ditype database sytem ini adalah untuk diatur some notion dari consistensi diantara yang di copy. Kriteria konsistensi yang paling didiskusikan adalah one copy equivalence, yang assert bahwa nilai dari semua copy dari data logik harus identik saat transaksi yang di update di terminasi.

Jika transparansi dari peniruan diatur, transaksi akan Issue operasi baca dan tulis di data logik x. Replika dari control protokol bertanggung jawab untuk menempatkan operasi di x ke operasi copy fisik dari x(x1……xn). Tipe kotrol protokol tiruan yang enforces satu copy serialibility dikenal sebagai Read-once/write-all(ROWA) protokol. ROWA menempatkan setiap read di x[Read(x)] ke read di salah satu copy fisik xi[Read(xi)]. Copy yang dibaca siginifikan dari persfektif kontrol protokol tiruan dan mungkin di terminasi oleh pertimbangan performansi. Dilain pihak, masing-masing write dalam data logik x ditempatkan ke dalam kumpulan write dalam semua copyan x.

ROWA protokol simpel dan sederhana tapi membutuhkan dari semua kopi dari data logik yang di update dari semua transaksi yang dapat diakses oleh transaksi untuk di terminasi. Titik kegagalan di satu tempat dapat memblog satu transaksi dan mengurangi ketersediaan database.

Jumlah alternatif dari algoritma telah ditawarkan yang mengurangi kebutuhan semua copy dari data logic yang di update sebelum transaksi di terminasi. Mereka relax ROWA dengan melakukan penempatan setiap write menjadi satu subset dari copy fisik.

Ide dari update ini hanya subset dari copy-an. Tetapi tidak sukses menterminasi transaksinya telah menampilkan dasar dari quorum-based voting untuk kontrol protokol tiruan. Algoritma konsensus utama dapat dilihat dari persepektif yang berbeda. Ini menandakan pemilihan yang seimbag untuk setiap copy dan transaksi yang mengupdate data logik dapat sepenuhnya selesai. Selama memiliki pemilihan yang utama, berdasarkan ide ini quorum based voting algoritma terbaru menandai pemilihan untuk setiap copy data tiruan. Setiap operasi harus mendapatkan read quorum(Vr) atau write quorum(Vw) untuk read atau write data secara bijaksana. Jika data yang diberikan memiliki total dari pemilihan V quorum harus mematuhi peraturan di bawah ini.

1.Vr+Vw>V (Sebuah data tidak di read atau ditulis oleh dua buah transaksi secara konkuren, untuk menghindari read,write konflik)

2. Vw>V/2 (Dua operasi write dri dua transaksi tidak dapat terjadi secara konkuren dalam data yang sama untuk menghindari read write konflik)

Perbedaan dengan pendekatan ini adalah bahwa transaksi dibutuhkan untuk memperoleh a quorum bahkan untuk membaca data. Hal ini secara significant memperlambat akses baca ke database. Sebuah alternatif quorum-based vooting protocol mengatasi kekurangan performansi telah diusulkan. Akan tetapi, protokol ini membuat asumsi yang tidak realistik tentang underlying communication system. Protokol ini membutuhkan kegagalan yang merubah topologi network terdeteksi oleh semua tempat secara instant, dan setiap tempat memiliki view dari network terdiri dari semua tempat dimana protokol dapat melakukan komunikasi. Umumnya komunikasi network tidak dapat menggaransikan untuk memenuhi kebutuhan ini. Single copy mensejajarkan kontrol protokol tiruan umumnya dipertimbangkan untuk dibatasi untuk menyediakan availability. Di lain sisi, protokol voting-based itu terlalu rumit dengan pengeluaran tambahan yang tinggi. Oleh karena itu, teknik ini tidak digunakan di produk tertentu di DBMS terdistribusi. Skema tiruan yang lebih fleksibel tel di investigasi dimana tipe dari konsistensi antar copy tertangani. Beberapa server tiruan telah dibangun atau sedang dibangun dengan prinsip ini. Sayangnya, ada beberapa teori yang tidak jelas yan dapat digunakan untuk menjadi alasan tenta kekonsistensian dari database tiruan ketika aturan tiruan lebih luwes.

Permasalahan Peneleitian

Teknologi DBMS terdidtribusi dan paralel telah berkembang di mana kerumitan dan sistem komersial yang dapat diandalakan tersedia. Seperti yang diharapkan, ada beberapa permasalahan yang belum terselesaikan. Di sesi ini kami menyediakan oeverview beberapa dari penelitian mengenai permaslahan ini.

Data Placement

Dalam sistem database parallel, data placement yang baik adalah untuk load balancing. Idealnya, interferensi antara operasi parallel yang konkuren dihindari dengan cara memngoperasikan setiap operasi dalam sebuah independent data set. Independen data set tersebut dapat di peroleh dengan pemecahan (horizontal partitioning) dari sebuah relasi pada sebuah fungsi. Pemecahan tersebut berguna untuk memperoleh interquery parallelisme dengan mengoperasikan independent query dalam beberapa partisi yang berbeda dan intraquery parallelisme, dengan mengoperasikan operasi query pada partisi yang berbeda.

Declustering dapat menjadi single-attribute or multi-attribute. Pada kasus lain, sebuah query memerlukan persamaan dari beberapa muli atribut yang dapat diproses oleh sebuah single node tanpa komunikasi. Pilihan diantara hashing atau range index untuk partisi didesain dengan pokok permasalahan yaitu bahwa hashing dapat mengurangi overhead storage tetapi menyediakan direct support hanya untuk exact match query, sedangkan range index dapat juga mendukung range query.

Full declustering, melalui jalan mempartisikan semua node masing-masing relasi, menyebabkan masalah untuk relasi atau sistem yang kecil dengan banyak node. Solusi yang lebih baik adalah dengan variable declustering dimana setiap relasi disimpan dalam sebuah node. Hal tersebut dapat dikombinasikan dengan multi relation clustering untuk menghindari over head communication dari sebuah operasi binary. Ketika criteria yang digunakan untuk data placement berubah, dibutuhkan reorganisasi yang dinamis. Hal ini penting untuk menampilak ndinamik reorganisasi secara online dan efisien. Tetapi, existing database system menampilkan statis reorganisasi untuk databese tuning. Reorganisasi statis berjalan secara periodik ketika sistem idle untuk mengubah data placement berdasarkan perubahan dalam ukuran database atau pola akses. Tetapi, reorganisasi dinamik tidak diperlukan untuk menghentikan aktivitas-aktivitas dan menyesuaikan untuk perubahan. Reorganisasi juga sisa transparansi untuk meng-compile program-program yang berjalan pada sistem parallel. Faktanya, program- program tidak akan di recompile karena reorganisasi. Oleh karena itu, progrma-program yang telah dicompile akan menyisakan lokasi data. Hal ini menyatakan bahwa optimizer tidak mengetahui aktual node disk dimana sebuah relasi disimpan atau sebuah operasi dieksekusi. Kumpulan node dimana relasi disimpan ketika sebuah relasi dieksekusi disebut home. Kumpulan node dimana sebuah operasi akan dieksekusi disebut home of operation. Namun, optimizer memerlukan abstarka knowledge home tersebut dan sistem runtime membuat asosiasi antara home dan aktual node.

Masalah serius dalam data placement adalah bagaimana distribusi data yang akan membentuk partisi non uniform dan efek negative load balancing. Arsitektur hibrid dengan node dari memori yang berbeda dan kekuatan pemrosesan dapat diekspliotasi dengan berguna. Solusi lain adalah merawat partisi non-uniform dengan tepat. Pemisahan antara phisical and logical nodes berguna sejak logical nodes dipetakan tepat ke beberapa phisical nodes.

Faktor yang menyebabkan komplikasi dalam data placement adalah data replication/ data tiruan. Sebuah pendekatan tak dibuat-buat adalah untuk memelihara 2 data yang telah disalin, yaitu sebuah primary dan backup data dalah 2 node terpisah. Namun ketika ada kegagalan node, pengambilan node yang mempunyai salinan akan menjadi dobel, dengan demikian akan menyakiti proses load balancing. Untuk menghindari masalah tersebut, beberapa strategi pembuatan data replication dibandingkan. Sebuah solusi menarik adalah pemecahan Teradata secara selang-seling dimana pemecahan backup-copy diselenggarakan dalam beberapa nodes. Ketika terjadi kegagalan, pengambilan primary-copy diseimbangkan diantara node dari backup copy. Namun rekonstruksi primary copy dari pecahan-pecahan backup copy akan menimbulkan biaya. Jika normal, pemeliharaan backup juga akan menimbulkan cost. Solusi yang lebih baik adalah dengan pemecahan menggunakan konsep Gamma yang berurutan, dimana menyimpan primary dan backup copy dalam 2 node yang berdekatan. Jika gagal, pengambilan failed node dan backup node diseimbangkan diantara seluruh sisa nodes dengan menggunakan kedua nya. Pemeliharaan backup copy akan lebih murah.

NETWORK SCALLING PROBLEM

Database community tidak mempunyai kepahaman secara menyeluruh terhadap arti dari performansi semua alternatif desain yang mengiringi pengembangan distributed DBMS. Secara spesific, pertanyaan akan bertambah mengenai scalability beberapa protocol dan algoritma sistem. Masalah scaling hanya satu bagian dari banyak problem. Hampir semua performansi mempelajari bagaimana kita aware terhadap biaya dari sebuah simple network. Kadang-kadang tidak realistis menggunakan sebuah fixed communication delay yang bebas terhadap semua karakteristik jaringan seperti penyimpanan, ukuran pesan, jaringan,dll. Secara umum, performansi algoritma dan protocol dalam arsitektur LAN ynag berbeda tidak mudah dimengerti baik dalam kelakuan comparative nya dalam pemindahan dari jaringan LAN ke WAN. Cara yang tepat untuk mengatasi masalah scalability adalah mengembangkan model performansi yang powerful, tools dan metode pengukuran.

Distributed and Parallel Query Processing

Seperti yang telah didiskusikan sebelumnya, query optimisasi menggenerate sebuah optimal execution plan sebagai input untuk membuat keputusan memperhatikan pemesanan operasi, pergerakan data, dan pilihan antara distributed dan local algoritma untuk operasi database. Ada beberapa masalah yang berhubungan dengan langkah ini.

Cost model digunakan untuk memprediksi cost untuk mengeksekusi alternative execution plan dari sebuah query. Sebuah hal penting bahwa seringkali cost model digabungkan dengan pembatasan keefektifan optimisasi dalam meningkatkan throughput. Query optimisasi akan berguna dalam mengukur cost model yang kemudian disaring setelah melalui beberapa percobaan. Walaupun bahasa query terus meningkat (misalnya versi baru SQL akan terus dikeluarkan), optimisasi query akan selalu fokus pada subset dari bahasa query yaitu pada operasi select-project-join queri. Hal ini adalah kelas penting dari sebuah query untuk sebuah optimisasi yang bagus. Sebagai hasilnya, sebuah transaksi yang baik dikembangkan untuk sebuah proses join dan semijoin. Namun, ada query penting yang lain yang menjamin optimisasi seperti queri dengan disjunsi, union, aggregasi ataupun sorting. Sebuah solusi menjanjikan adalah untuk memisahkan pengertian optimisasi itu sendiri yang dapat didedikasikan ke beberapa optimasi yang lebih ahli.

Biaya optimisasi dan kualitas rencana eksekusi merupakan dua hal yang penting. Biaya optimisasi yang lebih tinggi mungkin diterima untuk menghasilkan plan yang lebih baik bagi sebuah query yang dieksekusi berkali-kali. Namun biaya optimisasi yang tinggi dapat tidak diterima oleh queri ad hoc yang dieksekusi hanya sekali. Biaya optimasi diperoleh dengan mencari solution space untuk alternatif rencana eksekusi. Dalam sistem terdistribusi, solution space berupa sebuah temapat yang cukup besar karena range dari strategi eksekusi nya juga luas. Oleh karena itu, penting untuk mempelajari strategi pencarian yang efisien dari sebuah aplikasi yang dapat menghindari pencarian secara mendalam. Optimisasi query menunjukkan pengeksekusian sebuah query. Masalah besar yang berkaitan dengan pendekatan ini adalah bahwa cost model digunakan untuk optimisasi yang mungkin tidak akurat karena perubahan dalam ukuran fragment atau reorgaisasi database .

Persoalan rumit yang berkaitan dengan strategi pencarian adalah masalah penggabungan permintaan dimana NP-complete dalam banyaknya hubungan [Ibaraki and Kameda, 1984]. Suatu pendekatan khas untuk memecahkan masalah adalah menggunakan dynamic programming [Selinger et al., 1979], yang berupa strategi deterministic. strategi ini hampir lengkap dan meyakinkan serta terbaik dari semua rencana yang ditemukan. itu membuat suatu cost optimisasi dapat diterima ketika kecilnya hubungan di dalam query. Akan tetapi, pendekatan ini menjadi mah al ketika banyaknya hubungan lebih besar dari 5 atau 6. Oleh sebab itu, telah ada hal baru dari strategi randomized yang mengurangi kompleksitas optimisasi, tetapi tidak menjamin terbaik dari semua rencana. Strategi randomized menyelidiki pencarian tempat dalam sebuah cara dimana bisa dikendalikan penuh seperti optimisasi yang berakhir setelah budget waktu optimisasi telah dipenuhi. Cara lain untuk mengurangi kompleksitas optimisasi adalah untuk mengambil pendekatan heuristik. Tidak seperti strategi deterministik, strategi randomized memperbolehkan optimizer untuk saling menukar waktu optimisasi untuk waktu eksekusi [Ioannidis and Wong, 1987, Swami and Gupta, 1988, Ioannidis and Kang, 1990].

Proses Transaksi Terdistribusi

Meskipun penelitiaan telah selesai pada waktunya, masih ada topic yang berguna untuk investigasi di area proses transaksi terdistribusi. Sebelumnya kita telah mendiskusikan masalah pengukuran dari algoritma manajemen transaksi. Sebenarnya, tiruan mengkontrol protokol, model transaksi yang lebih rumit, dan kriteria kebenaran non-serializable membutuhkan perhatian lebih lanjut. Tempat data tiruan membutuhkan eksperimen lebih lanjut, penelitian dibutuhkan dalam metode tiruan untuk komputasi dan komunikasi, dan kelanjutan kerja dibutuhkan untuk mengaktifkan eksplorasi semantik dari spesifik aplikasi. Percobaan di butuhkan untuk mengevaluasi tuntutan yang dibuat oleh algoritma dan system designer. Dan kita kekurangan framework yang konsisten untuk membandingkan teknik.

Salah satu kesulitan dari pengevaluasiaan teknik tiruan secara kuantitatif pada ketiadaan penerimaan model kesalahan. Sebagi contoh model Markov kadangkala digunakan untuk menganalisa ketersediaan penerimaan oleh tiruan protokol dengan menganggap statistical independence dari kesalahan individu, dan jarangnya partisi network juga berhubungan dengan kegagalan. Kita tidak mengetahui, apakah kedua asumsi tersebut dapat dipertahankan, atau kita tahu seberapa sensitif model Markov terhadap asumsi ini. Validasi dari model markov melalui simulasi membutuhkan pengukuran empirik, sejak simulasi sering memasukkan asumsi yang sama yang mendasari analisis Markov. Pada pembelajaran empirik untuk pola kegagalan monitor dalam sistem produksi dunia nyata, yang bertujuan untuk menkonstruksikan model simpel dari tipe kegagalan.

Untuk mendapatkan tujuan dari data tiruan, yaitu availabiliy dan performance, sangatlah penting menyediakan sistem terintegrasi sedemikian sehingga data tiruan bergerak sejalan dengan peniruan dari komputasi dan komunikasi. Hanya data tiruan yang telah di pelajari secara intensif, yang hanya sedikit yang telah selesai tirukan di komputasi dan komunikasi.

Yang berhubungan dengan peniruan, kerja lebih dibutuhkan di model transaksi yang berkolaborasi, terutama yang memanfaatkan semantik dari aplikasi. Ketersediaan yang lebih besar dan performansi yang dapat dibuktikan , sama halnya dengan konkurensi, dapat diraih denga model tersebut. Teknologi database memasuki domain aplikasi yang baru seperti engineering design, software development, dan office information system, membutuhkan perubahan transaksi. Oleh karena itu, kerja lebih dibutuhkan dalam transaksi yang lebih kompleks.

Model transaksi yang rumit sangat penting dalam sistem terdistribusi untuk beberapa alasan. Yang paling penting adalah domain aplikasi yang baru yang di support oleh DBMS terdistribusi di masa yang akan datang membutuhkan model transaksi yang berkerja sama lebih abstrak dalam operasi yang mengeksekusi data yang kompleks. Aplikasi ini memiliki paradigma sharing yang berbeda dibandingkan tipe-tipe database.

Object Oriented DBMS saat ini sedang diinvestigasi sebagai kandidat yang potensial untuk menemukan kebutuhan dari “advance” aplikasi. Sistem ini men-enkapsulasi operasi dengan data. Oleh karena itu, mereka membutuhkan definis yang jelas dari perubahan sementiknya, dan model transaksi yang dapat mengekspoitasi semantik dari operasi yangg di enkapsulasi [Ozsu, 1994].

KESIMPULAN

DBMS terdistribusi dan paralel telah mejadi realitas di beberapa tahun belakangan. Mereka menyediakan fungsionalitas dari centralized DBMSs, tetapi di lingkungan yang datanya terdistribusi melalui tempat komputer network atau di multiprocessor system. Database terdistribusi telah memiliki pergerakan yang alami dan ekspansi dari database dengan sedikit penambahan dari mesin yang baru. Karateristik nilai performansi sistem ini, menguntungkan untuk meningkatkan teknologi komputer network. DBMS paralel mungkin satu-satunya yang realistis untuk menemukan kebutuhan performansi dari keberagaman aplikasi penting yang menempatkan signifikan kebutuhan output di DBMS. Untuk mendapatkan kebutuhan ini, DMBS terdistribusi dan paralel harus di disain dengan pertimbangan khusus untuk protokol dan strategi. Di sini kami menyediakan overview dari protokol dan startegi ini.

Terdapat beberapa isu yang berhubungan yang tidak kami jelaskan. Dua topik utama yang kami gunakan adalah multidatabase system dan distributed object-oriented database. Hampir sebagian informasi menyusun sistem lainnya dengan DBMS inplementasinya sendiri. Kebutuhan selanjutnya adalah untuk mengintegrasikan otonomi ini dan sistem heterogen yang mungkin menyingkapi kesulitan yang heterogen. Sistem yang menyediakan akses ke disain yang mandiri dan implementasi, kemungkinan yang heterogen, dan database di sebut multidatabase system [Sheth and Larson, 1990].

Penetrasi dari teknologi database management ke area yang sistem database relasionalnya yang tidak di disain untuk melayani telah membangkitkan keinginan untuk melakukan penelitian model sistem yang baru dan arsitektur. Kandidat utama untuk menemukan kebutuhan dari sistem ini adalah DBMS object oriented. Distribusi dari object-oriented DBMSs meningkatkan isu katagori umum sebagai manajemen objek terdistribusi.

KAMUS ISTILAH

Atomicity : properti dari proses transaksi dimana semua operasi dari transaksi tereksekusi atau tidak ada yang tereksekusi sama sekali. (semua atau tidak sama sekali)

Arsitektur Client/Server : Sebuah arsitektur DBMS yang paralel atau terdistribusi dimana satu set mesin dengan kemampuan yang terbatas untuk mengakses sustu server yang bertugas mengatur data.

Algoritma Concurency Control : Algoritma yang mensinkronkan operasi-operasi dari transaksi-transaksi yang bersamaan pada sebuah shared database.

DBMS terdistribusi : Sebuah DBMS yang mengatur database yang terdistribusi antar titik dari sebuah jaringan komputer dan membuat distribusi ini jelas untuk user.

Deadlock : sebuah keadaan dimana setiap transaksi saling menunggu lock yang sedang digunakan oleh transaksi lain pada suatu saat.

Durability : properti dari sebuah proses transaksi dimana hasil dari transaksi yang sudah sukses menahan beberapa kegagalan.

Inter-query parallelism : eksekusi paralel dari query yang banyak di-generate oleh transaksi yang konkuren.

Intra-query parallelism : eksekusi paralel dari operasi yang banyak, memungkinkan dalam satu query.

Isolation : properti dari eksekusi transaksi yang mengakibatkan sebuah transaksi di database diidolasi dari transaksi lainnya sampai transaksi yang pertama selesai.

Locking : Sebuah metode pengaturan konkurensi dimana lock ditempatkan di unit database untuk kepentingan transaksi yang mencoba mengaksesnya.

Query Optimization : proses dengan startegi eksekusi terbaik untuk memberikan query terbaik dari beberapa alternativ yang ada.

Query Processing : proses yang deklarasi query nya diterjemahkan ke low-level operasi manipulasi data.

Parallel database management system : sebuah DBMS yang diimplementasikan pada suatu multiprocessor yang digabungkan.

Quorum-based voting algorithm : tiruan mengendalikan protokol dimana transaksi mengumpulkan suara untuk mari embaca dan menulis salinan item data. mereka diijinkan untuk membaca atau menulis item data jika mereka dapat mengumpulkan suatu korum dari suara

Read-Once/Write-All protocol : tiruan mengendalikan protokol yang mana memetakan masing-masing operasi baca logic menjadi read dari salinan fisik dan memetakan operasi tulis logic menjadi tulis dari salinan fisik

Serializability : pengontrolan secara konkurensi kepada kebenaran dari kriteria yang membutuhkan eksekusi konkuren dari transaksi harus ekuivalen terhadap efek dari eksekusi serial transaksi tersebut

Shared-disk architecture : arsitektur DBMS paralel dimana semua prosesor memiliki akses kesemua unit disk melalui interkoneksi tetapi dengan aksesyang eksklusif ke memori utama.

Shared-memory architecture : arsitektur DBMS paralel dimana semua prosesor memiliki akses ke setiap modul memory atau disk melalui interkoneksi yang cepat.

Shared-nothing architecture : arsitektur DBMS paralel dimana semua prosesor memiliki akses eksklusive ke memori utama dan unit disk nya masing-masing.

Stable database: bagian dari database yang disimpan dalam secondary storage.

Termination protocol : protokol dimana individu dapat memutuskan bagaimana melakukan terminasi terhadap beberapa transaksi saat mereka tidak dapat berkomunikasi dengan sesamanya ketika transaksi sedang di eksekusi.

Transaction : unit dari konsisten dan atomik eksekusi.

Transparency :perluasan dari data independent ke sistem terdistribusi dengan menyembunyikan pendistribusiannya, fragmentasi, dan data tiruan dari user.

Two-phase commit : atomik komitmen protokolyang memastikan jika transaksi ditermminasi dengan cara yang sama disetiap tempat transaksi tersebut dieksekusi.

Two-phase locking : algoritma penguncian dimana transaksi tidak di perkenankan untuk memminta lock baru setelahmenjalankan lock sebelumnya.

Volatile database : bagian dari database yang disimpan di buffer memori utama.

DAFTAR PUSTAKA

[1]   Abdullah,  D.  (2003).  Query  Optimization  in

Distributed  Databases.Middle  East  Technical

University.

[2]   Alom,B.M.M.,  Henskens,  F.,  &  Hannaford,  H.

(2009).  Query  Processing  and  Optimization  in

Distributed Database Systems. IJCSNS. VOL.9 No.9.

halaman 143-152. 2009.

[3]  Bell,  D.,  Grimson,  J.  (1992).  Distributed  Database

System. Addison-Wesley Publishing Company, Inc.

Great Britain.

[4]   Chin,  W.  C.  1984.  An  Optimization  of  Queries  in

Distributed  Database  Systems.  JOURNAL  OF

PARALLEL  AND  DISTRIBUTED  COMPUTING  3.

halaman 137-157. 1986.

[5]   Elmasri,  Ramez  &  Navathe,  Shamkat  (2010).

Fundamentals  of  Database  Systems.  6th  edition.

Addison Wesley.

[6]   Groth, David and Skandler, Toby (2009). Network+

Study Guide, Fourth Edition. Sybex, Inc

[7]  McQuerry,  Steve.  'CCNA  Self-Study:

Interconnecting  Cisco  Network  Devices  (ICND),

Second Edition'. Cisco Press

[8]  Microsoft  Developer  Network.  (2013).  Query

Window  Statistics  Pane.

http://msdn.microsoft.com/enus/library/aa216969%28SQL.80%29.aspx.  1  Januari

2014