search

banditelol / SistemIntelijenS2ITB

Repository ini berisi mata kuliah yang saya ambil selama menjalani S2 IF ITB dengan opsi subjurusan Sistem Intelijen
3 stars 1 forks source link

IF5030 Management Informasi #2

Open banditelol opened 4 years ago

banditelol commented 4 years ago

Management Informasi

banditelol commented 4 years ago

20 Nov - Recovery System

Recovery System Target idealnya adalah tidak pernah tidak bisa diakses. Namun minimal setiap saat databasenya bs di akses, data tersebut harus benar.Memperbaiki databse, mengembalikan isi databse itu benar.

Apa yang diconsider rusak? transaksi jalan, transaksi belum selesai, listrik mati. Maka trx tersebut diconsider merusak DB. Walaupun transaksi tsb Read.

Recovery Algorithms

Have two parts:

Suplement DVD menggunakan prinsip cermin. Cara membacanya disinari, dan bila terpantul merepresentasikan bit nilai Cara menulisnya dengan mem-burn permukaannya untuk mengubah kondisi dari titik tersebut.

Saran Pahamilah segala sesuatu yang terkait dengan kekomputeran (tapi untuk apa?)

Mekanisme Persiapan untuk Recovery

TLDR: Cara backup

Recovery paling sederhana adalah dengan membuat duplikat dari Database secara periodik. Jadi bila rusak bisa recover dari backup yang telah dibuat.

Namun untuk hal seperti ini, periode untuk penyimpanannya perlu ditentukan dengan baik sesuai domain permasalahan. Misal untuk bank dengan transaksi tinggi akan tidak make-sense untuk melakukan backup per tahun.

Untuk itu, dilakukan step, yaitu: backup periodik, dan logging transaction semenjak backup terakhir.

image

Log Transaction

Sehingga saat recovery dilakukan juga terdiri dari 2 tahap. Pertama melakukan recovery dari backup yang dibuat, lalu melakukan semua transaksi yang tercatat telah dilakukan semenjak backup terakhir.

Shadow Database

Bila ada eksekusi write, itu akan hanya diterapkan pada shadow database. Sehingga yang rusak hanya akan shadownya saja. Bila transaksi selesai, database yang asli akan di update berdasarkan isi shadow

Question Gimana caranya mastiin waktu mindah ke database g rusak dan kalau rusak di apain? Harusnya sih kalau make dua step gini jadi aman kalau rusak karena rea di satu dan write di lain. Sehingga pun rusak hanya tabel tujaun yang rusak sehingga bsia langsung mengulangi

Log Changed Data

image

jadi hanya melakukan pencatatan perubahan data, sehingga bila recovery transaksi tak perlu mengulang eksekusi, sehingga hanya perlu mengganti datanya saja sesuai log yang dicatat

Question Kalau kayak gini kan changesnya chained gitu, bisa diresolve jadi satu perubahan aja ga sih? Sama berarti perlu checking integrity changesnya ya biar ga berubah dari 10 -> 20 terus log selanjtunya 24 - > 50

Immediate Database Modification

image gimana kalau ada transaksi yang dieksekusi dan rusak, maupun transaksi tersebut merusak. Sehingga concernnya bergeser ke recovery dari kerusakan yang terjadi saat transaksi dilakukan

deferred-modification : melakukan update ke disk/buffer hanya saat transaction commit periode tidak stabil : waktu dimana database bisa saja rusak karena transaksi sedang berjalan.

Mekanisme untuk Melakukan Recovery

banditelol commented 4 years ago

26 Nov - Database Architecture

Materi ada 3 bab (21-23) tentang distributed system untuk

Bagaimana data terdistribusi

Jadi ada 1 database tapi datanya terdistribusi di beberapa site. Studi kasus perbankan, kalau kita nasabah bandung apakah datanya ada di Bandung? bagaimana kalau user transaksi dari luar Bandung? salah satu caranya adalah dengan mengadakan data di area user sering melakukan transaksi, dan juga di tempat yang user mungkin akan sering melakukan transaksi. Salah satu konsep yang akan membantu proses ini adalah fragmentasi, replikasi dan duplikasi. Fragmentasi Vertikal : Pemecahan berdasarkan kolom Fragmentasi Horizontal: Pemecahan berdasarkan baris atau kombinasi keduanya, dimana akan ada duplikasi atau replikasi. Dalam kasus perbankan:

Bagaimana kalau ada transaksi update?

Untuk constraint integritas, maka bila ada 10 lokasi semuanya perlu di update. Dan untuk menjaga konsistensi, maka semua data id lokasi tersebut harus ter-update dalam periode tertentu. Periode ini sangat tergantung dari use case, bisa dalam orde detik maupun hingga menit, tergantung lokasi dan banyaknya replikasi database.

Extreme Case 1 : hanya ada 1 db di local tertentu, untuk semua query yang dieksekusi secara remote waktu eksekusi akan terhambat oleh overhead waktu komunikasi. Sedangkan saat local akan sangat cepat

Extreme Case 2 : DB di replikasi di semua lokasi, query read akan sangat cepat dimanapun karena "local" dimanapun. Tapi bila ada query update/ write maka akan kompleks karena setiap lokasi perlu di update setiap ada update/ write.

Permasalahan yang muncul sering kali adalah tentang integrity - sinkronisasi. Dimana saat terjadi update perlu yakin query di tempat lain perlu terupdate. Selain itu perlu juga menjamin serializability dari update ini.

Question Gimana kalau ada operasi read di lokasi remote saat ada update? ini dimanage dengan global lock

Fenomena Lock dan Unlock bisa digunakan disini namun perlu di distribusi di lokasi yang terdapat duplikatnya. Untuk itu ada dua level manager lock, yaitu manager local yang ada di tiap lokasi dan manager global yang ada di atas manager local dan memastikan semua manager lock local untuk memeanage urutan query secara keseluruhan.

Question Practically dimana manager global ini disimpan secara fisik?

Bagaimana mengendalikan Serializability?

Seriazibality ini penting agar query snkron dengan query lain yang datang dari berbagai lokasi yang bisa juga datang secara "bersamaan". Ada beberapa skenario

Query Local, Data Remote Copy

Referensi absolute : Query

Setiap query pasti akan dieksekusi di local dimana query akan dieksekusi. i.e. query di lokasi tersebut di eksekusi di lokasi tersebut, walaupun datanya ada di lokasi lain. Sehingga data yang diperlukan oleh query perlu dikumpulkan di lokasi query tersebut. Karena data tersebut bisa jadi dikirim dari lokasi lain, maka data yang ada di lokasi source data tersebut, maka data tersebut perlu di lock hingga query yang di eksekusi di commit. Walaupun waktu eksekusi query sebentar, namun pengiriman data tetap memerlukan waktu yang lama.

Query Remote Divided, Data Local

Referensi absolute : Data

Data tidak dipindah, namun querynya dipecah jadi subquery dan disesuaikan agar bisa dieksekusi dimana data ditemukan. Pendekatan ini tak bisa murni subquery di eksekusi di lokasi data yang berada. Mis. Join yang menggabungkan dua relasi, asumsi tidak ada fragmentasi. Sehingga data tersebut perlu dipindah

Question Ada penyimpanan intermediate ga ya? Property apa yang menyebabkan query teh bisa di decompose jadi subquery dan dijalnain terpisah2

Selain ada manager lock lokal dan global, ada juga skema relasi lokal dan global. Dan walaupun pada akhirnya hasil akhirnya perlu digabungkan juga di lokasi awal query. Untuk lebih mudah memahami query processing, bayangkan bahwa query akan dipecah menjadi struktur pohon dari operator relasi dan di setiap level branch bisa dipecah menjadi subquery yang dilakukan pada suatu relasi tertentu

Gimana constraint serializability di sini terpenuhi? Salah satu metode yang diceritakan pak Ben adalah dengan menggunakan TSO untuk mengidentifikasikan waktu query dilakukan.

Pipelining in Distributed Database

Object elementer yang dieksekusi bukan lagi relasi, namun tuple.

Optimization in Distributed Database

Pembuatan struktur pohon dengan memanfaatkan parallel processing di tingkat lokal dan global.

Dua Tipe Sistem

Centralised

Kalau satu bermasalah, kantor tutup

Distributed

Kalau salah satu mesin mati, maka di kacamata user tak ada masalah, Tapi lebih kompleks untuk dimanage karena perlu sinkronisasi. Kompleksitasnya lebih tinggi dan lebih banyak potential point of failure. Banyak juga yang critical dan bs melanggar sinkronisasi.

Distributed DB ini telah berkembang sejak lama '70an, namun saat itu kominkasi sangat tidak andal (avilability dan band) sehingga sistem distributed db ini sangat menjanjikan. Sekarang dengan perkembangan tekonologi informasi, speednya lebih cepat dibandingkan tahun 70-80an apalagi bila muncul generasi lanjutan dari protocol komunikasi.

Quote Menurut Pak Benhard, kecuali untuk kebutuhan2 tertentu, trend database ini akan ke centralised karena kontrolnya lebih sederhana, dan availability bs ditanggung dengan duplikasi, namun ini hanya perkiraan.

banditelol commented 3 years ago

4 Dec - Distributed Database

Telat 1 jam urang masuknya

Kalau mau maksimal processor 64 bit dengan kemampuan clock 2 GHz, harusnya komunikasi datanya 64 *bit 2 GHz 128 Gbps. Sayangnya sekarang teh yang jadi bottleneck seringnya adalah tentang komunikasi interdevice)

apa yang dijelaskan oleh pak ben teh arsitektur secara global. Paling tidak ini bisa jadi background untuk membangun sistem basis data untuk sistem tertentu kan perlu mempertibangkan konfigurasi requirement dan komputernya seperti apa (berbicara dengan yang optimal)

Distributed Databases

Homogeneous

Heterogenous

Konsekuensi dari pertumbuhan yang sporadis Ngomongin ODBC untuk bisa jadi "translator" database yang lain oleh suatu dbms. Ini

Question Apa sih bagian dari database network yang kira2 perlu tau, untuk sekarang yang urang kebayang baru:

  • Client
  • DB Server
  • Data Server
  • Lock
  • Recovery
  • Query Planning

UAS

9 Desember lbur 10 Desember UAS