2
Asit uyumlu olan FoundationDB vardı. Şimdi Apple kaptı
—
hiçbir şapka ile kullanıcıyı
Yanıtlar:
Bunu sadece konuşmayı desteklemek için bir cevap olarak göndereceğim - Tim Mahy , nawroth ve CraigTP uygulanabilir veritabanları önerdi. Erlang kullanımı nedeniyle CouchDB benim tercihim olurdu , ama orada başkaları da var.
Derdim ASİT çelişmediğini ya kavramını ortadan kaldırmamaktadır NoSQL tarafından ifade görüşünü şu bir eğilim var gibi görünüyor olsa da ... güvercin , ben kavramlar farklıdır iddia ediyorum.
NoSQL temel olarak klasik RDBMS'lerde açık şemaya doğrudan alternatif olarak basit anahtar / değer çifti (örneğin Redis) veya belge stili şema (bir "belge" modelinde toplanan anahtar / değer çiftleri, örneğin MongoDB) ile ilgilidir. Geliştiricinin, şeyleri asimetrik olarak işlemesine izin verirken, geleneksel motorlar veri modeli üzerinde katı bir benzerliği zorladı . Bunun bu kadar ilginç olmasının nedeni , değişimle başa çıkmanın farklı bir yolunu sağlaması ve daha büyük veri kümeleri için hacimler ve performansla başa çıkmak için ilginç fırsatlar sunmasıdır.
ACID , değişikliklerin veritabanına nasıl uygulandığını düzenleyen ilkeler sağlar. Çok basit bir şekilde, (kendi versiyonum) şunu belirtiyor:
Konuşma, yayılma ve kısıtlama fikri söz konusu olduğunda biraz daha heyecanlanır . Bazı RDBMS motorları, yayılma öğelerine (la kaskad ) sahip olabilen kısıtlamaları (örn. Yabancı anahtarlar) uygulama yeteneği sağlar . Daha basit bir ifadeyle, bir "şey" in veritabanındaki başka bir "şey" ile ilişkisi olabilir ve birinin özniteliğini değiştirirseniz diğerinin değiştirilmesi gerekebilir (güncellenmiş, silinmiş, ... birçok seçenek). Ağırlıklı olarak (şu anda) yüksek veri hacimlerine ve yüksek trafiğe odaklanan NoSQL veritabanları, (tüketici perspektifinden) keyfi zaman dilimleri içinde gerçekleşen dağıtılmış güncellemeler fikrini ele alıyor gibi görünmektedir. Bu temelde, üzerinden yönetilen özel bir çoğaltma biçimidir.işlem - geleneksel bir dağıtılmış veritabanı ACID destekleyebilir, bu yüzden bir NoSQL veritabanı söyleyebilirim.
Daha fazla okuma için bazı kaynaklar:
GÜNCELLEME (27 Temmuz 2012): Wikipedia makalesine bağlantı, bu yanıt gönderildiğinde geçerli olan makalenin sürümünü yansıtacak şekilde güncellendi. Mevcut Wikipedia makalesinin kapsamlı bir şekilde revize edildiğini lütfen unutmayın !
Peki, NoSQL hakkındaki Wikipedia makalesinin eski bir sürümüne göre :
NoSQL, ilişkisel veritabanlarının ve ACID garantilerinin uzun bir geçmişiyle kırılan, gevşek tanımlanmış ilişkisel olmayan veri depoları sınıfını destekleyen bir harekettir.
ve ayrıca:
Bu isim, sıklıkla ASİT garantileri sağlamaya çalışmayan, ilişkisel olmayan, dağıtılmış çok sayıda veri deposunun ortaya çıkışını tanımlama girişimidir.
ve
NoSQL sistemleri, ek bir ara katman katmanı ekleyerek tam ACID garantileri uygulayabilmesine rağmen, nihai tutarlılık ve tek veri öğeleriyle sınırlı işlemler gibi genellikle zayıf tutarlılık garantileri sağlar.
Yani, kısaca, bir "NoSQL" veri deposunun ana faydalarından birinin , ACID özelliklerinin belirgin eksikliği olduğunu söyleyebilirim . Dahası, IMHO, ACID özelliklerini uygulamaya ve uygulamaya çalıştıkça , aldığınız bir "NoSQL" veri deposunun "ruhundan" daha uzakta ve aldığınız "gerçek" bir RDBMS'ye ne kadar yakın olursanız (göreceli olarak tabii ki) ).
Bununla birlikte, söylenenlerin hepsi, "NoSQL" çok belirsiz bir terimdir ve bireysel yorumlara açıktır ve ağırlıklı olarak ne kadar saf bir bakış açısına sahip olduğunuza bağlıdır. Örneğin, çoğu günümüz sistemleri aslında uymayan RDBMS tüm arasında Edgar F. Codd 'ın 12 kural onun bir ilişki modeli !
Pragmatik bir yaklaşımla, Apache'nin CouchDB'sinin gevşek bağlanmış, ilişkisel olmayan "NoSQL" zihniyetini korurken, hem ACID uyumluluğunu somutlaştırmaya en yakın olduğu görülüyor .
Lütfen NoSQL veritabanlarıyla ilgili Martin Fowler tanıtımını okuduğunuzdan emin olun . Ve ilgili video.
Her şeyden önce, iki tip NoSQL veritabanını ayırt edebiliriz:
Tasarım gereği, Grafik odaklı veritabanlarının çoğu ACID'dir !
Peki ya diğer türler?
Toplam odaklı veritabanlarına üç alt tür koyabiliriz:
Burada Aggregate olarak adlandırdığımız şey, Eric Evans'ın Etki Alanına Dayalı Tasarımında belirli bir Sınırlı Bağlamda kendi kendine yeterli Varlıklar ve Değer Nesneleri olarak tanımladığı şeydir .
Sonuç olarak, toplu bir birim olarak etkileşimde bulunduğumuz veri topluluğudur. Toplamalar, veritabanıyla ACID işlemlerinin sınırlarını oluşturur. (Martin Fowler)
Yani, Agrega seviyesinde, en NoSQL veritabanları ASİT RDBMS gibi güvenli olabileceğini söyleyebiliriz uygun ayarlarla. Kaynak olarak, sunucunuzu en iyi hıza ayarlarsanız, ACID olmayan bir şeye gelebilirsiniz. Ancak çoğaltma yardımcı olacaktır.
Benim asıl nokta, RDBMS için (ucuz) bir alternatif olarak, oldukları gibi NoSQL veritabanlarını kullanmak zorunda olmasıdır. Belgeler arasındaki ilişkileri kötüye kullanan çok fazla proje gördüm. Bu ASİT olamaz. Belge düzeyinde, yani Toplam sınırlarda kalırsanız, herhangi bir işleme ihtiyacınız yoktur. Ve verileriniz ACID veritabanında olduğu gibi güvenli olacak, gerçekten ACID olmasa bile, bu işlemlere ihtiyacınız yok! İşlemlere ihtiyacınız varsa ve birden fazla "belgeyi" bir kerede güncellerseniz, artık NoSQL dünyasında değilsiniz - bunun yerine bir RDBMS motoru kullanın!
bazı 2019 güncellemeleri: Sürüm 4.0'dan başlayarak, birden fazla belgede güncelleme için atomisite veya birden çok belgeye okumalar arasında tutarlılık gerektiren durumlar için MongoDB, çoğaltma kümeleri için çoklu belge işlemleri sağlar .
FoundationDB ASİT uyumludur:
Uygun işlemlere sahiptir, böylece birden fazla farklı veri öğesini bir ACID tarzında güncelleyebilirsiniz. Bu, dizinleri daha yüksek bir katmanda tutmanın temeli olarak kullanılır.
Bu soruda birisi OrientDB'den bahsetmek zorundadır : OrientDB, tamamen ACID işlemlerini destekleyen birkaç NoSQL veritabanıdır. ACID sadece RDBMS için değildir, çünkü İlişkisel cebirin bir parçası değildir. Bu nedenle ACID'yi destekleyen bir NoSQL veritabanına sahip olmak mümkündür.
Bu özellik MongoDB'de en çok özlediğim özellik
ACID ve NoSQL tamamen dikeydir. Biri diğerini ima etmez.
Masamda bir defter var, hala yapmam gereken şeylerle ilgili notlar tutmak için kullanıyorum. Bu not defteri bir NoSQL veritabanıdır. "Sayfa önbelleği" ile doğrusal bir arama kullanarak sorgulamak, bu yüzden her zaman her sayfa aramak zorunda değilsiniz. Aynı zamanda ASID uyumludur, çünkü her seferinde sadece bir şey yazmamı sağlarken, okurken asla yazmam.
NoSQL basitçe SQL olmadığı anlamına gelir. Birçok insan kafası karışır ve bunun yüksek oranda ölçeklenebilir-vahşi-batı-süper hızlı depolama anlamına geldiğini düşünür. Öyle değil. Anahtar / değer deposu veya nihai tutarlılık anlamına gelmez. Bunun anlamı "SQL değil", bu gezegende çok fazla veritabanı var ve bunların çoğu SQL değil [alıntı gerekli] .
Diğer cevaplarda birçok örnek bulabilirsiniz, bu yüzden onları burada listelemem gerekmiyor, ancak çeşitli işlemler için ACID uyumluluğuna sahip SQL olmayan veritabanları var, bazıları sadece tek nesne yazma için ACID, bazıları ise daha fazlasını garanti ediyor. Her veritabanı farklıdır.
"NoSQL" iyi tanımlanmış bir terim değildir. Çok belirsiz bir kavram. Bu nedenle, "NoSQL" ürünü olan ve olmayanı söylemek bile mümkün değildir. Tipik olarak etiketli markalı ürünlerin neredeyse tamamı anahtar-değer deposu değildir.
Evet, MarkLogic Server, ACID işlemleriyle çalışan bir NoSQL çözümüdür (çağırmak istediğim belge veritabanı)
NoSQL: ZODB'in büyükbabası ASİT uyumludur. http://www.zodb.org/
Ancak, sadece Python.
NoSQL'in yaratıcılarından biri olarak (Apache CouchDB'ye erken katkıda bulunmuştum ve 2009'da CBS Interactive / CNET'te düzenlenen ilk NoSQL etkinliğinde konuşmacı olarak ) Yeni algoritmaların daha önce var olmayan olasılıklar yarattığını görmek için heyecanlıyım . Calvin protokolü , CAP ve PACELC gibi fiziksel kısıtlamaları düşünmenin yeni bir yolunu sunuyor .
Aktif / pasif eşzamansız çoğaltma veya etkin / etkin eşzamanlı çoğaltma yerine Calvin, bir işlem günlüğünü korumak için RAFT benzeri bir protokol kullanarak çoğaltma kesintileri sırasında doğruluğu ve kullanılabilirliği korur. Ayrıca, işlemler her çoğaltmada belirleyici olarak işlenerek kilitlenme olasılığını ortadan kaldırır, böylece yalnızca tek bir uzlaşma turu ile anlaşma sağlanır. Bu, dünya çapında çoklu bulut uygulamalarında bile hızlı olmasını sağlar.
FaunaDB , Calvin protokolünü kullanan tek veritabanı uygulamasıdır ve NoSQL ölçeği ve esnekliği ile anabilgisayar benzeri veri bütünlüğü gerektiren iş yükleri için benzersiz şekilde uygundur.
ACID uyumlu bir anahtar / değer deposu arıyorsanız Berkeley DB var . Grafik veritabanları arasında en azından Neo4j ve HyperGraphDB , ACID işlemleri sunar (HyperGraphDB, şu anda düşük seviye depolama için aslında Berkeley DB'yi kullanır).
Vikipedi katkıda bulunanlar Bu kavram şöyle tanımlar:
[…] Geleneksel bir veritabanı sisteminin ACID garantilerini korurken, çevrimiçi işlem işleme (OLTP) okuma-yazma iş yükleri için NoSQL sistemlerinin aynı ölçeklenebilir performansını sağlamaya çalışan modern ilişkisel veritabanı yönetim sistemleri sınıfı.
[1][2][3]
[1]Nancy Lynch ve Seth Gilbert, “Brewer'in varsayımı ve tutarlı, kullanılabilir, bölüm toleranslı web hizmetlerinin fizibilitesi” , ACM SIGACT News, Cilt 33 Sayı 2 (2002), sf. 51-59.
[2] "Brewer'ın CAP Teoremi" , julianbrowne.com, Erişim 02-Mar-2010
[3] "Dağıtılmış sistemlerde Brewers CAP teoremi" , royans.net
MongoDB, 4.0 versiyonunun çoklu belge işlemleri için ASİT uyumlu olacağını duyurdu.
Sürüm 4.2. parçalı kurulumlar altında desteklemesi gerekiyor.
https://www.mongodb.com/blog/post/multi-document-transactions-in-mongodb
FoundationDB'den bahsedildi ve o zaman açık kaynak değildi. Apple tarafından iki gün önce açık kaynaklandı: https://www.foundationdb.org/blog/foundationdb-is-open-source/
Asit uyumlu olduğuna inanıyorum.
Alternatifler listesine eklemek için, tamamen ACID uyumlu başka bir NoSQL veritabanı GT.M'dir .
Hyperdex Warp http://hyperdex.org/warp/ Warp (ACID özelliği) tescillidir, ancak Hyperdex ücretsizdir.
db4o
Kendi kalıcı kalıcılığınızın veya serileştirmenin aksine, db4o ACID işlem için güvenlidir ve çalışma zamanı sırasında sorgulama, çoğaltma ve şema değişikliklerine izin verir
Tarantool tamamen ACID NoSQL veritabanıdır. CRUD işlemleri veya saklı yordamlar verebilirsiniz, her şey bir ACID özelliğine sıkı sıkıya bağlı olarak çalıştırılacaktır. Bununla ilgili bilgileri buradan da okuyabilirsiniz: http://stable.tarantool.org/doc/mpage/data-and-persistence.html
MarkLogic ayrıca ASİT uyumludur. Sanırım şu anda en büyük oyunculardan biri.
Bekleme bitti.
ASİT uyumlu NoSQL DB çıktı ----------- sitrusleaf'a bir göz atın
BergDB , başlangıçtan itibaren ACID işlemlerini çalıştırmak için tasarlanmış hafif, açık kaynaklı bir NoSQL veritabanıdır. Aslında, BergDB, veritabanının durumunu değiştirmenin tek yolunun en yüksek yalıtım düzeyine (SQL terimi: "serileştirilebilir") sahip ACID işlemlerini çalıştırmak olduğu için çoğu SQL veritabanından "daha fazla" ACID'dir . Kirli okumalar, tekrarlanamayan okumalar veya hayali okumalarla ilgili hiçbir zaman sorun olmayacaktır.
Bence, veritabanı hala yüksek performanslı; ama bana güvenme, yazılımı ben yarattım. Bunun yerine kendiniz deneyin.
Birçok modern NoSQL çözümü, ACID işlemlerini (atomik yalıtılmış çok anahtarlı güncellemeler) desteklemez, ancak çoğu uygulama düzeyinde işlem gerçekleştirmenize izin veren ilkelleri destekler.
Bir veri deposu, anahtar doğrusallaştırmayı ve karşılaştırma ve ayarlama (belge düzeyi atomisitesi) başına destekliyorsa, istemci tarafı işlemleri uygulamak yeterlidir, daha fazla seçenek arasından seçim yapabilirsiniz:
Serializable izolasyon düzeyine ihtiyacınız varsa Google'ın Percolator sistemi veya CockroachDB için Cockroach Labs için kullandığı algoritmayı takip edebilirsiniz . Bu konuda blog yazdım ve adım adım görselleştirme oluşturdum , umarım algoritmanın arkasındaki ana fikri anlamanıza yardımcı olacaktır.
Yüksek çekişme bekliyorsanız, ancak Okunan Kararlılık izolasyon seviyesine sahip olmanız iyi ise, lütfen Peter Bailis'in RAMP işlemlerine bir göz atın.
Üçüncü yaklaşım destan deseni olarak da bilinen telafi edici işlemleri kullanmaktır. 80'lerin sonlarında Sagas gazetesinde tarif edildi, ancak dağıtılmış sistemlerin yükselmesi ile daha gerçek oldu. İlham almak için lütfen Saga Desenini Uygulama konusuna bakın .
Müşteri tarafı işlemleri için uygun veri mağazaları listesi, hafif işlemlere sahip Cassandra, tutarlı kovalara sahip Riak, RethinkDB, ZooKeeper, Etdc, HBase, DynamoDB, MongoDB ve diğerlerini içerir.
YugaByte DB , sorgu katmanında bir Redid ve CQL API uyumluluğunun yanı sıra bir ACID Uyumlu dağıtılmış txns'ı da destekler .
VoltDB , ACID uyumluluğunu iddia eden bir katılımcıdır ve hala SQL kullanırken, ölçeklenebilirliği açısından hedefleri aynıdır
Bir sunucu değil, yalnızca gömülü bir motor olsa da , leveldb'de WriteBatch ve ACID davranışı sağlamak için Eşzamanlı yazma özelliğini açma özelliği bulunur.
Düğüm levelUP işlemseldir ve leveldb üzerine kurulmuştur https://github.com/rvagg/node-levelup#batch
DynamoDB bir NoSQL veritabanı ve ACID işlemlerine sahiptir .
Sadece NoSQL, tasarımla ACID uyumlu değildir. NoSQL hareketi, ACID'in tersi olduğu iddia edilen BASE'i (Temelde Kullanılabilir, Yumuşak durum, Sonunda tutarlılık) kucaklar. NoSQL veritabanı genellikle Sonunda Yapılan veritabanı olarak adlandırılır. Farklılıkları anlamak için CAP teoremine (Brewer teoremi)
Http://www.julianbrowne.com/article/viewer/brewers-cap-theorem adresini ziyaret edin