Akhir-akhir ini istilah NoSQL (e.g. MongoDB) semakin jamak ditelinga, terutama pada pembahasan mengenai data yang besar (Big Data). Pertanyaan/diskusi yang paling sering muncul saat pertama kali mempelajari topik ini adalah:
- Apakah NoSQL adalah pengganti (lebih baik dari) database relational (e.g. MySQL) ?
- Apakah database relasional benar² tidak bisa digunakan saat ukuran datanya besar ?
- lalu apa kelebihan & kekurangan masing² ? ….
Artikel ini berusaha untuk menjawab pertanyaan² ini.
Mari kita mulai dengan definisi umum/penjelasan sederhana (non-formal) apa yang dimaksud dengan database relasional & NoSQL.
- Database relasional adalah koleksi data terstruktur yang disajikan lewat tabel², dimana tabel² tersebut dapat saling berhubungan (relasi). Tipe ini adalah bentuk basis data yang konvensional. Saat seseorang menyebut kata database, kemungkinan besar orang umum akan membayangkan database relasional (sekumpulan tabel²). contohnya MySQL, PostGreSQL, SqlLite, Microsoft Sql Server, dll. RDBMS (Relasional Database Management System) fokus pada konsep ACID: 1. Atomicity: Suatu proses selesai secara menyeluruh/tidak. 2. Consistency: Semua proses (transaction) yang terjadi di database harus memiliki state yang jelas. Setiap data yang disimpan harus memenuhi semua constraint, Cascades, dan triggers. 3. Isolation: Sebuah proses tidak boleh mempengaruhi proses lain. 4. Durability: Proses yang telah selesai harus bersifat permanen, walau aplikasinya di restart.
- Sedangkan NoSQL adalah tipe penyimpanan data selain yang berwujud tabular (tabel²), NoSQL tidak mengikuti prinsip (ACID) RDBMS sepenuhnya. Lalu kalau bukan ACID, apakah prinsip utama NoSQL ? NoSQL, menurut Eric Brewer menganut prinsip BASE: 1. Basic Availability: Setiap request sekedar mendapat garansi “response”: Sukses/Gagal. 2. Soft State: State NoSQL bisa berubah secara dinamis tanpa input manual untuk meyakinkan eventual consistency. 3. Eventual Consistency: Untuk “sementara” waktu NoSQL mungkin tidak konsisten (Akan diabahas kemudian maksud & contohnya). NoSQL bukan berarti “No SQL” atau “bukan SQL”/tidak mendukung bahasa Query, tapi “Not-Only SQL”. Masudnya database NoSQL tetap memiliki (support) ‘semacam’ bahasa Query, namun dalam bentuk (terminology yang berbeda). Beberapa literature bahkan tidak menggolongkan NoSQL sebagai suatu bentuk database. NoSQL bisa berupa Document (e.g. MongoDB), Key-Value (e.g. CouchDB), Graph (e.g. Neo4J), dsb.
Berikut beberapa perbedaan terminologi dan padanannya:
Sejarah ?
Banyak yang tidak menyukai pelajaran sejarah, namun sebagian orang mungkin tertarik sejarah awal lahirnya teknologi NoSQL. Ada beberapa istilah yang muncul pada tahun 2003-2006 ketika Google terkendala dengan data yang semakin membesar. Istilah² yang dijelaskan dalam artikel ilmiah ini terkait dengan perkembangan NoSQL saat ini.
Artikel/paper² tersebut kemudian memicu perkembangan beberapa project Open Source untuk data besar:
- Lucene: Java-based indexing dan search engine,
- Hadoop: Untuk Reliable (terpercaya), scalable (Untuk data besar), distributed computing (data yang tidak terpusat),
- Cassandra: Scalable, multi-master database with no single point of failure,
- ZooKeeper: High performance coordination service for distributed applications,
- Pig: High level dataflow language and execution framework for parallel computation.
Bilamana kita membutuhkan NoSQL (e.g. MongoDB) ketimbang database relasional (e.g. MySQL) dan sebaliknya ?
Pada saat apakah penggunaan NoSQL lebih cocok ketimbang database relasional ?
- Saat kita membutuhkan penyimpanan data yang “relatif” besar, namun terdapat keterbatasan resources (komputer/server). Mengapa saya tambahkan syarat “keterbatasan resources”? Karena sebenarnya relational database scalable untuk data besar bahkan untuk skala >PetaByte (e.g. Facebook menggunakan MySQL). Namun demikian butuh resources yang sangat besar untuk membuat database relasional memiliki performa yang baik bila datanya besar.
- Data tidak terstruktur (Misal Dokumen) atau biasa disebut sebagai Schemaless Data Representation. Bayangkan data yang masuk ke database terkadang hanya memiliki 4 kolom, tapi dilain waktu memiliki jumlah kolom yang berbeda lagi. Di Database relasional kejadian seperti ini akan memaksa kita mengubah struktur DB (schema) yang biasanya sangat fatal, terutama apabila datanya besar. Perubahan schema adalah bencana besar bagi sistem IT. Karena aplikasi harus direvisi mengikuti perubahan tersebut. Pada terminologi Big Data, ini terkait dengan “Variety”, yaitu semakin beragamnya tipe/struktur/format data yang masuk ke database.
- NoSQL (MongoDB) sangat cocok dengan aplikasi yang berorientasi objek. Dengan tidak adanya Join di NoSQL dan query yang rumit, NoSQL terkenal mempercepat para developer dalam membangun sebuah aplikasi.
- NoSQL sangat cocok bila aplikasi/system membutuhkan proses Write/Insertdalam jumlah yang sangat besar dan dalam waktu yang singkat. Dikaitkan dengan terminology di Big Data, NoSQL sangat cocok jika sistem kita memiliki Velocity data yang besar.
- Data anda mengandung informasi lokasi (e.g. Latitude/Longitude).
- Data complexity – data disimpan (& manage) tersebar di berbagai lokasi (data centres) yang berbeda (distributed).
- Berikut beberapa contoh aplikasi/Web besar/terkenal yang menggunakan MongoDB sebagai gambaran untuk aplikasi seperti apakah ia cocok untuk digunakan: FourSquare, SourceForge, CraigList, BitLy, Forbes, Bosch, dll.
Bilamana NoSQL secara umum kurang cocok untuk digunakan:
- Saat data yang diinput memiliki nilai yang sangat berharga (misal transaksi pemabayaran/transfer uang). NoSQL cepat dalam melakukan input namun tradeoff-nya ia tidak se-reliable tipe database lain.
- Analytic: walau memiliki implementasi map reduce-nya sendiri, NoSQL bukan pengganti Hadoop atau analytic engine lainnya. Ia sifatnya komplementari (membantu) analytic engine.
- Multi-Object Transactions: NoSQL (MongoDB) tidak mendukung input beberapa hal ke satu atau lebih “table”. Misal, MongoDB hanya support untuk penyimpanan ke sebuah dokumen.
- Complex Query: Jika aplikasi yang dibangun membutuhkan query yang rumit (complex), biasanya NoSQL kurang cocok. Walau NoSQL memiliki querynya sendiri, namun lebih terbatas ketimbang database konvensional.
- ‘Nature’ dari datanya memang relasional (A==>nB, B==>nA).
Beberapa catatan penting lain :
- NoSQL (e.g. MongoDB) bukanlah pengganti analytic engine seperti hadoop. (Penting untuk ditekankan 2x :) )
- NoSQL “umumnya” memerlukan memory lebih besar (beware).
- Record yang dihapus di collection (noSQL) tidak langsung mengurangi ukuran file (Penjelasan lebih Lanjut).
- Diagram berikut ini menjelaskan lebih detail tentang berbagai tipe database yang ada saat ini:
Berbagai jenis Database. Sumber Gambar: https://www.scalablepath.com/blog/the-future-of-data-stores-and-newsql/
Kesimpulan:
- NoSQL dan SQL database memiliki +/- masing².
- Keduanya saling melengkapi dan bukannya menggantikan.
- NoSQL lebih cocok untuk data yang memiliki volume & velocity besar serta variety yang beragam.
- NoSQL secara umum bukanlah analytic engine seperti Hadoop.
- Perpaduan penggunaan database NoSQL dan SQL yang tepat tidak hanya akan meningkatkan performa, namun juga meng-optimalkan biaya (cost) infrastruktur.
FAQ:
1. Mengapa NoSQL tidak disarankan untuk transaksi berharga (Misal perbankan) ? [toggle] Bisa, tapi sebaiknya untuk data yang tidak crucial (Selain transaksi dengan nilai besar). Mengapa ? NoSQL (misal MongoDB) cepat, karena mengorbankan feature yg biasanya ada di database SQL. MongoDB hanya ACID compliance pada level document:
Setiap update pada sebuah dokumen:
Setiap update pada sebuah dokumen:
- Atomic: Selesai secara menyeluruh/tidak.
- Consistent: Tidak ada user yang akan melihat data yang ter-update sebagian.
- Isolated: Tidak akan ada user yang mendapatkan data yg noisy/dirty.
- Durable: Nah ini agak tricky kalau di NoSQL, tapi masih doable.
Tapi MongoDB tidak mendukung transactions — yaitu multiple update yg bisa di cancel (rolled back) dan ACID compliance.
Untuk meningkatkan performa insert, MongoDB tidak langsung write ke disk, ia simpan dulu di (virtual) memory (hence butuh more memory). Bayangkan user insert/update data, lalu ada pesan “insert/update success” , tapi kemudian ada failure (misal mati listrik/meledak smile emoticon ). maka data yang baru saja dimasukkan sebenarnya belum tersimpan di disk (hence durable issue). Tapi tentu saja ada NoSQL yg respect ACID transactions (misal CouchDB). Semua ada +/-nya masing². Jadi sebagai developer harus benar² memperhatikan kebutuhan.
All in All, trend teknologi Database kalau “menurut saya” beralih dari general purpose ke adhoc (specific).
Nantikan tulisan terkait berikutnya tentang* (tergantung waktu luang :) ):
- Contoh kasus development SQL VS NoSQL,
- Pendahuluan/dasar² MongoDB, CouchDB, HBase, Hypertable, Cassandra, Redis, & Berkeley DB, serta
- Pembahasan lanjut tentang MongoDB.
Triggers:
- Tahukah anda bahwa di MongoDB kita bisa melakukan query sesuai dengan kebutuhan (seperti RDBMS ), tapi tidak semua NoSQL support query dinamis seperti ini ?
- Tahukah anda bahwa ada NoSQL yang Querynya ditetapkan di awal, tapi bentuk datanya boleh dinamis ? [aneh ya ? :) ]
- Tidak ada teknologi yang sempurna, tahukah anda masing² kelemahan & kelebihan teknologi NoSQL (Cassandra, CouchDB, MongoDB, HBase, MemCache, Neo4j, & Redis) ? …
Temukan jawabannya di tulisan² saya berikutnya ya … ;)
Tidak ada komentar:
Posting Komentar
Relevant & Respectful Comments Only.