事實上我並無作過任何大型的項目,可是高併發、大數據(此處指大量的數據,而不是在大量數據的基礎上進行分析)、性能、緩存等字眼如今更頻繁的被提出,甚至有的網友在面試普通程序員的時候也會被詢問有關的問題,並且他們還鄭重其事的諮詢個人意見,還好這只是經過網絡的問答,仍是比較容易混過去的,不過我仍是不得不認真思考一下,下次再有人問我我就能夠直接發連接了。程序員
防誤導聲明:本文內容純屬臆測,做者沒有相關的實際經驗。文章僅表明筆者對此類問題的思考角度而不是經驗之談。面試
既然要處理數據,那麼對於數據應該首先有一個認識,一樣,這隻表明我本身的觀點。算法
有經驗的程序員應該都知道,開發初期的一個小問題在後期可能演化爲災難,而我認爲核心數據與衍生數據的識別就屬於這種小問題。
什麼是核心數據呢?該數據是基於外部輸入的,除此以外咱們沒有其餘手段獲取。預約義常量也屬於核心數據的一種。
那麼相應的,衍生數據則是能夠被推導出來的,是在覈心數據的基礎上經過必定的規則計算而來。
例如在訂單信息中,用戶id、各類時間戳、商品id、數量、稅率(預約義的)就是核心數據,而小計、稅金、訂單總額之類的數據就屬於衍生數據。數據庫
若是核心數據與衍生數據是對數據的絕對分類,那麼有效數據與垃圾數據則是對數據的相對分類。好比對於會計來講,只有成交的訂單纔是有效數據,而相對的,對於銷售人員未成交的訂單可能對他們來講更有用。緩存
「敏捷」也是被常常提到的,簡單的說就是儘快的解決目前遇到的問題。由此,我認爲數據也須要敏捷,一方面避免收集無用的核心數據,可是更重要的一方面是不要產生衍生的垃圾數據。網絡
根據前述,我認爲最佳的寫入方式應該是優先寫入核心數據,而後在恰當的時間計算並寫入衍生數據,甚至於會屢次迭代「計算並寫入衍生數據」這一步,好比衍生數據的衍生數據。併發
單純的讀出只受限於計算機的性能,因此實際上此處咱們更關注的是如何找到須要的東西。沒有索引確定是最慢的,就像去垃圾堆裏面找回丟失的鉛筆;而大型超市就要好不少,可是你要先找到文教用品區;在檔案室找檔案也沒有預想的複雜,先找到檔案室,再找到其中一個櫃子,具體到一個格,一般裏面不會超過100份備選檔案。
因而可知,想更快的查找就須要管理更多的索引,而更多的索引必然消耗更多的存儲空間(固然寫入索引這種衍生數據一樣也須要時間)。
最終,我很無奈的發現,查詢速度已經在寫入數據的時候規定好了,好吧,問題獲得簡化,咱們只要考慮如何寫數據就足夠了。高併發
寫到這裏我忽然發現咱們是在研究一種很古老的東西,而不是什麼潮流,畢竟Google、Yahoo、百度已經運行這麼多年了,咱們在討論的這些問題就是搜索引擎的核心部分。性能
以上都是邏輯上的東西,即使我猜錯了某些細節也不重要,由於必然有一種正確的邏輯在支持着這一切。對速度的追求驅動了科技的進步,科技的進步造就了更快的介質,磁帶、磁盤、硬盤、內存、高速緩存,邏輯沒有變,可是當咱們使用了更快的介質,速度瓶頸就被打破一次。大數據
標題提到的種種無非是把存儲介質由硬盤遷移到內存或其它設備,區別就是硬盤是由操做系統控制的,而直接操做內存或其它設備時咱們須要使用特定的程序,可是最終數據庫軟件自己會固化此類程序。一方面咱們會見證這個過程,另外一方面咱們也在黎明前的黑暗中掙扎。
一提到MD5不少人的印象就是32位的16進制編碼,然而事實上這個用的最廣泛,MD5算法也能夠生成更多位的哈希碼,好比128位。在上文中提到檔案管理的時候我忽然想到這個問題,一個格子裏面放多少檔案更合適呢?基於迭代算法,按照十進制的方式,一個格子裏面放10份,100份,1000份?模擬一下。1374388:1號檔案樓3樓7室4號3行8列裏面的第8份檔案,也就是有10個樓,每樓10層,每層10室,每室10櫃,每櫃有10x10個檔案格,最多存放1億份檔案。18327442309981:18號檔案樓32樓74室42櫃30行99列的第81份檔案。1000份的就省略了吧。不過感受上一個格10份略少了一點,100份明顯太多了。若是是2進制呢?一個檔案格里面只有兩份檔案,檔案編號10100010001,感受上這樣分類比不分類好像也快不了多少。那麼16進制呢?感受上比較合適。那麼MD5呢?做者猜測:將數據進行MD5編碼,並以此做爲數據惟一編號,基於16進制算法建立16叉樹模型,對於32位的MD5碼其尋址時間區間爲32~512(即32*16)注:做者野路子出身,隨便亂想,雖然興高采烈的寫出來但事實上徹底多是孤陋寡聞和坐井觀天的緣由,歡迎您的任何意見,只要語言文明就好。