Sering diulang bahwa masalah Big Data adalah bahwa database relasional tidak dapat skala untuk memproses volume besar data yang sekarang sedang dibuat.
Tapi apa batasan skalabilitas yang tidak terikat oleh solusi Big Data seperti Hadoop? Mengapa Oracle RAC atau MySQL sharding atau MPP RDBMS seperti Teradata (dll) tidak dapat mencapai hal ini?
Saya tertarik pada batasan teknis - Saya sadar bahwa biaya finansial pengelompokan RDBMS dapat menjadi penghalang.
Jawaban:
MS baru saja berbicara teknologi di Belanda di mana mereka membahas beberapa hal ini. Dimulai perlahan, tetapi masuk ke daging Hadoop sekitar 20 menit.
Intinya adalah bahwa "itu tergantung". Jika Anda memiliki pengaturan yang masuk akal, (setidaknya agak) mudah mempartisi set data yang (setidaknya agak) homogen, itu harus cukup mudah untuk skala ke volume data tinggi dengan RDBMS, tergantung pada apa yang Anda lakukan .
Hadoop dan MR tampaknya lebih diarahkan pada situasi di mana Anda dipaksa untuk memindai data terdistribusi besar, terutama ketika data tersebut tidak selalu homogen atau terstruktur seperti yang kami temukan di dunia RDBMS.
Batasan apa yang tidak terikat dengan solusi Big Data? Bagi saya, batasan terbesar yang mereka tidak terikat adalah harus membuat skema yang kaku sebelumnya. Dengan solusi Big Data, Anda memasukkan sejumlah besar data ke dalam "kotak" sekarang, dan menambahkan logika ke pertanyaan Anda nanti untuk menangani kurangnya homogenitas data. Dari sudut pandang pengembang, tradeoff adalah kemudahan implementasi dan fleksibilitas di ujung depan proyek, dibandingkan kompleksitas dalam kueri dan konsistensi data yang kurang langsung.
Perintis dan peneliti basis data Michael Stonebraker ikut menulis makalah yang membahas keterbatasan arsitektur basis data tradisional. Secara umum, mereka ditingkatkan dengan perangkat keras yang lebih mahal, tetapi mengalami kesulitan meningkatkan dengan perangkat keras komoditas yang lebih banyak secara paralel, dan dibatasi oleh arsitektur perangkat lunak lama yang dirancang untuk era yang lebih tua. Dia berpendapat bahwa era BigData membutuhkan beberapa arsitektur basis data baru yang memanfaatkan infrastruktur modern dan mengoptimalkan untuk beban kerja tertentu. Contohnya adalah proyek C-store, yang mengarah ke database komersial Vertica Systems, dan proyek H-store yang mengarah ke VoltDB, database SQL OLTP dalam-memori yang dirancang untuk beban kerja BigData berkecepatan tinggi. (Pengungkapan penuh, saya bekerja untuk VoltDB).
Anda mungkin menemukan webinar ini menarik pada topik ini. Ini menanggapi beberapa mitos yang muncul dengan keberhasilan database NoSQL. Pada dasarnya, ia berpendapat bahwa SQL bukan masalah, tidak perlu menyerah fitur database tradisional seperti konsistensi untuk mendapatkan kinerja.
Tidak sepenuhnya benar bahwa RDBMS tidak dapat mengukur. Namun, kebenaran parsial dalam pernyataan itu tergantung pada arsitektur. Dalam daftar yang Anda berikan, Oracle RAC berbeda dari yang lain (MySQL Sharded dan Teradata). Perbedaan utama adalah arsitektur disk bersama vs apa-apa.
Arsitektur disk bersama seperti Oracle RAC mengalami penskalaan karena pada titik tertentu semua mesin yang berjalan harus melakukan sinkronisasi pada beberapa bagian data. Untuk mis global palungan kunci adalah pembunuh. Anda dapat terus menyesuaikannya sampai batas tertentu, tetapi pada akhirnya Anda akan menabrak dinding. Jika Anda tidak dapat dengan mudah menambahkan mesin, Anda harus memiliki lebih sedikit tetapi mesin yang sangat kuat yang dapat membakar saku Anda. Dalam hal arsitektur apa-apa yang dibagikan (atau data yang dibagikan), setiap mesin memiliki kepemilikan atas beberapa data. Itu tidak perlu disinkronkan dengan mahcines lain jika ingin memperbarui beberapa data.
Kemudian muncul jenis database NoSQL. Saya akan memperlakukan mereka sebagai bagian dari basis data RDBMS tradisional. Tidak semua aplikasi di dunia ini membutuhkan semua fungsionalitas yang ditawarkan oleh RDBMS. Jika saya ingin menggunakan database sebagai cache, saya tidak akan peduli tentang daya tahan. Mungkin dalam beberapa kasus saya juga tidak akan peduli dengan konsistensi. Jika semua pencarian data saya didasarkan pada kunci, saya tidak perlu dukungan untuk kueri rentang. Saya mungkin tidak perlu indeks sekunder. Saya tidak memerlukan seluruh pemrosesan kueri / optimisasi lapisan yang dimiliki semua database tradisional.