Minggu lalu di CHAR(10) konferensi kami mengadakan lokakarya tentang "Database Cloud". Sederhananya:apa yang harus dilakukan ketika persyaratan kasus penggunaan melebihi sumber daya yang tersedia di server database.
Ini adalah topik utama dari seluruh konferensi, dan beberapa solusi telah diilustrasikan sepanjang hari. Tema umum adalah bahwa tidak ada solusi yang cocok untuk semua kasus penggunaan, dan bahwa setiap solusi disertai dengan biayanya; maka Anda harus memilih solusi yang dapat dijangkau oleh use case Anda.
Hal umum lainnya (walaupun tersirat) telah menjadi fokus pada solusi "tingkat tinggi", yaitu:menghubungkan beberapa server database pada tingkat yang lebih tinggi untuk meniru satu server dengan sumber daya yang lebih besar.
Keuntungan yang jelas adalah bahwa Anda tidak perlu mengubah kode PostgreSQL yang telah diteliti dengan baik; kelemahannya adalah menggunakan beberapa server database dengan garis waktu independennya, Anda kehilangan beberapa properti yang berguna. Dua contoh:hilangnya sebagian semantik transaksional menghasilkan konflik; pra-parsing setiap kueri di luar database memperkenalkan batasan pada kueri yang diterima.
Diskusinya cukup menarik, dan ketika Dimitri Fontaine menyebutkan tablespace jarak jauh, saya mulai bertanya-tanya seputar ide terkait tetapi berbeda, yaitu:apakah pendekatan tingkat rendah untuk masalah penyatuan sumber daya akan benar-benar tidak praktis. Sebelum saya dapat menguraikan detailnya, lokakarya berakhir, dan saya hanya dapat membuat sketsa ide untuk beberapa orang yang ada di sekitar papan tulis (di antaranya Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) bersama dengan dasar pertanyaan "apakah itu terlihat layak?" dan “apakah itu menyerupai sesuatu yang sudah Anda ketahui?”.
Sketsa singkat:tumpukan aplikasi dapat direpresentasikan dengan cara ini
(application) --> (connection) --> (db server) --> (resources)
dimana sumber daya yang digunakan oleh database meliputi penyimpanan, RAM dan CPU. Tujuannya adalah untuk memungkinkan aplikasi memerintahkan lebih banyak sumber daya untuk meningkatkan kapasitas dan kecepatan. Aplikasi “pintar” yang mengelola beberapa database dapat direpresentasikan sebagai
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
sementara solusi "pengumpulan koneksi" dapat direpresentasikan sebagai
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
dengan solusi "tingkat bawah" yang saya maksudkan seperti
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
yang mungkin menyerupai sesuatu yang familier, tetapi bukan itu yang saya usulkan di sini. Untuk menjelaskan perbedaannya, saya dapat meningkatkan detail dan menulis
(resources) = (virtual resources) --> (physical resources)
untuk mewakili fakta bahwa pada level terendah Anda dapat memiliki pemetaan non-sepele antara objek fisik dan virtual. Misalnya, penyimpanan SAN atau striping RAID dapat menyediakan disk virtual yang lebih besar dengan menggabungkan disk fisik yang lebih kecil. Kasus-kasus seperti itu dapat digambarkan sebagai
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Proposal saya adalah untuk mengumpulkan sumber daya di server database tingkat, sehingga kita dapat memiliki "virtualisasi" yang lebih efisien dengan menggunakan pengetahuan tentang kasus penggunaan khusus untuk setiap sumber daya (CPU, RAM, disk), dan pada saat yang sama kita dapat menghindari kesulitan dari paradigma transaksional. Gambarnya adalah:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Keuntungannya adalah kita tidak perlu mengelola semua kemungkinan kasus penggunaan untuk setiap sumber daya virtual; kita hanya perlu mengelola (dan mengoptimalkan) kasus penggunaan yang sebenarnya dibutuhkan oleh PostgreSQL. Misalnya:WAL harus tetap ditulis dalam penyimpanan lokal "tidak tervirtualisasi", bgwriter akan mengakses sumber daya lokal dan jarak jauh (RAM dan disk), dll.
Beberapa kata terakhir tentang keandalan. Untuk beroperasi dengan baik seluruh sistem membutuhkan setiap subsistem; kegagalan parsial tidak dikelola, karena arsitektur ini tidak berlebihan. Ini adalah sistem terdistribusi, tetapi tidak dibagikan. Jika arsitektur ini dapat memberikan skalabilitas yang murah dan sederhana melalui server database virtual yang secara fungsional setara dengan server fisik dengan sumber daya yang lebih besar, maka ketersediaan tinggi dapat diperoleh dengan cara standar dengan menyiapkan dua server virtual identik dalam konfigurasi Hot Standby.
Kualitas jaringan memiliki dampak besar pada kinerja secara keseluruhan; desain ini mungkin berguna hanya jika Anda memiliki serangkaian mesin di LAN yang sama, tidak hanya karena alasan kecepatan tetapi juga karena kegagalan jaringan sebenarnya merupakan kegagalan sistem. Meski dengan batasan-batasan ini, menurut saya memiliki opsi ini akan sangat berguna.
Ini masih sketsa, untuk digunakan sebagai referensi untuk diskusi lebih lanjut. Kemungkinan langkah selanjutnya:
- untuk membuat daftar rinci kasus penggunaan sumber daya
- untuk memutuskan teknologi mana yang paling membantu dalam setiap kasus penggunaan
- untuk memperkirakan kinerja/biaya pengembangan yang sebenarnya
