Database Terdistribusi Disusun Oleh: Dr. Lily Wulandari

Distributed Database System Sebuah sistem basis data terdistribusi terdiri dari database bebas yang digabungkan Muncul di pengguna sebagai sistem tunggal Sistem database yang berjalan independen satu sama lain Pengolahan mungkin dilakukan di lokasi lain selain pencetus permintaan Transaksi dapat mengakses data pada satu atau lebih situs

Sistem Database Terdistribusi Homogen Semua pihak/lokasi memiliki perangkat lunak yang identik Mereka mengenali satu sama lain dan setuju untuk bekerja sama dalam mengolah permintaan pengguna Setiap situs menyerahkan bagian dari otonomi dalam hal hak untuk mengubah skema atau perangkat lunak pengguna sebagai sistem tunggal

Sebuah Contoh Sistem Database Terdistribusi Homogen Sebuah sistem terdistribusi menghubungkan tiga database : headquarters, manufacturing, dan sales Sebuah aplikasi secara bersamaan dapat mengakses atau memodifikasi data dalam beberapa database dalam lingkungan terdistribusi tunggal.

Apa yang dapat dilakukan? Sebuah query tunggal dari klien Manufaktur pada database manufacturing lokal dapat mengambil data yang merupakan gabungan dari tabel produk di database lokal dan tabel dept pada database headquarter secara jarak jauh. Untuk aplikasi client, lokasi dan platform database jelas

Memudahkan!! Misalnya, jika Anda terhubung ke database manufacturing tetapi ingin mengakses data pada database headquarters, menciptakan sinonim pada manufacturing untuk tabel dept secara jarak jauh memungkinkan untuk melakukan query ini: SELECT * FROM dept Dengan cara ini, sistem terdistribusi memberikan tampilan akses data asli. Pengguna di manufacturing tidak perlu tahu bahwa data yang mereka akses berada pada remote database.

Sistem Database Terdistribusi Heterogen Dalam sistem database terdistribusi heterogen, setidaknya salah satu database menggunakan skema dan perangkat lunak yang berbeda. Sebuah sistem database yang memiliki skema yang berbeda dapat menyebabkan masalah besar bagi pemrosesan query. Sebuah sistem database yang memiliki perangkat lunak yang berbeda dapat menyebabkan masalah besar bagi proses transaksi. Setiap pihak mungkin tidak mengenal satu sama lain dan mungkin hanya memberikan Fasilitas terbatas untuk kerjasama dalam proses transaksi

Arsitektur Database Terdistribusi Dua arsitektur alternatif DBMS terdistribusi adalah : Client/Server 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. 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 (sebagai contoh).

Client-Server Sistem Client Server

Client-Server Arsitektur ini menjadi sangat popular untuk beberapa alasan. Pertama, implementasi yang relatif sederhana karena pembagian fungsi yang baik dan karena 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 pemakaian lebih mudah dibandingkan antar muka pada server yang tidak user-friendly.

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

Collaboration 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. Collaboration System

Keuntungan Sistem Database terdistribusi Pengelolaan secara transparan data yang terdistribusi Mengacu pada struktur organisasi Meningkatkan untuk berbagi dan otonomi lokal Meningkatkan ketersediaan data Meningkatkan kehandalan Meningkatkan performasi kerja Memudahkan pengembangan sistem

Kerugian Sistem Database Terdistribusi Kompleksitas manajemen Kontrol integritas lebih sulit Biaya pengembangan Keamanan Sulitnya standarisasi Menambah kebutuhan penyimpanan Lebih sulit dalam mengatur lingkungan data

Penyimpanan Data Terdistribusi Replication Sistem memelihara beberapa salinan data, yang disimpan di lokasi yang berbeda, untuk temu kembali informasi lebih cepat dan toleransi terhadap kesalahan . Fragmentation Hubungan dipartisi menjadi beberapa fragmen disimpan di lokasi yang berbeda Replication dan fragmentation dapat dikombinasikan Hubungan dipartisi menjadi beberapa fragmen: Sistem memelihara beberapa replika yang identik dari setiap fragmen tersebut.

Keuntungan Replication Ketersediaan: kegagalan database pada lokasi yang berisi relasi r tidak mengakibatkan tidak tersedianya r ini karena ada replika. Paralelisme: query pada r dapat diproses oleh beberapa node secara paralel. Transfer data berkurang: relasi r tersedia secara lokal di tiap lokasi yang berisi replika r.

Kerugian Replication Peningkatan biaya update: setiap replika dari relasi r harus diperbarui. Meningkatnya kompleksitas kontrol konkurensi: update bersamaan ke replika yang berbeda dapat menyebabkan data yang tidak konsisten kecuali mekanisme kontrol konkurensi khusus dilaksanakan. Salah satu solusi: memilih satu salinan sebagai copy primer dan menerapkan operasi kontrol konkurensi pada salinan primer tsb

Fragmentation Data dapat didistribusikan dengan menyimpan tabel individu di lokasi yang berbeda Data juga dapat didistribusikan dengan membagi sebuah tabel dan menyimpan bagian-bagian tsb di lokasi yang berbeda - disebut Fragmentasi Fragmentasi dapat horizontal atau vertikal

Mengapa menggunakan Fragmentation? Penggunaan - dalam aplikasi umum menggunakan view sehingga tepat untuk bekerja dengan subset/himpunan Efisiensi - data disimpan dekat dengan tempat yang paling sering digunakan Paralelisme - transaksi dapat dibagi menjadi beberapa sub-query untuk meningkatkan tingkat konkurensi Keamanan - data lebih aman - hanya disimpan ketika dibutuhkan Disadvantages: Kinerja - mungkin lebih lambat Integritas - lebih sulit

Horizontal Fragmentation Setiap fragmen, Ti, dari table T berisi subset dari baris Setiap tuple dari T diberikan untuk satu atau lebih fragmen. Fragmentasi horizontal adalah lossless

Contoh Horizontal Fragmentation account1 = branch_name=“Hillside” (account) Sebuah skema rekening bank memiliki suatu relasi Account-schema = (branch-name, account-number, balance). Ia dilakukan fragmen hubungan dengan location dan store setiap fragmen secara lokal: record dengan branch-name = `Hillside` disimpan di Hillside di sebuah fragmen

Contoh Horizontal Fragmentation account2 = branch_name=“Valleyview” (account) account_number branch_name balance A-177 A-402 A-408 A-639 Valleyview 205 10000 1123 750

Vertical Fragmentation Setiap fragmen, Ti, dari T berisi subset/himpunan bagian dari kolom, setiap kolom setidaknya dalam satu fragmen, dan setiap fragmen termasuk kunci: Ti = attr_listi (T) T = T1 T2 ….. Tn Semua skema harus berisi calon kunci umum (dan superkey) untuk memastikan penggabungan property yang lossless. Sebuah atribut khusus, atribut tuple-id dapat ditambahkan ke setiap skema untuk melayani sebagai kunci kandidat.

Vertical Fragmentation of employee_info Relation branch_name customer_name tuple_id Hillside Valleyview Lowman Camp Kahn Green 1 2 3 4 5 6 7 deposit1 = branch_name, customer_name, tuple_id (employee_info )

Vertical Fragmentation of employee_info Relation account_number balance tuple_id A-305 A-226 A-177 A-402 A-155 A-408 A-639 500 336 205 10000 62 1123 750 1 2 3 4 5 6 7 deposit2 = account_number, balance, tuple_id (employee_info )

Data Transparency Transparansi Data: Tingkat dimana pengguna sistem tidak menyadari rincian tentang bagaimana dan di mana item data disimpan dalam sistem terdistribusi Pertimbangkan isu-isu transparansi dalam kaitannya dengan: Fragmentation transparency Replication transparency Location transparency

Data Transparency Penamaan item-item data : Kriteria Setiap item data harus memiliki nama yang unik Harus dimungkinkan untuk menemukan lokasi item data secara efisien. Harus dimungkinkan untuk mengubah lokasi dari item data secara transparan. Setiap pihak harus dapat membuat item data baru secara mandiri.

Commit Protocols Protokol commit digunakan untuk memastikan atomicity di berbagai lokasi Atomicity menyatakan bahwa modifikasi database harus mengikuti aturan "semua atau tidak". Suatu transaksi yang mengeksekusi beberapa lokasi harus di-commit di semua lokasi, atau dibatalkan di semua lokasi.

Two-Phase Commit (2 PC) Protocol Apakah itu? Two-phase commit adalah sebuah protokol transaksi dirancang untuk komplikasi yang timbul dengan manajer sumber daya terdistribusi. Teknologi Two-phase commit digunakan untuk sistem reservasi hotel dan penerbangan, transaksi stock market, aplikasi perbankan, dan credit card. Dengan protokol two-phase commit, manajer transaksi terdistribusi mempekerjakan koordinator untuk mengelola sumber daya individu. Hasil proses commit sebagai berikut:

Phase1: Obtaining a Decision Langkah 1  Coordinator meminta semua participants untuk mempersiapkan commit transaksi Ti. Ci menambahkan records <prepare T> ke log dan memaksa log to stable storage (log adalah file yang mengelola sebuah record dari seluruh perubahan terhadap database) Kirim pesan prepare T ke semua lokasi dimana T dieksekusi

Phase1: Making a Decision Langkah 2  Setelah menerima pesan, manajer transaksi di lokasi menentukan apakah bisa melakukan transaksi jika tidak: tambahkan sebuah record <no T> ke log dan kirim pesan abort T ke Ci Jika transaksi dapat di-commit, maka : 1). Tambahkan record <ready T> ke log 2). Memaksa semua record T untuk disimpan permanen 3). Kirim pesan ready T ke Ci

Phase 2: Recording the Decision Langah 1  T dapat di-commit dari Ci yang menerima pesan ready T dari semua lokasi yang berpartisipasi: jika tidak T harus dibatalkan Langkah 2  Coordinator menambahkan sebuah keputusan record, <commit T> atau <abort T>, ke log dan memaksa record ke penyimpanan permanen. Setelah record ini dalam penyimpanan permanen, tidak dapat dibatalkan (bahkan jika kegagalan terjadi) Langkah 3  Coordinator mengirim sebuah pesan ke masing-masing participant menginformasikan pesan keputusan tsb (commit atau abort). Langkah 4  Participants mengambil tindakan yang tepat secara lokal.

Two-Phase Commit Diagram

Query Terdistribusi Dalam sistem terpusat, kriteria utama untuk mengetahui cost dari sebuah strategi query adalah jumlah/waktu akses ke disk. Faktor-fakor yang perlu dipertimbangkan: 1. Biaya/waktu untuk transmisi data 2. Potensi peningkatan karena adanya sejumlah simpul yang dapat melaksanakan query secara paralel.

Transformasi Query Jika tabel telah direplikasi atau difragmentasi atau sekaligus direplikasi dan fragmentasi maka kita dapat memenuhi query tersebut dengan memilih salah satu simpul tempat suatu tabel berada kemudian mengeksekusi query. Jika tabel tidak direplikasi atau difragmentasi, pemilihan simpul akan didasarkan pada simpul yang memberikan ongkos transmisi data yang paling rendah.

Transformasi Query Jika tabel difragmentasi dan ditempatkan di berbagai simpul yang berbeda, maka kita harus melakukan operasi Join atau Union untuk merekonstruksi isi seluruh ini disamping tergantung pada query, juga tergantung pada jenis fragmentasi yang diterapkan terhadap tabel yang terlibat dalam query.

Transformasi Query Jika fragmentasi yang dilakukan horizontal maka operasi Union dapat dilakukan. Jika fragmentasi vertikal tdan query menghendaki penayangan semua atribut maka operasi Natural Join yang harus digunakan.

Contoh : Tabel Mahasiswa Ekspresi Standar dari query : kota = ‘Bandung (mahasiswa) Jika tabel mahasiswa difragmentasi secara horizontal di dua fragmen (diberi nama mahasiswa1 dan mahasiswa2) sehingga tabel mahasiswa sesungguhnya merupakan hasil operasi Union dari keduanya. mahasiswa1  mahasiswa2

Contoh : Maka query di atas dapat kita translasi menjadi : kota=‘Bandung’ (mahasiswa1  mahasiswa2)

Contoh 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

Contoh Query Terdistribusi 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.

Contoh Query Terdistribusi 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.

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.

TUGAS Jelaskan secara singkat apa yang dimaksud dengan jaringan komputer. Bagaimana konsep database terdistribusi Apa pengertian dari : a. Distributed Database b. Database Management System Terdistribusi Berikan contoh penerapan database terdistribusi di lingkungan sekitar anda Jelaskan keuntungan dan kerugian dalam menggunakan DBMS.