İlişkisel veritabanı kullanmak yerine neden CouchDB gibi belge tabanlı veritabanı kullanmalıyım? Belge tabanlı veritabanının ilişkisel veritabanından daha uygun olduğu tipik uygulama veya etki alanı türleri var mı?
Yanıtlar:
Muhtemelen yapmamalısınız :-)
İkinci en belirgin cevap, verileriniz ilişkisel değilse bunu kullanmanızdır. Bu genellikle verilerinizi bir sütun kümesi olarak tanımlamanın kolay bir yolu olmadığında kendini gösterir. Bunun iyi bir örneği, örneğin ofis postasını tarayarak kağıt belgeleri depoladığınız bir veritabanıdır. Veriler taranan PDF'dir ve her zaman var olan (taranan, taranan, belge türü) bazı meta verileriniz ve bir süre var olan olası birçok meta veri alanı (müşteri numarası, tedarikçi numarası, sipariş numarası, OCRed tam metin, vb.). Genellikle önümüzdeki iki yıl içinde hangi meta veri alanlarını ekleyeceğinizi önceden bilmezsiniz. CouchDB gibi şeyler bu tür veriler için ilişkisel veritabanlarından çok daha iyi çalışır.
Ben şahsen CouchDB için şu anda neredeyse her programlama dilinde bulunan bir HTTP istemcisi dışında herhangi bir istemci kütüphanesine ihtiyacım olmadığını seviyorum.
Muhtemelen en az açık cevap: RDBMS kullanarak acı hissetmiyorsanız, onunla kalın. İşinizi yapmak için her zaman RDBMS'niz üzerinde çalışmanız gerekiyorsa, belge odaklı bir veritabanı görülmeye değer olabilir.
Daha ayrıntılı bir liste için Richard Jones'un bu gönderisine bakın .
CouchDB ( web sitelerinden )
RESTful JSON API ile erişilebilen bir belge veritabanı sunucusu. Genellikle, ilişkisel veritabanlarına REST hizmetleri aracılığıyla erişilmez, ancak çok daha karmaşık bir SQL API'sı gerekir. Genellikle bu API'ler (JDBC, ODBC vb.) Oldukça karmaşıktır. REST oldukça basittir.
Düz adres alanı ile geçici ve şema içermez. İlişkisel veritabanlarının karmaşık, sabit şeması vardır. Tabloları, sütunları, dizinleri, dizileri, görünümleri ve diğer öğeleri tanımlarsınız. Kanepe bu düzeyde karmaşık, pahalı, kırılgan gelişmiş planlama gerektirmez.
İki yönlü çatışma algılama ve yönetimi ile sağlam, artımlı çoğaltma özelliğine sahip dağıtılmış. Bazı SQL ticari ürünleri bunu sunmaktadır. SQL API ve sabit şemalar nedeniyle, bu karmaşık, zor ve pahalıdır. Couch için basit ve ucuz görünüyor.
Sorgu yapabilen ve dizin kullanabilen, Javascript'i sorgu dili olarak kullanan tablo odaklı bir raporlama motoru. SQL ve ilişkisel veritabanları da öyle. Burada yeni bir şey yok.
Yani. Neden CouchDB?
Diğer sunucu verilerini aptalca saklamak ve sunmak için.
Son birkaç hafta içinde, beslemelerimi (lezzetli, flickr, github, twitter ...) yoklayan ve onları couchdb'de saklayan bir canlı yayın uygulamasıyla oynuyordum. Couchdb'nin güzelliği, orijinal verileri orijinal yapısında ek yük olmadan tutmama izin vermesidir. Kaynak belgeyi saklayarak her belgeye bir 'sınıf' alanı ekledim ve her kaynak için bir javascript render sınıfı yazdım.
Genelleştirme, sunucunuz başka bir sunucuyla her iletişim kurduğunda, şema üzerinde hiçbir kontrolünüz olmadığından şema içermeyen bir depolama en iyisidir. Bonusdp, couchdb, sunucuların ve istemcilerin yerel protokollerini kullanır - temsil için JSON ve aktarım için HTTP REST.
Hızlı uygulama geliştirme akla geliyor.
Şemamı sürekli olarak geliştirdiğimde, şemayı MySQL / SQLite'de korumak zorunda kaldığım için sürekli hayal kırıklığına uğradım. Henüz CouchDB ile çok fazla şey yapmamış olmama rağmen, RAD işlemi sırasında şemayı geliştirmenin ne kadar basit olduğunu seviyorum.
İlişkisel olmayan bir veritabanı kullanmak istemeyebileceğiniz bir durum, çoktan çoğa ilişkileriniz olduğunda; Özellikle de birleşme ilişkisinde meta verilere ihtiyacınız varsa, bu tür ilişkiler etrafında iyi MapReduce işlevlerinin nasıl oluşturulacağı konusunda henüz kafamı kurmadım. Emin değilim, ancak potansiyel olarak sonsuz döngülere neden olabileceğinden CouchDB Harita işlevlerinin veritabanında kendi sorgularını çağırabileceğini düşünmüyorum.
Her kayıt için tek biçimli alanlara sahip tablolarda veri depolamanız gerekmediğinde belge tabanlı bir veritabanı kullanın. Bunun yerine, her bir kaydı belirli özelliklere sahip bir belge olarak saklamanız gerekir. Herhangi bir uzunlukta herhangi bir sayıda alan, önce "tabloyu değiştirmeye" gerek kalmadan, herhangi bir zamanda bir belgeye dinamik olarak eklenebilir. Belge tabanlı alanlar da birden fazla veri parçası içerebilir.
Smdelfin hakkında ayrıntılı bilgi için: esneklik. Verileri herhangi bir yapıda (yapılandırılmamış ve hepsi) saklayabilirsiniz ve her belge tamamen farklı olabilir. CouchDB özellikle kullanışlıdır çünkü "görünüm" dizinleriyle, belirli belgeleri filtreleyebilir ve veritabanınızın bu alt kümelerini istediğinizde yalnızca bu görünümü sorgulayabilirsiniz.
Verileri JSON biçiminde depolayan belge veritabanlarının en büyük kazanan noktası: bu, JavaScript'in yerel biçimidir. Bu nedenle, JavaScript web uygulamaları CouchDB ile inanılmaz derecede iyi çalışır. Son zamanlarda CouchDB kullanan bir web uygulaması yaptım ve sürekli değişen bir veri yapısını idare edebiliyorken roket hızlı.
Belgeye dayalı veritabanlarının, herhangi bir veri girmeden önce bir şemanın önceden tanımlanmasını gerektirmedikleri için ilişkisel veritabanlarına göre büyük bir avantajı vardır.
Ayrıca, veriler ilişkisel değilse ve bir tabloda saklanamıyorsa, bir dizi resim veya örneğin gazete makaleleri ise, bir belge veritabanı kullanmalısınız.
Diğer bir avantajı da web tabanlı veritabanlarında doküman tabanlı veri tabanlarının kullanım kolaylığıdır. Daha ayrıntılı NoSQL veritabanı modelleri için comarison bu kaynağı kontrol edin: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf