Neden verilerinizi diske kaydetmek yerine bir veritabanı kullanıyorsunuz?

Bir veritabanı yerine sadece verilerimi JSON'a seriyorum, gerektiğinde kaydedip diske yüklüyorum. Tüm veri yönetimi, SQL sorguları kullanmaktan daha hızlı VE daha kolay olan programın kendisinde yapılır. Bu nedenle veritabanlarının neden gerekli olduğunu hiç anlamadım.

Neden biri sadece verileri diske kaydetmek yerine bir veritabanı kullanmalı?

1. Bir veritabanındaki verileri sorgulayabilirsiniz (sorularınızı sorun).
2. Veritabanındaki verileri nispeten hızlı bir şekilde arayabilirsiniz.
3. JOIN'leri kullanarak iki farklı tablodaki verileri birlikte ilişkilendirebilirsiniz.
4. Bir veritabanındaki verilerden anlamlı raporlar oluşturabilirsiniz.
5. Verilerinizde yerleşik bir yapı vardır.
6. Belirli bir türdeki bilgiler her zaman yalnızca bir kez saklanır.
7. Veritabanları ACID'dir .
8. Veritabanları hataya dayanıklı.
9. Veritabanları çok büyük veri kümelerini işleyebilir.
10. Veritabanları eşzamanlıdır; birden fazla kullanıcı, verileri bozmadan aynı anda bunları kullanabilir.
11. Veritabanları iyi ölçeklenir.

Kısacası, çok çeşitli akıllı insanlar tarafından yıllarca geliştirilen, tanınmış ve kanıtlanmış teknolojilerden faydalanırsınız.

Bir veritabanının fazla olduğundan endişeleniyorsanız, SQLite'a göz atın.

Robert’in söylediği her şeyle aynı fikirdeyken, verileri diske kaydetmenin aksine, bir veritabanını ne zaman kullanmanız gerektiğini size söylemedi.

Öyleyse bunu Robert’ın ölçeklenebilirlik, güvenilirlik, hata toleransı, vb. Hakkında söylediklerine ek olarak alın.

RDBMS'yi ne zaman kullanacağınızla ilgili olarak, göz önünde bulundurmanız gereken bazı noktalar şunlardır:

• İlişkisel verileriniz var, yani ürünlerinizi satın alan bir müşteriniz var ve bu ürünler bir tedarikçiye ve üreticiye sahip
• Çok miktarda veriye sahipsiniz ve ilgili bilgileri hızlı bir şekilde bulabilmeniz gerekiyor.
• Tanımlanan önceki konular hakkında endişelenmeye başlamanız gerekir: ölçeklenebilirlik, güvenilirlik, ACID uyumluluğu
• İşle ilgili sorunları çözmek için raporlama veya istihbarat araçlarını kullanmanız gerekir.

NoSQL kullanmaya gelince

• Saklanması gereken ve yapılandırılmamış birçok veriye sahipsiniz.
• Ölçeklenebilirlik ve hız ihtiyaçları
• Genellikle şemanızı önceden tanımlamanıza gerek yoktur, bu nedenle değişen gereksinimleriniz varsa, bu iyi bir nokta olabilir

Son olarak, ne zaman dosya kullanılır

• Dosya sisteminin işleyebileceği makul miktarlarda yapılandırılmamış verileriniz var.
• Yapı, ilişkiler umrunda değil
• Ölçeklenebilirlik veya güvenilirlik umrunda değil (bunlar dosya sistemine bağlı olarak yapılabilir)
• Bir veritabanının ekleyeceği ek yükü istemezsiniz veya işlemezsiniz
• Örneğin, dosya sistemine ait yapılandırılmış ikili verilerle uğraşıyorsunuz, örneğin: görüntüler, PDF'ler, belgeler vb.

Kimsenin bahsetmediği bir şey var ki kayıtların indekslenmesi. Şu anda yaklaşımınız gayet iyi ve çok küçük bir veri kümeniz olduğunu ve buna çok az kişinin eriştiğini varsayıyorum.

Daha karmaşık hale geldikçe, aslında bir veritabanı yaratıyorsunuz. Her ne çağırmak isteseniz, bir veritabanı diske kaydedilmiş kayıtlardan ibarettir. Dosyayı oluştururken veya MySQL , SQLite veya dosyaları oluştururken ne olursa olsun, ikisi de veritabanlarıdır.

Eksik olan, kullanımlarını kolaylaştırmak için veritabanı sistemlerinde yerleşik olan karmaşık işlevdir.

Akla gelen en önemli şey endekslemedir. Tamam, seri hale getirilmiş bir dizide veya bir JSON dizisinde 10 veya 20 veya hatta 100 veya 1000 kaydı saklayıp dosyanızdan çekip nispeten hızlı bir şekilde yineleyebilirsiniz .

Şimdi, 10.000, 100.000, hatta 1.000.000 kayıt bulunduğunu hayal edin. Birisi oturum açmaya çalıştığında, artık birkaç yüz megabayt büyüklüğünde bir dosyayı açmanız gerekecek, onu programınızdaki belleğe yükleyin, benzer boyuttaki bir bilgi dizisini çıkarın ve sonra sadece yüz binlerce kaydı yineleyin erişmek istediğiniz bir kaydı bulun.

Uygun bir veritabanı, kayıtlarda belirli alanlarda indeksler oluşturmanızı ve veritabanını sorgulamanızı ve çok büyük veri kümelerinde bile çok hızlı bir şekilde yanıt almanızı sağlar. Bunu Memcached veya hatta bir ev yapımı önbellekleme sistemi gibi bir şeyle birleştirin (örneğin, bir aramanın sonuçlarını 10 dakika boyunca ayrı bir tabloda saklayın ve bir başkasının aynı şeyi araması durumunda bu sonuçları yükleyin) ve yanan hızlı sorgulara sahip olacaksınız, manuel olarak dosya okurken / yazarken böyle büyük bir veri setiyle elde edemeyeceğiniz bir şey olacak.

Endekslemeyle gevşek bir şekilde ilişkili olan bir diğer şey de bilgi aktarımıdır. Yukarıda belirttiğim gibi, yüzlerce veya binlerce megabaytlık dosya bulunduğunda, tüm bu bilgileri belleğe yüklemek zorundasınız, el ile yineleyin (muhtemelen aynı iş parçacığında) ve verilerinizi değiştirin.

Bir veritabanı sistemiyle kendi iş parçacığında ya da kendi sunucusunda çalışacaktır. Programınız ve veritabanı sunucusu arasında aktarılanların tümü bir SQL sorgusu ve geri aktarılanların tümü erişmek istediğiniz veridir. Tüm veri setini belleğe yüklemiyorsunuz - tüm gönderdiğiniz ve aldığınız toplam veri kümenizin küçük bir kısmı.

Basit verileriniz olduğunda, sorunuzun yorumunda açıkladığınız şeylerin bir listesi gibi, o zaman bir SQL veritabanı size pek bir şey vermez. Pek çok insan hala bunları kullanıyor, çünkü verilerinin zaman içinde daha karmaşık hale gelebileceğini biliyorlar ve veritabanında önemsiz kılan birçok kitaplık var.

Ancak yüklediğiniz, bellekte tuttuğunuz, sonra gerektiğinde yazdığınız basit bir liste olsa bile, bir takım sorunlardan muzdarip olabilir:

Anormal program sonlandırma veri kaybedebilir veya diske veri yazarken bir şeyler ters gider ve tüm dosyayı öldürmeye son verebilirsiniz. Bunu yapabilmek için kendi mekanizmalarınızı kullanabilirsiniz, ancak veritabanları bunu kanıtlanmış savaş tekniklerini kullanarak sizin için halleder.

Verileriniz çok büyüyüp çok sık güncellenmeye başlarsa, tüm verilerinizi seri hale getirmek ve tasarruf etmek büyük bir kaynak olacak ve her şeyi yavaşlatacak. Bir şeyleri nasıl bölmek için çalışmaya başlamalısın, bu yüzden o kadar pahalı olmaz. Veritabanları, yalnızca diske değişen şeyleri hataya dayanıklı bir şekilde kaydetmek için optimize edilmiştir. Ayrıca tasarlanmışlardır, böylece istediğiniz zaman küçük veri parçalarını hızlıca yükleyebilirsiniz.

Ayrıca, SQL veritabanlarını kullanmak zorunda değilsiniz. Sen kullanabilirsiniz NoSQL , sadece veri depolamak için JSON kullanırım çok "veritabanlarını". Ancak, hataya dayanıklı bir şekilde ve verilerin akıllıca bölünebileceği, sorgulanabileceği ve akıllıca birden fazla bilgisayara bölünebileceği şekilde yapılır.

Ayrıca, bazı insanlar işleri karıştırır. Giriş bilgilerini depolamak için Redis gibi bir NoSQL veri deposunu kullanabilirler . Ardından, daha ilginç sorgular yapmaları gereken yerlerde daha karmaşık verileri depolamak için ilişkisel veritabanlarını kullanın.

Eşzamanlılık ve güvenilirlik sorununa odaklanan birçok cevap görüyorum. Veritabanları eşzamanlılık, güvenilirlik ve performansın yanı sıra başka avantajlar da sağlar. Baytların ve karakterlerin bellekte nasıl temsil edildiğini rahatsız etmemelerine izin verir. Başka bir deyişle, veritabanları programcının kendisini “nasıl” yerine “neye” odaklanmasına izin verir.

Cevaplardan biri sorgulardan bahsediyor. "SQL veritabanına bir soru sormak" bir sorunun karmaşıklığı ile iyi ölçeklenir. Kod geliştirme sırasında geliştikçe, "hepsini getir" gibi basit sorgular, özellik1'in bu değere eşit olduğu ve ardından özellik2'ye göre sıralanabildikleri her şeyi getirecek şekilde kolayca genişletilebiliyor. Sorguların çoğu, belirli bir özellik için dizin oluşturarak performansı hızlandırabilir.

Diğer fayda, ilişkilerdir. Sorgularla iç içe döngülere sahip olan farklı veri kümelerinden gelen verileri çapraz referanslamak daha kolaydır. Örneğin, kullanıcıların ve gönderilerin farklı veri kümeleri (veya DB tabloları veya JSON nesneleri) olduğu bir sistemde 3'ten daha az kullanıcıya sahip tüm forum mesajlarını aramak, okunabilirlikten ödün vermeden tek bir sorgu ile yapılabilir.

Sonuçta, SQL veritabanları daha iyidir, eğer veri hacmi büyükse (1000'den fazla nesne diyelim), önemsiz olmayan ve farklı kod bölümlerinde farklı veri alt kümelerine erişim.

TLDR

Uygulamanız için esasen geçerli, kısa vadeli bir veri deposu teknik kararı verdiğiniz anlaşılıyor - özel bir veri deposu yönetim aracı yazmayı seçtiniz.

Her iki yönde hareket etme seçenekleri ile bir süreklilik üzerinde oturuyorsunuz.

Uzun vadede, muhtemelen (neredeyse, ancak% 100 kesinlikle değil) başınızın belada olduğunu göreceksiniz ve mevcut veri deposu çözümlerini kullanmakta değişiklik yapmanız daha iyi olabilir. Başa çıkmanız gereken özel, çok yaygın, öngörülebilir performans sorunları vardır ve kendi araçlarınızı kullanmak yerine mevcut araçları kullanmaktan daha iyi olursunuz.

Uygulamanızın içine yerleştirilmiş ve doğrudan kullanılan (küçük) bir özel amaçlı veritabanı yazmışsınız gibi gözüküyor. Fiili disk yazmayı ve okumayı yönetmek ve kombinasyonu veri deposu olarak değerlendirmek için bir işletim sistemine ve dosya sistemine güvendiğinizi farz ediyorum.

Ne yaptığını ne zaman yapmalı

Veri depolamak için tatlı bir yerde oturuyorsun. Bir işletim sistemi ve dosya sistemi veri deposu inanılmaz derecede kullanışlı, erişilebilir ve platformlar arası taşınabilir. Kombinasyon, neredeyse her standart dağıtım yapılandırmasında, sizin desteklendiğinizden ve uygulamanızın çalışmasını sağladığınızdan emin olun.

Aynı zamanda kod yazmak için de kolay bir kombinasyon - API oldukça basit ve basit ve çalışmasını sağlamak için nispeten az sayıda kod satırı gerekiyor.

Genellikle ne yaptığınızı yapmak idealdir:

• Yeni fikirlerin prototiplenmesi
• Akıllıca ölçeklendirilmesi gerekmeyen uygulamalar oluşturmak, akıllıca yapmak
• Bir veritabanı kurmak için kaynak yetersizliği gibi olağandışı koşullar tarafından sınırlandırılmıştır.

Alternatifler

Süreklilik arzusunuz, ve buradan aşağıya gidebileceğiniz, 'aşağı' ve 'yukarı' olarak düşündüğüm iki yön var:

Aşağı

Bu, uygulanacak en düşük seçenek, ancak bütünlük uğruna burada:

İsterseniz aşağı inebilir , yani işletim sistemi ve dosya sistemini tamamen atlayabilir ve doğrudan diskten yazabilir ve okuyabilirsiniz. Bu seçim sadece aşırı verimlilik gerektiren durumlarda genellikle alakalı olduğunu - düşünmek, örneğin, minimal bir / küçücük bir MP3 yeterli olmadan, oyuncu cihazının RAM tamamen işlevsel OS için ya da benzeri bir şey Wayback Machine inanılmaz etkili kitle gerektirir veri yazma işlemleri (çoğu veri deposu daha hızlı okuma için daha yavaş yazılar yazar, çünkü neredeyse tüm uygulamalar için çok daha yaygın kullanım durumudur).

yukarı

Burada birkaç alt kategori var - bunlar yine de tamamen dışlayıcı değil. Bazı araçlar her ikisinde de işlevsellik sağlayan, her ikisi de bir modda çalışmaktan diğerine çalışmak arasında tamamen geçiş yapabilir ve bazıları uygulamanızın farklı bölümlerine farklı işlevler sağlayarak birbirlerinin üzerine yerleştirilebilir.

Daha güçlü veri depoları

Veri manipülasyon karmaşıklığını yönetmek için hala kendi uygulamanıza güvenirken, daha yüksek ve daha yüksek miktarda veri depolamak için kendinizi ihtiyaç duyabilirsiniz. İlgili işlevler için çeşitli destek uzantılarıyla birlikte çok çeşitli anahtar / değer depoları bulunmaktadır. NoSQL araçları diğerlerinin yanı sıra bu kategoriye girer.

Aşağıdakiler uygulamanızı tanımladığında ölçeklendirmenin açık yolu budur:

• Olağandışı ağır okuma bağımlı
• Düşük (kısa vadeli) tutarlılık garantileri için yüksek performansla işlem yapma konusunda sorun değil (çoğu teklif "nihai tutarlılık").
• Veri manipülasyonunun ve tutarlılık eksikliğinin çoğunu "doğrudan" idare ediyor mu (pratikte muhtemelen ilk önce üçüncü taraf bir araç kullanacaksınız, ancak sonunda bunu uygulamanıza veya özel bir yazılı ara katmana getireceksiniz) .
• Sakladığınız veri miktarını ve / veya "nispeten basit" veri manipülasyon gereklilikleriyle arama yeteneğinizi büyük ölçüde ölçeklendirmek istiyorsunuz.

Burada bir kıpırdatma odası var - daha yavaş okumalar için daha iyi okuma tutarlılığı elde edebilirsiniz. Çeşitli araçlar ve seçenekler, belirli uygulamanızı kolayca yazmak için uygun olabilecek veri manipülasyonu apis, indeksleme ve diğer seçenekleri sağlar. Dolayısıyla, yukarıdaki noktalar uygulamanızı neredeyse tamamen açıklarsa, daha güçlü bir veri deposu çözümü ile çalışmak için "yeterince yakın" olabilirsiniz.

Tanınmış örnekler: CouchDB , MongoDB , Redis , Microsoft'un Azure , Google App Veri Mağazası ve Amazon'un ECE'si gibi bulut depolama çözümleri .

Daha karmaşık veri işleme motorları

Veri depolama uygulamasının "SQL" ailesi ve diğerleri de saf veri depolama araçlarından ziyade veri işleme aracı olarak tanımlanmaktadır. Verilerin depolanmasının ötesinde ve çoğu zaman işlerin anahtar değer deposunda mevcut olanların ötesinde çok çeşitli ek işlevler sunarlar. Aşağıdaki durumlarda bu yolu kullanmak isteyeceksiniz:

• Performansta bir başarıya ulaşacağınız anlamına gelse bile kesinlikle tutarlı olmalısınız.
• Verimli bir şekilde karmaşık veri işlemlerini verimli bir şekilde yapmak istiyorsunuz - çok karmaşık JOIN ve UPDATE işlemlerini, veri küplerini ve dilimlemeyi, vb. Düşünün ...
• Performans için sağlamlık elde etmekte sorun yok (kolay ve / veya verimli bir şekilde değiştirilemeyen tablolar gibi zorlanmış, sabit veri depolama formatları düşünün).
• Çoğu zaman daha karmaşık araçlar ve arabirimlerle başa çıkacak kaynaklara sahipsiniz.

Bu, bir veritabanı veya veri deposunu düşünmenin daha "geleneksel" yoludur ve çok daha uzun zamandır var - bu yüzden burada mevcut çok şey var ve bununla başa çıkmak için çok fazla karmaşıklık var. Bazı uzmanlık ve bilgi almak ve basit çözümler üretmek / karmaşıklığın çoğundan kaçınmak mümkün olsa da, bu muhtemelen sizin için çoğunu yönetmek için üçüncü taraf araçlarını ve kütüphanelerini kullanmanızla sonuçlanacaktır.

İyi bilinen örnekler MySQL , SQL Server , Oracle'ın Veritabanı ve DB2'dir .

İşin dış kaynak kullanımı

Karmaşıklığı yönetmenize yardımcı olmak için, veri depolama araçlarınız ve uygulamanız arasında bir araya gelen çeşitli, modern, üçüncü taraf araçlar ve kütüphaneler vardır.

Başlangıçta, veri depolarını yönetme ve manipüle etme işinin çoğunu veya tamamını elinden almaya çalışırlar ve ideal olarak, yalnızca gerektiğinde ve gerektiğinde karmaşıklığa sorunsuz bir geçiş yapmanıza izin verir. Bu, hemen ulaşılabilir ve kullanılabilir bir kaç sonuçla birlikte aktif bir girişimcilik ve araştırma alanıdır.

İyi bilinen örnekler, MVC araçları ( Django , Yii ), Ruby on Rails ve Datomic'dir . Kelimenin tam anlamıyla adil olması zordur çünkü kelimenin tam anlamıyla çeşitli veri depolarının API'leri etrafına sarmalayıcı görevi yapan düzinelerce araç ve kitaplık vardır.

Not: Metni videoya çevirmeyi tercih ederseniz, Rich Hickey'in veritabanı ile ilgili bazı videolarını izlemek isteyebilirsiniz; Bir veri deposunu seçme, tasarlama ve kullanma konusundaki düşüncenin çoğunu açıklamak için iyi bir iş çıkarmıştır.

Bir dosya sistemi bir NoSQL veritabanının tanımına uyuyor, bu nedenle verilerinizi nasıl depolayacağınıza karar verirken bunu kullanmayı kesinlikle düşünmelisiniz, sadece RDBMS'nin lehine reddetmekle kalmayıp, bazı cevapların burada ortaya koyduğu gibi görünüyor.

Dosya sistemleriyle ilgili bir sorun (ve genel olarak NoSQL) veriler arasındaki ilişkileri ele almaktır. Buradaki ana engelleyici değilse, şimdilik RDBMS'yi atlayın derim. Ayrıca bir dosya sistemini depolama alanı olarak kullanmanın olumlu yanlarını da unutmayın:

• Sıfır yönetimi
• Düşük karmaşıklık, kurulumu kolay
• Herhangi bir işletim sistemi, dil, platform, kütüphaneler vb. İle çalışır
• Dizin sadece yapılandırma ayarlarıdır.
• Test etmek önemsiz
• Mevcut araçlarla inceleme, yedekleme, değiştirme vb.
• İyi performans özellikleri ve işletim sistemi tarafından iyi ayarlanmış
• Herhangi bir geliştiricinin anlaması kolay
• Bağımlılık yok, ekstra sürücüler yok
• Güvenlik modeli anlamak için önemsizdir ve işletim sisteminin temel bir parçasıdır
• Veri dışarıdan erişilebilir değil

( kaynak )

Dosya sistemleri bir tür veritabanıdır. Belki de herkes gibi konuştuğu gibi bir RDBMS değil, en kesin anlamıyla kesinlikle bir DB. Özetlenen depolama alanlarına ve programınızın iletişim kurduğu bir API'ye sahip arama verisine (dosya içeriği) ilişkin anahtarlar (dosya adı) sağlarsınız.

Yani, bir veritabanı kullanıyorsunuz. Diğer yazılar, farklı veritabanı türlerinin erdemleri hakkında tartışabilir ...

Verileri değiştiren birden fazla işleminiz varsa (kullanıcılar / sunucular) bir veritabanı gerekir. Ardından veritabanı, birbirlerinin değişikliklerinin üzerine yazmalarını önlemeye yarar.

Verileriniz bellekten büyük olduğunda da bir veritabanına ihtiyacınız vardır. Günümüzde elimizdeki hafıza ile, bu aslında pek çok uygulamada veritabanlarının kullanılmasını engellemektedir.

Yaklaşımınız kesinlikle "hafıza içi veritabanlarının" saçmalıklarından daha iyidir. Bu esasen sizin yaklaşımınızdır, fakat ek yükler çok fazladır.

Belirli bir uygulamanın bir RDBMS'ye ihtiyacı olup olmadığını her zaman kendinize sormalısınız. Gerekli tüm araçları ve çerçeveleri başlangıçta otomatik olarak varsayan bir tasarım süreci ile çok fazla uygulama oluşturulmuştur. İlişkisel veritabanları çok yaygındır ve birçok geliştirici daha önce olduğu gibi benzer uygulamalar üzerinde çalışmış olup, bunlar proje başlamadan önce otomatik olarak dahil edilmiştir. Birçok proje bununla başedebilir, bu yüzden çok sert yargılama.

Projenize bir olmadan başladınız ve işe yarıyor. SQL'e kadar beklemeden bu işlemi çalıştırıp çalıştırmanız daha kolaydı. Bunda yanlış bir şey yok.

Bu proje genişledikçe ve gereksinimler daha karmaşık hale geldikçe, bazı şeylerin inşa edilmesi zorlaşacaktır. Alternatif yöntemleri araştırıp test edene kadar hangisinin daha iyi olduğunu nereden biliyorsunuz? Alevlerden Programcılara ve yabancı otlara sorabilirsiniz ve bu soruyu cevaplamak için 'bağlıdır'. Öğrendikten sonra, bir veritabanının avantajlarından bazılarını ele almak için kendi dilinizde ne kadar kod satırı yazmak istediğinizi düşünebilirsiniz. Bir noktada, tekerleği yeniden icat ediyorsun.

Kolay genellikle görecelidir. Kullanıcının herhangi bir kod yazmasını gerektirmeden bir web sayfası oluşturabilecek ve bir formu bir veritabanı tablosuna bağlayabilecek bazı çerçeveler vardır. Sanırım fare ile mücadele edersen, bu bir sorun olabilir. Herkes biliyor, bu ölçeklenebilir veya esnek değil, çünkü tanrı her şeyi GUI ile sıkı sıkıya bağlamanızı yasaklıyor. Programcı olmayan bir prototip üretti; Burada birçok YAGNI bulunur.

SQL öğrenmek yerine seçtiğiniz dilde manipüle edilen bir ORM öğrenmek istiyorsanız , devam edin, ancak bir tablo oluşturmaya ve bazı verileri SQL ile popüler bir veritabanından çıkarmaya çalışın (Seç * Kimden; akıllara durgunluk veren şeyler). Yapması kolay. Bu yüzden birileri onları ilk etapta yarattı. Bilgili bir karar vermek için böyle büyük bir yatırım gibi görünmüyor. Muhtemelen bir performans testi de yapabilirsin.

Verilerin diske kaydetme IS Eğer kayıt anahtarı olan dosyanın adıyla kendi dosyasındaki her nesneyi koymak, özellikle eğer bir veritabanına yazma. Dosyayı okumak için arama sürelerini en aza indirmek için, anahtarın ilk birkaç karakterini temel alan alt dizinler oluşturun.

Örneğin, key = ghostwriter, g / ho / stwriter.json veya g / h / o / stwriter.json veya g / ho / ghostwriter.json veya g / h / o / ghostwriter.json öğelerine gider. Anahtarlarınızın dağıtımına göre adlandırma düzeninizi seçin. Sıra numaraları ise 5/4/3 / 12345.json, etrafındakilerden daha iyidir.

Bu bir veritabanıdır ve ihtiyacınız olan her şeyi yaparsa, o şekilde yapın. Günümüzde bu GDBM veya Berkeley db gibi bir NoSQL veritabanı olarak adlandırılacak. Çok fazla seçenek. Önce neye ihtiyacınız olduğunu belirleyin, sonra ayrıntılarla başa çıkmak için bir arabirim kütüphanesi oluşturun, belki de memcached veya bir CRUD arayüzü gibi bir get / set arayüzü, ve sonra bir tane için veritabanı biçimini değiştirmeniz gerekirse, kütüphaneleri değiştirebileceksiniz. farklı özelliklere sahip.

PostgreSQL ve Apache Derby DB gibi bazı SQL veritabanlarının, kendi homegrown veritabanlarınız dahil olmak üzere birçok NoSQL formatının üzerinde SQL sorguları yapmanıza izin vereceğini unutmayın. MyBatis hakkında emin değilim ama benzer olabilir.

NoSQL yutturmaca kaçının. Özellikleri okuyun, performansı ve kapasiteyi test edin ve ardından uygulamanızın gereksinimlerine ne kadar iyi uyduğunu temel alarak seçin.

http://www.hdfgroup.org/HDF5/ , insanların genellikle göz önünde bulundurmadığı ilginç ve yaygın olarak kullanılan başka bir veri formatı formatıdır.

Veriler eşzamanlı olarak güncellenir güncellenmez, bir veri tabanı kullanan yaklaşım (bellek veri tabanında da olabilir) büyük olasılıkla daha doğru ve daha performanslı olur, aynı zamanda kodunuz kolay kalır, çünkü eşzamanlı güncellemeler, işlemler, önbellekleme, asenkron I / O ve diğerleri hakkında endişelenmek.

Burada gönderdiklerimiz gibi QA'ları depolamak / almak için bir veritabanına ihtiyacınız var! Basit bir dosya, farklı konularla ilgili verileri düzenleyemiyor.