Date post: | 26-Jul-2015 |
Category: |
Internet |
Upload: | institut-teknologi-bandung |
View: | 72 times |
Download: | 1 times |
Pengenalan
TippyDB: Pengembangan Prototipe Geographically-Aware Distributed NoSQL
Sidang IF4092 – Tugas Akhir II
Iskandar Setiadi / 13511073Pembimbing: Achmad Imam Kistijantoro, ST, M.Sc,
Ph.D
Institut Teknologi Bandung4 Juni 2015
April 14, 2023 1
Iskandar Setiadi
Referensi: http://www.couchbase.com/nosql-resources/what-is-no-sql
Latar Belakang
April 14, 2023 2
Iskandar Setiadi
Referensi: http://was-sg.wascdn.net/wp-content/uploads/2014/01/Slide011.png
Media Sosial
April 14, 2023 3
Iskandar Setiadi
Penelitian yang dilakukan oleh Backstrom, Sun, dan Marlow (2010) menunjukkan bahwa lebih dari 70% teman seorang pengguna berada dalam jarak kurang dari 100 mil.
Relasi Pertemanan
April 14, 2023 4
Iskandar Setiadi
Sistem basis data NoSQL bertujuan untuk menyediakan layanan penyimpanan data yang sederhana (key-value, document) dan mampu mendukung scaling.
NoSQL
April 14, 2023 5
Referensi: http://www.couchbase.com/binaries/content/gallery/website/figures/why-nosql-5.png
Iskandar Setiadi
Teknik partisi dan replikasi yang digunakan dalam basis data NoSQL saat ini
Partisi dan replikasi yang memperhatikan faktor geografis (geographically-aware)
Partisi & Replikasi
April 14, 2023 6
Iskandar Setiadi
Prototipe basis data NoSQL yang dikembangkan di tugas akhir ini bertujuan untuk meminimalkan jarak data yang disimpan dalam server dengan pengguna.
Prototipe ini menggunakan asumsi probabilistik bahwa pengguna yang mengakses (read) data adalah pengguna yang terletak dekat dengan pengguna yang menulis data pertama kali.
Prototipe: TippyDB
April 14, 2023 7
Iskandar Setiadi
Operasi dasar basis data: write, update, read, dan deletePartisi dengan ukuran shard statik yang terdefinisiReplikasi dalam beberapa region dengan konfigurasi statik yang terdefinisiPengembangan dilakukan dengan memanfaatkan levelDB (key-value library) dan Apache Thrift (RPC library)
Fitur & Batasan
April 14, 2023 8
Iskandar Setiadi
ShardedKey:0001 0001 00000001
4 byte pertama merepresentasikan region tempat data tersebut ditulis4 byte selanjutnya merepresentasikan node tempat data tersebut ditulis8 byte terakhir merepresentasikan kunci unik yang dimiliki oleh data tersebut
Penyimpanan Berbasis Key-Value
April 14, 2023 10
Iskandar Setiadi
Replikasi data, terutama untuk menyamakan metadata antar node, memerlukan koordinasi antar node dalam sistem. Untuk simplifikasi, pemilihan koordinator dalam voting akan menggunakan random timer seperti yang digunakan dalam protokol konsensus berbasis Raft.
Koordinasi antar Node
April 14, 2023 11
Iskandar Setiadi
Konsensus Raft
April 14, 2023 12
Mekanisme pemilihan leader pada protokol Raft (Howard, 2014)
Iskandar Setiadi
db.config
April 14, 2023 13
{"id": "set1","numberRegions": 2,
"replicationFactors": 2, "shardSize": 32,
"distance": [[0, 1], [1, 0]],"members": [
{"region": 1,"node": 1,"ip": "127.0.0.1","port": 9090,"own": true
},{
"region": 2,"node": 1,"ip": "127.0.0.1","port": 9091,"own": false
}]
}
Iskandar Setiadi
Konsistensi Data
April 14, 2023 15
Relasi antara teori CAP dengan basis data (Katsov, 2012)
Iskandar Setiadi
Penulisan & Replikasi Data
April 14, 2023 16
Primary / Master
Secondary
Secondary
Region 1Node 1
Region 2 Node 1
Region 3 Node 1
Parameter replikasi = 3
putData
replicateData
replicateData
Value: {“n”:1}
ShardedKey:0001 0001 00000001
ts (timestamp):1
Master-Slave
Iskandar Setiadi
Proses Query Data
April 14, 2023 17
Region 1 Node 1
Region 1 Node 1 Region 2 Node 1
ShardedKey:0001 0001 00000001
ShardedKey:0002 0001 00000001
getData
getData getData
Value: {“n”: 1}
Value: {“n”: 1}
± 70 - 80%
± 20 - 30%
Iskandar Setiadi
Partisi Data
April 14, 2023 18
Region 1
Node 1
Node 2
Parameter shard = 32 MB
64 MB
0 MB
Proses partisi dilakukan internal dalam 1 region. putData
putDataForce
ShardedKey:0001 0002 00000001
ts (timestamp):1
Value: {“n”:1}
Iskandar Setiadi
Basis data NoSQL populer saat ini tidak mendukung failover secara otomatis untuk penyimpanan data yang menggunakan faktor geografis.
Permasalahan: Desain sistem yang tidak dapat mendukung proses failover secara otomatis.
Permasalahan Failover
April 14, 2023 19
Iskandar Setiadi
Proses Failover
April 14, 2023 20
Region 1 Node 1 Region 2 Node 1
Region 3 Node 1
Failure Detection
ShardedKey:0001 0001 ********Primary: Region 1 Node 1
Secondary: Region 2 Node 1
ShardedKey:0001 0001 ********Primary: Region 2 Node 1
Iskandar Setiadi
Proses Failover (II)
April 14, 2023 21
Region 2 Node 1
Region 3 Node 1
ShardedKey:0001 0001 ********Primary: Region 3 Node 1
Secondary: Region 2 Node 1
ShardedKey:0001 0001 ********Primary: Region 2 Node 1
resyncData
Pada prototipe ini, sinkronisasi dilakukan dengan melakukan resync terhadap semua data yang ada.Untuk pengembangan kedepannya, optimasi dapat dilakukan dengan membuat hinted handoff terhadap origin data (cth: Region 1 Node 1).
Region 1 Node 1
Block permintaan resyncData untuk ShardedKey:0001 0001 ********
Iskandar Setiadi
Proses Recovery
April 14, 2023 22
Region 2 Node 1
Region 3 Node 1
ShardedKey:0001 0001 ********Primary: Region 1 Node 1
Secondary: Region 2 Node 1
1 requestSyncData
Region 1 Node 1
ShardedKey:0001 0001 ********Primary: Region 3 Node 1
Secondary: Region 2 Node 1
Selama tahap recovery, server akan melakukan sinkronisasi metadata, kemudian melakukan sinkronisasi data (1 & 2) yang bersesuaian dengan region dan node dari server tersebut. Setelah tahap recovery selesai, server baru dapat melayani request pengguna.
2 updateMetadata
2 updateMetadata
Update dilakukan untuk ShardedKey:0001 0001 ********
Iskandar Setiadi
Pengembangan dilakukan dalam lingkungan Amazon Elastic Compute Cloud (EC2) yang telah dikonfigurasi pada dua instance t2.micro di dua access point berbeda, yaitu US East (N. Virginia): 1 replica dan Asia Pacific (Singapore): 2 replicas, dengan spesifikasi sebagai berikut:
- Processor Intel® Xeon E5-2670 CPU @ 2.50 GHz (1 vCPU)- Memory 1 GiB RAM
Implementasi
April 14, 2023 23
Iskandar Setiadi
Sistem operasi Amazon Linux 2015.03 (HVM) 64-bitCompiler g++ versi 4.7.2 (dengan dukungan C++11)Python versi 2.7Boost library versi 1.54Apache Thrift versi 0.9.2LevelDB versi 1.15.0MongoDB versi 3.0.1 & PyMongo versi 3.0 (untuk benchmark)Git versi 1.7.10.4
https://github.com/freedomofkeima/TippyDB
Implementasi (II)
April 14, 2023 24
Iskandar Setiadi
Secara garis besar, pengujian terhadap TippyDB akan dibagi dalam 3 bagian utama:
- Pengujian dilakukan untuk menjamin safety dan liveness dari komunikasi antar server (T-SS-XXX)- Pengujian dilakukan untuk menjamin kebenaran dari komunikasi antara client dengan server (T-CS-XXX)- Pengujian dilakukan untuk menjamin kebenaran internal dari server, mencakup komunikasi antara Apache Thrift dengan LevelDB (T-IS-XXX)
Pengujian: Correctness
April 14, 2023 25
Iskandar Setiadi
T-SS-001: Replikasi dataT-SS-002: Partisi dataT-SS-003: Pembaharuan data di secondary nodeT-SS-004: Penghapusan data di secondary nodeT-SS-005: Pembaharuan metadata dalam sistemT-SS-006: Pemilihan koordinator baruT-SS-007: Proses failover untuk kegagalan nodeT-SS-008: Proses recovery untuk node yang gagal
Pengujian T-SS-XXX
April 14, 2023 26
Iskandar Setiadi
T-CS-001: Penulisan dataT-CS-002: Pembaharuan dataT-CS-003: Pembacaan dataT-CS-004: Penghapusan data
T-IS-001: Pembaharuan informasi ukuran basis dataT-IS-002: Pembaharuan counter logical clock
Pengujian T-CS-XXX & T-IS-XXX
April 14, 2023 27
Iskandar Setiadi
Pengujian: Performansi Dasar
April 14, 2023 29
Ping RPC pada Apache Thrift: 466 mikrosekon / operasi
Pengujian dilakukan 100.000 kali (masing-masing berukuran 100 bytes)
Iskandar Setiadi
Pengujian: Request Pengguna
April 14, 2023 30
• Eksperimen dilakukan 4 kali, dengan spesifikasi masing-masing eksperimen sebagai berikut:
- 2.000 operasi (@ 100 KB), 3 replika- 200 operasi (@ 1.000 KB), 3 replika- 2.000 operasi (@ 100 KB), 2 replika: 1
replika di access point Singapore mengalami kegagalan
- 200 operasi (@ 1.000 KB), 2 replika: 1 replika di access point Singapore mengalami kegagalan
• 80% data ditulis di dekat lokasi pengguna
Iskandar Setiadi
Pengujian: Request Pengguna (II)
April 14, 2023 31
RTT Singapore – N. Virginia = 253.5 msPada TippyDB, 80% data berada di dekat pengguna, sedangkan pada MongoDB, 66.7% data berada di dekat pengguna
Iskandar Setiadi
Pengujian: Request Pengguna (III)
April 14, 2023 32
TippyDB memerlukan 60 detik untuk proses failover, sedangkan MongoDB memerlukan 30 – 60 detik untuk proses failover
Iskandar Setiadi
Pengujian: Komposisi write : read
April 14, 2023 33
Pengujian dilakukan 10.000 kali (masing-masing berukuran 1.024 bytes)
Iskandar Setiadi
Kesimpulan
April 14, 2023 34
TippyDB dapat mendukung penyimpanan data yang terpartisi maupun tereplikasi.
Basis data NoSQL yang membutuhkan cukup banyak operasi penulisan (write) dapat dikembangkan dengan memperhatikan aspek lokasi pengguna. Hal ini dapat mengurangi latensi RTT rata-rata dari pengguna 50 - 100 ms.
Iskandar Setiadi
Saran Pengembangan
April 14, 2023 35
1. Optimasi algoritma dan struktur data (Merkle Tree maupun B-tree)
2. Pengujian overhead maksimal disertai dengan pengembangan untuk metode balancing ke node kedua terdekat
3. Proses failover dengan scheduling terjadwal
4. Penambahan fitur seperti indexing, optimasi penyimpanan data, dan keamanan data