Dokumen ini membahas pengembangan prototipe basis data NoSQL bernama TippyDB yang mampu melakukan partisi dan replikasi data secara geografis dengan mempertimbangkan lokasi pengguna. Prototipe ini bertujuan untuk menyimpan data sedekat mungkin dengan lokasi pengguna untuk mengurangi latensi rata-rata akses data. Dokumen ini juga membahas pengujian performansi dan kebenaran dari prototipe tersebut.

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.