翻譯自：hadoop權威指南；
和rdbms的比較：
為什麼我們不能在許多磁碟上運用資料庫機型大規模批量分析？為什麼mapreduce是不可或缺的？
問題的答案來自於另乙個磁碟的發展趨勢：尋道時間的提高遠不如傳輸速率的提高。尋道是磁碟頭移動到指定位置的過程，並在其讀寫資料。它使磁碟操作具有延遲效應，而傳輸速率僅受限於磁碟頻寬。
如果資料的訪問模式主要是由查詢而構成的，它將在大部分的資料集的讀寫上花上相當長的時間，相比於流式讀寫（工作效率取決於傳輸速率），另一方面，如果是更新資料集的一小部分記錄，傳統的b-tree（傳統的關係性資料庫的組織結構）表現的很好，但如果是更新一資料庫的大部分資料，b-tree的效率就遠不如mapreduce，後者通過排序/合併來重建資料庫。
從許多方面來講，mapreuce似乎是rdbms的補充。在需要分析整個資料集，批量查詢，特別是即時指定分析的這些問題上，mapreduce的是很適合的，rdbms適用於在那些為了提供低延遲檢索和更新時間而建立索引的資料集上進行點查詢和更新。而mapreduce的應用場景是那些資料一次寫入，多次讀取的應用程式，不同的是關係型資料庫適用於資料集的不斷更新。
mapreduce和rdbms的另乙個不同點是在資料集上操作的結構化問題，結構化資料是能被有機整合到定義好的格式實體中的資料，像xml文件或者符合預定義好的模式的資料庫表。這是rdbms的範疇。半結構化資料，另一方面，是鬆散的，他們雖然有乙個模式，但他們常常被忽略，所以僅作為結構化資料的引導：比如，電子**，由網狀單元組成，雖然這些單元是儲存資料的地方。非結構化資料沒有指定的內部結構:純文字或者；mapreduce在半結構和結構化的資料上表現的效能非常好，因為它被設計在處理的時間內解釋資料，換據話講，鍵/值對不是資料的固有屬性，而是被分析者有機的設計出來的。
關係型資料經常是標準化，以保證其完整性，並且刪除冗餘的。而標準化給mapreduce帶來的是問題，因為它的讀取本就是乙個非本地化操作，並且mapreduce的乙個核心設想就是使高速流式讀取成為可能。
web伺服器日誌就是很好的非標準化資料集（比如，客戶端每次都被指定完整的主機名，即使同一客戶端會出現很多次），這就是為什麼所有的日誌都很適用於mapreduce進行分析。
mapreduce是乙個線性擴充套件的變成模型。程式設計師編寫兩個函式——乙個map，乙個reduce——它們都是定義了從key到value的對映。這些函式的執行和資料的大小及經營的集群無關，所以它們能不加改變的在小型資料集或大規模資料上執行。更重要的是，如果你的輸入擴大至原先的2倍，那麼執行時間也會變成原來的兩倍，但是如果你同時擴大集群規模同樣的大小，那麼執行時間就會和原先的一致。這就不是傳統rmbms的查詢了。
然而，隨著時間的推移，mapreduce和rdbms的差別逐漸變得模糊。無論是傳統關係型資料庫融入了一些mapreduce的想法，還是基於mapreduce的高階查詢語言的開發，都使mapreduce接近於傳統的資料庫。
hbase和RDBMS的區別
一 hbase是個什麼東西？首先我們來看看兩個概念，面向 行儲存和面向 列儲存。面向行儲存，我相信大夥兒應該都清楚，我們熟悉的rdbms就是此種型別的，面向行儲存的資料庫主要適合於事務性要求嚴格場合，或者說面向行儲存的儲存系統適合oltp，但是根據cap理論，傳統的rdbms，為了實現強一致性，通過...
HBase和RDBMS的區別
1沒有真正的索引 行是順序儲存的，每行中的列也是，所以不存在索引膨脹問題，而且插入效能和表的大小無關。2自動分割槽 在表增長的時候，表會自動 成區域，並分布到可用的節點上。線性擴充套件和對新節點的自動處理 增加乙個節點，把它指向現有集群並執行regionserver。3區域自動重新進行平衡，負載均勻...
關於Hadoop結合RDBMS應用的一些思考
最近一段時間一直在從事和hadoop相關的工作，主要是技術內容學習 安裝配置優化以及一些框架結構的設計。在此期間，我對於rdbms和hadoop的結合應用有了一些自己的看法，寫出來大家共同 一下。1 為什麼要用hadoop 這個在網上已近有很多的人說過這個問題，我在這裡就不多述了。但是我想說下，對於...