Lütfen alternatif veri depolama araçlarına işaret edebilir ve eski ilişkisel veritabanları yerine bunları kullanmak için iyi nedenler verebilir misiniz? Bence, çoğu uygulama nadiren SQL'in tam gücünü kullanır - SQL içermeyen bir uygulamanın nasıl oluşturulacağını görmek ilginç olurdu.
Yanıtlar:
Bir dosya sistemindeki düz metin dosyaları
Diskteki XML veya JSON dosyaları
Elektronik tablo / CSV dosyası
Subversion (veya benzeri disk tabanlı sürüm kontrol sistemi)
Berkeley DB (Temelde, disk tabanlı bir karma)
Google'ın App Engine Veri Deposu
Yerel dil koleksiyonları (bellekte depolanır veya diskte serileştirilir)
Özel (elle yazılmış) depolama motoru
Onlar hakkında çok şey bildiğimi iddia edemem, ancak nesne veritabanı sistemlerine de bakmak isteyebilirsiniz .
Matt Sheppard'ın cevabı harika (mod up), ancak bir mili düşünürken bu faktörleri dikkate alırım:
CSV dosyalarının RDBMS'lere göre özel bir avantajı, yoğunlaştırılmaları ve pratik olarak başka herhangi bir makineye taşınmalarıdır. Büyük veri aktarımları yapıyoruz ve her şey sadece bir büyük CSV dosyası kullandığımız kadar basit ve rsync gibi araçları kullanarak kodlaması kolay. Büyük CSV dosyalarındaki tekrarlamayı azaltmak için YAML gibi bir şey kullanabilirsiniz . Önemli ilişki gereksinimleriniz olmadıkça JSON veya XML gibi bir şey depolayacağımdan emin değilim.
Belirtilmeyen alternatiflere gelince , MapReduce'un açık kaynaklı bir uygulaması olan Hadoop'u indirmeyin. Analiz edilmesi gereken bir TON gevşek yapılandırılmış veriye sahipseniz ve veri işlemeyi gerçekleştirmek için sadece 10 makine daha ekleyebileceğiniz bir senaryoda olmak istiyorsanız, bu iyi çalışmalıdır.
Örneğin, yaklaşık 20 makinede kaydedilen farklı işlevlerin tüm zamanlama sayıları olan performansı analiz etmeye çalıştım. RDBMS içindeki her şeyi yapıştırmaya çalıştıktan sonra, bir kez topladıktan sonra verileri tekrar sorgulamam gerekmediğini fark ettim. Ve bu sadece benim için toplu biçiminde yararlıdır. Bu yüzden, günlük dosyalarını etrafta tutuyorum, sıkıştırıyorum ve sonra toplanmış verileri bir DB'de bırakıyorum.
Not "Büyük" boyutlarda düşünmeye daha alışkınım.
Prevayler'ı deneyin: http://www.prevayler.org/wiki/ Prevayler RDBMS'ye alternatiftir. Sitede daha fazla bilgi var.
ACID'ye ihtiyacınız yoksa , muhtemelen bir RDBMS'nin ek yüküne ihtiyacınız yoktur. İlk önce buna ihtiyacınız olup olmadığını belirleyin. Olmayan RDBMS çoğu yok burada sağlanan yanıtları değil ASİT sağlarlar.
Özel (elle yazılmış) depolama motoru / Gerekli kullanım durumlarında potansiyel olarak çok yüksek performans
Çok büyük veri kümeleriniz varsa, kendi verilerinizi döndürmek yerine Hiyerarşik Veri Biçimi olan HDF'yi kullanabilirsiniz.
http://en.wikipedia.org/wiki/Hierarchical_Data_Format :
HDF, çok boyutlu diziler, raster görüntüler ve tablolar dahil olmak üzere birçok farklı veri modelini destekler.
Aynı zamanda bir dosya sistemi gibi hiyerarşiktir, ancak veriler tek bir sihirli ikili dosyada saklanır.
HDF5, çok büyük ve karmaşık veri koleksiyonlarının yönetimini mümkün kılan bir pakettir.
NASA / JPL uzaktan algılama verilerinin petabaytlarını düşünün.
İyi günler,
Düşünebileceğim bir örnek, modellemekte olduğunuz verilerin ilişkisel bir veritabanında kolayca temsil edilememesidir.
Böyle bir örnek cep telefonu operatörleri tarafından mobil telefon şebekeleri için baz istasyonlarını izlemek ve kontrol etmek için kullanılan veritabanıdır.
Bu vakaların neredeyse hepsinde, bir OO DB , ticari bir ürün veya nesnelerin heirarchiesine izin veren kendi kendine haddelenmiş bir sistem kullanılır.
İsimsiz kalacak, ancak logosu kırmızı şarap lekesi olan büyük bir şirket için bir 3G izleme uygulaması üzerinde çalıştım (-: ve onlar içindeki bireysel hücreler için tüm çeşitli özellikleri takip etmek için böyle bir OO DB kullandılar ağ.
Bu tür DB'lerin sorgulanması, genellikle tamamen SQL içermeyen tescilli teknikler kullanılarak yapılır.
HTH.
şerefe,
soymak
Nesne veritabanları ilişkisel veritabanları değildir. Bir veritabanındaki bazı nesneleri doldurmak istiyorsanız gerçekten kullanışlı olabilirler. Ayrıca, veritabanında zaten var olan nesneler için sürüm oluşturmayı ve sınıfları değiştirmeyi de desteklerler. ilk akla gelen db4o .
Bazı durumlarda (örneğin finansal piyasa verileri ve süreç kontrolü) RDBMS yerine gerçek zamanlı bir veritabanı kullanmanız gerekebilir. Wiki bağlantısına bakın
Birkaç yıl önce JADE adlı yerleşik bir OODBMS'ye sahip olan bir RAD aracı vardı . DB motorunun önceki enkarnasyonları da Digitalk Smalltalk'i destekledi. RDBMS olmayan bir paradigma kullanarak uygulama oluşturma örneklemek istiyorsanız, bu bir başlangıç olabilir.
Diğer OODBMS ürünleri arasında Objectivity , GemStone ( Smalltalk sürümünü çalıştırmak için VisualWorks Smalltalk almanız gerekir, ancak bir java sürümü de vardır). Bu alanda bazı açık kaynaklı araştırma projeleri de vardı - EXODUS ve onun inen SHORE akla geliyor.
Ne yazık ki, muhtemelen SQL tabanlı RDMBS sistemlerine göre açıkça görülebilen bir standart ve nispeten zayıf ad-hoc sorgu yeteneğinin olmaması nedeniyle kavram bir ölümle ölmüş gibi görünüyordu.
OODBMS, en iyi birbirine bağlı düğümlerin grafiği olarak temsil edilen temel veri yapılarına sahip uygulamalar için en uygundur. Özetin özeti OODBMS uygulamasının, odaların oyuncuların avatarlarını ve diğer nesneleri içereceği Çok Kullanıcılı Zindan (MUD) olduğunu söylerdim.
Sadece dosya sisteminde saklanan dosyaları kullanarak uzun bir yol kat edebilirsiniz. RDBMS'ler lekeleri işlemede daha iyi hale gelir, ancak bu, özellikle sorgular basitse (tek tek öğeleri numaralandırma ve seçme), görüntü verilerini ve benzerlerini işlemenin doğal bir yolu olabilir.
Bir RDBMS'ye çok iyi uymayan diğer şeyler hiyerarşik veri yapılarıdır ve tahmin ediyorum ki coğrafi veri ve 3D modeller de çalışmak o kadar kolay değil.
Amazon S3 gibi hizmetler , SQL'i desteklemeyen daha basit depolama modelleri (anahtar-> değer) sağlar. Ölçeklenebilirlik burada anahtardır.
Özellikle kullanıcıların tanıdık bir ortamda verileri manipüle edebilmesi ve bunu yapmak için tam bir uygulama oluşturması gerekiyorsa, Excel dosyaları da yararlı olabilir.
Verileri depolamanın çok sayıda yolu vardır - hatta "ilişkisel veritabanları", yerel bir dosyayı (veya dosyaları) tek bir kullanıcı temelinde ilişkisel veritabanıymış gibi işleyen basit bir kod kitaplığından bir dizi alternatifi kapsar dosya tabanlı sistemlere göre çok sayıda kullanıcı ciddi "sunucu" tabanlı sistemlerin cömert bir seçim işlemek.
XML dosyalarını çok kullanıyoruz - iyi yapılandırılmış veriler, uygunsa düzenleme yapabilme yeteneğini sorgulamak için güzel araçlar, insan tarafından okunabilir bir şey elde edersiniz ve daha sonra db motorunun çalışması (veya işleyişi hakkında endişelenmenize gerek yoktur) db motoru). Bu, temelde yalnızca okunan şeyler (bizim durumumuzda başka bir yerde bir db'den üretilenden daha sık) ve ayrıca verileri yalnızca yükleyebileceğiniz ve gerektiği gibi kaydedebileceğiniz tek kullanıcı sistemleri için iyi çalışır - ancak fırsatlar yaratırsınız en azından tek bir dosyadan oluşan çok kullanıcılı düzenleme istiyorsanız sorunlar için.
Bizim için bu - ya SQL yapacak bir şey kullanacağız (MS, kurumsal sunucuya kadar tek kullanıcılı şeyler yapmak için bir .DLL'den çalışan bir dizi araç sunuyor ve hepsi aynı SQL'i konuşuyor (alt uçtaki sınırlamalarla birlikte)) veya XML'i biçim olarak kullanacağız çünkü (bizim için) ayrıntı düzeyi nadiren bir sorundur.
Şu anda uygulamalarımızdaki ikili verileri değiştirmek zorunda değiliz, bu nedenle bu soru ortaya çıkmıyor.
Murph
Uygulama verileri büyük ölçüde anahtar / değer yönelimli ve hiyerarşik nitelikte ise, geleneksel bir SQL veritabanı yerine bir LDAP sunucusunun kullanılması düşünülebilir.
BTree dosyaları genellikle ilişkisel veritabanlarından çok daha hızlıdır. SQLite, içinde kamusal alanda olan bir BTree kütüphanesi içerir (terimi 'gerçekten' kamusal alanda 'olduğu gibi, terimi gevşek bir şekilde kullanmaz).
Açıkçası, çok kullanıcılı bir sistem isteseydim, iyi bir sunucu ilişkisel veritabanı kullanmamaya ikna etmem gerekiyordu.
"10 kelimeden kısa sürede" gibi yakınlık operatörleriyle sorgulanabilen tam metin veritabanları.
İlişkisel veritabanları birçok amaç için ideal bir iş aracıdır - anlaması ve tasarımı yeterince kolay, yeterince hızlı, "tam gücü kullanabilen" bir dahi tarafından tasarlanıp optimize edilmese bile yeterli.
Ancak bazı ticari amaçlar, ilişkisel motorların sonradan düşünülmediği ya da üzerinde durmadığı tam metin dizinleme gerektirir. Özellikle, yasal ve tıbbi alanlarda, depolanacak ve geçecek büyük yapılandırılmamış metin alanları bulunmaktadır.
CAP teoremi bunu özlü bir şekilde açıklar. SQL temel olarak "Güçlü Tutarlılık: güncellemeler olsa bile tüm istemciler aynı görünümü görür".
Ben RDBMS teklif ediyorum :) Eğer kurulum / yönetim ile sıkıntılar alışkanlık yoksa SQLite için gidin. Tam SQL desteği ile dahili RDBMS. Hatta herhangi bir sütunda herhangi bir veri türünü saklamanızı sağlar.
Örneğin günlük dosyasına karşı ana avantajı: Büyük bir dosyanız varsa, onu nasıl arayacaksınız? SQL motoru ile sadece indeks oluşturur ve operasyonu önemli ölçüde hızlandırırsınız.
Tam metin araması hakkında: SQLite'nin tam metin araması için de modülleri vardır ..
Sadece verilerinize hoş bir standart arayüz tadını çıkarın :)
İlişkisel veritabanı kullanmamanın iyi bir nedeni, büyük bir veri kümeniz olduğunda ve veriler üzerinde büyük ölçüde paralel ve dağıtılmış işlem yapmak istediğinizde olabilir. Google web dizini bu tür bir duruma mükemmel bir örnek olacaktır.
Hadoop ayrıca Google Dosya Sistemi'nin Hadoop Dağıtılmış Dosya Sistemi adı verilen bir uygulamasına sahiptir .
Lua, SQLite-tür veri depolama alternatif olarak şiddetle tavsiye ediyorum.
Çünkü:
Bu, kabul edilen yanıtın "ana dil toplama" seçeneğidir. Uygulama seviyesi olarak C / C ++ kullanıyorsanız, sadece yapılandırmaları / verileri okumak veya yazmak için Lua motorunu (100kB ikili) atmak son derece mantıklıdır.