在沒有OMF(托管文件)之前，數據庫管理員在創建數據文件的時候，需要關心兩個問題。一是該為這個數據文件取一個什么樣的名字，二是需要考慮新創建的數據文件會不會與已經存在的數據文件重復。當企業的數據庫比較大，有數百個數據文件時，這項工作就會變得非常的困難。為此需要采用一種機制，對數據文件進行自動管理。在Oracle數據庫中就提供了OMF托管文件這種機制。

      計算機存儲的容量限制仍然日益成為IT系統的瓶頸。其主要原因有兩個：第一，信息革命導致人們產生了比過去多得多的數據。巨大的數據庫系統每時每刻都在產生海量的新數據。第二，隨著計算機存儲能力的增長，人們傾向于永久性保存所有的數據。例如，在信息革命早期，證券交易系統往往只保存近一段時間的交易細節數據。如今，人們傾向于保存所有能夠被保存的數據：每一次交易，每一通電話，網站的每一次點擊，交換機中的每一回通信等。

　　周 日的時候參加幾個記者朋友的派對，在有一句沒一句的聊天中，有人說Twitter真是個沒意思的東西，Tweets也大多是無意義的，除了生活的瑣碎，基 本不能在Twitter上發現什么有用的信息。我當時反駁了這些人，不知道他們有沒有認真考量我的意見，但是我相信，像我朋友這樣的Twitter Naysayer，一定有不少。以下這篇文章是我最近看到的，對Twitter Naysayer的很好的反駁，文章深入的分析了Twitter，在后web2.0時代，是怎樣的一個挖掘信息的強大工具。文章正文如下：

     最近聽說了很多關于NoSQL的新聞，比如之前Sourceforge改用MongoDB，Digg改用Cassandra等等。再加上之前做數據庫比較時有人推薦我mongodb，所以也搜索了一下NoSQL，覺得NoSQL可能真的是未來的趨勢。

　　最近討論的一個傳統的問題，問題本身比較簡單，針對key-list類型的數據，如何優化方案做到性能與成本的tradeoff。Key-list在社交產品及面向用戶的產品中非常普遍，如一個用戶的好友關系 {“uid”:{1,2,3,4,5}}，表示某個uid有1,2,3,4,5好友；一條微博下面的評論id列表結構是 {“weibo_id”: {comment_id1, comment_id2……}}，一個用戶發表的微博id列表等。

　　在《NoSQL架構實踐》系列的前面兩篇文章中，介紹了《以NoSQL為主》和《以NoSQL為輔》的架構。由于NoSQL數據庫天生具有高性能、易擴展的特點，所以我們常常結合關系數據庫，存儲一些高性能的、海量的數據。從另外一個角度看，根據NoSQL的高性能特點，它同樣適合用于緩存數據。用NoSQL緩存數據可以分為內存模式和磁盤持久化模式。

　　上一篇簡單的說明了為什么要使用NoSQL。接下來我們看下如何把NoSQL引入到我們的項目中，我們到底要不要把NoSQL引入到項目中。

　　在NoSQL的許多產品中，我們通過benchmark可以看到的都是寫性能極度提升，而讀性能并沒有太大的漲幅甚至相對傳統RDBMS還有下降。比如Cassandra，MongoDB這兩個NoSQL的杰出代表。究其原因，我們可能會想到是因為當前UGC模式已經發展到白熱化，用戶產生內容導致讀寫比已經接近或者說小于1：1。

　　馬化騰帶著一大批產品高管自上而下，持之以恒地推動產品本位的管理體制規范化，并不斷地創新和優化這套體制，使得整個公司上上下下融入了“產品的基因”，最終成就了“產品的騰訊”。

　　微信——騰訊戰略級產品，創造移動互聯網增速記錄，10個月 5000 萬手機用戶，433天之內完成用戶數從零到一億的增長過程，千萬級用戶同時在線，搖一搖每天次數過億...在技術架構上，微信是如何做到的？日前，在騰訊大講堂在中山大學校園宣講活動上，騰訊廣研助理總經理、微信技術總監周顥在兩小時的演講中揭開了微信背后的秘密。周顥，2001年畢業于華南理工大學，計算機專業碩士。2005年加入騰訊廣州研發部，歷任 QQ 郵箱架構師，廣研技術總監，T4技術專家，微信中心助理總經理。(注：演講 PPT 下載)