ANALISIS PERFORMANSI SHARDI NG / PARTITIONING PADA DOCUMENT-

ORIENTED DATABASE (NOSQL)

ANALYSIS OF SHARDING / PARTITIONING PERFORMANCE ON DOCUMENT-ORIENTED
DATABASE (NOSQL)
1
Diah Putri Damayanti
2
Muhammad Nasrun,S Si., M.T
3
M. Syaiful Sabril , S.T,
114080008 10750600-1 10860739-3
1,2,3
Fakultas Elektro dan Komunikasi Institut Teknologi Telkom
Jl. Telekomunikasi, Dayeuh Kolot, Bandung 40257, Indonesia
1
diahputridamayanti@yahoo.com
2
m_nasrun@yahoo.com
3
msb@ittelkom.ac.id
ABSTRAK

Skalabilitas pada sistem basis data merujuk pada kemampuan sistem dalam menangani
pertumbuhan data dan proses melebihi kapasitas sebelumnya. Salah satu metode yang digunakan untuk
mendukung skalabilitas pada sistem basis data adalah dengan metode partisi secara horizontal. Partisi atau
partitioning adalah sebuah metode yang digunakan untuk memecah data menjadi bagian-bagian yang lebih kecil
dan menyimpannya secara independen pada mesin yang berbeda. Istilah yang umum digunakan untuk partisi
data secara horizontal adalah sharding. Sharding dapat digunakan untuk memecah tabel/collection dalam sebuah
database ke beberapa server terpisah, sehingga idealnya penggunaan metode sharding dapat menjaga performa
sistem tetap baik jika terjadi overload data dan traffic.
Pada tugas akhir ini dilakukan pengujian performansi sharding pada document-oriented database.
Database yang diuji pada tugas akhir ini adalah mongodb. Mongodb merupakan database non-relational yang
berorientasi dokumen dan telah mendukung auto-sharding.
Hasil dari pengujian ini menunjukan bahwa hasil throughput query operasi update, find, dan delete
yang dihasilkan oleh mongodb dengan sharding lebih banyak sebesar 10% untuk operasi update, 146% untuk
operasi find, dan 192% untuk operasi delete. Sedangkan untuk operasi insert mongodb dengan sharding memiliki
throughput lebih rendah yaitu 39% dibanding mongodb tanpa sharding. Pada sharding mongodb, pemilihan
shard-key yang tepat dapat meningkatkan efektifitas query.
Kata Kunci : Database, Document-oriented database, Mongodb, Sharding, partitioning

ABSTRACT
Scalability in database system is refers to ability of system to handle the growth of data and handle
load of traffic. One of method used to support scalability in database system is horizontal partitioning.
Partitioning is a method used to split the data into several parts and saved them into separate machines
independently. The term commonly used to partition the data horizontally is sharding. Sharding can be used to
split up the collection in database into separate servers. Ideally, sharding method can maintain system
performance if there an overload of data and traffic.
At this final project, it will be tested the performance of sharding on document-oriented database.
Database model used in this testing is mongodb. Mongodb is non-relational database which document-oriented
and support to an auto sharding process.
The results of this testing show that the throughput of update, find, and delete operation generated
by mongodb with sharding has more throughput than mongodb without sharding, there are 10% for update
operation, 146% for find operation, and 192% for delete operation. Whereas, for insert operation mongodb with
sharding has less throughput that is 39% than mongodb without sharding. The selection of appropriate shard-
key can increase the effectiveness of the query.
Key words : : Database, Document-oriented database, Mongodb, Sharding, partitioning
BAB I
PENDAHULUAN
1.1 Latar Belakang Masalah
Ketika internet baru ditemukan, data yang
terdapat didalamnya masih cenderung sedikit dan
dapat dikelola dengan basis data sederhana atau file
sistem biasa. Bahasa yang digunakan pun masih
cenderung statik yaitu HTML. Tetapi dengan
bertambahnya data dan user yang mengakses, serta
adanya bahasa pemograman website yang
mendukung koneksi antara website dengan basis
data didalamnya, membuat website menjadi
dinamik dan data dapat terus bertambah setiap saat.
Oleh karena itu sebelum mendesain sistem basis
data untuk jangka panjang, skalabilitas merupakan
syarat utama agar sistem basis data dapat terus
berlangsung dengan baik. Salah satu teknik
skalabilitas pada database adalah dengan metode
partitioning atau partisi data.
Partisi data atau partitioning adalah
sebuah metode yang digunakan untuk memecah
data menjadi bagian-bagian yang lebih kecil dan
menyimpannya secara independen. Metode
penyimpanannya dapat menggunakan satu mesin
yang sama atau pada mesin yang berbeda.
Penerapan partisi data pada satu mesin, bertujuan
untuk mengurangi index individual dan mereduksi
jumlah kanal I/O yang dibutuhkan dalam
pengelolaan data, sedangkan tujuan mempartisi
data pada mesin yang berbeda adalah untuk
menaikan bandwidth dalam pengaksesan data,
karena dengan memakai beberapa mesin yang
berbeda, akan lebih banyak mempunyai network
interface dan ketersedian kanal I/O untuk
memproses data.
Terdapat dua pendekatan umum yang
digunakan dalam mempartisi data, yaitu partisi
secara vertikal dan partisi secara horizontal. Pada
database relational, data yang berupa record dapat
dipisahkan berdasarkan kolom dan disimpan pada
tabel yang berbeda. jika ingin menggabungkan
record tersebut dibutuhkan join tabel dengan one-
to-one relationship, hal ini dapat dikatakan sebagai
contoh penggunaan partisi data secara vertikal.
Sedangkan partisi secara horizontal adalah
mekanisme mempartisi atau memecah data dengan
batasan row/baris dan memungkinkan untuk
memecahnya kedalam mesin-mesin yang berbeda.
metode ini tentu dapat diimplementasikan pada
seluruh model database, tetapi untuk database yang
mempunyai ketergantungan data, hal ini menjadi
kendala, karena untuk menggabungkan data pada
mesin yang berbeda diperlukan mekanisme khusus
untuk melakukannya. Oleh karena itu partisi data
secara horizontal dengan manggunakan mesin yang
berbeda lebih cocok diimplementasikan pada
database yang tidak punya ketergantungan data
didalamnya (non-relational).
Istilah yang umum digunakan untuk
partisi data secara horizontal adalah sharding,
sharding dapat digunakan untuk memecah
tabel/collection dalam sebuah database ke beberapa
server, sehingga idealnya penggunaan metode
sharding dapat meningkatkan performa sistem.
Salah satu model basis data yang
disebut sebagai non-relational database adalah
model document-oriented, pada model document-
oriented data disimpan dalam bentuk document.
Pada model relational, document disebut juga
dengan record .sedangkan kumpulan dari document
dinamakan collection. Pada relational database,
collection dapat diibaratkan sebagai table. Database
yang menggunakan model ini salah satunya adalah
MongoDB. Sehingga penerapan teknik sharding
sangat mungkin diterapkan pada MongoDB karena
pada pemodelan data MongoDB document dapat di
embed ke dalam document lain sehingga tidak
dibutukan relasi antar document atau bisa dikatakan
non-relational database.
Seperti yang tertera pada website
resminya, MongoDB telah mendukung auto-
sharding yang memungkinkan penerapan Scaling
secara horizontal di beberapa node terpisah. Untuk
aplikasi yang memerlukan sumber daya (resource)
yang diperkirakan akan betambah besar dan hanya
mempuyai satu server, MongoDB dapat
mengkonversinya menjadi sharded cluster.
Failover dan penyeimbangan data atau Balancing
dapat dilakukan secara otomatis.
Pada tugas akhir ini, penulis akan
melakukan penelitian untuk menguji performansi
MongoDB dalam menerapkan auto-sharding pada
komputer biasa dan seberapa besar pengaruh
penambahan jumlah node serta pemberian index
terhadap kinerja sistem dengan parameter
throughput dan response time..
1.2 Tujuan
Tujuan penelitian dalam tugas akhir ini
adalah untuk menganalisis performansi metode
sharding pada document-oriented database
(MongoDB), serta mengetahui variabel apa
saja yang mempengaruhi performansi
database.
1.3 Rumusan Masalah
Dari latar belakang yang telah
disampaikan sebelumnya, maka rumusan
masalah pada penelitian ini adalah :
1 Bagaimana merancang dan
mengimplementasikan metode sharding pada
document-oriented database dalam sebuah
jaringan komputer
2 Bagaimana tingkat performansi database
setelah mengimplementasikan sharding.
3 Apa pengaruh penambahan jumlah node pada
performansi database dengan parameter
throughput dan response time.
1.4 Batasan Masalah
Agar permasalahan yang timbul dalam
penelitian ini tidak terlalu luas, maka penulis
membatasi permasalahan yang akan dibahas
pada penelitian ini . Adapun batasan masalah
ditetapkan sebagai berikut :
1. Model document-oriented database yang
diuji adalah MongoDB.
2. Jumlah komputer yang dipakai pada
pengujian ini sebanyak 4 komputer.
3. Parameter yang digunakan dalam
pengujian performansi ini berupa
throughput dan response time.
4. Pengujian tugas akhir ini membahas
sharding tanpa replikasi set.

BAB II
DASAR TEORI
2.1. Nosql
NoSQL adalah sebuah konsep
penyimpanan data base secara non-relasional.
Not-only SQL mempunyai arti bahwa database
Nosql tidak memakai bahasa SQL pada proses
pengolahan data. Nosql dapat menangani
sekumpulan struktur data hirarkis secara cepat
dan mudah. Dengan bahasa SQL
penangananan sekumpulan data yang saling
berkaitan dibutuhkan banyak tabel dengan
berbagai macam kunci yang unik. Lain halnya
dengan Nosql yang di desain untuk
mendistribusikan data berskala besar dan
bersifat dinamik dengan tidak relasional.
Kehadiran NoSQL bukan untuk
menggantikan posisi basis data relasional.
Tujuan pengembangan Nosql adalah untuk
meningkatkan skalabilitas pada pertukaran data
dengan skala besar. Sebagian besar database
Nosql dipakai pada skala web, karena
pertukaran data pada internet sangatlah tinggi,
sehingga dibutuhkan sebuah desain database
yang mampu melayani request dengan data
rate yang tinggi. Jika data akan berkembang
menjadi besar, maka Nosql dapat menjadi
pertimbangan alternatif sebagai penyimpanan
data.
NoSQL itu terminologi, dan tidak
mengarah ke satu teknologi. NoSQL bukanlah
satu produk atau bahkan satu teknologi
melainkan sekumpulan dari berbagai macam
produk yang mempunyai cara yang berbeda
untuk memanipulasi data dan tentu tidak
relational. Beberapa jenis basis data NoSQL
diantaranya adalah key-value stores, Table
Oriented, Document Oriented, dan Graph
Oriented.

2.3 Skalabilitas
Skalabilitas secara umum adalah
kemampuan sistem untuk mengolah lebih
banyak proses dari proses yang mampu
dikerjakan oleh sistem pada keadaan normal.
Sebuah sistem dikatakan mempunyai
skalabilitas yang baik apabila mampu
mengakomodir kebutuhan sistem pada saat
proses didalamnya melebihi batas normal dari
rata-rata proses biasanya.
Pada Sistem basis data, skalabilitas
merupakan hal yang penting untuk menjaga
performansi sistem agar tetap bekerja optimal
pada saat bertambahnya jumlah data dan user
yang sudah melebihi batas yang mampu
diproses oleh sistem. Terdapat dua pendekatan
skalabilitas pada sistem basis data yaitu
skalabilitas secara vertikal dan skalabilitas
secara horizontal.
2.3.1 Skala Vertikal
Skalabilitas secara vertikal, merupakan
penskalaan sistem dengan menambah kapasitas
sumber daya pada logical unit / mesin yang
sama. Contohnya adalah menambah CPU pada
suatu sistem dan menambah kapasitas memori.
2.3.2 Skala Horizontal
Skalabilitas secara horizontal,
merupakan penskalaan sistem dengan
menambah logical unit / mesin sehingga
seluruh mesin dapat bekerja sama untuk
melakukan sebuah proses dalam kesatuan
sistem.
2.4 MongoDB
MongoDB adalah salah satu basis
data yang menggunakan model document-
oriented sebagai struktur datanya dan di tulis
dengan bahasa pemograman C++ . MongoDB
bersifat open source dan dapat di download
dari website resminya http://mongodb.org.
MongoDb merupakan salah satu bentuk dari
NoSQL (Not Only SQL).
Skema data pada MongoDB tidak
terdapat tabel, baris, maupun kolom, Oleh
karena itu mongoDB merupakan database
yang tidak berskema (skema-free). Pada
operasinya mongodb tidak mengenal istilah
join, oleh karena itu, mongodb
memberlakukan linking dan embed dokumen
untuk menghindari join antar dokumen,
istilah ini disebut dengan pre joined.
Kapasitas maksimal dokumen yang
dapat disimpan pada mongodb versi 1.7
keatas adalah 16 MB. Jika dokumen yang
akan disimpan melebihi kapastitas yang
ditentukan, mongodb menyiapkan tool untuk
menyimpan file besar, yaitu gridFS. GridFS
mampu menyimpan data seperti file
dokumen, foto, bahkan video. Dalam
penyimpanannya GridFS akan memecah data
dan menyimpan metadata dari pecahan data
tersebut.
Pada pengaturan standar, mongodb
tidak menunggu respon sistem ketika
melakukan transaksi pada database, sehingga
terdapat kemungkinan akan terjadi kegagalan
dalam transaksi data. Oleh karena itu,
mongodb menyediakan fungsi getLastError
untuk memastikan tidak ada kesalahan yang
terjadi pada saat melakukan transaksi data.
Untuk mengatasi kegagalan sistem, mongodb
menyediakan journal file yang dapat
dikonfigurasi sesuai kebutuhan. Ketika sistem
restart maka sistem akan mengulang semua
proses yang sebelumnya terekam pada journal
file. Journaling telah terkonfigurasi untuk
mongodb dengan versi 1.9.2 keatas dan
dengan sistem 64 bit.
2.4.1 Sharding MongoDB
Sharding adalah metode
mempartisi data secara horizontal, yaitu
dapat memecah data pada mesin yang
berbeda, karena mongoDB merupakan
database non relational, maka metode ini
sangat mungkin diberlakukan pada
mongoDB.
Setiap potongan data secara
eksklusif di kendalikan oleh satu node atau
disebut juga dengan shard. Tiap shard dapat
mengontrol semua yang didefinisikan
sebagai subset dari data tersebut. Operasi
database dapat berjalan hanya dengan satu
shard atau multiple shard jika dibutuhkan.
Mapping atau pemetaan dokumen pada
shards dikendalikan oleh shard key, oleh
karena itu pemilihan shard key pada shrading
sangatlah penting, karena shard key akan
menentukan bagaimana data ditempatkan dan
dipindahkan.
Ada tiga elemen yang dibutuhkan
pada proses sharding diantaranya adalah :
- Mongod
Mongod adalah inti dari proses database
dan pada proses sharding, Mongod
bertindak sebagai shard server.
- Config Server
Config server berfungsi untuk
menyimpan semua meta data yang
terjadi pada proses sharding. Jika semua
server down, maka config data hanya
bisa dibaca tanpa ditulis (read only) .
Sharded cluster dapat tetap online jika
dan hanya jika satu dari config server
berjalan.
- Mongos Daemon
Mongos merupakan router dari proses
sharding, yaitu mendistribusikan operasi
atau permintaan dari klien pada sharded
cluster . Pada antar muka klien, mongos
sama dengan mongod lainnya dan klien
tidak perlu secara langsung mengetahui
tempat penyimpanan data secara pasti,
karena terdapat integrasi antara mongos
dan config server dalam menentukan
dimana data akan dibaca maupun
ditulis.














Gambar 2.3 Arsitektur sharding secara umum
MongoDB mendukung auto-sharding yang artinya
bila seorang admin database membuat node baru
pada sistem, maka secara otomatis MongoDB akan
membagi kelebihan data dari node lama ke node
baru secara proporsional, sehingga bila ruang
penyimpanan pada node sudah habis, admin hanya
perlu mengkonfigurasi node baru dan data akan
berpindah ke node baru dengan seimbang. Pada
proses sharding penentuan shard key menjadi hal
yang perlu diperhatikan dan perlu diadakan
penelitian lebih lanjut tentang jenis dan metode
pengolahan data karena shaad key tidak dapat
diubah ketika proses sharding telah berjalan.


BAB III
ANALISIS DAN PERANCANGAN
3.1 Gambaran Umum Sharding /Partitioning
Berikut adalah gambaran umum
arsitektur sharding pada pengujian
document-oriented database










Gambar 3.1 Arsitektur Sharding

3.2 Perancangan Sharding Pada Mongodb
Untuk menganalisis performansi
sharding pada document-oriented database,
basis data yang digunakan adalah Mongodb.
Mongodb telah mendukung fitur auto-sharding
yang dapat menyeimbangkan chunk dalam
shard server tanpa harus merubah banyak pada
sisi aplikasi.
Mongo
s
Shard2 Shard3 ShardN
Config
Server
Client
mon
god

mon
god

mon
god
Replica set
Mongos
Config
Server
Sebelum melakukan pengujian
sharding pada Nosql, akan dilakukan
pengukuran performansi antara mongodb dan
mysql yang masing-masing mewakili Nosql
dan RDBMS. Pada pengukuran ini akan
dilakukan basic query seperti insert, update,
select, dan delete.
Pada pengujian sharding, akan
dirancang sebuah jaringan yang memenuhi
ketiga komponen utama dari arsitektur
sharding, yaitu Mongod sebagai shard server,
mongos daemon sebagai router, dan Config
Server sebagai penyimpan metadata sistem.
Parameter yang akan diuji adalah throughput
dan response time serta pengaruh penambahan
node/shard pada arsitektur sharding yang
mengakibakan penurunan atau peningkatan
performa dari sistem database.
Rancangan yang akan diuji pada
pengujian sharding diantaranya adalah :
1. Single Node / Tanpa Sharding
2. 2 Shard Server, 1 Mongos, 1 Config
Server
3. 3 Shard Server, 1 Mongos, 1 Config
Server
4. 4 Shard Server, 1 Mongos, 1 Config
Server
5. 5 Shard Server, 1 Mongos, 1 Config
Server
3.2.1 Perancangan Single Node / Tanpa sharding
Pada percobaan sharding
pertama, akan dibuat sistem yang hanya
terdiri dari client dan single mongod tanpa
adanya mongos dan config server. Ini
adalah konfigurasi umum mongodb tanpa
sharding.

Gambar 3.2 Perancangan Single Node / Tanpa
Sharding
3.2.2 Perancangan dengan 2 Shard server, 1
Mongos, 1 Config Server
Pada percobaan kedua akan
dibangun arsitektur sharding dengan
menggunakan 4 komputer yang terdiri dari
dua shard server, satu mongos daemon,
dan satu config server. Mongos daemon
ditempatkan di komputer yang
mempunyai nomor ip 192.168.1.3 dengan
port 27021, Config server ditempatkan
pada komputer dengan nomor IP
192.168.1.1 dengan port 27025, shard
server masing-masing ditempatkan pada
computer dengan nomor IP 192.168.1.2
dan 192.168.1.4 dengan default port dari
mongodb yaitu port 21017. Berikut adalah
rancangan cluster dengan 2 shard server:

Gambar 3.3 Perancangan dengan 2 shard server,
1 Mongos, 1 Config Server
3.2.3 Perancangan dengan 3 Shard server, 1
Mongos, 1 Config Server
Pada percobaan ketiga akan
dibangun arsitektur sharding dengan
menggunakan 3 shard server, 1 mongos
daemon, dan 1 config server. Satu shard
server akan ditempatkan bersama config
server di komputer yang sama dengan
port yang berbeda. Hal ini dilakukan
karena config server merupakan program
yang kecil sehingga dapat dijalankan
bersama-sama dengan program yang lain.
Mongos daemon ditempatkan
pada IP 192.168.1.1 dengan port 27021,
Config server dan satu shard server
ditempatkan pada computer dengan IP
192.168.1.1 dengan port 27025 untuk
config server dan 27023 untuk shard
server. Berikut adalah rancangan cluster
dengan 3 shard server:



Gambar 3.4 Perancangan dengan 3
shard server, 1 mongos, 1 config server
3.2.4 Perancangan dengan 4 Shard server, 1
Mongos, 1 Config Server
Pada percobaan keempat,
sistem terdiri dari empat shard server, satu
mongos, dan satu config server. Percobaan
ini akan memakai 4 komputer.
Konfigurasi mongos dan config server
sama seperti percobaan sebelumnya.
Sedangkan pada shard 1 yang ditempatkan
di komputer dengan IP 192.168.1.2 akan
di buat shard baru yaitu shard 4 dengan
port 27023 . Berikut adalah rancangan
cluster dengan 4 shard server :




Gambar 3.5 Perancangan dengan 4
shard server, 1 mongos, 1 config server

3.2.5 Perancangan dengan 5 Shard server, 1
Mongos, 1 Config Server
Pada percobaan kelima, model arsitekur
sharding sama seperti percobaan
sebelumnya. Percobaan ini menggunakan 5
buah shard server. Shard 5 akan di
tempatkan bersama-sama dengan shard 2
yaitu pada komputer yang mempunyai
nomor IP 192.168.1.4 dengan port 27023.
Berikut adalah rancangan cluster dengan 5
shard server :

Gambar 3.8 Perancangan dengan 5shard server, 1
mongos, 1 config server
BAB IV
IMPLEMENTASI DAN PENGUJIAN


4.1 Analisis Hasil Pengujian
4.1.1 Hasil Pengujian Response time dan
Throughput Pada Mysql dan Mongodb
4.1.1.1 Pengujian Insert
Setelah dilakukan pengujian
operasi insert pada mysql dan mongodb,
hasil response time dan throughput query
pada pengujian ini, dapat dilihat pada tabel
berikut ini.
Tabel 4.1 Hasil Pengujian response time insert Mysql dan Mongodb
Doc/rows
count
Mysql (s) Mongodb(s)
1 0.00354 0.00142
100 0.2353 0.0464
500 1.2943 0.23684
1000 1.991 0.4691
10000 19.477 4.494
25000 48.714 11.1535
50000 99.785 22.244
100000 202.586 44.2436


Tabel 4.2 Hasil Pengujian throughput insert Mysql dan Mongodb
Doc/rows
count
Mysql Mongodb
1 282 704
100 425 2155
500 386 2111
1000 502 2132
10000 513 2225
25000 513 2241
50000 501 2248
100000 494 2260
Berikut adalah grafik hasil operasi insert data
pada kedua database berdasarkan response
time sistem :


Gambar 4.2 Grafik hasil pengukuran basic insert pada
mongoDB dan mysql

Pada table 4.1 terlihat bahwa pada saat insert
sebanyak 10.000 data, perbedaan response time
antar kedua database, mulai menunjukan perbedaan
yang signifikan. Mysql membutuhkan waktu 19,4
detik, sedangkan mongodb membuthkan waktu 4,4
detik. Perbedaan rata-rata throughput pada
pengujian ini mencapai 338.13%, yaitu 453 QPS
untuk mysql dan 2009 QPS untuk mongodb. Hasil
throughput QPS antara kedua database cenderung
stabil dan menunjukan peningkatan linier seiring
dengan peningkatan jumlah iterasi insert.
4.1.1.2 Pengujian Select
Hasil dari pengujian throughput pada
query select dapat dilihat pada grafik
dibawah ini

Gambar 4.3 Grafik hasil pengukuran basic select
pada mongoDB dan mysql

Grafik ini menunjukan hasil rata-rata
throughput query select pada mysql dan mongodb.
Hasil ini diperoleh dari response time query
dibagai dengan jumlah rows/documents yang
terpilih dari database. Dari pengujian ini didapat
bahwa rata-rata hasil throughput query mongodb
adalah 10627 QPS, sedangkan hasil rata-rata
throughput query mysql adalah 829 QPS. Hasil
rata-rata throughput query mongodb lebih tinggi
dibandingkan dengan rata-rata throughput query
mysql yaitu mencapai 1181 %. Hal ini merupakan
suatu hal yang wajar karena pada saat melakukan
perintah select, terdapat operasi join table pada
mysql yang memerlukan waktu eksekusi lebih
lama dibandingkan menampilkan satu tabel. Lain
halnya dengan mongodb yang hanya mencari pada
satu collection yang tidak saling berelasi dengan
collection lainnya.
4.1.1.3 Pengujian Update
Hasil dari pengujian update pada mysql
dan mongodb dapat dilihat pada grafik dibawah ini.

Gambar 4.4 Grafik hasil pengukuran basic update pada
mongodb dan mysql
Dari hasil yang di dapat berdasarkan
pengujian terlihat rata-rata throughput mysql
adalah 3.432 QPS, sedangkan rata-rata throughput
mongodb adalah 25.803 QPS. Jadi dapat
disimpulkan pada pengujian ini rata-rata
throughput mongodb lebih banyal dibandingkan
dengan mysql yaitu sebanyak 651%.
Mongodb menerepakan update-in place
yang langsung merubah isi dari database dengan
data baru ketika diberi perintah untuk meng-
update data pada database. Sedangkan mysql yang
menggunakan engine innodb, pada operasi update
akan merubah isi database tanpa menghilangkan
log dari data lama sehingga kronologis update
data tersimpan dan data lama masih terdapat
dalam sistem database. Hal ini dilakukan untuk
menjaga konsistensi dan integritas data. Sehingga
waktu eksekusi proses update pada mysql yang
menggunakan engine innodb lebih lama
dibandingkan dengan mongodb.
4.1.1.4 Pengujian Delete
Hasil dari pengujian delete pada mysql
dan mongodb dapat dilihat pada grafik dibawah
ini.

Gambar 4.5 Grafik hasil pengukuran basic delete pada
mongoDB dan mysql
Grafik 4.4 menunjukan hasil rata-rata
throughput query pada pengujian ini. Hasil dari
pengujian operasi delete adalah mysql mempunyai
rata-rata throughput sebesar 54.951 dan rata-rata
throughput mongodb adalah 218.209. Hal ini
menunjukan bahwa mongodb memiliki throughput
297% lebih banyak dibandingkan dengan
throughput query mysql.
4.1.2 Hasil Pengujian Response time dan
Throughput Pada Mongodb Sharding
4.1.2.1 Pengujian Insert
Pengujian command insert pada
mongodb dengan sharding menggunakan
field author sebagai shard key.
Hasil dari pengujian command
insert dengan field author sebagai shard key
pada single node mongodb dan dengan
menggunkan sharding environment dapat
dilihat pada tabel dan grafik dibawah ini.

Tabel 4.3 Response Time Operasi I nsert (shardkey : author)

count
Single
shard
2
shardsvr 3shardsvr 4shardsvr 5shardsvr
1 0.00075 0.000518 0.00051 0.000538 0.00048
5 0.001 0.0012 0.002 0.0014 0.001
10 0.004 0.004 0.00418 0.00227 0.0039
100 0.022 0.048 0.0151 0.0172 0.01408
1000 0.12 0.1036 0.092 0.097 0.13
5000 0.31 0.21 0.21 0.48 0.56
10000 0.916 0.9766 0.785 1.247 1.193
50000 4.642 4.795 6.11 4.16 4.84
100000 9.212 11.28 12.716 11.78 19.559
500000 43.33 47.45 59.48 69.77 71.88
1000000 81.2 127.37 141.83 142.1 142.8

Gambar 4.6 Grafik response time query insert
pada sharding environment
Pada pengujian insert 1 sampai 50.000
dokumen, terlihat tidak ada perbedaan yang
signifikan antara mongodb tanpa sharding dan
dengan sharding, bahkan mongodb dengan 5
shard server memiliki response time yang lebih
singkat dari mongodb single shard. Perbedaan
respon time mulai terlihat pada command dengan
100.000 insert karena dengan 600 byte per
dokumen maka pada saat insert 100.000 dokumen,
ukuran data akan berjumlah 66 MB atau lebih
besar dari ukuran konfigurasi chunk yaitu 64 MB.
Pada saat ukuran data mencapai 64 MB akan
terjadi perpindahan chunk antar shard. Proses
balancing chunk oleh mongos membuat waktu
eksekusi dengan lebih banyak shard server lebih
panjang dari pada waktu eksekusi single node.
Pada pengujian ini response time dari single
shard dalam proses insert lebih dari 100.000
dokumen mempunyai rata-rata response time 39%
lebih cepat dibandingkan dengan database dengan
2 shard server dan 75 % lebih cepat dibandingkan
5 shard server. Dengan penambahan shard server
waktu eksekusi meningkat secara linier.










Gambar 4.7 Grafik throughput insert pada
sharding environment
Gambar 4.6 adalah grafik QPS insert,
dimana database tanpa shard memiliki QPS lebih
banyak sebanyak 40 % dari rata-rata QPS dengan
mongodb sharding. Sharding dengan 2 shard, dan 3
shard memiliki QPS yang tidak berbeda jauh, tetapi
QPS dengan sharding mulai menurun saat shard
server ditambah menjadi 4 shard server, hal ini
dikarenakan shard ke empat ditempatkan bersama
dengan shard 2, sehingga proses mongod berjalan
pada satu komputasi komputer dan menyebabkan
proses terbagi dan tidak maksimal.
4.1.2.2 Pengujian Find
Dari hasil percobaan terlihat
mongodb tanpa shard memiliki
throughput sebanyak 542 QPS untuk
operasi find. Perbedaan throughput
antara single node dengan 2 shard server
sebanyak 146% dengan throughput
sebesar 1334 QPS untuk 2 shard server.
Hasilnya terus meningkatkan seiring
dengan penambahan node/shard server.
Dengan 5 shardserver, throughput sistem
meningkat sebanyak 5 kali lebih banyak
dibandingkan dengan throughput single
node yaitu sebanyak 400%.

Gambar 4.8 Grafik throughput query find
pada sharding environment
Hal ini dikarenakan terdapatnya shard
key pada pencarian, Sehingga mongos
daemon tidak perlu meneruskan request ke
semua shard server . Shard key sangat
berperan penting dalam proses pencarian,
karena mongos daemon meneruskan
request hanya pada shard yang
mempunyai chunk dengan shard key
tertentu dan proses dibagi pada banyak
nya shard sehingga proses akan cepat
selesai karena masing-masing shard
bekerja secara paralel dan mengirimkan
output kembali pada mongos daemon.
4.1.2.3 Pengujian Update
Pada skenario pengujian update,
dilakukan update dokumen yang
mempunyai struktur yang sama dengan
skenario sebelumnya. Field yang diubah
pada pengujian ini adalah title yang
mempunyai author dan category sesuai
dengan data acak yang di bangkitkan.





Gambar 4.9 Grafik throughput query update
pada sharding environment
Hasil dari pengujian ini adalah
database tanpa sharding mempunyai QPS
sebanyak 7965, hasilnya tidak jauh berbeda
dengan database yang mempunyai 2 shard
server yaitu sebanyak 10% dengan QPS 2
shard server sebanyak 8817. QPS mulai
terlihat berbeda saat node ditambah menjadi 3
yaitu adanya peningkatan QPS sebanyak
214%.
Dengan node lebih banyak maka
proses update data dilakukan secara paralel
dan waktu eksekusi akan lebih singkat
dibandingkan dengan single node yang
mengerjakan proses hanya dengan satu
mongod.
4.1.2.4 Pengujian delete
Tidak seperti proses update,
penghapusan dokumen dengan author sebagai
shard key tidak terlalu berpengaruh pada
proses sharding karena dengan penghapusan
ini tidak menyebabkan chunk yang memuat
author dengan value tertentu berpindah pada
chunk yang lain, tetapi dengan berkurangnya
dokumen pada chunk di shard tertentu maka
jumlah chunk akan mengalami perubahan dan
mongos akan kembali melakukan balancing
terhadap data. Balancing diperlukan bila
beban pada setiap node pada satu shard
bertambah di luar proporsi dengan node yang
tersisa. Dalam situasi ini, data harus
didistribusikan untuk menyamakan beban
pada shard lainnya.
Hasil throughput pada pengujian ini
dapat dilihat pada grafik berikut :

Gambar 4.10 Grafik throughput query
delete pada sharding environment
Pada gambar 4.9 terlihat jelas bahwa
database tanpa sharding memiliki QPS
terendah yaitu 6026 dibandingkan dengan
database dengan 2 shard server yang
mempunyai 17638 QPS pada operasi delete.
QPS dengan sharding terus meningkat hingga
4 node dan turun ketika shard ditambah
menjadi 5 node. Penurunan QPS antara 4 node
dan 5 node adlah sebanyak 10.3%. Hal ini
dikarenakan karena shard diletakan bersama
dengan shard lainnya sehingga menganggu
proses komputasi.
4.1.2.5 Pengujian mapreduce
Hasil pada proses map reduce
menunjukan bahwa database tanpa
sharding membutuhkan waktu 28.06
detik untuk melakukan operasi map
reduce pada 1.000.000 dokumen,
sedangkan dengan 5 shard server,
operasi map reduce dapat dilakukan
degan 9.62 detik, 18.4 detik lebih cepat
dibandingkan dengan database tanpa
sharding atau sebanyak 191% lebih
cepat.
Berikut adalah grafik response
time dari hasil pengujian map reduce :

Gambar 4.11 Grafik hasil response time
Mapreduce pada Sharding Environment
Dalam operasi ini fungsi map reduce
dilakukan pada masing-masing shard.
Ketika mongos daemon menerima
perintah untuk melakukan map reduce,
maka mongos mengirmkan fungsi pada
masing-masing shard server. Tiap-tiap
shard server melakukan komputasi
masing-masing sebelum mengirimkan
hasil dari proses mapreduce Sehingga
hasilnya akan lebih cepat didapatkan
karena jumlah dokumen yang dipetakan
tergantung pada masing-masing shard.
Pada single node sistem harus memetakan
1.000.000 dokumen dengan hanya
mengandalkan 1 mongod untuk proses
tersebut, sedangkan pada database
terpartisi, dokumen akan terbagi secara
seimbang pada semua cluster sehingga
fungsi map reduce akan dijalankan dengan
lebih cepat karena dokumen pada single
shard berjumlah lebih sedikit.



BAB V
KESIMPULAN DAN SARAN

5.1 Kesimpulan
Adapun yang dapat disimpulkan dalam tugas
akhir ini adalah sebagai berikut:
1. Pada pengujian ini rata-rata throughput
dari semua operasi yang diujikan pada
mongodb dan mysql, mongodb memiliki
rata-rata throughput yang lebih besar
dibandingkan dengan rata-rata throughput
mysql yaitu sebesar 338.13% untuk
operasi insert, 1181 % untuk operasi
select, 651% untuk operasi update, dan
297% untuk operasi delete.
2. Pada pengujian sharding, operasi insert
pada single shard memilki response time
yang lebih singkat dibanding database
dengan dua atau lebih shard server yaitu
sebesar 39%. Sedangkan perbandingan
response time berdasarkan penambahan
antara 2 shard server sampai 5 shard
server rata-rata meningkat sebanyak 5%.
3. Pada operasi update, find dan delete,
mongodb dengan 2 shard server memiliki
throughput lebih banyak dibandingkan
dengan mongodb tanpa sharding, yaitu
sebanyak 10% untuk operasi update,
146% untuk operasi find, 192% untuk
operasi delete dan hasilnya terus
meningkat seiring dengan bertambahnya
shard server.
4. Pada pengujian mapreduce dengan
1.000.000 dokumen. Mongodb dengan 2
shard server mempunyai waktu eksekusi
lebih singkat dibandingkan dengan
mongodb tanpa sharding, yaitu sebesar
37%. Waktu ekseskusi sistem semakin
singkat pada 3 shard server yaitu turun
sebesar 10 detik, akan tetapi pada saat
penambahan shard menjadi 4 dan 5 shard
server penurunan response time cenderung
stabil yaitu menurun sebanyak 10%.
5. Pemilihan shard key sangat penting pada
proses sharding, karena proses penyebaran
data oleh mongos bergantung pada shard
key. Pemilihan shard key yang tepat dapat
mempercepat hasil query khususnya untuk
query update, find, dan delete.

5.2 Saran
1. Adanya penambahan server fisik yang
dijadikan shard server.
2. Dilakukan penelitian menggunakan
replica set pada sharding environment.
3. Penambahan jumlah data dan pengujian
dengan query yang lebih kompleks.
4. Diadakan perbandingan performansi
dengan document-oriented database
lainnya.