PERBANDINGAN STRUKTUR PENYIMPANAN DAN PERFORMANSI

NOSQL MONGODB DENGAN DBMS SQL SERVER

NASKAH PUBLIKASI

diajukan oleh

Mufid Itsnaini Zain

10.11.4404

kepada

JURUSAN TEKNIK INFORMATIKA

SEKOLAH TINGGI MANAJEMEN INFORMATIKA DAN KOMPUTER

AMIKOM YOGYAKARTA

YOGYAKARTA

2014

ii

NASKAH PUBLIKASI

PERBANDINGAN STRUKTUR PENYIMPANAN DAN PERFORMANSI

NOSQL MONGODB DENGAN DBMS SQL SERVER

disusun oleh

Mufid Itsnaini Zain

10.11.4404

Dosen Pembimbing,

M. Rudyanto Arief, M.T NIK. 190302098

Tanggal, 7 Juli 2014

Ketua Jurusan

Teknik Informatika

Sudarmawan, MT NIK. 190302035

iii

THE STRUCTURE AND PERFORMANCE COMPARISON OF NOSQL MONGODB AND DBMS SQL SERVER

PERBANDINGAN STRUKTUR PENYIMPANAN DAN PERFORMANSI NOSQL

MONGODB DENGAN DBMS SQL SERVER

Mufid Itsnaini Zain M. Rudyanto Arief

Jurusan Teknik Informatika STMIK AMIKOM YOGYAKARTA

ABSTRACT

In an age filled with a disclosure of information, the need for a rapid exchange of news, as well as the rapid growth of web-based information system applications, the technicians who are experts in the field of database programming will always find the best solution, fastest, and efficient in an effort to present or store data required by the user. The data will be an information must be stored properly so that at any time the data required can be accessed quickly.

Research on the comparison between the RDBMS with a new concept by NoSQL DBMS will show the results of a comparison of the various aspects of the instrument and in accordance with the given scenario. Represented by MongoDB NoSQL and RDBMS using SQL Server 2008.

With the results of this research, is expected to help the general public know about the existence of a DBMS technology development, and also helps in determining which DBMS that suits your needs.

Keyword : RDBMS vs NoSQL, SQL Server 2008, MongoDB, database performance.

1

1. Pendahuluan

Di era yang penuh dengan keterbukaan sebuah informasi, kebutuhan akan

cepatnya sebuah pertukaran berita, serta berkembang pesatnya aplikasi sistem informasi

berbasis web, para teknisi yang ahli dalam bidang pemrograman basis data akan selalu

mencari solusi terbaik, tercepat, dan efisien dalam upaya menyajikan ataupun

menyimpan data yang dibutuhkan oleh para pengguna. Data-data yang nantinya menjadi

sebuah informasi harus dapat disimpan dengan baik sehingga sewaktu-waktu data

tersebut dibutuhkan dapat diakses secara cepat.

SQL merupakan basis yang digunakan RDBMS (Relational Database Management

System) yang pada awalnya sistem tersebut dirancang oleh Edgar F. Codd di IBM tahun

1970 . Selama beberapa dekade di seluruh dunia, pengaruh sebuah konsep RDBMS

sangat mendominasi dalam setiap kegiatan pemrograman yang mengharuskan data

tersebut tersimpan dan dilakukan sebuah pemanggilan data pada sebuah tempat

penyimpanan basis data.

Sebuah konsep penyimpanan yang saling berkaitan, ketangguhan database

relational dalam hal penghitungan, integritas, dan kelebihan lainnya menjadikan RDBMS

diadopsi secara luas dan dianggap sebagai alternatif terbaik untuk penyimpanan data

terutama pada perusahaan perbankan ataupun perusahaan yang memiliki relasi pada

setiap data-datanya.

Sementara itu, perusahaan yang berkaitan dengan sistem informasi seperti

Google, Facebook, Twitter, Amazon dan sebagainya tidak hanya menyimpan data-

datanya menggunakan struktur ber-relasi. Berkas-berkas HTML, ataupun file media

lainnya yang tidak terstruktur memerlukan tipe penyimpanan yang baru tidak hanya

sekedar bisa melakukan relasi. Google yang memiliki Big table, Oracle dengan CouchDB

merupakan salah satu contoh penggunaan DBMS NoSQL (Not Only SQL) sebagai

alternatif dalam penggunaan penyimpanan data.

Banyak penelitian ataupun pengujian untuk mengetahui perbandingan antara

RDBMS dengan DBMS NoSQL, oleh karena itu penulis mencoba menyajikan penelitian

sebuah perbandingan struktur penyimpanan dan performansi antara NoSQL (MongoDB)

dengan sebuah konsep yang selama ini sudah banyak dikenal yaitu RDBMS SQL (SQL

Server 2008) dengan instrumen-instrumen yang berbeda dari penelitian sebelumnya.

2. Landasan Teori

2.1 Basis Data

Menurut Kristanto (2004:7) data adalah sesuatu yang nyata, fakta mengenai

objek yang dapat mengurangi derajat ketidakpastian tentang suatu keadaan atau

kejadian. Sedangkan Basis Data didefinisikan sebagai kumpulan data yang

2

disatukan dalam suatu organisasi atau tempat tertentu. Basis data yang

merupakan kumpulan data operasional lengkap dari suatu organisasi dikelola dan

disimpan sehingga terintegrasi dengan metode tertentu, yang pada umumnya

adalah menggunakan komputer sehingga mampu menyediakan informasi yang

optimal sesuai yang dibutuhkan oleh pengguna.

Sedangkan menurut Connolly (2004:15) mengenai basis data (database)

adalah sekumpulan koleksi data yang berhubungan secara logikal, dan sebuah

deskripsi dari data tersebut, didesain untuk menemukan keperluan informasi pada

sebuah perusahaan.

2.2 DBMS (Database Management System)

DBMS (Database Management System) merupakan sekumpulan program

yang mengatur ataupun mengkoordinasikan semua kegiatan yang berhubungan

dengan basis data. Dengan adanya berbagai tingkatan pandangan dalam suatu

basis data maka untuk mengakomodasikan masing-masing pengguna dalam

piranti lunak manajemen database biasanya terdapat bahasa-bahasa tertentu yang

disebut Data Sub Language.

Sedangkan menurut Kadir (2003:17) pengertian DBMS itu adalah suatu

program komputer yang digunakan untuk memasukkan, mengubah, menghapus,

memanipulasi dan memperoleh data/informasi dengan praktis dan efisien.

Hampir sama dituliskan oleh Connolly yang mengartikan DBMS adalah

sebuah perangkat lunak yang memungkinkan pengguna untuk mendefinisikan,

membuat, mengambil data, dan mengontrol akses kepada database

(Connolly.2004:16).

2.3 NoSQL (Not only SQL)

Pada tahun 1998 pertama kalinya dikembangkan sebuah konsep

penyimpanan basis data yaitu NoSQL oleh Carlo Strozzi, yang kemudian pada

tahun 2009 Eric Evans memperkenalkan kembali teknologi NoSQL. Kehadiran

NoSQL bukan berarti untuk menggantikan model RDBMS yang sudah ada. Awal

kemunculannya dilatarbelakangi oleh beberapa masalah yang muncul dari

RDBMS. NoSQL dan RDBMS memiliki kelebihan dan tempat masing-masing

sehingga diharapkan dapat saling melengkapi teknologi penyimpanan basis data.

Secara bahasa NoSQL merupakan singkatan dari Not Only SQL yang

berarti sistem manajemen basis data tersebut berbeda dengan basis data

relasional dalam beberapa aspek. Dalam RDBMS dikenal adanya konsep ACID

(Atomicity, Consistency, Isolation, Durability). Sedangkan dalam NoSQL

menerapkan konsep BASE (Basically Available, Soft state, Eventually Consistent).

3

1. Basically Available memastikan bahwa sistem bekerja sepanjang

waktu.

2. Soft state merupakan suatu kondisi sistem tidak harus konsisten setiap

saat.

3. Eventually Consistent menekankan bahwa sistem akan menjadi

konsisten beberapa waktu kemudian.

2.4 Performance Baseline

Pada dasarnya Performance Baseline adalah istilah yang sering digunakan

pada perangkat SQL Server. Namun secara umum, performance baseline adalah

suatu standar pada DBMS yang harus selalu terpenuhi selama sistem bekerja.1

Terdapat lima buah faktor yang digunakan untuk menentukan performance

baseline, yaitu : workload, throughput, system resources, optimization, contention.

Workload berhubungan dengan jumlah aktifitas yang terdapat pada sistem.

Throughput berhubungan dengan jumlah query yang terjadi pada periode tertentu.

System resources berhubungan dengan kapasitas perangkat keras yang dipunyai

oleh sistem. Optimization berhubungan dengan desain basis data serta aplikasi.

Dan terakhir contention berhubungan dengan kompetisi dari data yang berupa

records.

Gambar 2.1 Performance Baseline

1 Gunawan, ibnu dan Adipranata, Rudy. Peranan Ms Sql Agent Dalam Menjaga Performa Basis

Data Pada Ms Sql Server Secara Otomatis. http://fportfolio.petra.ac.id/, diakses pada tanggal 28

Maret 2014

4

2.5 Scalability

Dalam konsep relasi basis data untuk jumlah data yang sangat besar sangat

diperlukan adanya tindakan optimasi query. Mengoptimalkan query untuk

mengurangi penggunaan sumberdaya secara keseluruhan sangat penting untuk

diterapkan karena akan meningkatkan kinerja order of magnitude secara

keseluruhan. Berbeda dengan generasi navigasi basis data sebelumnya, sebuah

query dalam relasi basis data adalah menentukan apa yang akan diperoleh dari

basis data bukan bagaimana cara mendapatkannya (A.Ghazal, and R. Bhashyam:

2011). Untuk mempercepat pengambilan data yang diperlukan, RDBMS

menggunakan kunci primer dan kunci sekunder serta penggunaan index.

Basis data relasional dapat ditingkatkan kinerjanya dengan meningkatkan

komponen-komponen perangkat kerasnya seperti meningkatkan kemampuan

processor, menambahkan modul RAM, dan memberikan media penyimpanan

tambahan (Scale Up). Namun peningkatan tersebut hanya dapat dilakukan pada

sebuah node server. Jika kemampuan suatu node sudah mencapai batas

maksimum spesifikasi maka untuk meningkatkan kemampuan harus membeli

perangkat server baru yang lebih mahal dengan spesifikasi yang lebih tinggi. Cara

lain adalah dengan menambahkan perangkat baru pada jaringan dan mempartisi

basis data agar penyimpanannya dapat dibagi pada server lama dan server

tambahan. Cara tersebut relatif lebih murah namun tidak mudah untuk

diimplementasikan pada basis data relasional karena aturan konsistensi data lebih

diprioritaskan.

Dari penjelasan diatas, dapat disimpulkan terdapat dua metode dalam

konsep scale database (scalability), yaitu dengan peningkatan perangkat keras

(vertical scaling/scale up) dan partisi basis data yang kemudian dibagi dengan

server tambahan (horizontal scaling/scale out).

3. Analisis dan Perancangan Sistem

3.1 Gambaran Umum

Perbandingan struktur penyimpanan ataupun performansi sebuah kinerja

DBMS secara umum banyak faktor yang mempengaruhi hasil dari perbandingan

tersebut. Namun pada dasarnya pada sisi perangkat keras, sebuah performansi

kinerja DBMS akan selalu dikaitkan dengan tiga hal yaitu: kinerja processor,

memory, dan disc.

Dalam penelitian komparatif ini, dari sisi skalabilitas penulis akan melihat

dan melakukan analisa terhadap file-growth yang terjadi pada MongoDB maupun

5

SQL Server. Dari sisi performansi akan dilihat dari sisi kecepatan eksekusi perintah

serta kinerja dari processor maupun memory.

Sedangkan dalam penelitian ini untuk mendapatkan hasil dari perbandingan

kecepatan eksekusi perintah adalah menggunakan bahasa php. Hal ini

dimaksudkan agar dapat melihat langsung hasil kinerja kedua DBMS tersebut

setelah diimplementasikan kedalam suatu aplikasi berbahasa php.

Untuk performansi perangkat keras (processor dan memory), penulis hanya

akan menggunakan performance monitor yang sudah include dalam sistem

operasi Windows.

3.2 Analisis Kebutuhan Sistem

3.2.1 Kebutuhan Perangkat Keras

Proses komparasi dilakukan menggunakan sebuah Laptop dengan

spesifikasi perangkat keras (hardware) sebagai berikut.

1. Processor : Core i3 @2.20GHz (4 CPUs).

2. RAM : 2048MB.

3. Harddisk : Dialokasikan 150GB.

4. Monitor : resolusi 1366 x 768.

3.2.2 Kebutuhan Perangkat Keras

Untuk perangkat lunak yang digunakan adalah sebagai berikut.

1. Sistem operasi : Windows 7 64-bit.

2. Microsoft SQL Server 2008 Native Client dengan SQL Server

Management Studio version 10.0.1600.22 dengan driver

sqlsrv.dll.

3. MongoDB for windows version 1.5.1 dengan driver

php_mongo.dll.

4. Web Server Apache 2.2 dan script engine PHP 5.3.5.

5. Rockmongo .

Semua perangkat lunak yang akan digunakan seperti driver php,

Apache, dan PHP menggunakan versi yang kompatibel dengan compiler

MSVC9 (Visual C++ 2008) agar semua driver php dapat terbaca dan kedua

DBMS dapat dijalankan. Pada saat pemilihan perangkat lunak yang

menggunakan versi VC6, driver php untuk MongoDB tidak dapat dibaca baik

dari web server Apache maupun oleh PHP.

3.2.3 Sampel Data

Adapun data yang akan digunakan sebagai sampel data yang akan

dipergunakan untuk penelitian adalah data mahasiswa yang mencakup 1

6

field integer (id), 1 field string (nama), 1 field string (alamat), 1 field string

(NIM) dan akan dilakukan proses perulangan untuk insert datanya.

3.3 Perancangan Database SQL Server

Untuk sampel data yang akan digunakan, dalam penerapan tipe data pada

SQL diharuskan memberi tipe data apa yang akan digunakan. Berikut struktur

tabel untuk database SQL Server:

Tabel 3. 1 Perancangan Tabel Data SQL Server

Kolom Tipe Data Keterangan

Id Integer Not Null, Primary Key, Identity (1,1)

Nama Varchar (35) Null

Alamat Varchar (50) Null

NIM Varchar (10) Null

3.4 Perancangan Database MongoDB

Sedangkan untuk struktur tabel yang akan digunakan dalam skenario

penelitian juga sama dengan SQL Server. Perbedaannya adalah secara default

tipe data yang akan digunakan tidak perlu dituliskan dan langsung mengambil

value dari data yang dimasukkan.

Tabel 3. 2 Perancangan Tabel Data MongoDB

Kolom Tipe Data Keterangan

Id Value Not Null

Nama Value Null

Alamat Value Null

NIM Value Null

Untuk “id” yang akan ditampilkan pada database MongoDB bukanlah “id”

default (dalam MongoDB dikenal sebagai ObjectId). ObjectId merupakan value

yang sudah secara default digenerate oleh MongoDB dan digunakan sebagai

primary key (seperti pada RDBMS).

3.5 Perancangan Uji Coba

Berikut penjelasan mengenai kondisi yang akan digunakan sebagai proses

percobaan.

1. Pengujian I

7

Pengujian dengan memberikan variasi banyaknya data baik itu perintah

insert, view, edit, dan delete/drop. Berikut tabel rancangan yang akan digunakan

sebagai hasil tabulasi perbandingan :

Tabel 3. 3 Perancangan Tabel Hasil Pengujian I

Data 1000 10000 50000 100000

Percobaan Mongo SQL Mongo SQL Mongo SQL Mongo SQL

I

II

III

IV

V

VI

VII

VIII

IX

X

2. Pengujian II

Masih mengambil beberapa data dari hasil Pengujian I, namun dalam

Pengujian II ini akan ditambahkan tabulasi hasil percobaan berupa ukuran file-

storage yang digunakan pada kedua DBMS tersebut.

Tabel 3. 4 Perancangan Tabel Hasil Perbandingan Ukuran Data

Data 1000 10000 50000 100000

Percobaan Mongo SQL Mongo SQL Mongo SQL Mongo SQL

I-X

3. Pengujian III

Pengujian III ini akan fokus pada hasil kestabilan yang terjadi di perangkat

keras pada saat eksekusi program tersebut dilakukan. Agar dapat melihat hasil

yang benar-benar dapat diharapkan, maka dari itu penulis tidak memberikan

batasan data yang masuk. Dan untuk membatasinya, hanya menghentikan proses

perulangan dengan waktu tertentu.

8

Tabel 3. 5 Perancangan Tabel Hasil Kestabilan Perangkat Keras

4. Implementasi dan Pembahasan

4.1 Implementasi

Tahap implementasi akan menerapkan segala sesuatu yang sudah

dirancang sebelumnya pada perancangan prototipe. Sebelum penerapan

perancangan dijabarkan, terdapat beberapa software yang harus diintegrasikan

agar dapat digunakan sebagai proses pengujian.

Tabel pada database SQL Server dan collection pada database MongoDB

akan diimplementasikan dan disambungkan dalam prototipe yang sudah disiapkan

dengan nama database skripsi. Kedua prototipe tersebut dibuat identik dalam

semua aspek kecuali dalam penggunaan basis data, dan juga

pengimplementasian source code yang memang mengharuskan struktur tersebut

berbeda.

Prototipe yang sudah disiapkan, disimpan dalam folder htdocs dari folder

Apache web server. Pada kondisi yang biasa, alamat pemanggilan sebuah web

yang disimpan dalam folder htdocs yang berjalan pada sistem koneksi lokal dapat

dipanggil dengan mengetikkan “localhost” pada web browser. Namun dalam

penelitian ini, akan digunakan port:8080 pada “localhost” sehingga

pemanggilannya adalah “localhost:8080” (tanpa tanda petik).

9

4.2 Skenario Pengujian

Pada tahapan Pengujian I, proses pengujian dilakukan dengan alur sebagai

berikut.

Gambar 4.1 Alur Skenario Pengujian I

Skenario pengujian tersebut berlaku pada pengujian MongoDB maupun

SQL Server. Pengujian dilakukan sebanyak sepuluh kali dan laptop akan dilakukan

restart pada tiap lima kali pengujian. Pengujian juga tidak dilakukan secara

bersamaan antara MongoDB dengan SQL Server.

Pengujian II masih merupakan hasil dari skenario yang dilakukan pada

Pengujian I. Namun hasil pengujian yang diambil adalah ukuran data pada masing-

masing pengujian. Ukuran data dalam penggunaan media penyimpanan pada

pengujian ini diambil dari hasil akhir tiap alur pengujian yang dilakukan, bukan

berdasarkan jumlah data yang dimasukkan karena pada tahap pengujian eksekusi

perintah update data, jumlah karakter yang dimasukkan juga berbeda.

Sedangkan untuk skenario Pengujian III, pengujian hanya akan dilakukan

satu kali pada masing-masing DBMS. Hal ini dilakukan karena pada Pengujian III,

variabel kontrol yang digunakan adalah waktu. Dalam prototipe akan dimasukkan

kode program batasan berupa waktu eksekusi perintah yang diberikan.

Gambar 4.2 Kode Program Tambah Data dengan Batasan Waktu

4.3 Analisis Hasil Pengujian

4.3.1 Analisis Pengujian I

Skenario Pengujian I adalah melakukan pengujian dengan mengambil

sampel data yang jumlahnya sudah dipersiapkan sebanyak 10 kali,

didapatkan hasilnya untuk masing-masing DBMS dan perintah yang

diberikan sebagai berikut.

10

Tabel 4.1 Hasil Pengujian I insert data

Data MongoDB SQL Server 1000 0,28377 0,82261

10000 0,54441 6,18453 50000 1,82421 24,71238

100000 3,7072 73,73148

Dari hasil pengujian insert data yang dilakukan, kecepatan insert data

yang dilakukan oleh MongoDB lebih cepat dibandingkan SQL Server.

Semakin banyak insert data yang diberikan, menunjukkan semakin besar

perbedaan kecepatan yang terlihat pada kedua DBMS tersebut.

Skenario pengujian I selanjutnya adalah perintah view data. Berikut

tabel hasil pengujian yang dilakukan.

Tabel 4.2 Hasil Pengujian I view data

Data MongoDB SQL Server 1000 0,02722 0,07159

10000 0,70332 0,68637 50000 5,46985 5,98989

100000 12,45059 12,8364

Berbeda dengan kecepatan saat melakukan insert data, kecepatan

kedua DBMS pada saat melakukan perintah untuk melihat data memiliki

kecepatan yang hampir sama meskipun jumlah data yang dieksekusi

semakin banyak. Perbedaan kecepatan antara kedua DBMS pada saat

100.000 data juga hanya terlihat kurang dari 1 detik.

Pengujian I yang berikutnya adalah perintah untuk update data. Hasil

pengujiannya adalah sebagai berikut.

Tabel 4.3 Hasil Pengujian I update data

Data MongoDB SQL Server 1000 0,00368 0,05098

10000 0,0158 0,68637 50000 0,01469 0,71591

100000 0,01378 1,69665

11

Pada pengujian kecepatan update data dalam pengujian ini, kembali

terlihat perbedaan kecepatan yang terlihat besar antara MongoDB dengan

SQL Server meskipun rata-rata kecepatan update data berjalan dibawah

kecepatan angka 1 dalam satuan detik.

Proses pengujian I yang terakhir adalah pengujian perintah untuk

menghapus data. Berikut tabel hasil dari pengujian perintah hapus data.

Tabel 4.4 Hasil Pengujian I update data

Data MongoDB SQL Server 1000 0,01336 0,05549

10000 0,02013 0,08782 50000 0,03847 0,40696

100000 0,04033 0,99898

Dari hasil pengujian tersebut, juga terlihat perbedaan kecepatan untuk

melakukan perintah hapus data pada MongoDB dan SQL Server. Pada

Tabel 4.8 bahkan terlihat saat pengujian menggunakan MongoDB dengan

banyak data 100.000 pada beberapa pengujian memiliki kecepatan yang

lebih kecil dibandingkan saat jumlah data 50.000. Sedangkan untuk SQL

Server mempunyai kecepatan yang stabil dari tiap-tiap pengujian.

Berdasarkan Pengujian I pada sisi kecepatan eksekusi perintah,

diperoleh grafik pada masing-masing DBMS seperti berikut.

Tabel 4.5 Perbandingan Kecepatan Pengujian I

Pengujian Keterangan

Insert Data MongoDB melakukan insert data 16 kali lebih cepat dibanding SQL Server

View Data MongoDB melakukan view data 1,05 kali lebih cepat dibanding SQL Server

Update Data MongoDB melakukan update data 65 kali lebih cepat dibanding SQL Server

Delete Data MongoDB melakukan delete data 13 kali lebih cepat dibanding SQL Server

12

Gambar 4.3 Kecepatan Eksekusi MongoDB

Gambar 4.4 Kecepatan Eksekusi SQL Server

4.3.2 Analisis Pengujian II

Berikut hasil pengujian ukuran data pada MongoDB dan SQL Server

terhadap banyaknya data yang diberikan.

Tabel 4.6 Hasil Pengujian Ukuran Data

data 1000 10000 50000 100000 Pengujian Mongo SQL Mongo SQL Mongo SQL Mongo SQL insert 131072 2304 131072 2304 131072 5376 131072 8448

update 131072 2304 131072 3328 131072 8448 393216 15616

Berdasarkan Tabel 4.6 dapat dilihat bahwa dengan sampel data yang

sudah disiapkan dan banyak data yang diberikan, MongoDB mempunyai

13

ukuran penyimpanan data yang jauh lebih besar dibandingkan dengan SQL

Server.

4.3.3 Analisis Pengujian III

Pengujian III adalah untuk mengetahui pengaruh dari eksekusi

perintah insert data pada sisi perangkat keras yang digunakan. Eksekusi

perintah insert berjalan selama 30 detik dan pergerakan performance pada

processor ataupun memory direkam untuk diambil nilai dari angka yang

tertera pada Performance Monitor.

Setelah dilakukan pengujian eksekusi program selama 30 detik,

didapatkan hasil sebagai berikut.

Tabel 4.7 Hasil Pengujian III

Waktu 30 Detik

Percobaan Mongo SQL

Performansi processor (0,_total) 44,2340625 20,9813125

Performansi memory (%) 74,77453125 71,97240625

Banyak Data 698063 33253

Ukuran Data 458752 kb 5376 kb

Pada tabel diatas, MongoDB memberikan beban sehingga processor

bekerja pada nilai 0,_total sebesar 44,2340625. Dengan angka tersebut

dapat disimpulkan performance kinerja processor 2 kali lebih berat

dibandingkan kinerja yang dilakukan saat eksekusi menggunakan SQL

Server.

5. Penutup

5.1 Kesimpulan

Secara keseluruhan hasil yang diperoleh dari pengujian menunjukkan

bahwa dari segi kecepatan eksekusi perintah CRUD MongoDB memiliki performa

yang lebih baik dibandingkan SQL Server. Dari segi ukuran penyimpanan data,

SQL Server lebih efisien dibandingkan MongoDB karena mempunyai ukuran yang

lebih kecil. Sedangkan dari segi pengaruh terhadap processor dan memory (RAM),

SQL Server memiliki kestabilan dan pengaruh performansi yang lebih kecil

dibandingkan MongoDB.

14

Tabel 5.1 Hasil Keseluruhan Pengujian

Pengujian Keterangan

Insert Data MongoDB melakukan insert data 16 kali lebih cepat dibanding SQL Server

View Data MongoDB melakukan view data 1,05 kali lebih cepat dibanding SQL Server

Update Data MongoDB melakukan update data 65 kali lebih cepat dibanding SQL Server

Delete Data MongoDB melakukan delete data 13 kali lebih cepat dibanding SQL Server

Ukuran Data SQL Server memiliki ukuran penyimpanan data lebih kecil dari MongoDB

Pengaruh

terhadap

perangkat keras

SQL Server lebih stabil dan memiliki pengaruh performa terhadap perangkat

keras yang lebih kecil daripada MongoDB

5.2 Saran

1. Pada penelitian yang dilakukan ini adalah fokus pada pengujian untuk

melihat perbedaan size yang diperoleh dari skenario pengujian dan

performansi kecepatan baik itu kecepatan perintah CRUD, maupun

pengaruhnya terhadap perangkat keras yang digunakan. Untuk penelitian

berikutnya, ada baiknya melakukan pengujian terhadap hal-hal serta

penyebab dari ukuran penyimpanan data pada MongoDB yang sebesar itu.

Karena dalam pengujian ini, didapatkan penyimpanan pada MongoDB

memiliki ukuran (size) yang sama pada saat data 1000 sampai 50000.

2. Dikarenakan penelitian ini hanya bersifat stand alone (localhost),

penelitian selanjutnya bisa mengimplementasikannya pada sebuah jaringan

yang nyata dengan banyak user dan koneksi yang tidak hanya bersifat lokal.

3. Dari skenario pengujian ini belum dapat menunjukkan hasil bahwa

MongoDB ataupun SQL Server adalah DBMS yang cocok dan baik

digunakan pada sistem informasi tertentu. Sehingga pengembangan

selanjutnya harus ada sebuah penelitian yang menunjukkan bahwa

meskipun MongoDB mempunyai performa eksekusi perintah yang lebih baik,

namun MongoDB kurang dapat diterapkan pada sebuah basis data yang

banyak mempunyai relasi antar tabel.

15

DAFTAR PUSTAKA

Andi, W.R.E dan Sentosa, J. 2013. Perbandingan Kinerja Data Manipulation Language MongoDB dan SQL Server, http://andiwre.itmaranatha.org/jurnal/Paper%20Andi%20WRE%20cs%20-%20Seminasik%202013%20v%20prosiding.pdf, diakses pada tanggal 19 Januari 2014

Bin Ladjamudin, Al-Bahra. 2005. Analisis dan Desain Sistem Informasi.Graha Ilmu. Yogyakarta

Connolly, T., and Begg, C. 2004. Database Systems: A Practical Approach to Design, Implementation and Management, Fourth Edition. Pearson Education. Boston

Firdausillah, F., Erwin, Y., dan Novita, I. NoSQL: Latar Belakang, Konsep, danKritik,http://download.portalgaruda.org/article.php?article=113631&val=5187 diakses pada tanggal 9 September 2013

Gunawan, I., dan Adipranata, R. Peranan Ms Sql Agent Dalam Menjaga Performa Basis Data Pada Ms Sql Server Secara Otomatis. http://fportfolio.petra.ac.id/, diakses pada tanggal 28 Maret 2014

Hariguna, T., dan Tahyudin, I. 2013. NoSQL Database model untuk social network dan web 2.0, http://www.academia.edu/2627545/NoSQL_Database_Model_untuk_Social_Network_dan_web_2.0, diakses pada tanggal 30 Agustus 2013

Indrajani. 2011. Pengantar dan Sistem Basis Data.Elex Media Komputindo. Jakarta

Jeffrey, D., and Sanjay, G. 2004. MapReduce: Simplified Data Processing on Large Clusters. Proceeding of OSDI.

Julian, B. Brewer’s CAP Theorem, http://www.julianbrowne.com/article/viewer/brewers-cap-theorem, diakses pada 28 Maret 2014

Lakhsman, A., and Malik, P. 2009. Cassandra – A Decentralized Structured Storage System, http://www.cs.cornell.edu/Projects/ladis2009/papers/Lakshman-ladis2009.PDF, diakses pada tanggal 30 Agustus 2013

Leavit, N.2010. Will No-SQL Basis datas Live Up to Their Promise?. IEEE Computer Society.

Lee, K.J., and Whangbo T.K. 2007. Semantic Mapping between RDBMS and Domain Ontology . IEEE

Simarmata, J. 2007. Perancangan Basis Data. Penerbit ANDI. Yogyakarta

Utami, E., dan Dwi, A. H. 2012. Sistem Basis Data menggunakan Microsoft SQL Server 2005. Penerbit Andi. Yogyakarta

http://books.couchdb.org/relax/intro/eventual-consistency diakses pada 28 Maret 2014

http://bsonspec.org/ diakses pada tanggal 28 Maret 2014

http://docs.mongodb.org/ diakses pada tanggal 19 Januari 2014

http://en.wikipedia.org/wiki/Scalability diakses pada tanggal 26 Maret 2014.

http://id.wikipedia.org/wiki/Sistem_manajemen_basis_data_relasional diakses pada tanggal 23 Maret 2014

http://json.org/ diakses pada tanggal 28 Maret 2014

http://rockmongo.com/ diakses pada tanggal 15 Januari 2014