NoSQL veya SQL? Bu makale açık
Büyük veri çağının gelişiyle birlikte, giderek daha fazla web sitesi ve uygulama sistemi, büyük veri depolamayı, yüksek eşzamanlılığı, yüksek kullanılabilirliği ve yüksek ölçeklenebilirliği desteklemeye ihtiyaç duyuyor.
Geleneksel ilişkisel veritabanları bu sorunlarla başa çıkamadı ve birçok aşılamaz sorunu ortaya çıkardı.
Sonuç olarak, çeşitli NoSQL (Yalnızca SQL Değil) veritabanları, geleneksel ilişkisel verilere güçlü bir tamamlayıcı olarak hızla gelişti.
Bu makale, geleneksel veritabanlarında var olan bazı sorunları ve birkaç ana NoSQL türünün bu sorunları nasıl çözebileceğini analiz edecek.Farklı iş senaryolarında depolama teknolojisi seçimi için size bazı referanslar sunmayı umuyorum.
Geleneksel veri tabanlarının dezavantajları
Geleneksel veritabanları aşağıdaki dezavantajlara sahiptir:
Büyük veri senaryosunda, G / Ç yüksektir çünkü veriler satırlar halinde depolanır.Yalnızca bir sütun hesaplansa bile, ilişkisel veritabanı, depolama cihazından belleğe veri satırının tamamını okuyarak yüksek G / Ç ile sonuçlanır.
Satır kayıtlarını depolar ve veri yapılarını saklayamaz.
Tablo yapısı Şema uzantısı sakıncalı. Tablo yapısını değiştirmek istiyorsanız, DDL (veri tanımlama dili) ve ifade değişikliğini yürütmeniz gerekir.Değişiklik sırasında tablo kilitlenecek ve bazı hizmetler kullanılamayacaktır.
Tam metin arama işlevi zayıftır ve ilişkisel veritabanları altında yalnızca alt dize eşleştirme sorguları gerçekleştirilebilir.Tablodaki veriler giderek büyüdüğünde, benzer sorguların eşleştirilmesi, dizinler ile bile çok yavaş olacaktır. Dahası, ilişkisel veritabanları metin alanlarını indekslememelidir.
Karmaşık ilişkisel verileri saklama ve işleme yeteneği zayıftır. Çoğu uygulamanın sosyal uygulamalar, öneri motorları, dolandırıcılık tespiti, bilgi grafikleri, yaşam bilimleri ve BT / ağlar gibi kullanım durumlarını etkinleştirmek için yüksek oranda bağlı veriler arasındaki ilişkileri anlaması ve bunlarda gezinmesi gerekir.
Bununla birlikte, geleneksel ilişkisel veritabanları, veri noktaları arasındaki ilişkilerle başa çıkmada iyi değildir. Tablolu veri modelleri ve katı modelleri, yeni veya farklı türde ilgili bilgiler eklemelerini zorlaştırır.
NoSQL çözümü
NoSQL, genellikle ilişkisel olmayan veritabanlarına atıfta bulunur ve SQL'e güçlü bir tamamlayıcı olarak anlaşılabilir.
NoSQL'in performansı birçok yönden ilişkisel olmayan veritabanlarından çok daha iyi olsa da, genellikle bazı özelliklerin eksikliğine eşlik eder.En yaygın olanı, işlem kütüphanesinin işlem fonksiyonlarının eksikliğidir.
Veritabanı işlemlerinin doğru yürütülmesi için dört temel unsur olan ACID aşağıdaki gibidir:
Aşağıda, geleneksel ilişkisel veritabanları için 5 ana NoSQL verileri kategorisi tarafından sağlanan eksiklikler ve çözümler tanıtılmaktadır:
Sütunlu veritabanı
Sütunlu veritabanı, temelde toplu veri işleme ve anlık sorgulama için uygun olan, veri depolama için sütunla ilgili depolama mimarisine sahip bir veritabanıdır.
Satır veritabanına karşılık gelen veriler, esas olarak küçük toplu veri işleme için uygun olan ve genellikle çevrimiçi işlemsel veri işleme için kullanılan, satırla ilgili bir depolama mimarisine tahsis edilir.
Sütunlu veri tabanlarının sütun depolama özelliğine dayanarak, belirli özel senaryolarda ilişkisel veri tabanlarının yüksek G / Ç sorununu çözebilir.
Temel
Geleneksel ilişkisel veritabanları verileri "satır veritabanı" adı verilen satırlar halinde saklarken, sütunlu veritabanları verileri sütunlar halinde depolar.
Depolama sistemine bir tablo koymanın iki yolu vardır ve çoğumuz satır depolamayı kullanırız. Satır depolama yöntemi, her satırı, geleneksel bir kayıt ve dosya sistemine çok benzeyen sürekli bir fiziksel konuma yerleştirmektir.
Sütun depolama yöntemi, veri tabanındaki verileri satır depolamaya benzer şekilde sütunlar halinde depolamaktır. Aşağıdaki şekil, iki depolama yönteminin grafiksel bir açıklamasıdır:
Ortak sütun veritabanı
HBase: Google'ın BigTable modellemesine atıfta bulunan, açık kaynaklı ilişkisel olmayan dağıtılmış bir veritabanıdır (NoSQL) ve programlama dili Java'dır.
Apache Software Foundation'ın Hadoop projesinin bir parçasıdır. HDFS dosya sistemi üzerinde çalışır ve Hadoop'a BigTable'a benzer hizmetler sağlar. Bu nedenle, büyük miktarlarda seyrek veriyi hataya dayanıklı bir şekilde depolayabilir.
BigTable: Bulut bilişim için uygun, büyük ölçekli yapılandırılmış verileri depolamak için kullanılan, Google Dosya Sistemine (GFS) dayalı, sıkıştırılmış, yüksek performanslı ve yüksek düzeyde ölçeklenebilir bir veri depolama sistemidir.
İlgili özellikler
Avantajlar aşağıdaki gibidir:
Verimli depolama alanı kullanımı: Sütunlu veritabanları, farklı sütun veri özellikleri için icat edilen farklı algoritmalar nedeniyle genellikle satır veritabanlarından çok daha yüksek sıkıştırma oranlarına sahiptir.
Sıradan satır tabanlı veritabanları genellikle 3: 1 ila 5: 1 sıkıştırma oranına sahipken, sütun tabanlı veritabanları genellikle 8: 1 ila 30: 1 sıkıştırma oranına sahiptir.
Verileri bir sözlük tablosu aracılığıyla sıkıştırmak daha yaygındır: Aşağıdaki tablo nasıl görünür. Sözlük tablosunda veri sıkıştırıldıktan sonra, tablodaki tüm dizeler sayı haline gelir.
Her dizge sözlük tablosunda yalnızca bir kez göründüğünden, sıkıştırmanın amacına ulaşılır (normalleştirme ve denomalizasyon Normalize ve Dengesizleştirme gibi).
Yüksek sorgu verimliliği: Birden çok verinin aynı sütununu okumak verimlidir, çünkü bu sütunlar birlikte saklanır, bir disk işlemi belirtilen tüm veri sütunlarını belleğe okuyabilir.
Aşağıdaki şekil, bir sorgunun yürütülmesi yoluyla sütunsal depolamanın (ve veri sıkıştırmanın) avantajlarını göstermektedir.
Uygulama adımları aşağıdaki gibidir:
Dizenin karşılık gelen numarasını bulmak için sözlük tablosuna gidin (yalnızca bir dizi karşılaştırması yapın).
Listede eşleşecek sayıları kullanın ve eşleşen konumu 1 olarak ayarlayın.
Tüm koşulları karşılayan kayıt indeksini elde etmek için farklı sütunların eşleşen sonuçları üzerinde bir bit işlemi gerçekleştirin.
Nihai sonuç kümesini oluşturmak için bu alt simgeyi kullanın.
Sütunlu veritabanları, küçük veriler yerine büyük miktarda veri için uygun olan toplama işlemleri için de uygundur.
Dezavantajlar aşağıdaki gibidir:
Küçük miktarda veriyi taramak için uygun değildir.
Rastgele güncellemeler için uygun değil.
Silme ve güncelleme içeren gerçek zamanlı işlemler için uygun değildir.
Tek sıralı veriler ACID'dir. Çok sıralı işlemlerde, işlemin normal geri dönüşü desteklenmez, I (İzolasyon) izolasyon (işlem seri tamamlama), D (Dayanıklılık) dayanıklılığı ve A (Atomiklik) atomikliği garanti edilemez , C (Tutarlılık) tutarlılığı.
kullanılacak sahneler
HBase'i örnek olarak alın:
Büyük miktarda veri (100 TB düzeyinde veri) ve hızlı rastgele erişime ihtiyaç vardır.
Büyük günlük yazma hacmine ve nispeten küçük okuma hacmine sahip, anlık ileti geçmişi mesajları, oyun günlükleri vb. Gibi yoğun yazma gerektiren uygulamalar.
Verileri sorgulamak için karmaşık sorgu koşulları gerektirmeyen uygulamalar. HBase yalnızca satır anahtarına dayalı sorguları destekler. HBase için, tek bir kayıt veya küçük bir sorgu aralığı kabul edilebilir.
Büyük ölçekli sorgular, dağıtılmış nedenlerden dolayı performans üzerinde bir miktar etkiye sahip olabilir HBase, birleştirmeler, çok düzeyli dizinler ve karmaşık tablo ilişkileri içeren veri modelleri için uygun değildir.
Çok yüksek performans ve güvenilirlik gereksinimleri olan uygulamalar için, HBase'nin kendisinde tek bir hata noktası olmadığından, kullanılabilirlik çok yüksektir.
Büyük veri hacimleri ve öngörülemeyen büyümeye sahip uygulamalar için, zarif veri genişletme gerektiren HBase, çevrimiçi genişletmeyi destekler.Veri hacmi belirli bir süre içinde katlanarak artsa bile, HBase yatay genişletmesi de işlevleri karşılamak için kullanılabilir.
Yapılandırılmış ve yarı yapılandırılmış verileri depolayın.
K-V veritabanı
Anahtar-değer depolamasını kullanan bir veritabanını ifade eder ve verileri anahtar-değer çiftleri şeklinde düzenlenir, dizine alınır ve depolanır.
K-V depolama, çok fazla veri ilişkisi ve iş ilişkisi içermeyen veriler için çok uygundur.Aynı zamanda diske okuma ve yazma sayısını etkin bir şekilde azaltabilir.SQL veritabanı depolamasına göre daha iyi okuma ve yazma performansına sahiptir ve veri yapılarını depolayamayan ilişkisel veritabanları sorununu çözebilir.
Ortak K-V veritabanı
Redis: ANSI C ile yazılmış açık kaynaklı, ağ destekli, bellek tabanlı, isteğe bağlı kalıcı anahtar-değer çifti depolama veritabanıdır.
Haziran 2015'ten itibaren Redis'in geliştirilmesine Redis Labs sponsor oldu ve Mayıs 2013'ten Haziran 2015'e kadar geliştirmesine Pivotal sponsor oldu.
Mayıs 2013'ten önce geliştirilmesine VMware sponsor oldu. Aylık sıralama web sitesi DB -Engines.com'dan alınan verilere göre, Redis en popüler anahtar-değer çifti depolama veritabanıdır.
Cassandra: Apache Cassandra (toplulukta genellikle C * olarak anılır) açık kaynaklı dağıtılmış bir NoSQL veritabanı sistemidir.
Başlangıçta Facebook tarafından verileri gelen kutuları gibi basit biçimlerde depolamak için geliştirilmiştir.Google BigTable'ın veri modelini ve Amazon Dynamo'nun tamamen dağıtılmış mimarisini birleştirir.
Facebook, Cassandra'yı 2008 yılında açık kaynak kodlu olarak açtı. O zamandan beri, Cassandra'nın iyi ölçeklenebilirliği ve performansı sayesinde.
Apple, Comcas, Instagram, Spotify, eBay, Rackspace ve Netflix gibi tanınmış web siteleri tarafından benimsenmiştir ve popüler bir dağıtılmış yapılandırılmış veri depolama çözümü haline gelmiştir.
LevelDB: Google tarafından geliştirilmiş, açık kaynak BSD lisansı altında yayınlanan bir anahtar / değer çifti (Anahtar / Değer Çifti) yerleşik veritabanı yönetim sistemi programlama kitaplığıdır.
İlgili özellikler
Redis'i örnek olarak alırsak, K-V veritabanının avantajları aşağıdaki gibidir:
Yüksek performans: Redis, 10W üzerinde TPS'yi destekleyebilir.
Zengin veri türleri: Redis; String, Hash, List, Set, Sorted Set, Bitmap ve Hyperloglog'u destekler.
Zengin özellikler: Redis ayrıca yayınlama / abone olma, bildirim, anahtar süre sonu ve diğer özellikleri destekler.
Dezavantajlar aşağıdaki gibidir:
ACID için Redis işlemleri atomikliği ve dayanıklılığı (A ve D) destekleyemez, ancak yalnızca izolasyonu ve tutarlılığı (I ve C) destekler.
Özellikle atomikliğin burada garanti edilememesi gerçeği Redis işlem operasyonları içindir, çünkü işlemler geri dönüşü desteklemez ve Redis'in tek iş parçacıklı modeli nedeniyle Redis'in ortak işlemleri atomiktir.
Çoğu işletmenin, gerçek zamanlı oyun sıralaması, hayranların ilgisi ve diğer senaryolar gibi ACID ilkesini sıkı bir şekilde takip etmesi gerekmez.Verilerin bir kısmı devam etmekte başarısız olsa bile, iş etkisi aslında çok küçüktür. Bu nedenle, bir plan tasarlarken, iş özelliklerine ve gereksinimlerine göre bir seçim yapmanız gerekir.
kullanılacak sahneler
Uygulanabilir sahne:
Kullanıcı bilgilerini (oturumlar gibi), yapılandırma dosyalarını, parametreleri, alışveriş sepetlerini vb. Saklayın. Bu bilgi genellikle ID (anahtar) ile bağlantılıdır.
Geçerli olmayan senaryolar:
Anahtarla değil, değere göre sorgulamanız gerekir. Anahtar-Değer veritabanında değer sorgusunun hiçbir yolu yoktur.
Veriler arasındaki ilişkinin saklanması gerekiyor. Veriler, Anahtar-Değer veritabanındaki iki veya daha fazla anahtarla ilişkilendirilemez.
İşlerden desteğe ihtiyacınız var. Anahtar-Değer veritabanında bir hata oluştuğunda, geri alınamaz.
Belge veritabanı
Belge veritabanı (belge veritabanı olarak da bilinir), yarı yapılandırılmış verileri belgeler olarak depolamayı amaçlayan bir veritabanıdır. Belge veritabanları genellikle verileri JSON veya XML biçiminde depolar.
Doküman veritabanının şema yok özelliği sayesinde, rastgele veriler saklanabilir ve okunabilir.
Kullanılan veri formatı JSON veya BSON olduğundan, JSON verileri kendi kendini tanımladığından, kullanmadan önce alanları tanımlamaya gerek yoktur. JSON'da bulunmayan bir alanı okumak, SQL gibi sözdizimi hatalarına neden olmaz ve ilişkisel veritabanı tablolarını çözebilir. Yapı Şeması uzantısındaki rahatsızlık sorunu.
Ortak belge veritabanı
MongoDB: Uygulama geliştirme topluluğundaki çok sayıda pratik sorunu çözmek için C ++ ile yazılmış, belge odaklı bir veritabanı yönetim sistemidir. Ekim 2007'de MongoDB, 10gen ekibi tarafından geliştirildi. İlk olarak Şubat 2009'da piyasaya sürüldü.
CouchDB: Apache CouchDB, kullanım kolaylığına odaklanan ve "Web'i tamamen kucaklayan bir veritabanı" haline gelen açık kaynaklı bir veritabanıdır.
Depolama biçimi olarak JSON, sorgu dili olarak JavaScript ve API olarak MapReduce ve HTTP kullanan bir NoSQL veritabanıdır.
Dikkate değer özelliklerden biri çoklu ana kopyalamadır. CouchDB'nin ilk sürümü 2005'te yayınlandı ve 2008'de bir Apache projesi oldu.
İlgili özellikler
MongoDB'yi örnek olarak alırsak, bir belge veritabanının avantajları aşağıdaki gibidir:
Yeni alanlar basittir, tablo yapısını ilişkisel bir veritabanı gibi değiştirmek için DDL ifadelerini yürütmeye gerek yoktur, program kodu doğrudan okunabilir ve yazılabilir.
Geçmiş verilerle uyumlu olması kolaydır.Yeni alan olmasa bile geçmiş veriler için bir hataya neden olmaz ve yalnızca boş bir değer döndürür.Bu durumda kod, işleme ile uyumludur.
Karmaşık verileri depolaması kolay JSON, karmaşık veri yapılarını tanımlayabilen güçlü bir açıklama dilidir.
Geleneksel ilişkisel veritabanları ile karşılaştırıldığında, bir belge veritabanının ana dezavantajı, aşağıdakilere yansıyan çoklu veri kayıtları için zayıf işlem desteğidir:
Atomiklik (atomiklik), yalnızca tek satırlık / belge düzeyinde atomiteyi destekler ve çok satırlı, çok belgeli ve çoklu ifadeli atomikliği desteklemez.
Solation (izolasyon), izolasyon seviyesi sadece tekrarlanamayan okumalara ve hayali okumalara neden olabilecek olan okuma tamamlanmış (Okuma taahhütlü) seviyesini destekler.
Birleştirme sorguları gibi karmaşık sorguları desteklemez.Sorguları birleştirmeniz gerekirse, veritabanını birden çok kez çalıştırmanız gerekir.
MongonDB aynı zamanda çok belgeli işlemlerin Tutarlılığını ve Dayanıklılığını da destekliyor .. MongoDB'nin 4.0 sürümünde çok belgeli ACID işlem desteğini resmi olarak başlatacağı resmi olarak duyurulsa da, nihai uygulama göreceğiz.
kullanılacak sahneler
Uygulanabilir sahne:
Veri miktarı çok fazla veya gelecekte çok büyük olacak.
Tablo yapısı net değil ve içerik yönetim sistemi, bilgi yönetim sistemi gibi alanlar artıyor.
Geçerli olmayan senaryolar:
Farklı belgeler üzerine işlem eklemeniz gerekiyor. Belge Odaklı veritabanı, belgeler arasındaki işlemleri desteklemez.
Birleştirme gibi birden çok belge arasında karmaşık sorgular gerekir.
Tam metin arama motoru
Geleneksel ilişkisel veritabanları, hızlı sorgulama amacına ulaşmak için esas olarak indeksleri kullanır. Tam metin arama işinde, indeksler de güçsüzdür ve esas olarak aşağıdakilere yansır:
Tam metin aramanın koşulları isteğe göre düzenlenebilir ve birleştirilebilir, eğer dizin tarafından karşılanırsa, dizin sayısı çok fazladır.
Tam metin aramanın bulanık eşleme yöntemi, dizin tarafından tatmin edilemez ve yalnızca benzer sorgu kullanılabilir ve sorgu gibi, çok verimsiz bir tam tablo taramasıdır.
Tam metin arama motorlarının ortaya çıkışı, ilişkisel veritabanlarındaki zayıf tam metin arama işlevleri sorununu çözmektir.
Temel
Tam metin arama motorunun teknik ilkesi, temel ilkesi belgelere bir sözcük dizini oluşturmak olan bir dizin oluşturma yöntemi olan "tersine çevrilmiş dizin" olarak adlandırılır. Bunun tersi, temel ilkesi dokümanları kelimelere endekslemek olan "ileriye doğru indekslemedir".
Şimdi şu belge koleksiyonu var:
Pozitif satır dizininin dizini aşağıdaki gibidir:
Yukarıdan, ileriye doğru dizinin, belge adına göre belge içeriğini sorgulamak için uygun olduğu görülebilir. Basit ters çevrilmiş indeks aşağıdaki gibidir:
Kelime frekansı bilgisine sahip ters çevrilmiş indeks aşağıdaki gibidir:
Tersine çevrilmiş dizinin, anahtar kelimelere dayalı olarak belge içeriğini sorgulamak için uygun olduğu yukarıdan görülebilir.
Yaygın tam metin arama motorları
Elasticsearch: Lucene tabanlı bir arama motorudur. Motor HTTP Web arayüzü ve şemasız JSON dosyaları ile dağıtılmış, çok kiracılı, tam metin araması sağlar.
Elasticsearch, Java'da geliştirilmiş ve Apache Lisansı koşulları altında açık kaynak olarak yayınlanmıştır.
DB-Engines sıralamasına göre, Elasticsearch en popüler kurumsal arama motorudur ve onu Lucene tabanlı Apache Solr izlemektedir.
Solr: Apache Lucene projesinin açık kaynaklı kurumsal arama platformudur. Ana işlevleri arasında tam metin arama, isabet işaretleme, yönlü arama, dinamik kümeleme, veritabanı entegrasyonu ve zengin metin (Word ve PDF gibi) işleme yer alır. Solr son derece ölçeklenebilirdir ve dağıtılmış arama ve dizin çoğaltması sağlar.
İlgili özellikler
Elasticsearch'ü örnek alırsak, tam metin arama motorunun avantajları aşağıdaki gibidir:
Yüksek sorgu verimliliği, büyük verilerin neredeyse gerçek zamanlı işlenmesi.
Ölçeklenebilirlik, küme ortamına bağlı olarak, yatay olarak kolayca genişletilebilir ve petabaytlarca veri taşıyabilir.
Yüksek kullanılabilirlik, Elasticsearch küme esnekliği, verilerin güvenli ve erişilebilir olmasını sağlamak için yeni veya başarısız düğümleri keşfedecek, verileri yeniden düzenleyecek ve yeniden dengeleyecekler.
Dezavantajlar aşağıdaki gibidir:
ACID desteği yetersiz, tek bir belgenin verisi ACID, işlem birden fazla belge içerdiğinde işlemin normal geri dönüşü desteklenmiyor, I (İzolasyon) izolasyonu (iyimser kilitleme mekanizmasına göre), D (Dayanıklılık) kalıcılığı, hayır A (Atomiklik) atomitesini ve C (Tutarlılık) tutarlılığını destekleyin.
Benzer veritabanlarında yabancı anahtarlar aracılığıyla karmaşık çoklu tablo ilişkilendirme işlemleri desteği zayıftır.
Okuma ve yazmada belirli bir gecikme olur ve yazılan veriler 1 saniye kadar kısa bir sürede alınabilir.
Güncelleme performansı düşüktür ve temelde yatan uygulama önce verileri silmek ve ardından yeni verileri eklemektir.
Bellek ayak izi büyüktür çünkü Lucene dizin bölümünü belleğe yükler.
kullanılacak sahneler
Uygulanabilir senaryolar aşağıdaki gibidir:
Dağıtık arama motoru ve veri analiz motoru.
Tam metin arama, yapılandırılmış arama, veri analizi.
Büyük verilerin neredeyse gerçek zamanlı olarak işlenmesi, depolama ve erişim için birden çok sunucuya dağıtılabilir.
Uygun olmayan senaryolar aşağıdaki gibidir:
Verilerin sık sık güncellenmesi gerekiyor.
Karmaşık ilişkisel sorgulara ihtiyacınız var.
Grafik veritabanı
Grafik veritabanı, varlıklar arasındaki ilişki bilgilerini depolamak için grafik teorisini kullanır. En yaygın örnek, sosyal ağlardaki insanlar arasındaki ilişkidir.
İlişkisel veritabanları "ilişkisel" verileri depolamak için çok etkili değildir ve sorguları karmaşık, yavaştır ve beklentileri aşar.
Grafik veritabanının benzersiz tasarımı, bu eksikliği giderir ve zayıf ilişkisel veritabanı depolama ve karmaşık ilişkisel verilerin işlenmesi sorununu çözer.
Ortak grafik veritabanı
Neo4j: Neo4j, Inc. tarafından geliştirilmiş bir grafik veritabanı yönetim sistemidir. Geliştiricileri tarafından yerel grafik depolama ve işleme ile ACID uyumlu işlem veritabanı olarak tanımlanan DB-Engines sıralamasına göre Neo4j, en popüler grafik veritabanıdır.
ArangoDB: triAGENS GmbH tarafından geliştirilmiş yerel bir çok modelli veritabanı sistemidir. Veritabanı sistemi, bir veritabanı çekirdeği ve birleşik sorgu dili AQL (ArangoDB Sorgu Dili) dahil olmak üzere üç önemli veri modelini (anahtar / değer, belge, grafik) destekler.
Sorgu dili bildirimseldir ve farklı veri erişim modellerinin tek bir sorguda birleştirilmesine izin verir. ArangoDB bir NoSQL veritabanı sistemidir, ancak AQL birçok yönden SQL'e benzer.
Titan: Çok makineli bir kümede dağıtılmış on milyarlarca köşe ve kenar içeren grafikleri depolamak ve sorgulamak için optimize edilmiş ölçeklenebilir bir grafik veritabanıdır.
Titan, binlerce eşzamanlı kullanıcıyı gerçek zamanlı olarak karmaşık grafik geçişleri gerçekleştirmek için destekleyebilen bir işlemsel veritabanıdır.
İlgili özellikler
Neo4j'i örnek alırsak, Neo4j modelleme için veri yapısında grafik kavramını kullanır. Neo4j'deki en temel iki kavram düğümler ve kenarlardır.
Düğümler varlıkları temsil eder ve kenarlar varlıklar arasındaki ilişkileri temsil eder. Hem düğümlerin hem de kenarların kendi nitelikleri olabilir. Farklı varlıklar, karmaşık bir nesne grafiği oluşturmak için çeşitli ilişkilerle birbirine bağlanır.
İlişkisel veriler için, iki veritabanının depolama yapıları farklıdır:
Neo4j'de, düğümleri depolarken "indekssiz bitişiklik" kullanılır, yani her düğüm, komşu düğümü O (1) zamanında bulmamızı sağlayan komşu düğümüne bir göstericiye sahiptir.
Ayrıca resmi açıklamaya göre, Neo4j'de en önemli olan kenar, yani "birinci sınıf varlıklar" dır, bu nedenle bunlar ayrı ayrı depolanır, bu da grafikte hareket edildiğinde hızın artmasına yardımcı olur ve ayrıca herhangi bir yönde kolayca hareket ettirilebilir.
Avantajlar aşağıdaki gibidir:
Yüksek performanslı, grafik geçişi, grafik veri yapısının benzersiz bir algoritmasıdır, yani bağlantı ilişkisine göre bir düğümden başlayarak komşu düğümlerini hızlı ve kolay bir şekilde bulabilir.
Bu veri bulma yöntemi, veri hacminin boyutundan etkilenmez, çünkü yakınlık sorgusu her zaman sınırlı yerel verileri bulur ve tüm veritabanında arama yapmaz.
Tasarımın esnekliği, veri yapısının doğal uzantısı ve yapılandırılmamış veri formatı, grafik veritabanı tasarımının büyük ölçeklenebilirlik ve esnekliğe sahip olmasını sağlar.
Çünkü talepteki değişikliklerle eklenen düğümler, ilişkiler ve öznitelikler, orijinal verilerin normal kullanımını etkilemeyecektir.
Geliştirme çevikliği, sezgisel veri modeli, gereksinimlerin tartışılmasından program geliştirme ve uygulamaya kadar ve nihayet veri tabanında saklanan, görünüşü değişmiş gibi görünmüyor, hatta tamamen aynı olduğu bile söylenebilir.
ACID'yi tam olarak destekler Diğer NoSQL veritabanlarının aksine Neo4j ayrıca tam işlem yönetimi özelliklerine sahiptir ve ACID işlem yönetimini tam olarak destekler.
Dezavantajlar aşağıdaki gibidir:
Desteklenen düğümlerin, ilişkilerin ve özniteliklerin sayısında bir sınır vardır.
Bölme desteklenmez.
kullanılacak sahneler
Uygulanabilir senaryolar aşağıdaki gibidir:
Sosyal ağlar gibi güçlü ilişkilere sahip bazı verilerde.
Öneri motoru. Verileri grafikler halinde sunarsak, tavsiyelerin formüle edilmesinde çok faydalı olacaktır.
Uygun olmayan senaryolar aşağıdaki gibidir:
Büyük miktarlarda olaya dayalı verileri (günlük girişleri veya sensör verileri gibi) günlüğe kaydedin.
Hadoop'a benzer şekilde büyük ölçekli dağıtılmış verileri işleyin.
İlişkisel veritabanlarında depolanan yapılandırılmış veriler için uygundur.
İkili veri depolama.
sonuç olarak
İlişkisel veritabanı ve NoSQL veritabanı seçiminde genellikle birkaç göstergenin dikkate alınması gerekir:
Veri miktarı
Eşzamanlılık
gerçek zaman
Tutarlılık gereksinimleri
Dağıtımı ve türleri okuyun ve yazın
Emniyet
İşletme ve bakım maliyeti
Yaygın yazılım sistemi veritabanı seçim referansı aşağıdaki gibidir:
İşletim sistemleri gibi dahili olarak kullanılan yönetilen sistemler, az miktarda veriye ve küçük eşzamanlılığa sahiptir. İlişkisel türün dikkate alınması önerilir.
E-ticaret tek ürün sayfaları gibi yüksek trafikli sistemler için, arka plandaki ilişkisel türü ve ön plandaki bellek türünü göz önünde bulundurun.
Günlük tabanlı sistemler için, ham veriler için sütun seçimini göz önünde bulundurun ve günlük arama için tersine çevrilmiş dizini düşünün.
Site araması gibi arama tabanlı sistemler, ürün arama gibi genel olmayan arama, arka plandaki ilişkisel türü ve ön plandaki ters çevrilmiş dizini dikkate alır.
Envanter, işlem ve muhasebe gibi işlem sistemleri, ilişkisel + önbelleğe alma + tutarlılık protokolünü seçmeyi düşünün.
Büyük miktarda veri analizi gibi çevrimdışı hesaplamalar da sütunsal veya ilişkisel olarak kabul edilebilir.
Gerçek zamanlı izleme gibi gerçek zamanlı hesaplamalar için, bellek içi veya sütunlu bir veritabanı seçmeyi düşünebilirsiniz.
Tasarım pratiğinde, talebe ve iş odaklı mimariye dayanmalıyız.RDB / NoSQL / DRDB seçimine bakılmaksızın, talep odaklı olmalıdır. Nihai veri depolama çözümü, çeşitli değiş tokuşların kapsamlı bir tasarımı olmalıdır.
Referans malzemeleri:
0-Alibaba Li Yunhua'dan mimariyi öğrenin
NoSQL konuşma
Grafik veritabanı Neo4j geliştirme savaşı
Büyük veri çağında 9 anahtar-değer depolama veritabanı
İşler-Redis resmi belgesi
MongoDB işlemler için ACID'yi nasıl uygular?
MySQL kirli okuma, sanal okuma, hayalet okuma
İlişkisel veritabanları ve NoSQL'in kullanım senaryolarını kapsamlı bir şekilde sıralayın
Sütunlu Veritabanının Özellikleri Üzerine Analiz
Sütunlu ve satır veritabanını bir dakikada anlayın
HBase temel kavramları
NoSQL Veritabanları, neden kullanmalıyız ve hangisini seçmeliyiz
Geleneksel ilişkisel veritabanı ve dağıtılmış veritabanı bilgi noktaları
