Implementasi VLDB (Very Large Database)

advertisement
MongoDB: Implementasi VLDB (Very Large Database)
Untuk Sistem Basis Data Tersebar (Distributed Database)
Dra. Sri Hartati, MSc, PhD 1 , Adi Nugroho, ST, MMSI2
Abstrak
Selama 4 dekade sistem basis data relasional (RDBMS-Relational Database
Management System) hampir selalu digunakan sebagai sumber data bagi
aplikasi-aplikasi tersebar (distributed system). Sesungguhnya tidak ada yang
salah dengan konsep „relasional‟ serta implementasinya dalam sistem-sistem
basis data yang populer saat ini, seperti Oracle, SQL Server, MySQL, dan
sebagainya. Meski demikian, pada saat ini, dengan munculnya aplikasi-aplikasi
tersebar yang menuntut kinerja aplikasi (baca: kecepatan) yang semakin tinggi,
sistem basis data relasional memiliki kelemahan saat menangani tabel-tabel
yang dipartisi baik secara vertikal maupun horizontal. Sistem basis data ini akan
menurun kinerjanya saat aplikasi-aplikasi membutuhkan data yang berasal dari
2 atau lebih tabel sekaligus. Hal inilah yang coba diatasi oleh sistem-sistem
basis data NoSQL (Not Only SQL) yang juga sering disebut sebagai VLDB
(Very Large Database) saat ini seperti Apache Cassandra (Facebook),
Hadoop, HBase, BigTable (Google), serta MongoDB. Pada tulisan ini, kami
akan mencoba mengeksplorasi sistem MongoDB, yaitu berkaitan dengan
konsep dasarnya, operasi-operasi dasarnya, serta implementasinya untuk
menangani data dalam sistem tersebar.
Kata kunci: MongoDB, VLDB, Distributed Database
1
PENDAHULUAN
Sistem basis data relasional (RDBMS-Relational Database Management System) yang konsepnya
diperkenalkan oleh Peter Chen (1970) dan diimplementasikan dalam bentuk sistem basis data DB2 di
IBM (International Bussines Machine) oleh DR. Edgar F. Codd beberapa tahun sesudahnya merupakan
sistem yang sangat tangguh karena ditopang oleh landasan matematika (Kalkulus Relasional) yang sangat
mumpuni [9]. Sistem basis data relasional ini (misalnya Oracle, SQL Server, MySQL, dan sebagainya)
hingga saat ini masih digunakan pada sebagian besar sistem di seluruh dunia. Sesungguhnya tidak ada
yang „salah‟ dengan konsep dan implementasi „relasional‟ dalam sistem basis data. Meski demikian,
karena karakteristik sistem „relasional‟ yang seringkali menuntut data yang berkaitan dengan entitas
tertentu disimpan dalam 2 atau lebih tabel yang saling berhubungan (baca: berelasi) maka sebagai
1
Staf Pengajar Program S3 Ilmu Komputer Fakultas Matematika dan Ilmu Pengetahuan Alam - Universitas Gadjah
Mada (FMIPA–UGM) di Jogyakarta. Email :[email protected]
2
Staf pengajar di Fakultas Teknologi Informasi – Universitas Kristen Satya Wacana (FTI–UKSW) di Salatiga –
Jawa Tengah. Saat ini sedang menempuh studi di Program S3 Ilmu Komputer Fakultas Matematika dan Ilmu
Pengetahuan Alam – Universitas Gadjah Mada (FMIPA–UGM) di Jogyakarta. Email : [email protected]
konsekuensinya muncul juga kebutuhan untuk menggabungkan 2 atau lebih tabel itu saat aplikasi
membutuhkan data yang utuh/lengkap [1]. Penggabungan tabel ini bisa dilakukan menggunakan
pernyataan SQL (Structured Query Language) JOIN (pada tabel yang dipartisi secara vertikal) atau
UNION (pada tabel yang dipartisi secara horizontal) [1, 7]. Pada gilirannya, kedua operasi penggabungan
tabel ini akan sangat membebani kerja server basis data sebab, untuk melakukannya, server basis data
harus terus menerus melakukan pencarian data (lookup) pada tabel-tabel yang akan digabungkan [2, 6].
(Pada umumnya pencarian ini dilakukan berdasarkan kesamaan nilai „kunci primer‟ [primary key] pada
tabel utama/tabel induk dengan „kunci tamu‟ [foreign key] yang ada pada tabel-tabel anak.) Pencarian
data ini seringkali menurunkan kinerja (baca: kecepatan) sistem.
Berkaitan dengan hal di atas, para pakar di bidang pemrograman dan basis data di seluruh dunia mencoba
mencari suatu teknik yang baru sedemikian rupa sehingga fakta penurunan kinerja sistem itu bisa diatasi.
Dalam hal ini, suatu teknik yang relatif berbeda, yang berkaitan dengan query, dikembangkan. Teknik ini
pada dasarnya melakukan penyimpanan data bukan dengan basis query terhadap tabel-tabel yang saling
berelasi satu terhadap yang lainnya, melainkan menyimpan data sesuai dengan query yang diharapkan
akan dilakukan oleh aplikasi [15]. Pendekatan ini kadang melanggar prinsip-prinsip „tabel yang normal‟
pada basis data relasional, tetapi akan sangat meningkatkan kinerja sistem sebab, saat melakukan query,
sistem basis data tidak perlu melakukan pencarian (lookup) pada berbagai tabel yang berbeda. Query
hanya dilakukan pada 1 tabel saja! Hal inilah (ditambah dengan harapan akan adanya suatu sistem
penyimpanan data yang mampu menangani data yang jumlahnya sangat besar/banyak serta tersimpan
secara tersebar) pada akhirnya memunculkan suatu sistem basis data yang baru, yang sering dinamakan
sebagai VLDB (Very Large Database) (karena mampu menangani data hingga satuan Petabyte [1015
byte] bahkan lebih besar lagi) atau yang juga sering dinamakan sebagai sistem NoSQL (Not Only SQL)
karena operasi-operasi dasarnya tidak menggunakan bahasa nirprosedural SQL lagi melainkan
menggunakan teknik-teknik yang umum dikenali dalam bahasa-bahasa pemrograman berorientasi objek
pada umumnya [8, 15]. (Dalam tulisan ini, kami nanti akan mencoba melakukan akses ke sistem basis
data MongoDB menggunakan bahasa pemrograman Java.)
Jika kita membahas sistem-sistem basis data/tempat penyimpanan data yang tidak beradaptasi dengan
konsep sistem relasional, sesungguhnya (selain konsep NoSQL yang digunakan oleh MongoDB) dunia
Teknologi Informasi juga mengenal beberapa konsep-konsep
sistem-sistem basis data/tempat
penyimpanan data (Data Store) yang lainnya (tidak dibahas dalam tulisan ini) misalnya [2, 3, 13, 15]:
sistem basis data graf (Neo4j, OrientDB), sistem basis data berorientasi objek (OODBMS-Object
Oriented Database Management System) (misalnya Versant, GemFire ), sistem basis data XML (Oracle
Berkeley DB XML, MonetDB/XQuery), dan sebagainya. Selain itu, dari sudutpandang sistem NoSQL
seperti MongoDB, kita juga mengenal beberapa konsep yang secara umum serupa, tetapi tidak tepat
sama, misalnya Key-Values Store (Voldemort, Riak, Redis, Scalaris, Tokyo Cabinet), Document Store
(SimpleDB, CouchDB, MongoDB, TerraStore ), serta Extensible Record Store (BigTable-nya
Google, HBase, HyperTable, PNUTS-nya Yahoo, Dynamo-nya Amazon, Apache Cassandra-nya
Facebook). Dalam hal ini, MongoDB layak untuk dibahas sebab saat ini banyak digunakan di beberapa
situs Web besar, misalnya FourSquare, Shutterfly, Intuit, Github, Sourceforge (bahkan Google pun,
untuk beberapa bagian sistemnya, menggunakan MongoDB sebagai basis datanya) [12, 14].
2
KONSEP DASAR MONGODB
MongoDB, tidak seperti sistem basis data relasional, sering disebut sebagai tempat penyimpanan data
yang berorientasi pada dokumen (document) dan dapat menyimpan data yang memiliki berbagai tipe [4,
5]. MongoDB menyimpan data dalam format serupa dengan notasi JSON (Java Script Object Notation)
-lebih tepat menggunakan format penyimpanan data BSON (Binary JSON) karena, selain menangani data
teks, juga mampu untuk menyimpan data biner (binary) [4, 5]. Contohnya adalah sebagai berikut.
{
"First_Name": "Adi",
"Last_Name" : "Nugroho",
"phone_numbers": [
"+0222 1234 5678",
"+62 1234 456 678"
]
}
DATABASE
COLLECTION
DOCUMENT
Gambar 1
Struktur Penyimpanan Data Dalam MongoDB
Adapun kelebihan dari BSON dibandingkan JSON pada umumnya adalah karena elemen-elemennya juga
mampu menyimpan data berformat biner (binary) [5, 6]. Sementara itu, kelebihan notasi JSON/BSON ini
dibandingkan dengan apa yang disimpan dalam sistem basis data relasional pada umumnya adalah bahwa
pemrogram tidak harus menyediakan nilai pada setiap elemennya. Dalam sistem basis data relasional,
nilai yang tidak ada pada dasarnya tetap akan disimpan dalam basis data (meskipun mungkin cuma
bernilai NULL) sehingga penyimpanan data di MongoDB akan lebih hemat ruang. Sebaliknya, yang juga
merupakan kelebihan notasi BSON dari struktur tabel pada sistem basis data relasional adalah bahwa,
dalam notasi BSON ini, kita juga sangat dimungkinkan untuk menambahkan elemen yang baru (yang
tidak dimiliki oleh dokumen-dokumen yang lainnya), misalnya untuk dokumen yang baru (mengikuti
contoh berkas BSON di atas) kita bisa menambahkan elemen Fax yang tidak dimiliki dokumen
sebelumnya, sehingga pemanfaatannya secara umum lebih fleksibel.
Dalam sistem basis data MongoDB, pengembang juga tidak perlu memberikan nilai kunci primer
(primary key) untuk setiap elemen yang ada pada masing-masing dokumen, karena secara otomatis setiap
elemen dalam dokumen yang masuk ke basis data akan memiliki _id-nya masing-masing yang bernilai
unik, yang didapatnya dari sistem (terutama berdasarkan waktu elemen masuk ke sistem serta
nama/alamat komputer yang digunakan) [4, 5]. Dengan demikian, setiap dokumen yang disimpan dalam
MongoDB pada dasarnya akan berupa elemen-elemen pasangan „kunci/nilai‟ (key/value) yang masingmasing memiliki _id-nya yang unik. Elemen “First_Name” pada contoh di atas, memuat di dalamnya
kunci (key) dan nilai (value)-nya. Kunci-kunci biasanya ditulis dalam bentuk string, tetapi nilai-nilainya
bisa saja merupakan tipe-tipe data yang beragam seperti [4, 5]: (1) String, yang digunakan untuk
menyimpan nilai teks, (2) Integer (32b dan 64b) yang digunakan untuk menyimpan nilai-nilai numerik,
(3) Boolean yang menyimpan nilai TRUE atau FALSE, (4) Double yang digunakan untuk menyimpan
bilangan bertitik desimal, (5) Min/Max yang digunakan untuk membandingkan nilai terkecil dan terbesar
untuk elemen-elemen BSON, (6) Array yang digunakan untuk menyimpan nilai-nilai larik (array), (7)
Timestamp yang menyimpan tanggal dan waktu saat data disisipkan ke basis data, (7) Object yang
digunakan untuk menyimpan dokumen-dokumen yang menyimpan dokumen lain di dalamnya (nested
object), (8) Null yang menyimpan data yang tidak diketahui nilainya, (9) Symbol yang serupa dengan
string tetapi bisa digunakan untuk menyimpan simbol-simbol dalam bahasa-bahasa Jepang, Cina, India,
Arab, Jawa, dan sebagainya, (10) ObjectID yang digunakan sebagai pengidentifikasi suatu dokumen,
serta (11) Binary Data yang digunakan untuk menyimpan data biner (binary).
Sistem basis data MongoDB ditulis menggunakan bahasa pemrograman C++, tetapi sesungguhnya para
penciptanya tidak mengharuskan aplikasi-aplikasi ditulis menggunakan bahasa C++ juga [4, 5]. Tersedia
driver-driver yang memungkinkan MongoDB diakses oleh aplikasi-aplikasi yang ditulis menggunakan
C#, Ruby, PHP, Java, dan sebagainya. Secara umum, tempat penyimpanan utama data dalam MongoDB
dinamakan sebagai koleksi (collection) yang analog dengan tabel pada sistem basis data relasional
(Gambar 1). Secara sederhana dapat dikatakan bahwa koleksi menyimpan sejumlah elemen data yang
serupa (tidak harus sama!). Sementara itu, terminologi basis data, yang dalam sistem basis data relasional
merupakan kumpulan dari sejumlah tabel, dalam MongoDB didefinisikan sebagai kumpulan dari koleksikoleksi. Selain itu, dalam MongoDB, seperti juga dalam sistem basis data relasional, dikenal konsep
indeks (index) [4, 5], yang dibentuk oleh MongoDB dari hasil pengindeksan _id yang dimiliki oleh setiap
elemen dokumen.
Kelas MongoManager
package MongoDBProgram;
// Package-package dari driver Java untuk MongoDB.
import com.mongodb.DB;
import com.mongodb.DBCollection;
import com.mongodb.DBCursor;
import com.mongodb.DBObject;
import com.mongodb.Mongo;
import com.mongodb.MongoException;
// Package-package dari JDK (Java Development Kit).
import java.net.UnknownHostException;
import java.util.ArrayList;
public class MongoManager {
private String dbname;
private DB db;
// Konstruktor kelas.
public MongoManager(String dbname) {
this.dbname = dbname;
try {
Mongo mongo = new Mongo();
this.db = mongo.getDB(dbname);
} catch (UnknownHostException ex) {
} catch (MongoException ex) {
}
}
// Metoda untuk mendapatkan nama database.
public String getDBName() {
return this.dbname;
}
// Metoda untuk menambahkan dokumen (CREATE).
public void addDocument(DBObject object, String collectionName) {
db.getCollection(collectionName).insert(object);
}
// Metoda untuk mendapatkan elemen-elemen dokumen (READ/RETRIEVE).
public ArrayList getCollectionData(String collectionName) {
ArrayList list = new ArrayList();
DBCursor cursor = db.getCollection(collectionName).find();
while (cursor.hasNext()) {
DBObject object = cursor.next();
list.add(object);
}
return list;
}
// Metoda untuk meng-update dokumen (UPDATE).
public void updateDocument(DBObject criteria, DBObject newObject,
String collectionName) {
db.getCollection(collectionName).update(criteria, newObject);
}
// Metoda untuk menghapus dokumen (DELETE).
public void removeDocument(DBObject criteria, String collectionName) {
db.getCollection(collectionName).remove(criteria);
}
}
Gambar 2
Operasi CRUD Pada Sistem MongoDB
(Untuk Bahasa Pemrograman Java)
3
OPERASI-OPERASI DASAR PADA MONGODB
Operasi-operasi dasar dalam basis data sering dinamakan sebagai operasi-operasi CRUD (CreateRead/Retrieve-Update-Delete). Untuk sistem basis data MongoDB, untuk melaksanakan operasi-operasi
CRUD dari arah aplikasi, pemrogram tidak bisa lagi menggunakan bahasa nirprosedural SQL yang
bersifat baku untuk sistem basis data relasional [4, 5], melainkan harus menggunakan teknik-teknik
pemrograman pada umumnya. (Yang terbaik adalah saat pemrogram menggunakan bahasa-bahasa
pemrograman berorientasi objek sebab pemrogram yang bersangkutan akan lebih mudah menyesuaikan
program/aplikasinya dengan struktur penyimpanan data seperti yang diperlihatkan dalam Gambar 1.)
Perhatikan Gambar 2 di atas, dimana kita dapat melihat kelas MongoManager yang memuat operasioperasi CRUD dasar terhadap basis data MongoDB dilakukan menggunakan bahasa pemrograman Java.
Kelas MongoManager pada Gambar 2 selanjutnya bisa dimanfaatkan untuk operasi-operasi CRUD yang
akan dilakukan pada sistem MongoDB.
Seperti terlihat melalui Gambar 2, operasi-operasi CRUD pada sistem MongoDB dilakukan menggunakan
paradigma “pemrograman berorientasi objek” pada umumnya [8]. Baik basis data, koleksi, dokumen,
maupun elemen-elemen di dalamnya, diperlakukan seperti objek-objek, dimana objek dasar pada sistem
MongoDB dinamakan sebagai BasicDBObject. Dalam hal ini, pemrogram aplikasi sistem tersebar
harus membuat objek dalam bahasa Java (objek BasicDBObject) kemudian, untuk operasi
penambahan (CREATE/INSERT) menambahkannya menjadi elemen-elemen dalam dokumen yang
dikelola oleh MongoDB. Dalam hal ini, operasi-operasi CRUD itu difasilitasi oleh kelas-kelas yang
tersedia pada driver Java untuk sistem MongoDB. Perlu dicatat juga bahwa, dalam sistem MongoDB,
untuk melakukan query terhadap sistem MongoDB, perlu digunakan struktur data koleksi yang dimiliki
oleh bahasa pemrograman yang digunakan. Berbagai struktur data berjenis koleksi bisa digunakan [8].
Dalam contoh operasi CRUD pada Gambar 2, khususnya untuk operasi pembacaan (READ/RETRIEVE),
kami menggunakan struktur data ArrayList. Meski demikian, sesungguhnya struktur-struktur data
yang lainnya dalam bahasa Java (misalnya Map, HashTable, List, dan sebagainya) juga dapat
digunakan dengan penyesuaian-penyesuaian tertentu pada program. Pada dasarnya, pemrogram aplikasi
yang memahami konsep “pemrograman berorientasi objek” dengan baik kemungkinan besar tidak akan
mengalami kesulitan saat ia bekerja dengan sistem basis data MongoDB.
4
PENGGUNAAN MONGODB PADA SISTEM TERSEBAR
MongoDB merupakan sistem basis data yang ideal untuk implementasi sistem tersebar. Hal ini
disebabkan, selain karena kemampuannya menangani data yang jumlahnya sangat banyak, juga karena
MongoDB mampu menangani sejumlah data yang tersebar di beberapa komputer sekaligus dengan cara
sedemikian rupa sehingga beban masing-masing server akan merata (load balancing) [5]. Lebih bagus
lagi, MongoDB juga memungkinkan pemrogram „memandang‟ keseluruhan data pada sistem tersebar itu
secara logika bersifat tunggal [4, 5]. MongoDB akan mengelola data dalam sistem tersebar di luar
pengetahuan pemrogram sehingga pemrogram bisa lebih berfokus pada logika bisnis yang diperlukan
aplikasi, alih-alih memikirkan juga dimana data yang dibutuhkan aplikasi berada. Apa yang
memungkinkan terjadinya transparansi basis data dari pemrogram dan yang memungkinkan beban server
yang merata adalah konsep shard [5]. Shard sesungguhnya adalah himpunan bagian dari keseluruhan
data dimana hal ini pada dasarnya serupa dengan partisi horisontal seperti yang dikenal pada sistem basis
data tersebar selama ini [8]. Sebagai contoh, misalkan sistem basis data MongoDB untuk suatu aplikasi
tersebar memiliki 10 juta dokumen dan sistem yang berangkutan menggunakan 5 server data, maka
masing-masing server data itu mungkin (bergantung pengaturan-pengaturan saat konfigurasi awal
MongoDB [5]) akan memiliki 1 shard yang berkapasitas 2 juta dokumen.
100000 data dipindah
Shard 1
Shard 2
Shard 3
Shard 4
Shard 5
2000000
2100000
2000000
1900000
2000000
Gambar 3
Mekanisme Penyeimbangan Beban Shard
Oleh MongoDB
Shard pada masing-masing server, jika kapasitas/ukurannya sama, akan mengakibatkan beban masingmasing server akan sama [1, 10, 11]. Tetapi bagaimana hal itu dapat diupayakan secara kontinyu? Kami
akan konsisten menggunakan contoh di atas. Gambar 3 memperlihatkan bahwa masing-masing shard
pada awalnya masing-masing berisi 2 juta dokumen (dengan total data basis data MongoDB berjumlah 10
juta dokumen). Seiring berjalannya waktu, maka mungkin saja ada operasi-operasi CRUD yang lebih
intensif di beberapa shard (misalnya Shard 2 dan Shard 4). Dalam hal ini, shard 2 isinya mungkin
berubah menjadi 2,1 juta dokumen; shard 4 isinya mungkin berubah menjadi 1,9 juta dokumen. Jika ini
benar-benar terjadi, sistem basis data MongoDB akan mendeteksinya dan kemudian memindahkan 100
ribu dokumen dari shard 2 ke shard 4 sehingga secara keseluruhan bebannya akan menjadi seimbang dan,
yang lebih menakjubkan, semuanya ini bersifat transparan dari pandangan pemrogram.
Dalam sistem basis data MongoDB, ukuran masing-masing shard ditentukan saat konfigurasi awal [5].
Konfigurasi awal ini juga dilakukan dengan menentukan shard key yaitu elemen mana dalam dokumen
yang akan ditentukan sebagai basis proses sharding akan dilakukan [5]. Selain itu, dalam MongoDB,
pengembang juga bisa menentukan basis data dan/atau dokumen mana yang nantinya akan bisa disharding [5]. Saat aplikasi berkembang, pengembang mungkin akan merasa perlu menambahkan lebih
banyak shard (misalnya pada contoh di atas, shard yang ke-6). Saat pengembang menambahkan shard
yang baru, MongoDB akan secara otomatis memindahkan data dari shard yang ada ke shard yang baru
tadi dengan masih melakukannya di luar pengetahuan pemrogram. Dalam melakukan pemindahan data
(sharding), MongoDB memiliki suatu proses yang dinamakan mongos [5] dimana proses mongos ini
akan mengelola klien-klien yang akan melakukan koneksi ke server MongoDB. Mongos ini akan
meneruskan permintaan-permintaan (request) ke server (atau server-server) yang sesuai (sejumlah server
yang menangani permintaan tunggal dari aplikasi sering dinamakan sebagai cluster [2, 10, 11]) dan
mengirimkan kembali tanggapannya (response) ke klien yang mengirimkan permintaan tadi.
5
KESIMPULAN
MongoDB merupakan sistem basis data NoSQL (Not Only SQL)/VLDB (Very Large Database) yang
cukup ideal digunakan sebagai tempat penyimpanan data pada sistem tersebar (distributed system) karena
kemampuannya untuk menangani data yang berjumlah sangat besar. Fitur pemerataan beban (load
balancing) dengan pola sharding yang dimiliki oleh MongoDB melalui proses mongos yang dimilikinya
juga menjadikan basis data MongoDB sangat layak untuk digunakan sebagai basis bagi sistem tersebar.
Lebih bagusnya lagi, proses sharding ini juga bersifat transparan dari pandangan pemrogram sehingga
pemrogram bisa lebih berfokus pada pembuatan logika bisnis aplikasi alih-alih harus juga berpikir
tentang dimana sesungguhnya data yang dibutuhkan aplikasi berada.
Biaya perolehan MongoDB yang sangat rendah (gratis!) juga merupakan nilai tambah yang signifikan
selain ukuran berkas (file)-nya yang relatif kecil (kurang dari 20 MB!). Meski demikian, di sekian banyak
keunggulannya, MongoDB juga memiliki kekurangan karena sintak bahasa pengaksesnya sangat
bergantung pada bahasa pemrograman yang digunakan (tidak seperti SQL yang bersifat baku untuk
hampir semua sistem basis data relasional). (Meski sesungguhnya hal terakhir ini tidak menjadi masalah
yang terlalu signifikan sepanjang pemrogram-pemrogram yang akan mengembangkan aplikasi di atas
MongoDB memahami dengan baik konsep dan implementasi “pemrograman berorientasi objek” dalam
bahasa pemrograman yang akan digunakan.) Selain itu, yang juga merupakan kekurangan MongoDB
(sekaligus juga mungkin merupakan kelebihannya karena dengan demikian ukuran berkas instalasi akan
menjadi sangat kecil dibandingkan kebanyakan sistem basis data relasional yang ada saat ini, seperti
Oracle, SQL Server, MySQL, dan sebagainya) adalah fitur administrasi (pengaturan hak akses basis data
oleh pengguna, pengaturan alokasi memori server, prosedur penyalinan dan pemulihan [backup and
recovery], pemantauan kinerja, dan sebagainya) yang tidak dijumpai di dalamnya karena semuanya
diserahkan pada aplikasi.
DAFTAR PUSTAKA
1.
2.
Alsultany, Yas, 2010. Database Management and Partitioning to Improve Database Processing
Performance. Journal of Database Marketing & Customer Strategy Management (2010) 17, 271 –
276. doi: 10.1057/dbm.2010.14; published online 11 October 2010.
Bezdek, James C., Richard J. Hathaway, Jacalyn M. Huband, Christopher Leckie, Ramamohanarao
Kotagiri, 2006. Approximate Clustering in Very Large Relational Data. International Journal of
Intelligent System Vol. 21, 817–841. Wiley Periodicals, Inc. Published online in Wiley InterScience.
www.interscience.wiley.com.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Basis data NoSQL. www.wikipedia.com. Diakses 3 Maret 2011.
Chodorow, Kristina, Michael Dirolf, 2010. MongoDB : The Definitive Guide. O‟Relly Media Inc.,
Sebastopol-USA.
Chodorow, Kristina, 2011. Scaling MongoDB. O‟Reily Media, Inc., Sebastopol.
Giroux, David Paul, 2009. DBCC CheckedDB for Very Large Databases. SQL Server Magazine.
www.sqlmag.com. Diakses 28 Februari 2011.
Kemne, Bettina, Gustavo Allonso, 2010. Database Replication : A Tale About Research Across
Communities. VLDB Concept from ETH Zurich and McGill University Montreal.
Nugroho, Adi, 2008. Algoritma dan Struktur Data Menggunakan Bahasa Java. Penerbit ANDI
OFFSET, Jogyakarta.
Nugroho, Adi, 2004. Konsep-konsep Pengembangan Sistem Basis Data. Penerbit INFORMATIKA,
Bandung.
Load
balancing
pada
sistem
basis
data
Microsoft
SQL
Server.
http://www.ristinet.com/index.php?ch=8&lang=&s=83dffd757167487d9410d5ef58eeee7e&n=215.
Load
balancing
pada
sistem
basis
data
terdistribusi
Oracle
11g.
http://blogs.oracle.com/stevenChan/entry/optimizing_r12_performance_via.
Plugge, Eelco, Peter Membrey, Tim Hawkins, 2010. The Definitive Guide to MongoDB: The NoSQL
Database for Cloud and Desktop Computing. Springer-Verlag, New York.
Situs perbandingan basis data-basis data NoSQL. http://kkovacs.eu/cassandra-vs-mongodb-vscouchdb-vs-redis.
Situs resmi MongoDB. www.mongodb.org.
Tiwari, Shashank, 2011. Proffesional NoSQL. John Wiley & Sons, Inc., Indianapolis.
Download