Design Data-Intensive Application

前言 本篇繼續探討 Design Data-Intensive Application 這本書的第三章：Storage and Retrieval 簡單整理一下本小節主要談論的架構： OLTP(Transaction) Row-orient storage Database engine Log-structure -> ex: LSM, SSTable, Lucene… page-orient(B tree) -> some RDBMs and NoSQL OLAP(Analytic) data warehouse(ETL) Column-orient storage bitmap encoding run-length encoding Column Families(Cassandra) 今天這篇主要要談論的是 OLAP 的部分 OLTP vs OLAP 兩者比較的關鍵是 事務處理(Transaction)還是分析(Analytic)？ OLTP(OnLine Transaction Processing) 以往來說，資料庫交互都圍繞在商業交易這類跟錢相關的交易(commercial transcation)，當應用拓展到不同領域後，漸漸已經跟錢無關，最後就剩下保留 交易/事務(transcation) 這個術語與概念，用於描述一組讀寫操作的邏輯單元 使用上，應用程式會需要透過索引(index)的方式查找某個鍵值對應的少量資料，依據 user 的 input(insert, update, delete)來更新紀錄 這種交互式的方式關心的是能否快速的回應 user 的 query 或 insert，在大量負載時能降低操作時的延遲，所以 disk search time 會是瓶頸，而 OLTP 應付的資料量相對於 OLAP 來說更少，也比較關心的是即時的資料．...

前言 本篇繼續探討 Design Data-Intensive Application 這本書的第三章：Storage and Retrieval 簡單整理一下本小節主要談論的架構： OLTP(Transaction) Row-orient storage Database engine Log-structure -> ex: LSM, SSTable, Lucene… page-orient(B tree) -> some RDBMs and NoSQL OLAP(Analytic) data warehouse(ETL) Column-orient storage bitmap encoding run-length encoding Column Families(Cassandra) 今天這篇主要要談論的是 OLTP 的部分，以 index structure 的設計為主題 Database storage engine 書中從被應用至 RDBMs 和 NoSQL 底層的 database storage engine 談起 Log-structured 許多資料庫都會有內部的日誌(log)，本身是一個 append-only 的文件，用於描述應用程式正在發生的事情的紀錄，或許是二進位制的，因為本來就不是設計給人類看的．但當紀錄變多時，查詢時間會很久，所以為了加速搜尋，就需要有額外的結構來輔助我們，這個 additional structure 就是 index 但為了維護這個額外的結構，會多多少少的影響到寫入的速度，因為每增加一筆資料都要更新 index，正因如此，資料庫預設都不會加上 index，而是交給程式開發者或是 DBA 來設計該用什麼樣的 index 來增快查詢，避免額外的開銷...