[Seminar II] Pengembangan Prototipe Geographically-Aware Distributed NoSQL

Tugas Akhir II - S1 Teknik Informatika
Institut Teknologi Bandung

https://github.com/freedomofkeima/TippyDB

Transcript

1. Pengenalan Pengembangan Prototipe Geographically-Aware Distributed NoSQL (TippyDB) Seminar IF4092 – Tugas Akhir II Iskandar Setiadi / 13511073 Pembimbing: Achmad Imam Kistijantoro, ST, M.Sc, Ph.D Institut Teknologi Bandung 22 April 2015 April 22, 2015 1
2. Iskandar Setiadi Referensi: http://www.couchbase.com/nosql-resources/what-is-no-sql Latar Belakang April 22, 2015 2
3. Iskandar Setiadi Referensi: http://was-sg.wascdn.net/wp-content/uploads/2014/01/Slide011.png Media Sosial April 22, 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 April 22, 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 April 22, 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 April 22, 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 April 22, 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 April 22, 2015 8
9. Iskandar Setiadi Arsitektur Solusi April 22, 2015 9
10. Iskandar Setiadi Konsistensi Data April 22, 2015 10 Relasi antara teori CAP dengan basis data (Katsov, 2012)
11. Iskandar Setiadi Penulisan & Replikasi Data April 22, 2015 11 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
12. Iskandar Setiadi metadata.tmp April 22, 2015 12
13. Iskandar Setiadi Proses Query Data April 22, 2015 13 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} ± 80% ± 20%
14. Iskandar Setiadi Partisi Data April 22, 2015 14 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}
15. Iskandar Setiadi db.config April 22, 2015 15 { "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 } ] }
16. Iskandar Setiadi Sinkronisasi Data April 22, 2015 16 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
17. Iskandar Setiadi Sinkronisasi Data (II) April 22, 2015 17 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 ********
18. Iskandar Setiadi Sinkronisasi Data (III) April 22, 2015 18 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 ********
19. Iskandar Setiadi Beberapa kasus seperti replikasi data maupun penyeimbangan data 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 22, 2015 19
20. Iskandar Setiadi Konsensus Raft April 22, 2015 20 Mekanisme pemilihan leader pada protokol Raft (Howard, 2014)
21. 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) dan Asia Pacific (Singapore), dengan spesifikasi sebagai berikut: - Processor Intel® Xeon CPU @ 2.50 GHz (1 vCPU) - Memory 1 GiB RAM Implementasi April 22, 2015 21
22. 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) April 22, 2015 22
23. Iskandar Setiadi Pengujian: Performansi Dasar April 22, 2015 23 •Semua operasi dilakukan dengan 100.000 data •Ukuran data adalah jumlah dari ukuran key dan value (masing-masing bernilai sama), tidak termasuk ObjectID MongoDB •1 MB = 1.048.576 Bytes Jenis Operasi Ukuran Data (Byte) Performansi (usec / op) MB / s LevelDB MongoDB LevelDB MongoDB FILL 20 3,10 223,05 6,15 0,09 100 4,05 224,15 23,55 0,42 UPDATE 20 3,17 246,54 6,02 0,08 100 4,75 259,17 20,08 0,37 READ 20 0,60 196,09 31,79 0,10 100 1,77 197,99 53,88 0,48 DELETE 20 2,93 224,74 6,51 0,08 100 3,55 223,19 26,86 0,43
24. Iskandar Setiadi Pengujian terhadap request dari pengguna Rencana Pengujian: Performansi April 22, 2015 24 Jenis Operasi Ukuran Data (KB) Jumlah Operasi Performansi (msec / op) Prototipe (TippyDB) MongoDB Avg Min Max Avg Min Max CREATE (Primary) CREATE (Primary mati) READ (Primary) READ (Primary mati) UPDATE (Primary) UPDATE (Primary mati) DELETE (Primary) DELETE (Primary mati) •Key yang digunakan berukuran 16 bytes •1 shard / partisi = 32 MB •Total data yang disimpan berukuran 200.000 KB
25. Iskandar Setiadi Pengujian terhadap komposisi read : write yang bervariasi Rencana Pengujian: Performansi April 22, 2015 25 Komposisi Write Komposisi Read Performansi (sec) Prototipe (TippyDB) MongoDB 1% 99% 5% 95% 25% 75% 50% 50% •Pengujian dilakukan menggunakan 10.000 request dengan 100 workers untuk mensimulasikan request konkuren pengguna •Ukuran data untuk setiap operasi write adalah 100 KB •Pengujian dilakukan dengan 2.000 data awal yang masing-masing berukuran 100 KB dan tersebar dalam 2 replika
26. Iskandar Setiadi Secara garis besar, pengujian terhadap prototipe solusi akan dibagi dalam 3 bagian utama: - Pengujian dilakukan untuk menjamin safety dan liveness dari komunikasi antar server - Pengujian dilakukan untuk menjamin kebenaran dari komunikasi antara client dengan server - Pengujian dilakukan untuk menjamin kebenaran internal dari server, mencakup komunikasi antara Apache Thrift dengan LevelDB Rencana Pengujian: Correctness April 22, 2015 26
27. Iskandar Setiadi Tanggal Kegiatan (Milestone) 31 April 2015 Penanganan terhadap kegagalan node 5 Mei 2015 Pengujian terhadap performansi prototipe solusi (TippyDB) dengan MongoDB yang tereplikasi 10 Mei 2015 Pengujian terhadap correctness prototipe solusi 15 Mei 2015 Dokumen TA II 22 Mei 2015 Revisi terhadap prototipe solusi maupun dokumen TA II pra-sidang Rencana Kedepan April 22, 2015 27
28. Iskandar Setiadi Kesimpulan Sementara April 22, 2015 28 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 sampai dengan 100 ms.