[Sidang] Pengembangan Prototipe Geographically-Aware Distributed NoSQL

Tugas Akhir II - S1 Teknik Informatika
Institut Teknologi Bandung

https://github.com/freedomofkeima/TippyDB

Transcript

1. Pengenalan TippyDB: Pengembangan Prototipe Geographically-Aware Distributed NoSQL Sidang IF4092 – Tugas Akhir II Iskandar Setiadi / 13511073 Pembimbing: Achmad Imam Kistijantoro, ST, M.Sc, Ph.D Institut Teknologi Bandung 4 Juni 2015 June 5, 2015 1
2. Iskandar Setiadi Referensi: http://www.couchbase.com/nosql-resources/what-is-no-sql Latar Belakang June 5, 2015 2
3. Iskandar Setiadi Referensi: http://was-sg.wascdn.net/wp-content/uploads/2014/01/Slide011.png Media Sosial June 5, 2015 3
4. 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 June 5, 2015 4
5. Iskandar Setiadi Sistem basis data NoSQL bertujuan untuk menyediakan layanan penyimpanan data yang sederhana (key-value, document) dan mampu mendukung scaling. NoSQL June 5, 2015 5 Referensi: http://www.couchbase.com/binaries/content/gallery/website/figures/why-nosql- 5.png
6. 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 June 5, 2015 6
7. 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 June 5, 2015 7
8. Iskandar Setiadi Operasi dasar basis data: write, update, read, dan delete Partisi dengan ukuran shard statik yang terdefinisi Replikasi dalam beberapa region dengan konfigurasi statik yang terdefinisi Pengembangan dilakukan dengan memanfaatkan levelDB (key-value library) dan Apache Thrift (RPC library) Fitur & Batasan June 5, 2015 8
9. Iskandar Setiadi Arsitektur Solusi June 5, 2015 9
10. Iskandar Setiadi ShardedKey: 0001 0001 00000001 4 byte pertama merepresentasikan region tempat data tersebut ditulis 4 byte selanjutnya merepresentasikan node tempat data tersebut ditulis 8 byte terakhir merepresentasikan kunci unik yang dimiliki oleh data tersebut Penyimpanan Berbasis Key-Value June 5, 2015 10
11. 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 June 5, 2015 11
12. Iskandar Setiadi Konsensus Raft June 5, 2015 12 Mekanisme pemilihan leader pada protokol Raft (Howard, 2014)
13. Iskandar Setiadi db.config June 5, 2015 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 } ] }
14. Iskandar Setiadi metadata.tmp June 5, 2015 14
15. Iskandar Setiadi Konsistensi Data June 5, 2015 15 Relasi antara teori CAP dengan basis data (Katsov, 2012)
16. Iskandar Setiadi Penulisan & Replikasi Data June 5, 2015 16 Primary / Master Secondary Secondary Region 1 Node 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
17. Iskandar Setiadi Proses Query Data June 5, 2015 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%
18. Iskandar Setiadi Partisi Data June 5, 2015 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}
19. 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 June 5, 2015 19
20. Iskandar Setiadi Proses Failover June 5, 2015 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
21. Iskandar Setiadi Proses Failover (II) June 5, 2015 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 ********
22. Iskandar Setiadi Proses Recovery June 5, 2015 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 ********
23. 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 June 5, 2015 23
24. Iskandar Setiadi Sistem operasi Amazon Linux 2015.03 (HVM) 64-bit Compiler g++ versi 4.7.2 (dengan dukungan C++11) Python versi 2.7 Boost library versi 1.54 Apache Thrift versi 0.9.2 LevelDB versi 1.15.0 MongoDB versi 3.0.1 & PyMongo versi 3.0 (untuk benchmark) Git versi 1.7.10.4 https://github.com/freedomofkeima/TippyDB Implementasi (II) June 5, 2015 24
25. 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 June 5, 2015 25
26. Iskandar Setiadi T-SS-001: Replikasi data T-SS-002: Partisi data T-SS-003: Pembaharuan data di secondary node T-SS-004: Penghapusan data di secondary node T-SS-005: Pembaharuan metadata dalam sistem T-SS-006: Pemilihan koordinator baru T-SS-007: Proses failover untuk kegagalan node T-SS-008: Proses recovery untuk node yang gagal Pengujian T-SS-XXX June 5, 2015 26
27. Iskandar Setiadi T-CS-001: Penulisan data T-CS-002: Pembaharuan data T-CS-003: Pembacaan data T-CS-004: Penghapusan data T-IS-001: Pembaharuan informasi ukuran basis data T-IS-002: Pembaharuan counter logical clock Pengujian T-CS-XXX & T-IS-XXX June 5, 2015 27
28. Iskandar Setiadi Pengujian: Konfigurasi MongoDB June 5, 2015 28
29. Iskandar Setiadi Pengujian: Performansi Dasar June 5, 2015 29 Ping RPC pada Apache Thrift: 466 mikrosekon / operasi Pengujian dilakukan 100.000 kali (masing-masing berukuran 100 bytes)
30. Iskandar Setiadi Pengujian: Request Pengguna June 5, 2015 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
31. Iskandar Setiadi Pengujian: Request Pengguna (II) June 5, 2015 31 RTT Singapore – N. Virginia = 253.5 ms Pada TippyDB, 80% data berada di dekat pengguna, sedangkan pada MongoDB, 66.7% data berada di dekat pengguna
32. Iskandar Setiadi Pengujian: Request Pengguna (III) June 5, 2015 32 TippyDB memerlukan 60 detik untuk proses failover, sedangkan MongoDB memerlukan 30 – 60 detik untuk proses failover
33. Iskandar Setiadi Pengujian: Komposisi write : read June 5, 2015 33 Pengujian dilakukan 10.000 kali (masing-masing berukuran 1.024 bytes)
34. Iskandar Setiadi Kesimpulan June 5, 2015 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.
35. Iskandar Setiadi Saran Pengembangan June 5, 2015 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