Ulasan tentang kekuatan dan kelemahan sistem manajemen Cloud Database saat ini.

Prinsip dasar sistem cloud adalah fokus pada banyak mesin, sekali pakai, dan dapat diganti. Ini memiliki konsekuensi langsung untuk teknik implementasi, dan oleh karena itu kemampuan sistem Database yang diimplementasikan di cloud.

Database tradisional dapat secara kasar diklasifikasikan sebagai paralel-pertama (misalnya, MongoDB atau Teradata) atau sistem tunggal terlebih dahulu (misalnya, PostgreSQL atau MySQL), seringkali dengan skala kemudian (misalnya, Redshift, Greenplum). Setiap kategori memiliki keterbatasan yang melekat pada desain intinya. Luasnya keterbatasan ini sebagian merupakan fungsi dari kedewasaan. Namun, untuk keputusan arsitektur inti tertentu, fitur tertentu mungkin tidak dapat didukung secara efisien.

Misalnya, Greenplum memiliki urutan, tetapi Redshift tidak, meskipun keduanya merupakan turunan PostgreSQL. BigQuery tidak memiliki urutan, tetapi Teradata memiliki (meskipun mereka tidak benar-benar berurutan, dalam pengertian tradisional). Baca juga tren teratas cloud computing

Kategori Cloud Database

Cloud Database termasuk dalam kategori yang sama, dengan bias yang berbeda terhadap parallel-pertama untuk sistem baru. Sifat dasar sistem cloud adalah paralelisme untuk skala dan kemampuan mesin yang dapat diganti.

Dalam kategori sistem tunggal-pertama, instansiasi cloud cenderung berfokus pada biaya terkelola, peningkatan, dan keandalan (RPO/RTO) dari produk mesin tunggal tradisional, seperti Heroku PostgreSQL, Amazon Aurora (PostgreSQL/MySQL), Google Cloud SQL (PostgreSQL/MySQL), dan Azure SQL (SQL Server).

Dalam kategori paralel, secara efektif ada dua sub kategori: kategori SQL/relasional (BigQuery, Snowflake, Redshift, Spark, Azure Synapse) dan kategori DHT/NoSQL (BigTable, Dynamo, Cassandra, Redis). Perbedaan ini kurang berkaitan dengan ada atau tidak adanya bahasa seperti SQL dan lebih berkaitan dengan apakah tata letak fisik data dalam sistem disetel untuk akses baris tunggal dengan hashing untuk pencarian cepat pada kunci, atau massal akses menggunakan sort-merge dan operasi filter.

Database relasional pertama yang paralel akan sering mengandalkan satu atau lebih sistem penyimpanan cloud asli. Sistem penyimpanan ini selalu dibangun secara paralel terlebih dahulu, dan mengekspos API get-object/put-object yang sangat terbatas; yang biasanya memungkinkan untuk mempartisi data, tetapi tidak mengizinkan akses acak berkinerja tinggi. Ini membatasi kemampuan database untuk mengimplementasikan struktur data persisten tingkat lanjut seperti indeks; atau, dalam banyak kasus, data yang dapat diubah.

Akibatnya, implementasi cloud yang menggunakan penyimpanan asli cenderung mengandalkan pembacaan dan penulisan sekuensial partisi mikro, bukan indeks. Cenderung ada tepat satu jalur akses fisik ke objek tingkat penyimpanan, berdasarkan nama objek. Indeks harus diimplementasikan secara eksternal ke penyimpanan yang mendasarinya, dan bahkan ketika ini dilakukan; API penyimpanan awan yang mendasarinya mungkin menyulitkan penggunaan alamat atau byte-offset secara praktis menjadi objek tingkat penyimpanan.

Kekuatan Cloud Database

Infrastruktur dikelola untuk Kalian. Di cloud, penerapan, keandalan, dan administrasi adalah masalah orang lain. Semua lapisan tumpukan mulai dari daya, instalasi perangkat lunak, dan perangkat keras hingga manajemen dan keamanan sistem operasi (dari pengerasan hingga deteksi intrusi) dikelola oleh vendor cloud.

Kenyamanan penawaran uji coba gratis vendor cloud untuk membuat Kalian siap dan menjalankan eksperimen awal dan kemudian dengan anggun meningkatkan skala besar jika diperlukan adalah sesuatu yang paling sulit dalam sistem lokal tradisional.

Manfaat lainnya adalah vendor cloud menawarkan banyak proses standar untuk diintegrasikan dengan produk SaaS pihak ketiga. Hasilnya adalah vendor cloud membuat infrastruktur menjadi masalah orang lain sehingga Kalian dapat fokus pada bisnis inti Kalian.

Efisiensi

Cloud hidup dengan memaksimalkan pemanfaatan sumber daya. Jauh lebih umum bagi sistem cloud untuk mengekspos kontrol pemanfaatan sumber daya ke aplikasi database daripada sistem non-cloud. Beban dapat dihaluskan, dipindahkan ke slot waktu dengan permintaan rendah, dan pekerjaan interaktif serta bisnis penting dapat diprioritaskan.

Tentu saja vendor cloud dapat memanfaatkan efisiensi pembelian dalam skala besar, pembagian beban, dan rasio pemanfaatan yang sangat tinggi. Argumen skala ini saja dapat membuat kasus untuk pindah ke cloud. Apalagi keuntungan menggunakan keahlian vendor untuk pengerasan dan deteksi intrusi.

Berkaitan erat dengan skala adalah kemampuan vendor cloud untuk menyediakan penyimpanan pasif dengan harga murah; yang membuatnya lebih mudah untuk menyimpan jendela data historis yang lebih lama; baik untuk alasan eksperimental atau analitis, atau untuk pencadangan atau audit; dan lebih hemat biaya untuk mengimplementasikan fitur seperti perjalanan waktu, dimana data dapat diperiksa dari perspektif sejarah.

Dan tentu saja, beban pemrosesan data yang berat dapat diselesaikan dengan penskalaan sementara menggunakan skala vendor cloud (dengan biaya yang ditanggung pengguna, tentu saja).

Ekonomi

Selain skala ekonomi dan efisiensi, mekanisme akuntansi vendor cloud cenderung memaparkan data biaya penyimpanan dan pemrosesan hingga ke tingkat kueri individual. Hal ini memungkinkan pengguna untuk membuat keputusan bisnis yang rasional tentang biaya-manfaat dari setiap bagian analisis yang diberikan; dan membuat keputusan pengoptimalan yang sesuai.

“Memang terkadang bisnis mungkin memutuskan lebih murah untuk menggunakan skala cloud menjadi lebih besar dan; “sederhana” dalam cara analisis terstruktur daripada menghabiskan waktu; dan energi mental, untuk membuat “analisis yang kuat” (analisis yang lebih murah dan mungkin lebih akurat)”.

Cloud

Kelemahan Cloud Database

Infrastruktur dikelola untuk Kalian. Cloud memiliki kumpulan domain kegagalan yang sangat berbeda dari, misalnya, mainframe seri-Z. Komputasi terdistribusi di cloud, yang merupakan substrat bersama (komputasi, penyimpanan; jaringan), tunduk pada lebih banyak gangguan, dan salah satunya dapat menyebabkan kegagalan interaktivitas atau kegagalan pekerjaan sementara. Bahkan manajemen otomatis oleh vendor cloud, pada kesempatan langka; dapat berdampak negatif pada pengalaman pelanggan dengan mengubah properti atau perilaku sistem.

Efisiensi

Sebagian besar Cloud Database masih belum matang dibandingkan dengan sistem lokal tradisional. Cloud Database tidak memiliki fitur produk yang lebih matang. Beberapa fitur mungkin tidak pernah diperkenalkan karena konsep platform yang sepenuhnya terdistribusi dan rawan kegagalan membuatnya tidak praktis.

Banyak sistem relasional paralel berbasis cloud memiliki efisiensi yang sangat kurang untuk mutasi database tertentu (operasi INSERT, UPDATE, DELETE); yang dapat menyebabkan masalah dalam kasus penggunaan tertentu.

Tentu saja latensi tambahan antara cloud dan sistem lokal atau sistem yang dihosting di cloud lain akan cenderung memaksa konsolidasi infrastruktur cloud. Pengguna cenderung dipaksa untuk memilih lokasi geografis dan penyedia terlebih dahulu; dan kemudian secara efektif terbatas pada layanan di dalam penyedia itu.

Ekonomi

Biaya cloud mengikuti kurva yang sangat berbeda dari penerapan di tempat: Sangat mudah untuk memperluas kapasitas. Sangat mudah sehingga pengendalian biaya menjadi lebih sulit. Di sisi lain, jika biaya dibatasi, maka pekerjaan interaktif yang diajukan setelah batas biaya tercapai dapat ditolak. Ini menambah lapisan kompleksitas yang perlu dipelajari oleh administrator Database tradisional untuk membuat penerapan yang sukses.

Dan, tentu saja, penguncian vendor sama lazimnya di cloud seperti di tempat lain. Migrasi antar cloud tidak lebih mudah daripada migrasi antar sistem lokal.

Ada begitu banyak penawaran untuk dipilih dan tidak ada satupun penawaran yang memiliki semua fitur. Langkah pertama yang paling penting adalah mengidentifikasi properti atau perilaku dasar dari semua alur kerja yang diperlukan; dan memastikan bahwa vendor cloud yang dipilih memiliki kemampuan untuk menyediakan semuanya—mungkin setiap perilaku dari produk yang berbeda; tetapi setidaknya terintegrasi dengan lemah, dari produk mereka. rangkaian. Jangan berharap melihat satu produk seperti Oracle atau Teradata yang melakukan “segalanya” untuk harganya.