Belge Veritabanı ve İlişkisel Veritabanı: nasıl seçilir?

Ben bir SQL adamım, ama sadece SQL veritabanları olduğunu biliyorum - çoğunlukla belge veritabanı. Çoğu teknolojide olduğu gibi, her teknoloji için yanlısı ve eksileri vardır.

Bazı makaleler okudum ama çok teoriklerdi. İstediğim iki gerçek durum:

1. ilişkiselden belge veritabanına geçiş iyileştirildiğinde
2. belge- ilişkisel veritabanına geçiş bir gelişme sağladığında

Geliştirme, daha iyi programlar yapan herhangi bir şeydir - daha az geliştirme süresi, ölçeklenebilirlik, performans, programlamayla ilgili her şey. 2 için bir uyarı var: "herkes SQL'i bildiği için ilişkisel veritabanına geri dönme" gibi hikayeler iyi değil

Son yıllarda bir NoSQL veritabanı seçmenin ana nedeni Kullanılabilirlik . Amazon, Google ve Facebook gibi şirketler için bir saatlik kesinti süresi kabul edilemez. Yüksek kullanılabilirlik elde etmek için tek hata noktasını azaltmanız gerekir, bu da bir bilgisayarın çökmesi durumunda birden fazla bilgisayarla dağıtılmış bir sistem kullanmanız gerektiği anlamına gelir, hizmet hala kullanılabilir.

Geleneksel Relatione veritabanları dağıtılmış bir çok yöneticili kurulumda çok iyi değildir. Bu yüzden NoSQL son zamanlarda çok popüler oldu. Yüksek kullanılabilirliğe ihtiyacınız varsa Riak, Cassandra, HBase, S3 veya BigTable gibi bir NoSQL veritabanı seçebilirsiniz.

Amazon'un Dinamo hakkında iyi bir blog yazısı var dağıtılmış NoSQL veritabanlarına iyi bir giriş olan .

Şimdi, NoSQL terimi çok geniştir, bu nedenle dağıtılmayan birçok NoSQL veritabanı vardır. Ama başka sorunları da çözüyorlar. Örneğin Neo4j - grafik veritabanı, geleneksel RDBMS'nin optimize edilmediği bir tür sorgular için iyidir. Veya durumunuzda olduğu gibi, bazı belgeler için bazı alanlar eklemek isterseniz şemayı değiştirmeniz gerekmez. Diğer bir deyişle, çoğu yazı (belge) farklı alanlara sahip olduğunda belge veritabanı iyidir, bu nedenle önceden tanımlanmış sütunlara sahip bir ilişkisel tablo kullanılamaz.

Bununla birlikte, NoSQL veritabanlarının çoğu geleneksel RDBMS veritabanları kadar esnek değildir, bu nedenle artık sorunlarınızı çözemeden geleneksel bir RDBMS veritabanı kullanmak iyi bir seçimdir.

Verilere en uygun veritabanını belirlemek için basit bir yaklaşım var.

Sadece kendime soruyorum: Veritabanımın olmadığı varsayılarak, en çok ve önemli verileri belge olarak mı saklıyorum yoksa bir e-tabloda mı saklıyorum?

Cevap "E-tablo" olduğunda, bu ilişkisel bir model ve geleneksel bir RDBMS'nin çoğu zaman görevlere en uygun olduğuna dair açık bir işarettir. Veriler gerçekten basitse, sadece anahtar değer çiftleri veya basit tablolar gibi ve referans bütünlüğü bir konu değilse, muhtemelen bir NoSQL veritabanı görev için en uygunudur ve performansı oldukça artırabilir!

Ayrıca, ortak bir yapı bulamadığınızda, NoSQL veritabanı görev için en uygunudur.

Veriler daha açık belge olmadan hiyerarşik olarak yapılandırılmış metin verileri olduğunda, daha sonra hiyerarşik yapılandırılmış belgeleri kolayca saklamanızı sağlayan bir XML Veritabanı düşünürüm. Bununla birlikte, bazen bir belge yönetimi yazılımı kullanmak en iyisidir.

Bu nedenle, her iki soruya da somut ve basit bir cevap vermek için: Verilere bağlıdır.

ilişkiselden belge veritabanına geçiş iyileştirildiğinde

Hiyerarşik olarak yapılandırılmış metin verilerini sürdürmeniz gerektiğinde, bir Xml-Veritabanı sürdürülebilirlik ve muhtemelen ölçeklenebilirlik açısından büyük bir gelişme olabilir.

belge- ilişkisel veritabanına geçiş bir gelişme sağladığında

Örneğin, veriler çoğunlukla açık ilişkilerle tablo benzeri bir formdaysa ve bütünlüğü garanti etmeniz gerektiğinde.

İlişkisel modelden vazgeçmek zorunda kaldık çünkü elde ettiğimiz verilerin basit, açık, sabit, statik şeması yoktu.

Kullanıcıların ve kullanıcı hikayelerinin sabit, statik bir şeması yoktu.

Sabit, statik bir RDBMS şeması uygulamaya çalıştık, ancak bu bir hataydı.

Her üçüncü taraf veri dağıtımı (müşterilerden ve satıcılardan) benzerdi, ancak aynı değildi. Sabit bir ilişkisel şema ile eşleştirmeyi denedik, ancak değişkenlik çok büyüktü. Ya her dosyaya (her hafta birkaç tane) alan eklemek zorunda kaldık ya da sabit, statik ilişkisel şemadan uzaklaşmak zorunda kaldık.

Her kaydı ortak bir alt kümeye sahip bir "belge" olarak görüntülersek öğe ve benzersiz (ve kötü tanımlanmış) ek veri öğeleri koleksiyonuna olarak görürsek çok daha mutluyduk.

Veri öğelerinin kötü tanımlanmış koleksiyonu, kullanıcıların kullanım durumları için gerçekten ihtiyaç duydukları şeydir.

İlişkisel modelin sabit, statik şeması kullanım durumlarımıza uymadı.