PERBANDINGAN STRUKTUR PENYIMPANAN DAN PERFORMANSI NOSQL MONGODB DENGAN DBMS SQL SERVER NASKAH PUBLIKASI

(1)

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

(2)

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

(3)

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.

(4)

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

(5)

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).

(6)

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

(7)

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

(8)

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

(9)

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.

(10)

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.

(11)

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).

(12)

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.

(13)

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

(14)

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

(15)

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

(16)

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.

(17)

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.

(18)

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_Net work_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