Distribusi Database

Distribusi Database

Pokok Bahasan

• Pendahuluan
• Tipe Basis Data Terdistribusi
• Arisitektur Basis Data Terdistribusi
• Penyimpanan Data pada Sistem Terdistribusi
• Manajemen Katalog Terdistribusi
• Qery Terdistribusi
• Joins pada DBMS Terdistribusi
• Mengubah Data Terdistribusi
• Locking pada Sistem Terdistribusi
• Distribusi Recovery

Tujuan

Setelah mempelajari materi bab ini, mahasiswa diharapkan mampu :

1. Memahami perbedaan DBMS terdisribusi dan DMBS terpusat.
2. Memahami arsistektur basis data terdistribusi
3. Memahami penyimpanan data, catalog data pada system terdistribusi
4. Memahami query, join dan optimasi query pada DBMS terdistribusi
5. Memahami bagaimana mengubah data, melakukan locking data pada DBMS terdistribusi.
6. Memahami bagaimana menangani kegagalan pada sistem terdistribusi

Pendahuluan

Pada basis data terdistribusi (distributed database), data disimpan pada beberapa tempat (site), setiap tempat diatur dengan suatu DBMS (Database Management System) yang dapat berjalan secara independent.

Properti yang terutama terdapat pada basis data

terdistribusi :

• Independensi data terdistribusi : pemakai tidak perlu mengetahui dimana data berada (merupakan pengembangan prinsip independensi data fisik dan logika).
• Transaksi terdistribusi yang atomic : pemakai dapat menulis transaksi yang mengakses dan mengubah data pada beberapa tempat seperti mengakses transaksi local.

Kedua property tersebut harus mendukung system secara efisien. Untuk system terdistribusi yang bersifat global, properti-properti tersebut kemungkinan tidak tepat karena adanya administrasi yang terlalu berlebihan dalam membuat lokasi data yang transparan.

Tipe Basis Data Terdistribusi

Terdapat dua tipe basis data terdistribusi :

• Homogen : yaitu sistem dimana setiap tempat menjalankan tipe DBMS yang sama
• Heterogen : yaitu sistem dimana setiap tempat yang berbeda menjalankan DBMS yang berbeda, baik Relational DBMS (RDBMS) atau non relational DBMS.

Arsitektur Basis Data Terdistribusi

Terdapat tiga pendekatan alternatif untuk membagi fungsi pada proses DBMS yang berbeda. Dua arsitektur alternatif DBMS terdistribusi adalah Client/Server dan Collaboration Server.

1. Client-Server

Sistem client-server mempunyai satu atau lebih proses client dan satu atau lebih proses server, dan sebuah proses client dapat mengirim query ke sembarang proses server . Client bertanggung jawab pada antar muka untuk user, sedangkan server mengatur data dan mengeksekusi transaksi. Sehingga suatu proses client berjalan pada sebuah personal computer dan mengirim query ke sebuah server yang berjalan pada mainframe.

Arsitektur ini menjadi sangat popular untuk beberapa alasan.

Pertama, implementasi yang relatif sederhana karena pembagian fungis yang baik dank arena server tersentralisasi.

Kedua, mesin server yang mahal utilisasinya tidak

terpengaruh pada interaksi pemakai, meskipun mesin client tidak mahal.

Ketiga, pemakai dapat menjalankan antarmuka berbasis grafis sehingga pemakai lebih mudah dibandingkan antar muka pada server yang tidak user-friendly.

2.Collaboration Server

Arsitektur client-server tidak mengijinkan satu query mengakses banyak server

karena proses client harus dapat membagi sebuah query ke dalam beberapa subquery untuk dieksekusi pada tempat yang berbeda dan kemudian membagi jawaban ke subquery.

Proses client cukup komplek dan terjadi overlap dengan server; sehingga

perbedaan antara client dan server menjadi jelas. Untuk mengurangi perbedaan digunakan alternatif arsitektur client-server yaitu sistem Collaboration Server.

Pada sistem ini terdapat sekumpulan server basis data, yang menjalankan transaksi data lokal yang bekerjasama mengeksekusi transaksi pada beberapa server .

Jika server menerima query yang membutuhkan akses ke data pada server lain,

sistem membangkitkan subquery yang dieksekusi server lain dan mengambil

hasilnya bersama-sama untuk menggabungkan jawaban menjadi query asal.

Sistem basis data

Ada 2 sistem basis data :

1. Terpusat (Centralized)
2. Terdistribusi (Distributed)

Perbedaan utama ke dua sistem tersebut :

• Pada sistem terpusat data ditempatkan di satu lokasi dan semua lokasi lain mengakses basis data di lokal tsb.
• Pada sistem terdistribusi data ditempatkan dibanyak lokasi, tetapi menerapkan suatu mekanisme tertentu untuk membuatnya menjadi satu kesatuan basis data.

Struktur Basis Data Terdistribusi

Sebuah sistem basis data terdistribusi hanya mungkin dibangun dalam sebuah sistem jaringan komputer (topologi).

Sistem topologi yang dapat digunakan :

1. Topologi star (bintang)
2. Topologi Ring (cincin)
3. Topoogi Bus

Perbedaan utama dari ke tiga topologi tsb :

1. Biaya Instalasi

Biaya dalam membangun hubungan (link) antar simpul.

2. Biaya Komunikasi

Waktu dan biaya dalam pengoperasian sistem berupa pengirim data dari satu simpul ke simpul lain.

3.Kehandalan

Frekuensi/tingkat kegagalan komunikasi yang terjadi.

4.Ketersediaan

Tingkat kesiapan data yang dapat diakses sebagai antisipasi kegagalan komunikasi.

Jenis Transaksi sistem basis data terdistribusi

Dalam sebuah sistem basis data terdistribusi, ada 2 jenis transaksi yang terjadi :

1. Transaksi lokal

Transaksi yang mengakses data pada suatu simpul (mesin/server) yang sama dengan simpul.

2.Transaksi Global

Transaksi yang membutuhkan pengaksesan data di simpul yang berbeda dengan simpul dimana transaksi tsb dijalankan, atau transaksi dari sebuah simpul yang membutuhkan pengaksesan data ke sejumlah simpul yang lain.

Keuntungan dan Kerugian

Keuntungan dari Basis Data Terdistribusi :

1. Pembagian (pemakaian bersama) Data dan Kontrol yang Tersebar.

Setiap user pada suatu lokasi (simpul) dapat mengakses data yang berada di lokasi lainnya.

2. Kehandalan dan Ketersediaan.

Jika ada sebuah simpul mengalami kerusakan, simpul/lokasi yang lain akan tetap dapat beroperasi.

3.Kecepatan Query

Sebuah query melibatkan data di sejumlah lokasi/simpul, maka query tsb dapat dipilah ke sejumlah subquery yang akan dijalankan di simpul yang bersesuaian.

Kelemahan dari sistem basis data terdistribusi :

1. Biaya pembangunan perangkat lunak.

perlu biaya besar untuk implementasi sistem basis data.

2.Potensi Bug yang lebih Besar.

Akan lebih sulit menjamin kebenaran algoritma/program karena beroperasi secara paralel.

3.Peningkatan Waktu Proses (Overhead).

Waktu untuk pertukaran data dan tambahan komputasi yang diperlukan untuk mengupayakan koordinasi antar simpul merupakan beban tambahan (overhead) yang tidak dijumpai dalam sistem terpusat.

Desain Basis Data Terdistribusi

Ada beberapa pendekatan yang berkaitan dengan penyimpanan data/tabel dalam sebuah sistem basis data terdistribusi.

1. Fragmentasi

Data dalam tabel dipilah dan disebarkan ke dalam sejumlah fragmen. Tiap fragmen disimpan di sejumlah simpul yang berbeda-beda.

2.Replikasi

Sistem memelihara sejumlah salinan/duplikat tabel data. Setiap salinan tersimpan dalam simpul yang berbeda, yang menghasilkan replikasi data.

3. Replikasi dan Fragmentasi

Merupakan kombinasi dari kedua hal sebelumnya. Data/tabel dipilah dalam sejumlah fragmen. Sistem lalu mengelola sejumlah salinan dari masing-masing fragmen tadi di sejumlah simpul.

Fragmentasi Data

Rekontruksi ini dapat dilakukan melalui sebuah penerapan operasi Union (untuk menggabungkan baris data) ataupun operasi Natural Join (penggabungan field data) terhadap fragmen-fragmen tersebut.

Ada 2 jenis pembentukan fragmentasi :

1. Fragmentasi Horizontal
2. Fragmentasi Vertikal
   
   

Fragmentasi Horizontal

Fragmentasi Horizontal sebuah tabel r di partisi ke dalam sejumlah fragmen r_1, r₂, r₃ ... r_n yang merupakan pemilahan baris data. Setiap baris data pada tabel r harus berada minimal di sebuah fragmen, sedemikian hingga tabel awalnya dapat dibentuk kembali jika diperlukan.

Kita dapat melakukan rekonstruksi dari tabel r dengan menerapkan operasi Union dari semua fragmen, dengan ekspresi :

r = r₁ U r₂ U r₃ ... Ur_n

Menurut ekspresi diatas maka nasabah1 dan nasabah2 dapat digabungkan dengan operasi Union untuk mendapatkan kembali tabel Nasabah awal.

Nasabah = Nasabah₁ U Nasabah₂

Fragmentasi Vertikal

Fragmentasi Vertikal sama dengan dekomposisi (penguraian) tabel yang merupakan pemilahan field.

Bagaimana cara untuk memutuskan field apa saja yang akan ditempatkan di fragmen pertama, di fragmen kedua dan fragmen-fragmen selanjutnya ?

Answer :

Dengan mempertimbangkan fungsinya atau perkiraan frekuensi pemakaian.

Ekspresi :

nasabah₁ = Π no_nasabah, nama, alamat, kota (nasabah)

nasabah₂ = Π no_nasabah, saldo_simpan(nasabah)

nasabah₃= Π no_nasabah, saldo_pinjam(nasabah)

Satu hal yang paling penting diperhatikan dalam Fragmentasi adalah jaminan bahwa kita dapat mengembalikan semua fragmen itu ketabel semula dengan tepat.

r = r₁ |Χ| r₂ |Χ|r₃ ... |Χ|r_n

Replikasi Data

berarti bahwa kita menyimpan beberapa copy sebuah relasi atau fragmen relasi. Keseluruhan relasi dapat direplikasi pada satu atau lebih tempat.

contoh :

jika relasi R difragmentasi ke R1, R2 dan R3, kemungkinan terdapat hanya satu copy R1, dimana R2 adalah replikasi pada dua tempat lainnya dan R3 replikasi pada semua tempat.

Motivasi untuk replikasi adalah :

• Meningkatkan ketersediaan data

Jika sebuah tempat yang berisi replika melambat, kita dapat menemuka data yang sama pada tempat lain. Demikian pula, jika copy lokal dari relasi yang diremote tersedia, maka tidak terpengaruh saluran komunikasi yang gagal.

• Evaluasi query yang lebih cepat

query dapat mengeksekusi lebih cepat menggunakan copy local dari relasi termasuk ke remote site.

• Memperbaiki performansi dari operasi query

Manajemet Katalog Terdistribusi

Menyimpan data terdistribusi pada beberapa tempat dapat menjadi sangat kompleks. Kita harus menyimpan data bagaimana relasi difragmentasi dan replikasi, bagaimana fragmen relasi didistribusikan ke beberapa tempat dan dimana kopi dari fragmen disimpan. Nama setiap replika dari setiap fragmen harus ada. Untuk menyediakan otonomi lokal digunakan format sebagai berikut :

<local-name, birth-site>

Katalog setiap tempat menggambarkan semua obyek (fragmen, replika) pada suatu tempat dan menyimpan data replika dari relasi yang dibuat pada tempat tersebut.

Untuk menemukan relasi, lihat pada katalog birth-site. Birth-site tidak pernah berubah meskipun relasi dipindahkan.

Query Terdistribusi

Misalnya pada dua relasi :

Sailors(sid: integer, sname: string, rating: integer, age: real)

Reserves(sid: integer, bid: integer, day: date, rname: string)

Kemudian dilakukan query berikut :

SELECT AVG(S.age) FROM Sailors S WHERE S.rating > 3 AND

S.rating < 7

• Fragmentasi horisontal : tupel dengan rating < 5 pada Shanghai, >= 5 pada Tokyo. Harus menghitung SUM(age), COUNT(age) pada kedua tempat. Jika WHERE berisi hanya S.rating>6, maka hanya satu tempat.
• Fragmentasi vertikal : sid dan rating pada Shanghai, sname dan age pada Tokyo, tid pada kedua tempat. Harus melakukan rekonstruksi relasi dengan join pada tid kemudian mengevaluasi query.
• Replikasi : Sailor di-copy kan pada kedua tempat.

Joins pada DBMS Terdistribusi

Sebagai contoh, London menyimpan 500 halaman Sailor dan Paris mempunyai 1000 halaman Reserves seperti Gambar berikut

LONDON PARIS

500 halaman 1000 halaman

contoh sistem terdistribusi

Optimasi Query pada DBMS Terdistribusi

Untuk optimasi query pada sistem terdistribusi, menggunakan pendekatan biaya, misalnya pada semua plan, mengambil yang termurah, sama dengan optimasi tersentralisasi. Perbedaan optimasi query pada sistem terdistribusi dan sistem tersentralisasi,

1. biaya komunikasi harus dipertimbangkan.
2. otonomi tempat lokal harus diperhatikan.
3. menggunakan metode join terdistribusi yang baru.

Query site membangun daerah global, dengan daerah local menggambarkan pemrosesan pada setiap tempat. Jika sebuah tempat dapat melakukan improvisasi pada daerah lokal, dapat dilakukan dengan bebas.

Mengubah Data Terdistribusi

Untuk melakukan pengubahan data terdistribusi, dilakukan replikasi transaksi yang dapat dilakukan dengan cara :

1. Synchronous Replication

semua copy dari relasi yang dimodifikasi (fragmen) harus diubah sebelum modifikasi transaksi commit. Distribusi data dibuat transparan ke pemakai.

1. Asynchronous Replication

Copy dari sebuah relasi yang dimodifikasi hanya diubah secara periodik, copy yang berbeda akan keluar dari sinkronisasi. User harus waspada pada distribusi data. Produk saat ini mengikuti pendekatan ini.

Synchronous Replication

Terdapat dua teknik dasar untuk menjamin transaksi terlihat nilai yang sama dengan copy, yaitu :

• Voting

transaksi harus menulis mayoritas copy untuk memodifikasi sebuah obyek, harus membaca cukup copy untuk meyakinkan bahwa terlihat setidaknya satu dari copy saat itu. Misalnya terdapat 10 copy, 7 penulisan untuk perubahan dan 4 copy untuk pembacaan. Setiap copy mempunyai nomor versi. Teknik ini biasanya tidak atraktif karena pembacaan adalah hal yang biasa.

• Read-any Write-all

penulisan lebih lambah dan pembacaan lebih cepat daripada teknik Voting. Teknik ini banyak digunakan pada synchronous replication

Pemilihan teknik synchronous replication akan menentukan tempat mana yang terkunci untuk seting.

Data Warehousing : Sebuah contoh Replication

Trend yang berkembang saat ini adalah membangun “warehouses” data yang sangat besar dari beberapa tempat. Hal ini memungkinkan untuk query pendukung keputusan yang kompleks dari data pada keseluruhan organisasi. Warehouse dapat dipandang sebagai instance dari asynchronous replication. Data sumber biasanya dikontrol dengan DBMS yang berbagi, penekanannya pada cleaning data dan menghapus kesalahan pada pembuatan replikasi. Prosedur Capture dan aplikasi Apply baik untuk lingkungan ini.

LOCKING PADA SISTEM TERDISTRIBUSI

Untuk menangani penguncian obyek pada beberapa tempat digunakan cara :

• Sentralisasi :

satu tempat melakukan semua penguncian dan membuka kunci untuk semua obyek

• Primary Copy :

semua penguncian untuk suatu obyek dikerjakan pada tempat primary copy dari obyek tersebut. Untuk pembacaan membutuhkan akses ke tempat terkunci sebaik tempat dimana obyek disimpan.

• Terdistribusi penuh :

penguncian untuk suatu copy dilakukan pada tempat dimana copy disimpan. Hal in akan mengunci semua tempat pada saat menulis obyek.

Distribusi Recovery

Proses pemulihan pada DBMS terdistribusi lebih kompleks daripada pada DBMS tersentralisasi karena sebab berikut :

• Terjadi kegagalan yang baru, misalnya saluran komunikasi dan remote site.
• Jika sub transaksi dari suatu transaksi mengeksekusi tempat yang berbeda, semua atau tidak ada yang harus commit. Hal ini memerlukan commit protocol untuk menangani hal tersebut.

Suatu log ditangani pada setiap tempat, sebagaimana pada DBMS tersentralisasi dan aksi commit protocol ditambahkan pada log.

Ringkasan

• Pada basis data terdistribusi, data disimpat pada beberapa lokasi dengan tujuan untuk membuat distribusi yang transparan. Pada basis data terdistribusi, distributed data independence (pemakai tidak perlu mengetahui lokasi data ) dan distributed transaction atomicity (dimana tidak ada perbedaan antara transaksi terdistribusi dan transaksi local). Jika semua lokasi menjalankan perangkat lunak DBMS yang sama, system disebut homogen, selain itu disebut heterogen.
• Arsitektur sistem basis data terdistribusi terdapat tiga tipe. Pada system Client-Server, server menyediakan fungsi DBMS dan client menyediakan antar muka pemakai. Pada Collaboration system system, tidak terdapat perbedaan antara proses client dan server.
• Pada DBMS terdistribusi, suatu relasi difragmentasi dan direplikasi pada beberapa tempat. Dalam fragmentasi horizontal, setiap partisi terdiri dari himpunan baris dari relasi asal. Dalam fragmentasi vertika, setiap partisi terdiri dari himpunan kolom pada relasi asal. Pada replikasi, disimpan beberapa copy dari relasi atau suatu partisi pada beberapa tempat.
• Jika suatu relasi difragmen dan direplika, setiap partisi memerlukan nama global yang unik yang disebut relation name. Manajemen catalog terdistribusi diperlukan untuk menyimpan rekaman dimana data disimpan.
• Jika suatu transaksi melibatkan aktivitas pada tempat yang berbeda, maka memanggil aktivitas sub transaksi.
• Pada DBMS terdistribusi, manajemen lock berupa lokasi sentral, primary copy atau terdistribusi penuh. Deteksi deadlock pada system terdistribusi dibutuhkan.
• Pada pemrosesan query dalam DBMS terdistribusi, lokasi partisi dari relasi perlundihitung. Join dua relasi dapat dilakukan dengan mengirim satu relasi ke tempat lain dan membentuk local join. Jika join melibatkan kondisi seleksi, jumlah tupel yang diperlukan kemungkinan kecil. Semijoin dan Bloomjoin mengurangi jumlah tupel yang dikirim ke jaringan dengan mengirim informasi terlebih dahulu yang mengijinkan mem-filter tupel yang tidak relevan. Optimasi query pada system terdistribusi harus mempertimbangkan komunikasi dengan model biaya.
• Pada synchronous replication, semua copy dari relasi replica diubah sebelum transaksi commit. Pada asynchronous replication, copy hanya diubah secara periodic. Terdapat dua teknik untuk menjamin synchronous replication. Secara voting, perubahan harus menulis mayoritas copy dan membaca harus mengakses cukup copy untuk menjamin bahwa satu copy sudah tersedia. Pada replikasi peerto-

peer, lebih dari satu copy dapat diubah dan strategi conflict resolution dapat mengubah konflik yang terjadi. Pada replikasi primary site, terdapat satu primary copy yang dapat diubah, copy sekunder lain tidak dapat diubah. Pengubahan pada primary copy dipropaganda menggunakan capter dan kemudian apply ke tempat lain.

• Pemulihan pada DBMS terdistribusi dilakukan menggunakan commit protocol yang mengkoordinasi aktivitas pada tempat yang berbeda yang dilibatkan pada transaksi. Pada Two-Phase Commit, setiap transaksi didesain oleh tempat coordinator. Sub transaksi dieksekusi pada tempat sub ordinat. Protokol menjamin bahwa perubahan dibuat oleh beberapa transaksi dapat dipulihkan. Jika tempat coordinator bertabrakan, sub ordinat di blok, dan sub ordinat harus menunggu coordinator pulih.