像MongoDB和db4o這樣的對象數據庫最近得到了很多宣傳。與他們一起玩的每個人似乎都喜歡它。我猜他們正在處理他們示例應用程序中大約640K的數據。有沒有人使用過大量數據的對象數據庫？
有沒有人試圖用大量的數據（比如50GB或更多）使用對象數據庫？你是否仍然能夠對它執行復雜的查詢（如從搜索屏幕）？它與你通常選擇的關係數據庫相比如何？
我只是好奇。我想將對象數據庫暴跌，但我需要知道它是否可以用於比示例應用程序更多的功能。
MongoDB的權力SourceForge上，紐約時報等幾個大型數據庫...
你應該閱讀MongoDB use cases。正在玩技術的人往往只是看着這個工作是如何工作的，而不是他們能夠理解這些限制的地步。對於正確的各種數據集和訪問模式，50GB對於在正確的硬件上運行的MongoDB毫無用處。
這些非關係系統着眼於RDBM作出的折衷，並稍微改變了它們。在某些情況下，一致性不如其他事情那麼重要，所以這些解決方案可以讓您將其換掉。在某些情況下，折衷仍然是相對較小的ms或者可能是secs。
關於CAP theorem也值得一讀。
這裏有一些基準上的db4o：
http://www.db4o.com/about/productinformation/benchmarks/
我認爲這最終取決於很多因素，包括數據的複雜性，但db4o的似乎肯定他們最好的掛起。
我正在尋找移動的API我肯定與堆棧溢出iPhone應用程序，我寫了一段時間，然後回到MongoDB從它現在位於MySQL數據庫中。在原始形式中，SO CC轉儲處於數GB範圍，我爲MongoDB構建文檔的方式導致了10G +數據庫。有爭議的是，我沒有很好地構建文件，但我不想花費大量時間做這件事。
如果你開始沿着這條路走下去，你會遇到的第一件事就是缺少32位的支持。當然，現在一切都轉向64位，但只是要記住。我不認爲任何主要的文檔數據庫都支持32位模式下的分頁，從代碼複雜性的角度來看這是可以理解的。
爲了測試我想要做的事情，我使用了一個64位實例EC2節點。我碰到的第二件事是，儘管當物理內存耗盡時，這臺機器有7G的內存，但事情從快到慢並沒有那麼快。我不確定在這一點上我沒有設置錯誤的東西，因爲32位系統的不支持會導致我想要使用它，但我仍然想看看它的樣子。將相同的數據轉儲裝載到MySQL中需要大約2分鐘的時間，但是用於加載兩個數據庫的腳本工作方式不同，因此我無法做出很好的比較。只要將數據的一部分數據運行到MongoDB中，只要數據庫小於7G即可。
我認爲我的承諾是大型數據庫可以正常工作，但如果要保持高性能，您可能不得不考慮數據的結構比使用傳統數據庫更多。我看到很多使用MongoDB進行日誌記錄的人，我可以想象很多這些數據庫都很龐大，但同時他們可能沒有做大量的隨機訪問，因此可能會掩蓋更多傳統應用程序的性能。最近的資源visual guide to nosql systems可能有幫助。在MongoDB之外有很多選擇。我也使用了Redis，儘管沒有使用大數據庫。
對不起，你有這樣一個悲慘的經歷。如果您仍然感興趣，可以在http://groups.google.com/group/mongodb-user/上發佈您正在做的事情，也許我們可以提供幫助？導入應該非常快，查詢聽起來像你可能只需要索引某處或某事。 – kristina 2010-03-23 20:28:20
根本不痛苦。我將補充一點，我的意圖是使得到的MongoDB數據庫「正確」。我並沒有試圖僅僅使負載與mysql數據庫相匹配，而是構建了一個代表每個問題，答案，投票和評論的完整文檔。這些都是非正規化的傾銷，我認爲這個問題的一部分是把他們拉到一起。無論如何，32位限制是我唯一真正的問題。如果我可以證明使用它，我相信我可以花更多的時間使它工作。 – carson 2010-03-23 23:29:04
有人剛剛在MongoDB中使用了12 TB的數據進行了生產。我之前知道的最大的是1TB。很多人在Mongo中保存了大量的數據。
重要的是要記住，Mongo的工作方式非常像關係數據庫：您需要正確的索引才能獲得良好的性能。您可以在查詢中使用explain（）並聯系the user list尋求幫助。
當我在2000年開始db4o時，我並沒有考慮到龐大的數據庫。關鍵目標是非常簡單地用一行代碼存儲任何複雜的對象，並以低資源消耗的方式快速，高效地完成任務，因此它可以運行嵌入式和移動設備。
隨着時間的推移，我們有很多用戶使用db4o進行webapps和大量數據，接近當前最大數據庫文件大小爲256GB（配置塊大小爲127字節）。因此，要回答您的問題：是的，db4o可以使用50GB，但您不應該計劃將其用於TB級數據（除非您可以將數據很好地分割到多個db4o數據庫中，否則單個數據庫的安裝成本可以忽略不計，你可以叫#openFile（））
的db4o被Versant 2008年收購，因爲它的capabilites（嵌入式，低的ressource消費，輕量）使它成爲一個偉大的免費產品Versant的高端對象數據庫VOD。 VOD可以對大量數據進行縮放，它比關係數據庫要好得多。我認爲它只會輕鬆超過50GB。
也許值得一提。
歐洲空間局的Planck任務正在Versant對象數據庫上運行。 http://sci.esa.int/science-e/www/object/index.cfm?fobjectid=46951
這是一個衛星，它有74個板載傳感器，去年推出了它，它映射宇宙的infrarred頻譜並將信息存儲在地圖段模型中。近來它一直在大肆宣傳，因爲它產生了一些宇宙中最酷的圖像。
無論如何，它已經產生了存儲在Versant中的25T信息並在3大洲進行復制。當明年任務完成時，總數將達到50T
也許值得注意的是，對象數據庫往往會小得多以保存相同的信息。這是因爲它們是真正規範化的，沒有數據重複的連接，沒有空的列空間浪費和索引很少，而不是100個。您可以找到有關ESA測試的公開信息，以考慮以多列關係數據庫格式存儲--vs-使用適當的對象模型並存儲在Versant對象數據庫中。 THey發現他們可以使用Versant節省75％的磁盤空間。
下面是執行： http://www.planck.fr/Piodoc/PIOlib_Overview_V1.0.pdf
在這裏，他們談論航班嗎3T 12T在測試 http://newscenter.lbl.gov/feature-stories/2008/12/10/cosmic-data/
而且......有基準，其顯示幅度Versant的訂單上更快找到分析方面的使命。
歡呼聲， - 羅伯特
TBH類似Hibernate這樣的ORM抽象這樣的事情離我真的不明白這一點的這樣一個夢幻般的工作。 – 2010-03-23 18:56:08
在大多數情況下，MongoDB並沒有真正與NHibernate和關係數據庫競爭。看看我鏈接到的用例列表。關係數據庫對於某些情況確實很糟糕，這些備用數據庫是更好的解決方案。 OP在這裏也可能不正確地使用術語對象數據庫。 – 2010-03-23 19:01:49
640K對任何人都應該足夠了。 – 2010-03-23 19:17:17