Basis Data Terdistribusi

Basis Data Terdistribusi adalah sekumpulan database atau data logic yang saling berhubungan secara fisik terdistribusi dalam jaringan komputer, yang tidak tergantung dari program aplikasi sekarang maupun masa yang akan datang.


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.

Untuk trend basis data terdistribusi saat ini, pemakai harus mengetahui dimana data ditempatkan, juga harus mengetahui dimana system yang tidak mendukung independensi data terdistribusi dan transaksi terdistribusi atomic. 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

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.

•          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 seperti pada Gambar 7-2. 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. Pada saat menulis aplikasi client-server, perlu diingat batasan antara client dan server dan untuk menjaga komunikasi antara keduanya yang berorientasi himpunan. Khususnya membuka kursor dan mengambil tupel pada satu waktu membangkitkan beberapa pesan dan dapat diabaikan.

•          Collaboration Server

Arsitektur client-server tidak mengijinkan satu query mengakses banyak server karena proses client harus dapat membagi sebuah quer 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 diguankan 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 seperti pada Gambar 7-3.. 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.

Pada DBMS terdistribusi, relasi disimpan pada beberapa tempat. Pengaksesan relasi yang disimpan pada remote side mengakibatkan biaya melewatkan pesan dan untuk menguranginya, sebuah relasi dipartisi atau difragmentasi ke beberapa tempat, dengan fragmen dikirim pada tempat dimana fragmen tersebut sering diakses, atau replika pada pada setiap tempat dimana relasi menjadi kebutuhan yang tinggi

Fragmentasi Fragmentasi terdiri dari relasi yang dibagi ke relasi atau fragmen yang lebih kecil dan mengirim fragmen, pada beberapa tempat. Terdapat dua macam fragmentasi, fragmentasi horizontal dan fragmentasi vertikal. Pada fragmentasi horisontal, setiap fragmen terdiri dari sebuah subset baris dari relasi asal. Pada fragmentasi vertikal, setiap fragment terdiri dari sebuah subset kolom dari relasi asal. Fragmentasi horisontal dan vertikal diilustrasikan pada Gambar 7-4.

Bila sebuah relasi difragmentasi, harus meliputi relasi asal dari fragmen :

·         Fragmentasi horisontal : union dari fragmen horisontal harus sama dengan relasi asal. Fragmen biasaNya dibutuhkan disjoint.

·         Fragmentasi vertikal : koleksi fragmen vertikal seharusnya dekomposisi

lossless-join. Untuk menjamin fragmentasi vertikal lossless-join, sistem harus menyediakan id tupel yang unik untuk setiap tupel dalam relasi asli. Jika kita berpilir bahwa relasi asal sebagai field yang berisi tambahan tupel-id sebagai kunci, field ini ditambahkan ke setiap fragmen vertikal. Sehingga dekomposisi dijamin lossless-join.

Replikasi Replikasi berarti bahwa kita menyimpan beberapa copy sebuah relasi atau fragmen relasi. Keseluruan relasi dapat direplikasi pada satu atau lebih tempat. Sebagai 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.

MANAJEMEN 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 otonomo lokal digunakan format sebagai berikut:

>

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

MENGUBAH DATA TERDISTRIBUSI

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

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

·         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.

1.      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.

Biaya pada synchronous replication adalah sebagai berikut : sebelum transaksi yang diubah commit, harus dilihat penguncian pada semua copy yang dimodifikasi. Kirimkan perintah lock ke remote site, dan sementara menunggu respon, pegang kunci yang lain. Jika tempat atau saluran gagal, transaksi tidak dapat commit sampai transaksi kembali. Meskipun tidak terjadi kegagalan, commit harus mengikuti commit protocol dengan beberapa pesan yang mahal. Karena itu alternative teknik asynchronous replication banyak digunakan.

1.                  Asynchronous Replication

Asynchronous replication mengijinkan memodifikasi transaksi commit sebelum semua copy diubah (dan pembaca tidak hanya melihat satu copy). Pemakai harus waspada copy yang keluar dari sinkronisasi untuk suatu periode waktu yang pendek.

Teknik asynchronous replication menggunakan dua pendekatan, yaitu Primary Site dan Peer to Peer replication. Perbedaan kedua teknik ini terletak pada berapa banyak copy yang dapat diubah atau copy master.

Peer to Peer replication. Lebih dari satu copy dari suatu obyek dapat menjadi sebuah master. Perubahan ke copy master harus dipropaganda ke copy lain dengan cara yang berlainan. Jika dua copy master diubah dan terjadi suatu konflik, konflik harus dipecahkan (misalnya Tempat 1 : umur Joe mengubah 35, Tempat 2 : mengubah 36. Teknik ini bagus digunakan jika konflik tidak terjadi, misalnya setiap tempat master memiliki fragmen disjoin dan yang memiliki hak pengubahan dimiliki oleh satu master pada satu waktu.

Primary Site replidation. Tepat satu copy dari suatu relasi digunakan sebagai primary copy atau master copy. Replika pada tempat lain tidak langsung diubah. Primary copy dipublikasikan. Tempat lain menjalankan (fragmen) ke relasi ini, terdapat beberapa copy sekunder. Isu utama adalah bagaimana pengubahan primary copy dapat dipropaganda ke copy sekunder ? Hal in idapat dilakukan dalam dua langkah. Langkah pertama ambil pengubahan yang dibuat dengan transaksi commit, kemudian aplikasikan perubahan tersebut. Exactly one copy of a relation is designated the primary or master copy. Replicas at other sites cannot be directly updated.

Implementasi Primary Site pada Asynchronous Replication

Isu utama dalam mengimplementasikan primary site replication adalah menentukan barapa banyak perubahan ke primary copy dipropaganda ke copy sekunder. Perubahan biasanya dipropaganda dalam dua langkah yaitu Capture dan Apply. Perubahan dibuat dengan transaksi commit ke primary copy yang diidentifikasi selama langkah Capture dan dipropaganda ke copy sekunder selama langkah Apply.

·         Mengimplementasikan Langkah Capture

Langkah Capture diimplementasikan dengan satu dari dua pendekatan, yaitu Log-Based Capture dan Procedureal Capture.

•          Log-Based Capture : log (menyimpan recovery) digunakan untuk membangkitkan Change Data Table (CDT). Jika hal ini dikerjakan ketika log terakhir ditulis ke disk, harus menghapus perubaan ke subsequent yang dihentikan transaksi.

•          Procedural Capture: suatu prosedur yang secara otomatis dibangkitkan (trigger)

mengerjakan capture. Implementasi capture dengan Log-Based Capture lebih baik karena lebih murah dan lebih cepat tetapi harus memahami detail dari property log.

·         Mengimplementasikan Langkah Apply

Proses Apply pada tempat sekunder secara periodic mengakibatkan perubahan ke table CDT dari primary site, dan mengubah copy. Periode didefinisikan oleh timer atau pemakai/aplikasi. Replika dapat dipandang lebih dari relasi yang dimodifikasi. Jika hal ini terjadi, replica terdiri dari pengubahan pandangan material yang naik sebagai perubahan relasi.

Log-Based Capter ditambah Apply yang terus-menerus akan meminimalkan delay pada propaganda perubahan. Procedureal Capture ditambah application-driven Apply merupakan cara yang fleksibel untuk perubahan proses.

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 berbadi, penekanannya pada cleaning data dan menghapus kesalahan pada pembuatan replikasi. Prosedur Capture dan aplikasi Apply baik untuk lingkungan ini.

link pak jati http://jati.staff.unisbank.ac.id/