Saran basis data untuk komunitas jejaring sosial / basis pengetahuan?

Saya mencari berbagai tipe database dan DBMS untuk proyek baru yang ingin saya mulai di musim panas.

Saya telah membangun sistem di MySQL dan postgreSQL, sekarang saya ingin memperluas pengetahuan dan pengalaman saya di Database.

Proyek saya akan menjadi jenis jejaring sosial / pengetahuan agregat. (Masih belum mengembangkan istilah untuk menggambarkannya).

Saya telah melihat:

• Cassandra (gunakan jenis bahasa kueri sendiri); Tampaknya bagus untuk konten kaya fitur dan memberikan eksekusi permintaan berkinerja tinggi. Namun saya tidak terlalu tertarik pada itu karena memerlukan lingkungan java untuk bekerja dan saya lebih suka tidak ada hubungannya dengan Oracle.
• MongoDB (tipe DBMS noSQL); skalabilitas hebat namun Anda kehilangan semua kemampuan yang sudah tersedia pada bahasa SQL yang sudah terbukti seperti permintaan informasi bisnis.

Persyaratan sistem:

• Teks Data , tanggal, waktu, xml, int kecil, gumpalan,
• Struktur / perilaku : 3NF dinormalisasi, non realtime, relasional, scalable, kuat
• Lingkungan: unix / linux, tidak ada JAVA !, sebaiknya dijalankan di C

Saya ingin tahu apakah Anda bisa mengarahkan saya ke sistem Database lain yang harus saya teliti.

Saya juga telah melihat di Object Relational Database, saya cukup menyukai gagasan mereka bekerja dengan objek PHP (PDO) tetapi kinerja mereka tampaknya agak buruk.

Melihat akan ada DBA di sini, umpan balik apa pun pada sistem ini yang telah Anda operasikan akan dihargai.

Terima kasih

Persyaratan abstrak Anda berteriak "PostgreSQL" kepada saya. Namun, saya pikir ada baiknya mengikuti apa yang sedang dilakukan oleh borjuasi, jadi inilah daftar berbagai hal yang mungkin ingin Anda periksa.

Barang gratis

• CouchDB - salah satu dari database NoSQL pertama, peta yang kuat / sistem pengurangan permintaan, sangat terdistribusi dan toleran terhadap kesalahan. Salah satu pesaing NoSQL yang lebih baik.
• Hyperdex - tabel hash terdistribusi yang sangat baru dengan kemampuan pencarian.
• Riak - tabel hash didistribusikan layak dihormati.

Barang gratis yang aneh

• Metakit - lebih dari database tertanam seperti SQLite tetapi tidak berbasis SQL, jadi lebih prosedural.
• FramerD - mirip database "jaringan" klasik, sangat pointer-centric. Mungkin mati?
• Magma - Smalltalk OODBMS. Keren tapi tidak terdokumentasi dengan baik.

Barang-barang tidak bebas

• Database AllegroGraph - RDF (grafik), mendukung SPARQL. Cuma rasa.
• Caché - database relasional / OO hibrida, awalnya didasarkan pada MUMPS (IIRC).
• Objektivitas - Salah satu dari beberapa OODB yang sangat besar. Sangat kuat, mengesankan, dan mahal.
• VoltDB - Database relasional sebagian besar sangat terukur. Mendukung "sebagian besar" SQL. Sangat baru. Saya kira mereka juga memiliki versi komunitas.

Kesimpulan

Saya belum pernah menggunakan hal-hal ini secara ekstensif. Saya telah bermain dengan sebagian besar dari mereka sedikit dan selalu kembali dengan PostgreSQL. Melihat kebutuhan Anda, satu-satunya yang PostgreSQL tidak penuhi adalah skalabilitas. Di sisi lain, untuk keperluan saya, jauh lebih mudah untuk membuang $ 4000 perangkat keras pada satu mesin database khusus daripada membuang $ 4000 node cloud atau mesin kelas bawah pada masalah ini. Dan ada beberapa cara untuk mencapai skalabilitas dengan PostgreSQL, seperti dengan EnterpriseDB .

Sangat menyenangkan untuk bermain-main dengan hal-hal ini di samping, tetapi ketika tiba saatnya untuk menempatkan data produksi yang berharga dan tidak dapat diproduksi kembali ke dalam sesuatu, sekelompok atribut membosankan seperti keandalan, stabilitas dan kelangsungan hidup jangka panjang akhirnya muncul ke permukaan.

Eksperimen pemikiran untuk Anda

Pertimbangkan ini. Bayangkan Anda adalah Mark Zuckerberg, dan Anda harus memilih untuk melepaskan basis kode atau data Anda. Anda dapat menyimpan semua staf pengembangan Anda, tetapi Anda juga harus menyerahkan semua kode Anda — setiap baris, katakan bahkan semua memori pengembang tentang bagaimana mereka mengimplementasikan semuanya hilang — tetapi Anda harus menyimpan semua akun pengguna Anda dan semua pengguna Anda diunggah. data dan semua itu, atau Anda bisa memberikan semua data. Simpan semua struktur dan server dan konfigurasi, pengaturan, tetapi kehilangan setiap baris di setiap tabel di setiap basis data.

Seharusnya jelas bahwa akan lebih buruk kehilangan data. Mengapa semua pengguna Anda membuat ulang semua data itu? Pikirkan semua data pemasaran yang hilang, itulah cara Facebook benar-benar menghasilkan uang. Dan ada banyak pengusaha yang mengeluarkan air liur pada kesempatan untuk membuat orang menggunakan kloning Facebook mereka — sekarang semua pengguna mantan Facebook yang kehilangan haknya akan ada di luar sana mempertimbangkan alternatif. Di sisi lain, jika mereka kehilangan basis kode, mereka dapat membangunnya kembali, mungkin bahkan lebih baik daripada sekarang, tetapi mereka dapat memiliki sesuatu secara online dalam waktu yang sangat singkat. Heck — mereka mungkin bisa membelibasis kode kloning Facebook orang lain dan memuatnya dengan data nyata, tetapi Anda tidak bisa hanya menyalin data mereka. Jika Facebook masih memiliki data penting semua orang di server mereka, insentif untuk pergi jauh lebih rendah. Masih buruk, tapi apalagi begitu. Anehnya kurang begitu.

Ironinya adalah jauh lebih mudah kehilangan semua data Anda dalam kecelakaan aneh daripada kehilangan semua kode Anda. Bagi sebagian besar perusahaan internet, data adalah perusahaan, itu adalah aset Anda yang paling berharga. Dan ini adalah alasan kuat untuk mempertimbangkan menggunakan database relasional tradisional, teruji waktu, kuno, tidak seksi.

Pertimbangkan juga bahwa tidak ada alasan mengapa Anda tidak dapat menggunakan database relasional untuk beberapa hal dan database nosql untuk hal-hal lain.

Berbicara tentang nosql, saya hanya perlu menambahkan 1 hal tentang referensi Facebook:

Jika Anda berencana untuk berskala sangat besar, saya sarankan Anda mendapatkan mesin DB ramah sysadmin versus ramah ramah.

Keluar dari MongoDB yang ramah dan super cepat yang tidak dapat menskala secara geografis, dan tidak memiliki cara untuk mencadangkan secara efisien dan mudah. Meskipun di sini kita menggunakan MongoDB, tampaknya Riak atau CouchDB terlihat lebih baik dalam spesifikasi untuk sysadmin (saya tidak punya pengalaman dengan Riak atau CouchDB)