Sosyal ağ / bilgi tabanı topluluğu için veritabanı önerisi?


12

Yaz aylarında başlamak istediğim yeni bir proje için çeşitli veritabanı türlerini ve DBMS'leri arıyorum.

MySQL ve postgreSQL'de sistemler oluşturdum, şimdi Veritabanlarındaki bilgi ve deneyimimi genişletmek istiyorum.

Projem bir tür sosyal ağ / toplu bilgi konusu olacak. (hala sığınak henüz tanımlamak için bir terim geliştirdi).

Şuna bakıyorum:

  • Cassandra (kendi sorgulama türünü kullanın); Zengin özelliklere sahip içerik ve yüksek performanslı sorgu yürütme sağlamak için iyi görünüyor. Ancak üzerinde çok hevesli değilim, çünkü üzerinde çalışmak için bir java ortamı gerektiriyor ve Oracle ile ilgisi olmamayı tercih ediyorum.
  • MongoDB (noSQL DBMS türü); büyük ölçeklenebilirlik, iş bilgisi sorguları gibi kanıtlanmış SQL dilinde zaten mevcut olan tüm yetenekleri kaybedersiniz.

Sistemin gereksinimleri:

  • Veri Metni, tarihler, saatler, xml, küçük ints, damla,
  • Yapı / davranış : normalleştirilmiş 3NF, gerçek zamanlı olmayan, ilişkisel, ölçeklenebilir, sağlam
  • Çevre: unix / linux, JAVA yok!, Tercihen C ile çalışır

Beni araştırmam gereken diğer Veritabanı sistemlerine yönlendirip yönlendiremeyeceğinizi merak ediyordum.

Ayrıca Nesne İlişkisel Veritabanlarına bir göz vardı, ben oldukça PHP nesneleri (PDO) ile çalışma fikri gibi ancak performansları biraz zayıf görünüyor.

Burada DBA'lar olacağına baktığınızda, çalıştırdığınız bu sistemler hakkında herhangi bir geri bildirim takdir edilecektir.

Teşekkürler


3
Eğer normalleştirilmiş 3nf istiyorsanız ilişkisel bir mağaza yapmanız gerekir. Dönemi.
JNK

2
Java'yı sadece "Oracle" olduğu için çalmam. İş için doğru aracı kullanın. Java en iyi araçsa, onu kullanırım. C doğru işse, onu kullanın. Her bir aracın size, artıları ve eksileri ne verdiğine odaklanın. Duyguya dayanmak yerine, bu konuda (DB tarafı ile aynı) iyi eğitilmiş bir karar verin.
Chris Aldrich

Yanıtlar:


4

Soyut gereksinimleriniz bana "PostgreSQL" diye bağırıyor. Ancak, burjuvazinin ne yaptığını takip etmeye değer olduğunu düşünüyorum, bu yüzden kontrol etmek isteyebileceğiniz çeşitli şeylerin bir listesi.

Ücretsiz şeyler

  • CouchDB - ilk NoSQL veritabanlarından biri, güçlü harita / azaltma sorgulama sistemi, yüksek dağıtılmış ve hataya dayanıklı. Daha iyi NoSQL yarışmacılarından biri.
  • Hyperdex - arama özelliklerine sahip çok yeni, dağıtılmış karma tablo.
  • Riak - dağıtılmış hash tablosu biraz saygı görmeye değer.

Tuhaf ücretsiz şeyler

  • Metakit - SQLite gibi gömülü bir veritabanından daha fazlası, ancak SQL tabanlı değil, bu yüzden daha prosedürel.
  • FramerD - klasik bir "ağ" veritabanı gibi, çok işaretçi merkezli. Belki ölüdür?
  • Magma - Smalltalk OODBMS. Serin ama iyi belgelenmiş değil.

Ücretsiz olmayan şeyler

  • AllegroGraph - RDF (grafik) veritabanı, SPARQL'i destekler. Lisp aromalı.
  • Caché - başlangıçta MUMPS (IIRC) tabanlı bir hibrit ilişkisel / OO veritabanı.
  • Nesnellik - Son birkaç büyük OODB'den biri. Çok güçlü, etkileyici ve pahalı.
  • VoltDB - Yüksek oranda ölçeklenebilir çoğunlukla ilişkisel veritabanı. "En" SQL destekler. Çok yeni. Sanırım bir topluluk versiyonları da var.

Sonuç

Bunlardan hiçbirini yoğun bir şekilde kullanmadım. Çoğuyla biraz oynadım ve her zaman PostgreSQL ile geri döndüm. Gereksinimlerinize baktığımızda, PostgreSQL kutudan çıktığı tek şey ölçeklenebilirliktir. Öte yandan, benim amacım için, tek bir özel veritabanı makinesine 4000 $ donanım atmak, bu soruna 4000 $ bulut düğümleri veya düşük-uç makineler atmaktan çok daha kolay. EnterpriseDB gibi PostgreSQL ile ölçeklenebilirlik sağlamanın yolları da var .

Yanlarında bu şeylerle oynamak çok eğlencelidir, ancak değerli, yeniden üretilemez üretim verilerini bir şeye koymanın zamanı geldiğinde, güvenilirlik, istikrar ve uzun vadeli canlılık gibi sıkıcı nitelikler öne çıkmaktadır.

Sizin için düşünce deneyi

Bunu düşün. Mark Zuckerberg olduğunuzu ve kod tabanınızı ya da verilerinizi bırakmayı seçmeniz gerektiğini düşünün. Tüm geliştirme personelinizi koruyabilirsiniz, ancak ya tüm kodunuzu bırakmak zorundasınız - her satırda, tüm geliştiricilere bile her şeyin nasıl uygulandığına dair anılarınızı söyleyin - ancak tüm kullanıcı hesaplarınızı ve tüm kullanıcılarınızı yüklediniz veri ve tüm bu, ya da tüm verileri vazgeçebilir. Tüm yapıları ve sunucuları ve yapılandırmayı, kurulumu koruyun, ancak her veritabanındaki her tablodaki her satırı kaybedin.

Verileri kaybetmenin daha kötü olacağı açık olmalıdır. Tüm kullanıcılarınız neden tüm bu verileri yeniden oluştursun? Kaybedilen tüm pazarlama verilerini düşünün, Facebook aslında para kazanıyor. İnsanları Facebook klonlarını kullanma fırsatına saldıran tonlarca girişimci var - şimdi tüm haklarından mahrum bırakılmış eski Facebook kullanıcıları alternatifleri göz önünde bulundurarak dışarıda olacaklardı. Öte yandan, kod tabanını kaybettiler, muhtemelen şimdi olduğundan daha iyi olabilirler, ancak çok kısa bir sırada çevrimiçi bir şeyleri olabilirler. Heck — muhtemelen satın alabilirlerdibaşkasının Facebook klon kod tabanını klonlayın ve gerçek verilerle yükleyin, ancak verilerini kopyalayamazsınız. Facebook hala herkesin sunucularında önemli verilere sahipse, ayrılma teşviki çok daha düşüktür. Hala kötü, ama çok daha az. Şaşırtıcı derecede daha az.

İronik olan, tüm verilerinizi bir ucube kazasında kaybetmenin, tüm kodunuzu kaybetmekten çok daha kolay olmasıdır. En internet şirketleri için olsa da, veri olduğunu o şirket olan en değerli varlık. Ve bu, geleneksel, zamanla test edilmiş, eski moda, unsexy ilişkisel veritabanı kullanmayı düşünmek için güçlü bir nedendir.


Buradan silinen uzun yorum dizisinin özeti: "NOSQL mağazalarının bir şekilde veri kaybetme olasılığınızı artıracağını ima etmek haksızlıktır".
Jack diyor ki topanswers.xyz

Dediğim şey, depolama motorunun tasarımıyla değil, yaş ve geniş kullanımla ilgili.
Daniel Lyons

6

Ayrıca, bazı şeyler için ilişkisel veritabanı ve diğer şeyler için nosql veritabanını kullanamamanızın bir nedeni olmadığını düşünün.


0

Nosql konuşma, ben sadece Facebook referans hakkında eklemek için 1 şey var:

Çok büyük ölçeklendirmeyi planlıyorsanız, geliştirici dostu bir DB motor sysadmin dostu almanızı öneririm.

Coğrafi olarak dağıtılamayan ve verimli ve kolay bir şekilde yedekleme yapamayan geliştirici dostu ve süper hızlı MongoDB'den çıkın. Burada MongoDB kullanmamıza rağmen, Riak veya CouchDB sistem yöneticileri için daha iyi görünüyor (Riak veya CouchDB ile hiçbir deneyimim yok)


2
Büyük ölçeklemeyi seçerseniz, bunun nedeni zaten mikrodan küçüğe ve küçücükten küçüğe ölçeklendirilmiş olmanız ve yol boyunca doğru seçimleri yapmanıza yardımcı olacak bazı şeyleri öğrenmiş olmanızdır. Ölçeklendirmeye hazır olduğunuzda, nasıl ölçeklendirileceğini bilen mühendisleri karşılayabilirsiniz.
jcolebrand
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.