Skema-kurang / fleksibel + ACID Database?

Saya melihat penulisan ulang aplikasi VB berbasis lokal (terpasang secara lokal) (faktur + inventaris) sebagai aplikasi Clojure berbasis web untuk pelanggan perusahaan kecil. Saya bermaksud ini ditawarkan sebagai aplikasi SaaS untuk pelanggan dalam perdagangan serupa.

Saya melihat opsi basis data: Pilihan saya adalah RDBMS: Postgresql / MySQL. Saya mungkin meningkatkan hingga 400 pengguna di tahun pertama, dengan biasanya 20-40 tampilan halaman / per hari per pengguna - sebagian besar untuk transaksi bukan tampilan statis. Setiap tampilan akan melibatkan pengambilan data dan pembaruan data. Kepatuhan ACID diperlukan (atau jadi saya pikir). Jadi volume transaksi tidak besar.

Ini akan menjadi no-brainer untuk memilih salah satu dari ini berdasarkan preferensi saya, tetapi untuk persyaratan yang satu ini, yang saya percaya adalah khas dari aplikasi SaaS: Skema akan berubah ketika saya menambah lebih banyak pelanggan / pengguna dan untuk setiap pelanggan mengubah persyaratan bisnis (saya akan menawarkan fleksibilitas terbatas hanya untuk memulainya). Karena saya bukan ahli DB, berdasarkan apa yang dapat saya pikirkan dan baca, saya dapat mengatasinya dalam beberapa cara:

1. Memiliki desain skema RDBMS tradisional di MySQl / Postgresql dengan satu DB penyewa ganda. Dan tambahkan kolom "mengambang bebas" di setiap tabel untuk memungkinkan perubahan di masa mendatang karena saya menambahkan lebih banyak pelanggan atau perubahan untuk pelanggan yang sudah ada. Ini mungkin memiliki kerugian menyebarkan perubahan ke DB setiap kali perubahan kecil dibuat untuk Skema. Saya ingat pernah membaca bahwa dalam pembaruan skema Postgresql dapat dilakukan secara real time tanpa mengunci. Tetapi tidak yakin, seberapa menyakitkan atau seberapa praktis dalam kasus penggunaan ini. Dan juga, karena perubahan skema mungkin juga memperkenalkan perubahan SQL baru / kecil juga.
2. Memiliki RDBMS, tetapi rancang skema basis data secara fleksibel: dengan dekat dengan entitas-atribut-nilai atau hanya sebagai penyimpan nilai-kunci. (Hari Kerja, FriendFeed misalnya)
3. Simpan seluruh benda dalam memori sebagai objek dan simpan dalam file log secara berkala (mis. Edval, lmax)
4. Gunakan DB NoSQL seperti MongoDB atau Redis. Tetapi berdasarkan apa yang bisa saya kumpulkan, mereka tidak cocok untuk kasus penggunaan ini dan tidak sepenuhnya sesuai ACID.
5. Pergi untuk beberapa DBS NewSQL seperti VoltDb atau JustoneDb (berbasis cloud) yang mempertahankan perilaku yang sesuai dengan SQL dan ACID dan RDBMS "gen baru".
6. Saya melihat neo4j (graphdb), tetapi tidak yakin apakah itu cocok dengan case-use ini

Dalam kasus penggunaan saya, lebih dari skalabilitas atau komputasi terdistribusi, saya melihat cara yang lebih baik untuk mencapai "Fleksibilitas dalam Skema + ACID + beberapa Kinerja yang masuk akal". Sebagian besar artikel yang saya dapat temukan di internet berbicara tentang fleksibilitas dalam skema sebagai penyebab mengarah pada kinerja (dalam kasus DB NoSQL) dan skalabilitas sambil meninggalkan sisi ACID / Transaksi.

Apakah ini merupakan "salah satu atau" kasus transaksi 'Skema fleksibilitas vs ACID' atau Apakah ada jalan keluar yang lebih baik?

Pilihan 1

Ada beberapa alasan untuk ini, yang akan saya jelaskan di bawah ini. Pertama, inilah cara melakukannya.

• Gunakan pilihan platform RDBMS standar Anda.

• Siapkan skema Anda dengan beberapa bidang yang dapat dikonfigurasi pengguna, dan buat aplikasi Anda memfasilitasi konfigurasi berdasarkan basis per penyewa.

• Dari metadata per-penyewa, Anda dapat membuat tampilan per-penyewa atas data mereka , yang memiliki filter bawaan, dan kolom-kolom yang dinamai dari metadata Anda. Laporan apa pun yang diberikan juga dapat mewarisi metadata. Jika mereka ingin melakukan MI dari data maka berikan mereka ekstrak data transaksional, atau mungkin beberapa aplikasi SIM tambahan pada server yang berbeda jika mereka akan membayar untuk itu.

• Jangan mencoba memberikan lebih banyak penyesuaian daripada ini (yaitu tidak ada perubahan radikal pada skema) kecuali klien siap membayar untuk mesin virtual pribadi mereka sendiri dan mempertahankan bangunan kustom.

Alasan di balik ini adalah:

• Sistem basis data ini akan menangani jenis volume yang Anda gambarkan pada perangkat keras biasa. Anda tidak benar-benar memiliki jenis volume transaksi yang pantas untuk basis data NoSQL. Kecuali Anda memiliki alasan arsitektur lain untuk menginginkannya, tidak ada gunanya melakukan pendarahan.

• Mereka matang, teknologi yang dipahami dengan baik.

• Manajemen sistem, cadangan / pengembalian, replikasi, pelaporan dan pemulihan bencana semuanya diurutkan dengan baik pada platform RDBMS.

• Anda bisa mendapatkan perpustakaan klien termasuk JDBC untuk semua platform RDBMS utama.

• Tampilan dapat digunakan untuk kustomisasi per pengguna dan dihasilkan dari metadata aplikasi Anda.

• Ini jauh lebih efisien daripada bidang XML atau struktur EAV.

Dengan PostgreSQL Anda memiliki opsi untuk menggunakan basis data terpisah, skema atau tampilan terpisah untuk menangani multi-tenancy.

Menggunakan banyak basis data (dalam server basis data yang sama) membuat administrasi lebih kompleks karena setiap basis data harus dikelola secara individual. Oleh karena itu, ini hanya disarankan jika keamanan antara penyewa menjadi perhatian utama.

Skema terpisah menawarkan banyak fleksibilitas dan keamanan tetapi membuat peningkatan lebih kompleks karena harus diterapkan secara individual dan mungkin hanya diperlukan jika penyewa Anda menggunakan struktur tabel yang sama sekali berbeda; yang tidak mungkin jika mereka menggunakan aplikasi yang sama.

Tampilan memungkinkan penyewa untuk melihat bagian yang berbeda dari struktur tabel umum dan memungkinkan Anda untuk mengontrol tabel mana, kolom mana dan baris mana yang dapat mereka akses. Satu-satunya peringatan adalah bahwa aplikasi Anda harus memastikan hanya menggunakan tampilan tersebut dan bukan tabel dasar jika tidak ada potensi kebocoran data yang tidak disengaja antara penyewa karena cacat perangkat lunak.

Anda tidak benar-benar perlu membuat kolom sebelum persyaratan aplikasi. Kolom dapat ditambahkan ke tabel secara dinamis (tanpa dampak nyata pada pengguna) dan tampilan juga dapat diperbarui secara dinamis. Anda hanya perlu memikirkan urutan melakukan perubahan - yaitu. ubah tabel, lalu lihat kemudian kode aplikasi.

Satu-satunya masalah potensial Anda adalah jika Anda perlu menambahkan kolom baru yang perlu ditambahkan ke indeks yang ada atau memerlukan indeks baru. Saat itulah tabel dapat dikunci dari penggunaan saat indeks sedang dibangun - tetapi PostgreSQL mendukung kemampuan untuk membangun indeks secara bersamaan tanpa mengunci tabel. Ini berfungsi dengan baik kecuali jika indeks baru harus unik dan menemukan pelanggaran keunikan.

Anda mungkin tidak memerlukan database NoSQL karena mereka secara efektif menghapus skema dari database dan memerlukan aplikasi untuk mengelolanya. Itu tidak terdengar seperti volume Anda menuntut pengorbanan semacam itu.