Upgrade to Pro — share decks privately, control downloads, hide ads and more …

[Seminar II] Pengembangan Prototipe Geographically-Aware Distributed NoSQL

[Seminar II] Pengembangan Prototipe Geographically-Aware Distributed NoSQL

Tugas Akhir II - S1 Teknik Informatika
Institut Teknologi Bandung

https://github.com/freedomofkeima/TippyDB

Iskandar Setiadi

April 22, 2015
Tweet

More Decks by Iskandar Setiadi

Other Decks in Research

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 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. Iskandar Setiadi Konsistensi Data April 22, 2015 10 Relasi antara

    teori CAP dengan basis data (Katsov, 2012)
  8. 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
  9. 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%
  10. 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}
  11. 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 } ] }
  12. 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
  13. 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 ********
  14. 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 ********
  15. 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
  16. 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
  17. 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
  18. 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
  19. 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
  20. 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
  21. 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
  22. 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
  23. 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.