Şema olmadan / esnek + ASID Veritabanı?

Küçük kurumsal müşteriler için web tabanlı Clojure uygulaması olarak bir VB tabanlı şirket içi (yerel olarak yüklü) uygulamayı (faturalama + envanter) yeniden yazmayı düşünüyorum. Bunu benzer ticaretteki müşteriler için bir SaaS uygulaması olarak sunmayı planlıyorum.

Veritabanı seçeneklerine bakıyordum: Seçimim RDBMS: Postgresql / MySQL idi. İlk yıl 400 kullanıcıya kadar ölçeklendirebilirim, genellikle kullanıcı başına günde 20-40 sayfa görüntüleme / çoğunlukla statik görüntüleme olmayan işlemler için. Her görünüm, veri alma ve güncelleme verilerini içerecektir. ASİT uyumluluğu gereklidir (ya da bence). Yani işlem hacmi çok büyük değil.

Bunlardan birini tercihime göre seçmek bir beyinsiz olurdu, ancak SaaS uygulamasının tipik olduğuna inandığım bu bir gereksinim için: Daha fazla müşteri / kullanıcı ve her müşterinin ekledikçe Şema değişecek değişen iş gereksinimi (sadece başlangıç ​​için sınırlı esneklik sunacağım). Ben bir DB uzmanı değilim, ne düşünebilir ve okudum dayalı, ben bunu çeşitli şekillerde başa çıkabilirim:

1. Birden çok kiracıyı barındıran tek bir DB ile MySQl / Postgresql'de geleneksel bir RDBMS şema tasarımına sahip olun. Ve daha fazla müşteri veya mevcut bir müşteri için değişiklik eklediğimde, gelecekteki değişikliklere izin vermek için her tabloya yeterli "serbest kayan" sütun ekleyin. Bu, Şemada her küçük değişiklik yapıldığında değişiklikleri DB'ye yaymanın dezavantajı olabilir. Postgresql şema güncellemelerinin kilitlenmeden gerçek zamanlı yapılabileceğini okuduğumu hatırlıyorum. Ancak emin değilim, bu kullanım durumunda ne kadar acı verici veya ne kadar pratiktir. Ayrıca şema değişiklikleri yeni / küçük SQL değişiklikleri de getirebilir.
2. RDBMS'ye sahip olun, ancak veritabanı şemasını esnek bir şekilde tasarlayın: varlık-öznitelik değerine yakın veya yalnızca bir anahtar / değer deposu olarak. (Örneğin Workday, FriendFeed)
3. Her şeyi nesneler olarak belleğe alın ve bunları günlük dosyalarında düzenli olarak saklayın. (Örneğin, edval, lmax)
4. MongoDB veya Redis gibi bir NoSQL DB için gidin. Ama toplayabildiğim şeye dayanarak, bu kullanım durumu için uygun değiller ve tamamen ASİT uyumlu değiller.
5. SQL ve ACID uyumlu davranışları koruyan ve "yeni nesil" RDBMS olan VoltDb veya JustoneDb (bulut tabanlı) gibi bazı NewSQL Dbs için gidin.
6. Neo4j'ye (graphdb) baktım, ancak bunun bu kullanım durumuna uygun olup olmadığından emin değilim

Benim kullanım durumumda, ölçeklenebilirlik veya dağıtılmış bilgi işlemden daha fazla, "Şema + ACID + esneklik bazı makul Performans" elde etmek için daha iyi bir yol arıyorum. Net üzerinde bulabildiğim makalelerin çoğu, performansa (NoSQL DB'lerde) neden olan şemadaki esneklik ve ACID / İşlemler tarafını terk ederken ölçeklenebilirlikten bahsediyor.

Bu, 'Şema esnekliğine karşı ACID' işlemlerinin "ya da" vakası mıdır, yoksa daha iyi bir çıkış yolu var mı?

seçenek 1

Bunun aşağıda açıklayacağım birkaç nedeni var. İlk olarak, bunu nasıl yapacağınız aşağıda açıklanmıştır.

• Standart RDBMS platformu seçiminizi kullanın.

• Şemanızı, kullanıcı tarafından yapılandırılabilen birkaç alanla ayarlayın ve uygulamanızın kiracı başına yapılandırmayı kolaylaştırmasını sağlayın.

• Başına kiracı meta veri itibaren, bir başına kiracı görünüm oluşturabilirsiniz kendi yerleşik filtreler, ve meta verilerden adlandırılmış sütunları olan verilere. Sağlanan raporlar meta verileri de devralabilir. Veriyi MI yapmak istiyorlarsa, onlara işlem verilerinin bir özetini veya bunun için ödeme yapacaklarsa farklı bir sunucuda bazı ek MIS uygulamaları sağlayın.

• İstemci kendi özel örneği için ödeme yapmaya ve özel bir yapıyı yönetmeye hazırlanmadığı sürece, bundan daha fazla özelleştirme (şemada köklü bir değişiklik olmaması) sağlamaya çalışmayın.

Bunun nedenleri:

• Bu veritabanı sistemleri, oldukça sıradan bir donanımda tanımladığınız hacimleri işleyecektir. NoSQL veritabanını hak eden bir işlem hacmine sahip değilsiniz. Bir tane istemek için başka bir mimari nedeniniz olmadıkça, kanamaya çıkmanın pek bir anlamı yoktur.

• Olgun, iyi anlaşılmış teknolojiler.

• Sistem yönetimi, yedekleme / geri yükleme, çoğaltma, raporlama ve olağanüstü durum kurtarma, RDBMS platformlarında iyi bir şekilde sıralanmıştır.

• Tüm büyük RDBMS platformları için JDBC dahil istemci kitaplıkları alabilirsiniz.

• Görünümler, kullanıcı başına özelleştirme için kullanılabilir ve uygulama meta verilerinizden oluşturulabilir.

• XML alanlarından veya EAV yapılarından önemli ölçüde daha verimlidir.

PostgreSQL ile çoklu kiracılıkla başa çıkmak için ayrı veritabanları, ayrı şemalar veya görünümler kullanma seçeneğiniz vardır.

Birden çok veritabanı (aynı veritabanı sunucusu içinde) kullanmak, yönetimi daha karmaşık hale getirir, çünkü her veritabanı ayrı ayrı yönetilmelidir. Bu nedenle, bu sadece kiracılar arasındaki güvenlik çok önemliyse tavsiye edilir.

Ayrı şemalar çok fazla esneklik ve güvenlik sunar, ancak yükseltmeleri daha karmaşık hale getirir, çünkü tek tek uygulanması gerekir ve muhtemelen sadece kiracılarınız tamamen farklı masa yapıları kullanıyorsa gereklidir; ki bunlar aynı uygulamayı kullanıyorlarsa olası değildir.

Görünümler, kiracıların ortak tablo yapısının farklı bölümlerini görmesine izin verir ve hangi tabloları, hangi sütunları ve hangi satırlara erişebileceklerini denetlemenizi sağlar. Tek uyarı, uygulamanızın temel tabloları değil yalnızca bu görünümleri kullanmasını sağlamalıdır, aksi takdirde yazılım hataları nedeniyle kiracılar arasında kazara veri sızıntısı olasılığı vardır.

Gerçekten uygulama gereksinimlerinden önce sütunlar oluşturmanız gerekmez. Sütunlar tablolara dinamik olarak eklenebilir (kullanıcılar üzerinde belirgin bir etkisi olmadan) ve görünümler de dinamik olarak güncellenebilir. Sadece değişiklik yapma sırasını düşünmelisiniz - yani. tabloları değiştirin, ardından uygulama kodunu görüntüleyin.

Tek potansiyel endişeniz, varolan bir dizine eklenmesi gereken veya yeni bir dizin gerektiren yeni bir sütun eklemeniz gerektiğidir. Dizin oluşturulurken tablo kullanımdan kilitlenebilir, ancak PostgreSQL, tabloyu kilitlemeden aynı anda dizin oluşturma yeteneğini destekler. Yeni dizinin benzersiz olması gerekmediği ve benzersiz bir ihlal bulunmadığı sürece bu iyi çalışır.

Şemayı veritabanından etkili bir şekilde kaldırdıkları ve bunun yerine uygulamanın yönetilmesini gerektirdikleri için muhtemelen bir NoSQL veritabanına ihtiyacınız yoktur. Hacimleriniz böyle bir fedakarlık gerektiriyor gibi gelmiyor.