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

Arsitektur Solusi

April 14, 2023 9

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

metadata.tmp

April 14, 2023 14

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: Konfigurasi MongoDB

April 14, 2023 28

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