7 fakta keras tentang revolusi NoSQL

Kata kunci NoSQL telah bermetastasis selama beberapa tahun. Kegembiraan tentang penyimpanan data yang cepat ini telah memabukkan, dan kami sama bersalahnya dengan siapa pun yang melihat daya tarik inovatif dari NoSQL. Namun bulan madu akan segera berakhir, dan inilah saatnya untuk mulai menyeimbangkan antusiasme kita dengan beberapa kebenaran yang bermata tajam.

Jangan salah paham. Kami masih menjalankan untuk mencoba eksperimen terbaru dalam membangun mekanisme sederhana untuk menyimpan data. Kami masih menemukan nilai yang dalam di MongoDB, CouchDB, Cassandra, Riak, dan standout NoSQL lainnya. Kami masih berencana membuang beberapa data paling tepercaya ke dalam tumpukan kode ini karena mereka tumbuh lebih baik dan lebih teruji dalam pertempuran setiap hari.

[Juga pada: NoSQL menonjol: Database baru untuk aplikasi baru | Tampilan pertama: Oracle NoSQL Database | Dapatkan intisari dari cerita utama setiap hari di buletin Harian. ]

Tapi kami mulai merasa lecet, karena sistem NoSQL jauh dari kesesuaian dan sering kali salah jalan. Pengembang terpintar mengetahui hal ini sejak awal. Mereka tidak membakar manual SQL dan mengirim nastygram ke tenaga penjualan vendor SQL mereka yang dulu setia. Tidak, pengembang NoSQL yang cerdas hanya mencatat bahwa NoSQL adalah singkatan dari "Not Only SQL." Jika massa salah menafsirkan akronim itu, itu masalah mereka.

Daftar keluhan ini, besar dan kecil, dengan demikian merupakan upaya untuk mendokumentasikan fakta ini dan untuk menjernihkan suasana. Ini dimaksudkan untuk meluruskan segalanya sekarang sehingga kami dapat melakukan pekerjaan yang lebih baik dengan memahami kompromi dan kompromi.

Kebenaran keras NoSQL No. 1: GABUNG berarti konsistensi

Salah satu keluhan pertama yang dimiliki orang tentang sistem SQL adalah biaya komputasi untuk mengeksekusi JOIN antara dua tabel. Idenya adalah menyimpan data di satu dan hanya satu tempat. Jika Anda menyimpan daftar pelanggan, Anda meletakkan alamat jalan mereka di satu tabel dan menggunakan ID pelanggan mereka di setiap tabel lainnya. Saat Anda menarik data, GABUNG menghubungkan ID dengan alamat dan semuanya tetap konsisten.

Masalahnya adalah bahwa JOIN bisa mahal, dan beberapa DBA telah membuat perintah JOIN kompleks yang mengejutkan pikiran, bahkan mengubah perangkat keras tercepat menjadi lumpur. Tidaklah mengherankan bahwa para pengembang NoSQL mengubah kurangnya JOIN mereka menjadi sebuah fitur: Mari kita simpan alamat pelanggan di tabel yang sama seperti yang lainnya! Cara NoSQL adalah menyimpan pasangan nilai kunci untuk setiap orang. Ketika saatnya tiba, Anda mengambil semuanya.

Sayangnya, orang yang ingin tabelnya konsisten masih membutuhkan GABUNG. Setelah Anda mulai menyimpan alamat pelanggan dengan semua hal lain tentang mereka, Anda sering kali mendapatkan banyak salinan dari alamat tersebut di setiap tabel. Dan bila Anda memiliki banyak salinan, Anda perlu memperbarui semuanya pada saat yang bersamaan. Kadang-kadang berhasil, tetapi jika tidak, NoSQL belum siap membantu transaksi.

Tunggu, Anda berkata, mengapa tidak memiliki tabel terpisah dengan informasi pelanggan? Dengan cara itu hanya akan ada satu catatan untuk diubah. Itu ide yang bagus, tapi sekarang Anda bisa menulis GABUNGAN itu sendiri dalam logika Anda sendiri.

Kebenaran keras NoSQL No. 2: Transaksi rumit

Katakanlah Anda OK untuk hidup tanpa GABUNG tabel karena Anda menginginkan kecepatan. Ini trade-off yang dapat diterima, dan terkadang SQL DBA mendenormalisasi tabel hanya karena alasan ini.

Masalahnya adalah NoSQL menyulitkan untuk menjaga konsistensi berbagai entri. Seringkali tidak ada transaksi untuk memastikan bahwa perubahan pada beberapa tabel dilakukan secara bersamaan. Untuk itu, Anda sendirian, dan crash dapat memastikan bahwa tabel menjadi tidak konsisten.

Implementasi NoSQL yang paling awal mengacungkan hidung mereka pada transaksi ini. Mereka akan menawarkan daftar data yang konsisten, kecuali jika sebenarnya tidak. Dengan kata lain, mereka mengejar data dengan nilai terendah di mana kesalahan tidak akan membuat perbedaan materi.

Sekarang beberapa implementasi NoSQL menawarkan sesuatu yang mendekati transaksi. Produk NoSQL Oracle, misalnya, menawarkan kontrol transaksional atas data yang ditulis ke satu node dan memungkinkan Anda memilih jumlah konsistensi yang fleksibel di beberapa node. Jika Anda menginginkan konsistensi yang sempurna, Anda harus menunggu setiap penulisan menjangkau semua node. Beberapa penyimpanan data NoSQL lainnya sedang bereksperimen dengan menambahkan lebih banyak struktur dan perlindungan seperti ini.

NoSQL keras kebenaran No. 3: Basis data bisa pintar

Banyak programmer NoSQL suka membual tentang bagaimana kode ringan dan mekanisme sederhana mereka bekerja dengan sangat cepat. Mereka biasanya benar ketika tugasnya sesederhana bagian dalam NoSQL, tetapi itu berubah ketika masalahnya semakin sulit.

Pertimbangkan tantangan lama dari JOIN. Setelah programmer NoSQL mulai membuat perintah JOIN mereka sendiri dalam logika mereka sendiri, mereka mulai mencoba melakukan ini secara efisien. Pengembang SQL telah menghabiskan beberapa dekade mengembangkan mesin canggih untuk menangani perintah JOIN seefisien mungkin. Seorang pengembang SQL mengatakan kepada saya bahwa dia mencoba untuk menyinkronkan kodenya dengan hard disk yang berputar sehingga dia akan meminta data hanya ketika head berada tepat di atas tempat yang tepat. Ini mungkin tampak ekstrem, tetapi pengembang SQL telah mengerjakan peretasan serupa selama beberapa dekade.

Tidak ada keraguan bahwa programmer menghabiskan waktu berhari-hari mencoba menyusun kueri SQL mereka untuk memanfaatkan semua kecerdasan laten ini. Mungkin tidak mudah untuk mengetuknya, tetapi ketika programmer mengetahuinya, database benar-benar dapat bernyanyi.

Bahasa kueri yang canggih seperti SQL selalu berpotensi untuk mengungguli bahasa kueri yang tidak canggih seperti yang ditemukan di NoSQL. Ini mungkin tidak masalah dengan hasil yang sederhana, tetapi ketika tindakan menjadi kompleks, SQL dijalankan pada mesin tepat di sebelah data. Ini memiliki sedikit overhead mengambil data dan melakukan pekerjaan. Server NoSQL biasanya harus mengirimkan data ke tempat tujuan.

NoSQL hard truth No. 4: Terlalu banyak model akses

Secara teori, SQL seharusnya menjadi bahasa standar. Jika Anda menggunakan SQL untuk satu database, Anda harus dapat menjalankan kueri yang sama di versi lain yang sesuai. Klaim ini mungkin berfungsi dengan beberapa kueri sederhana, tetapi setiap DBA tahu bahwa perlu waktu bertahun-tahun untuk mempelajari keistimewaan SQL untuk versi berbeda dari database yang sama. Kata kunci ditentukan ulang, dan kueri yang bekerja pada satu versi tidak akan berfungsi dengan versi lainnya.

NoSQL bahkan lebih misterius. Ini seperti Menara Babel. Sejak awal, pengembang NoSQL telah mencoba membayangkan bahasa terbaik, tetapi mereka memiliki imajinasi yang sangat berbeda. Sarang eksperimen ini bagus - sampai Anda mencoba beralih antar alat. Kueri untuk CouchDB dinyatakan sebagai sepasang fungsi JavaScript untuk pemetaan dan pengurangan. Versi awal Cassandra menggunakan API mentah tingkat rendah yang disebut Hemat; versi yang lebih baru menawarkan CQL, bahasa kueri seperti SQL yang harus diurai dan dipahami oleh server. Masing-masing berbeda dengan caranya sendiri.

Setiap alat tidak hanya memiliki keistimewaannya sendiri, tetapi juga memiliki filosofi dan cara yang sama sekali berbeda untuk mengekspresikannya. Tidak ada cara mudah untuk beralih di antara penyimpanan data dan Anda sering ditinggalkan menulis banyak kode perekat hanya untuk memberi diri Anda pilihan untuk beralih di masa depan. Ini mungkin tidak terlalu sulit saat Anda memasukkan pasangan kunci dan nilai ke dalam sistem, tetapi ini dapat semakin memperburuk kerumitan yang Anda perkenalkan.

Kebenaran keras NoSQL No. 5: Fleksibilitas skema adalah masalah yang menunggu untuk terjadi

Salah satu ide hebat dari model NoSQL adalah tidak membutuhkan skema. Dengan kata lain, programmer tidak perlu memutuskan sebelumnya kolom mana yang akan tersedia untuk setiap baris dalam tabel. Satu entri mungkin memiliki 20 string yang dilampirkan padanya, entri lain mungkin memiliki 12 bilangan bulat, dan entri lainnya mungkin benar-benar kosong. Pemrogram dapat membuat keputusan kapan pun mereka perlu menyimpan sesuatu. Mereka tidak perlu meminta izin dari DBA, dan tidak perlu mengisi semua dokumen untuk menambahkan kolom baru.

Semua kebebasan itu terdengar memabukkan, dan di tangan kanan itu bisa mempercepat perkembangan. Tetapi apakah itu benar-benar ide yang bagus untuk database yang mungkin hidup melalui tiga tim pengembang? Apakah itu bahkan bisa diterapkan untuk database yang mungkin bertahan lebih dari enam bulan?

Dengan kata lain, para pengembang mungkin menginginkan kebebasan untuk memasukkan pasangan lama ke dalam database, tetapi apakah Anda ingin menjadi pengembang kelima setelah empat memilih kunci mereka sendiri? Sangat mudah untuk membayangkan berbagai representasi "ulang tahun", dengan setiap pengembang memilih representasi mereka sendiri sebagai kunci saat menambahkan ulang tahun pengguna ke entri. Sebuah tim pengembang mungkin membayangkan hampir semua hal: "bday", "b-day", "birthday".

Struktur NoSQL tidak menawarkan dukungan untuk membatasi masalah ini karena itu berarti menata ulang skema. Itu tidak ingin kasar pada lembut pengembang yang benar-benar keren. Sebuah skema akan menghalangi.

Faktanya adalah menambahkan kolom ke tabel bukanlah masalah besar, dan disiplin tersebut mungkin benar-benar baik untuk pengembang. Sama seperti membantu memaksa pengembang untuk menunjuk tipe variabel, ini juga membantu untuk memaksa pengembang untuk menunjuk tipe data yang dilampirkan ke kolom. Ya, DBA dapat memaksa pengembang untuk mengisi formulir dalam rangkap tiga sebelum melampirkan kolom tersebut, tetapi tidak seburuk menangani setengah lusin kunci berbeda yang dibuat dengan cepat oleh seorang programmer.

Kebenaran keras NoSQL No. 6: Tidak ada tambahan

Katakanlah Anda tidak menginginkan semua data di semua baris, dan Anda menginginkan jumlah dari satu kolom. Pengguna SQL dapat mengeksekusi kueri dengan operasi SUM dan mengirim satu - hanya satu - nomor kembali kepada Anda.

Pengguna NoSQL mendapatkan semua data yang dikirimkan kembali kepada mereka dan kemudian dapat melakukan penambahan sendiri. Penambahan bukan masalah karena membutuhkan jumlah waktu yang sama untuk menjumlahkan angka di mesin mana pun. Namun, pengiriman data berjalan lambat, dan bandwidth yang dibutuhkan untuk mengirim semua data itu bisa mahal.

Ada beberapa tambahan dalam database NoSQL. Jika Anda ingin melakukan apa pun selain menyimpan dan mengambil data, Anda mungkin akan melakukannya sendiri. Dalam banyak kasus, Anda akan melakukannya di komputer lain dengan salinan data yang lengkap. Masalah sebenarnya adalah seringkali berguna untuk melakukan semua komputasi pada mesin yang menyimpan data karena pengiriman data membutuhkan waktu. Tapi sulit untukmu.

Solusi NoSQL sedang bermunculan. Struktur kueri Map and Reduce dari MongoDB memberi Anda struktur JavaScript arbitrer untuk meringkas data. Hadoop adalah mekanisme yang kuat untuk mendistribusikan komputasi ke seluruh tumpukan mesin yang juga menyimpan data. Ini adalah struktur yang berkembang pesat yang menawarkan alat yang meningkat pesat untuk membangun analisis yang canggih. Sangat keren, tapi masih baru. Dan secara teknis Hadoop adalah kata kunci yang sama sekali berbeda dari NoSQL, meskipun perbedaan di antara mereka semakin memudar.

NoSQL hard truth No. 7: Lebih sedikit alat

Tentu, Anda bisa mendapatkan tumpukan NoSQL Anda dan berjalan di server Anda. Tentu, Anda dapat menulis kode khusus Anda sendiri untuk mendorong dan menarik data Anda dari tumpukan. Tetapi bagaimana jika Anda ingin berbuat lebih banyak? Bagaimana jika Anda ingin membeli salah satu dari paket laporan mewah itu? Atau paket grafik? Atau untuk mengunduh beberapa alat sumber terbuka untuk membuat bagan?

Maaf, sebagian besar alat ditulis untuk database SQL. Jika Anda ingin membuat laporan, membuat grafik, atau melakukan sesuatu dengan semua data di tumpukan NoSQL, Anda harus mulai membuat kode. Alat standar siap untuk mengambil data dari Oracle, Microsoft SQL, MySQL, dan Postgres. Data Anda ada di NoSQL? Mereka sedang mengerjakannya.

Dan mereka akan mengerjakannya sebentar. Bahkan jika mereka melewati semua rintangan untuk bangun dan menjalankan salah satu database NoSQL, mereka harus memulai dari awal lagi untuk menangani sistem berikutnya. Ada lebih dari 20 pilihan NoSQL yang berbeda, yang kesemuanya memiliki filosofi dan cara mereka sendiri dalam bekerja dengan data. Cukup sulit bagi pembuat alat untuk mendukung keistimewaan dan ketidakkonsistenan dalam SQL, tetapi bahkan lebih rumit lagi untuk membuat alat bekerja dengan setiap pendekatan NoSQL.

Ini adalah masalah yang perlahan akan hilang. Pengembang dapat merasakan kegembiraan di NoSQL, dan mereka akan memodifikasi alat mereka untuk bekerja dengan sistem ini, tetapi itu akan memakan waktu. Mungkin mereka akan mulai di MongoDB, yang tidak akan membantu Anda karena Anda menjalankan Cassandra. Standar membantu dalam situasi seperti ini, dan NoSQL tidak menyukai standar.

Singkatnya, kekurangan NoSQL

Semua kekurangan NoSQL ini dapat direduksi menjadi satu pernyataan sederhana: NoSQL membuang fungsionalitas untuk kecepatan. Jika Anda tidak memerlukan fungsinya, Anda akan baik-baik saja, tetapi jika Anda membutuhkannya di masa mendatang, Anda akan menyesal.

Revolusi adalah endemik budaya teknologi. Sebuah kelompok baru datang dan bertanya-tanya mengapa generasi terakhir membangun sesuatu yang begitu kompleks, dan mereka berangkat untuk menghancurkan institusi lama. Setelah beberapa saat, mereka mulai menyadari mengapa semua institusi lama begitu kompleks, dan mereka mulai menerapkan fitur-fiturnya sekali lagi.

Kami melihat ini di dunia NoSQL, karena beberapa proyek mulai menambahkan kembali hal-hal yang terlihat seperti transaksi, skema, dan standar. Inilah sifat kemajuan. Kami meruntuhkan segalanya hanya untuk membangunnya kembali. NoSQL selesai dengan fase pertama revolusi dan sekarang saatnya untuk revolusi kedua. Raja telah meninggal. Panjang umur raja.

Artikel terkait

  • Keunggulan NoSQL: Database baru untuk aplikasi baru
  • Tampilan pertama: Oracle NoSQL Database
  • Meregangkan NoSQL: MongoDB sedang ditinjau
  • 10 tip kinerja penting untuk MySQL
  • 10 alat MySQL penting untuk admin
  • Kuasai MySQL di cloud Amazon
  • Waktu untuk standar NoSQL sekarang

Kisah ini, "7 kebenaran pahit tentang revolusi NoSQL," awalnya diterbitkan di .com. Ikuti perkembangan terbaru dalam manajemen data di .com. Untuk perkembangan terbaru dalam berita teknologi bisnis, ikuti .com di Twitter.