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

Iskandar Setiadi

Referensi: http://www.couchbase.com/nosql-resources/what-is-no-sql

Latar Belakang

April 22, 2015 2

Iskandar Setiadi

Referensi: http://was-sg.wascdn.net/wp-content/uploads/2014/01/Slide011.png

Media Sosial

April 22, 2015 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 22, 2015 4

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

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

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

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

Iskandar Setiadi

Arsitektur Solusi

April 22, 2015 9

Iskandar Setiadi

Konsistensi Data

April 22, 2015 10

Relasi antara teori CAP dengan basis data (Katsov, 2012)

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

Iskandar Setiadi

metadata.tmp

April 22, 2015 12

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%

Iskandar Setiadi

Partisi Data

April 22, 2015 14

Region 1

Node 1

Node 2

Parameter shard = 32 MB

64 MB

0 MB

Proses partisidilakukan internal dalam 1 region.

putData

putDataForce

ShardedKey:

0001 0002 00000001

ts (timestamp):

1

Value: {“n”:1}

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

}

]

}

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

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

********

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 ********

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

Iskandar Setiadi

Konsensus Raft

April 22, 2015 20

Mekanisme pemilihan leader pada protokol Raft (Howard, 2014)

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

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

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 OperasiUkuran 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

Iskandar Setiadi

Pengujian terhadap request dari pengguna

Rencana Pengujian: Performansi

April 22, 2015 24

Jenis OperasiUkuran 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

Iskandar Setiadi

Pengujian terhadap komposisi read : write yang

bervariasi

Rencana Pengujian: Performansi

April 22, 2015 25

Komposisi Write Komposisi ReadPerformansi (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

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

Iskandar Setiadi

Tanggal Kegiatan (Milestone)

31 April 2015 Penanganan terhadap kegagalan node

5 Mei 2015 Pengujian terhadap performansi prototipesolusi (TippyDB) dengan MongoDB yang tereplikasi

10 Mei 2015 Pengujian terhadap correctness prototipesolusi

15 Mei 2015 Dokumen TA II

22 Mei 2015 Revisi terhadap prototipe solusi maupundokumen TA II pra-sidang

Rencana Kedepan

April 22, 2015 27

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.