Perencanaan Infrastruktur Lanjutan

Konsep
Infrastructure Client
Server dalam
Database
PROGRAM Terdistribusi
PASCASARJANA (PPs)
Arsitektur Client/Server
 Menerapkan model komputasi jaringan:
 Sistem terdistribusi dengan client dan server yang terhubung
lewat jaringan
 Proses komputasi terbagi antara client dan server:
 Client workstation/PC “konsumen” layanan server
 Server PC/mini/mainframe) yang menyediakan layanan
 Untuk DBMS, servernya adalah server database

2
Evolusi Arsitektur Client/Server

 Arsitektur File Server Pemrosesan

ekstensif
 Logika aplikasi dan penyimpanan data di client oleh client
 Arsitektur Database Server
 Logika penyimpanan data di server
 Arsitektur 3-Tier
 Logika aplikasi dan penyimpanan data pada
server-server yang berbeda

Pemrosesan
minimal
oleh client

3
Arsitektur File Server

 Semua pemrosesan dilakukan di client (PC) yang

mengambil data dari server
 Sering disebut “Fat Client”
 File data secara keseluruhan dikirim dari server ke client
untuk pemrosesan.
 Problem:
 Volume transfer data melalui jaringan sangat tinggi.

4
 Arsitektur File Server
CLIENT GEMUK

5
Arsitektur File Server
 Problem:
 Volume transfer data melalui jaringan sangat tinggi.
 Setiap client harus memiliki kemampuan DBMS
penuh
 Kebutuhan sumber daya komputasi tinggi pada mesin client.
 Fungsi DBMS pada client-client harus dapat
mengkoordinasikan penguncian data, pengecekan integritas
data, dsb.

6
Arsitektur Database Server

Pendekatan 2-tiered
 Client bertanggung jawab atas
 Logika pemrosesan I/O (presentasi)
 Logika aturan/prosedur bisnis
 Server melakukan semua proses penyimpanan dan
akses data
 DBMS hanya ada di server
 Juga dapat menyimpan logika prosedural (stored
procedure)

7
 Arsitektur Server Database

Client lebih
ramping

Juga menyimpan
stored procedure

DBMS hanya di
server

8
Arsitektur Database Server

Keuntungan:
 Mesin client tidak harus berkemampuan besar
 Sangat mengurangi lalu lintas data melalui jaringan
 Integritas data mudah dijaga karena operasi data
dilakukan secara terpusat
 Sebagian aturan/prosedur bisnis dapat dijalankan di
server dengan stored procedures

9
Kelebihan Stored Procedure

Stored Procedure
 Berupa perintah SQL (routine) yang disimpan oleh DBMS
 Syntax: CREATE PROCEDURE …
 Dapat dibuat untuk membakukan prosedur, penambahan
dan pengubahan data
 Meningkatkan keamanan data
 Meningkatkan integritas data.
 Mengurangi lalu lintas data jaringan.
 Merampingkan/menyederhanakan client.

10
Arsitektur 3-Tier

Arsitektur Aplikasi Multi-tier:

 Logika Presentasi GUI
 Input: keyboard/mouse (Web Browser)
 Output: monitor/printer
 Logika Pengolahan
Prosedur,
 Pemrosesan Input/Output
Fungsi,
 Aturan/prosedur bisnis Program
 Manajemen Data (Web Server)
 Logika Penyimpanan Data
 Penyimpanan dan pengambilan data
Aktivitas
DBMS
(Database Server)

11
 Arsitektur 3-Tier

Client sangat
ramping

Prosedur bisnis pada

server terpisah

DBMS hanya pada

Server DB
12
Keuntungan Arsitektur 3-Tier
Keuntungan:
 Client Ramping
 PC hanya untuk user interface dan proses aplikasi minim, dengan
kapasitas penyimpanan data terbatas atau tidak ada samasekali
(misal, tanpa hard drive)
 Skalabilitas
 Biaya penambahan client baru minimal
 Server dapat diganti dengan yang lebih besar tanpa mengganti
client maupun server yang lain
 Meningkatkan tingkat layanan pengguna
 Karena terdistribusi, penanganan gangguan pada satu komponen
lebih mudah ditangani

13
Keuntungan Arsitektur 3-Tier
Keuntungan:
 Lebih mudah untuk diselaraskan dengan kebutuhan
bisnis
 Modifikasi/penyesuaian dapat dilakukan di salah satu
komponen tanpa mempengaruhi komponen-komponen lain
 Fleksibilitas teknologi
 Dapat memadukan terknologi dari berbagai vendor
 Memperkecil resiko kesalahan memilih teknologi
 Dapat mengganti salah satu komponen dengan teknologi baru
tanpa mempengaruhi komponen yang lain
 Efisiensi biaya dalam jangka panjang

14
Tantangan Arsitektur 3-Tier
Permasalahan:
 Biaya jangka pendek (awal) tinggi
 Biaya administrasi/pemeliharaan:
 Membutuhkan tambahan tools dan training
 Membutuhkan pengalaman teknis
 Standar-standar komponen yang tidak kompatibel
 Jika tidak menerapkan open standard
 Kesulitan mendapatkan aplikasi yang kompatibel
untuk end user
 Umumnya aplikasi desktop dirancang sebagai sistem stand
alone (fat client)

15
Sistem Database Terdistribusi
 Database Terdistribusi:
Suatu database logis yang secara fisik tersebar pada
beberapa komputer (di beberapa lokasi) yang
dihubungkan melalui jaringan komunikasi data.

16
Motivasi Database Terdistribusi
 Otonomi dan desentralisasi unit-unit usaha.
 Berbagi data antar aplikasi-aplikasi lokal.
 Menurunkan biaya komunikasi data, jika dibandingkan
database terpusat.
 Meningkatkan keandalan sistem terhadap gangguan.
 Aplikasi-aplikasi yang dimiliki dibuat oleh vendor-vendor
yang berbeda.
 Memungkinkan duplikasi/replikasi data di beberapa
tempat.

17
Sistem Homogen (vs Heterogen)

Homogen:
 Data terdistribusi pada server-server.
 DBMS yang sama di tiap server.
 Memungkinkan pengelolaan semua data oleh DBMS
terdistribusi (tidak ada data lokal eksklusif).
 Semua akses menggunakan skema global tunggal.
 Skema global adalah gabungan (union) dari skema-
skema lokal.

18
 Database Homogen
Source: adapted from Bell and Grimson, 1992.

DBMS-DBMS identik

19
Sistem Heterogen

 Data terdistribusi pada server-server.

 DBMS yang berbeda dapat digunakan pada tiap
server.
 Akses lokal dilakukan dengan menggunakan DBMS
dan skema lokal
 Akses non-lokal (remote) dilakukan dengan
menggunakan skema global

20
 Sistem Heterogen
Source: adapted from Bell and Grimson, 1992.

DBMS-DBMS berbeda

21
Kriteria Teknis
 Transparansi Lokasi
 Pengguna tidak harus tahu lokasi fisik data
 Permintaan data secara otomatis disalurkan ke server
yang sesuai.
 Otonomi Lokal
 Server lokal dapat tetap beroperasi dengan database
lokal jika hubungan jaringan terputus
 Setiap server mengontrol datanya sendiri, termasuk
masalah keamanan, pencatatan, backup & recovery.

22
Keuntungan Database Terdistribusi

 Meningkatkan keandalan dan ketersediaan (dari

gangguan).
 Desentralisasi pengelolaan data.
 Pertumbuhan secara modular (penambahan database
baru tanpa mengubah database-database lain).
 Menurunkan biaya komunikasi data.
 Response time yang lebih cepat untuk quary-query
tertentu (yang hanya melibatkan data lokal).

23
Kelemahan Database terdistribusi

 Harga dan kompleksitas perangkat lunak tinggi.

 Response time lambat untuk query-query yang melibatkan
database-database tersebar.
 Ancaman integritas data – jika ada duplikat data yang
diubah.

24
Terdistribusi atau Tidak?
 Ketersediaan dana, otonomi, keamanan.
 Pola akses data menurut lokasi.
 Rencana pertumbuhan dan ekspansi.
 Kemampuan/ketersediaan teknologi.
 Biaya pengelolaan teknologi yang kompleks.
 Kebutuhan akan layanan data yang handal.

25
 DBMS Terdistribusi
 Database terdistribusi membutuhkan DBMS terdistribusi
 Fungsi-fungsi DBMS Terdistribusi:
 Mencari lokasi data dengan suatu Kamus Data Terdistribusi
(distributed data dictionary).
 Menentukan lokasi untuk mengambil dan memproses bagian-
bagian query.
 Translasi antar DBMS yang berbeda-beda.

26
 DBMS Terdistribusi
… Fungsi-fungsi DBMS Terdistribusi:
 Menjaga konsistensi data akibat akses secara bersamaan.
 Menjaga keunikan primary key global.
 Meningkatkan skalabilitas.
 Keamanan, konkurensi, optimasi query, recovery dari
gangguan.

27
 Langkah-langkah Transaksi Lokal pada
Arsitektur DBMS terdistribusi

3 5

4
Transaksi lokal: semua data
tersimpan secara lokal

28
 Langkah-langkah Transaksi Global pada Arsitektur
DBMS terdistribusi

2
3
1
7 6
8
4

Transaksi global: sebagian data berada

5
di lokasi-lokasi remote

29
 Transparansi pada DBMS Terdistribusi
 Transparansi Lokasi
 Pengguna/aplikasi tidak harus tahu dimana lokasi fisik data
 Transparansi Replikasi
 Pengguna/aplikasi tidak harus tahu bahwa data direplikasi
 Transparansi Gangguan
 Bahwa semua aktivitas suatu transaksi terjadi, atau sama
sekali tidak terjadi (tidak setengah-setengah)

30
Transparansi pada DBMS Terdistribusi

… Transparansi Gangguan
 Setiap server memiliki komponen Manajemen Transaksi
 Mencatat transaksi dan rekaman (image) data sebelum dan
setelah transaksi.
 Prosedur pengendalian konkurensi (akses modifikasi
bersamaan) untuk menjaga integritas data.

31
Kapan kita menggunakan 3-tier?
 Saat ini 3-tier menjadi sangat populer dibanding 2-tier
arsitektur tapi 2-tier tidak akan bisa ditinggalkan.
 Masih terdapat banyak aplikasi yang ideal
menggunakan arsitektur 2-tier.
 Lalu bagaimana kita mengetahui model apa yang cocok
untuk aplikasi kita dan sesuai dengan karakteristik
perusahaan? Berikut ini adalah beberapa kriteria yang
bisa digunakan untuk menentukan kapan sebuah
aplikasi menggunakan model arsitektur 3-tier client/
server :
 Kapan kita menggunakan 3-tier?
 Banyaknya layanan atau class aplikasi lebih dari 50
 Program aplikasi di buat atau ditulis dalam
beberapa bahasa pemrograman yang berbeda
untuk masing-masing organisasi.
 Dua atau lebih data source yang heterogen seperti
dua DBMs yang berbeda atau DBMs dan file system
Suatu aplikasi akan digunakan
https://www.researchgate.net/
https://www.freetranslation.com/
https://phpmu.academia.edu/
Kapan kita menggunakan 3-tier?
 Suatu aplikasi akan digunakan lebih dari 3 tahun.
Apalgi jika kita akan merencanakan banyak modifikasi
atau penambahan Beban kerja yang sangat tinggi.
 Lebih dari 50000 transaksi perhari atau lebih dari 300
user yang mengakses ke sistem yang sama pada
database yang sama dalam waktubersamaan
 Ekspektasi bahwa aplikasi akan terus berkembang
sepanjang waktu