Performance

社交網路/知識庫社區的數據庫建議?

  • March 1, 2012

我正在為一個想在夏天開始的新項目研究各種數據庫類型和 DBMS。

我已經在 MySQL 和 postgreSQL 中建構了系統,現在我想擴展我在數據庫方面的知識和經驗。

我的項目將是一種社交網路/聚合知識的東西。(還沒有開發出一個術語來描述它)。

我一直在看:

  • Cassandra(使用自己的查詢語言類型);它似乎有利於功能豐富的內容和提供高性能查詢執行。但是我不太熱衷於它,因為它需要一個 java 環境才能工作,我寧願與 Oracle 無關。
  • MongoDB(noSQL 類型的 DBMS);出色的可擴展性,但是您失去了經過驗證的 SQL 語言已經具備的所有功能,例如業務資訊查詢。

系統要求:

  • 數據文本、日期、時間、xml、小整數、blob、
  • 結構/行為:規範化 3NF、非實時、關係、可擴展、穩健
  • 環境: unix/linux,沒有JAVA!,最好在C上執行

我想知道您是否可以指出我應該研究的任何其他數據庫系統。

我還查看了 Object Relational Databases ,我非常喜歡它們使用 PHP 對象(PDO)的想法,但是它們的性能似乎有點差。

鑑於這裡將有 DBA,因此對您操作過的這些系統的任何回饋將不勝感激。

謝謝

您的抽像要求向我尖叫“PostgreSQL”。但是,我認為了解資產階級的最新動態是值得的,因此這裡列出了您可能想要查看的各種內容。

免費的東西

  • CouchDB - 最早的 NoSQL 數據庫之一,強大的 map/reduce 查詢系統,高度分佈式和容錯。更好的 NoSQL 競爭者之一。
  • Hyperdex - 具有搜尋功能的非常新的分佈式雜湊表。
  • Riak - 值得尊重的分佈式雜湊表。

奇怪的免費東西

  • Metakit - 更像是像SQLite這樣的嵌入式數據庫,但不是基於 SQL 的,因此更加程序化。
  • FramerD - 很像經典的“網路”數據庫,非常以指針為中心。也許死了?
  • Magma - Smalltalk OODBMS. 很酷但沒有很好的記錄。

非免費的東西

  • AllegroGraph -RDF(圖)數據庫,支持 SPARQL. Lisp 風味的。
  • Caché - 一種混合關係/OO 數據庫,最初基於 MUMPS (IIRC)。
  • 客觀性- 最後幾個真正大的 OODB 之一。非常強大,令人印象深刻且昂貴。
  • VoltDB - 高度可擴展的主要是關係數據庫。支持“大多數”SQL。很新。我猜他們也有社區版本。

結論

我沒有廣泛使用這些東西。我和他們中的大多數人玩過一點,最後總是回到 PostgreSQL。看看您的要求,PostgreSQL 唯一不能開箱即用的就是可擴展性。另一方面,就我的目的而言,扔掉要容易得多 $ 4000 of hardware at a single dedicated database machine than to throw $ 4000 個雲節點或低端機器在這個問題上。還有一些方法可以使用 PostgreSQL 實現可伸縮性,例如EnterpriseDB

一邊玩這些東西很有趣,但是當需要將有價值的、不可重現的生產數據放入某物時,可靠性、穩定性和長期生存能力等一堆無聊的屬性就會脫穎而出。

給你的思想實驗

考慮一下。想像一下,你是馬克·扎克伯格,你必須選擇放棄你的程式碼庫或數據。你可以保留所有的開發人員,但是你要麼必須放棄所有的程式碼——每一行,甚至所有開發人員對他們如何實現一切的記憶都已經消失了——但是你可以保留所有的使用者帳戶和所有上傳的使用者數據和所有這些,或者您可以放棄所有數據。保留所有結構和伺服器以及配置、設置,但會失去每個數據庫中每個表中的每一行。

很明顯,失去數據會更糟。為什麼您的所有使用者都會重新生成所有這些數據?想想所有失去的行銷數據,這就是 Facebook 真正賺錢的方式。有大量的企業家對讓人們使用他們的 Facebook 複製的機會垂涎三尺——現在所有那些被剝奪權利的前 Facebook 使用者都將在那裡考慮替代方案。另一方面,如果他們失去了程式碼庫,他們可以重建它,甚至可能比現在更好,但他們可以在很短的時間內線上獲得一些東西。見鬼——他們可能會別人的 Facebook 複製程式碼庫並用真實數據載入它,但你不能只是複制他們的數據。如果 Facebook 的伺服器上還有每個人的重要數據,那麼離開的動機就會低得多。仍然很糟糕,但要少得多。出乎意料地少了。

具有諷刺意味的是,在一次意外事故中失去所有數據比失去所有程式碼要容易得多*。然而,對於大多數網際網路公司來說,數據就是公司,它是*你最寶貴的資產。這是考慮使用傳統的、經過時間考驗的、老式的、不受歡迎的關係數據庫的一個強有力的理由。

引用自:https://dba.stackexchange.com/questions/13744