1. 資料庫
1.1. 資料庫管理系統
-
1.1.1. 用於儲存和提供資料的資料庫系統
-
1.1.2. 簡稱DBMS，它由儲存引擎、查詢最佳化器、災難恢復和其他管理資料庫系統的關鍵元件組成
-
1.1.2.1. 查詢
-
1.1.2.2. 查詢最佳化器
-
1.1.2.3. 擴充套件和分發
-
1.1.2.4. 模型
-
1.1.2.5. CRUD
-
1.1.2.6. 一致性
-
1.2. 關聯式資料庫
-
1.2.1. 最常見的應用程式後端之一
-
1.2.2. 表通常由主鍵索引，主鍵是表中每一行的唯一欄位
- 1.2.2.1. 主鍵的索引策略與表在磁碟上的佈局密切相關
-
1.2.3. RDBMS系統通常是ACID相容的
-
1.2.4. 將規範化模式、ACID相容和對高事務率的支援相結合，使關聯式資料庫系統成為有快速儲存變化的應用程式的理想選擇
1.3. NoSQL
-
1.3.1. 非關聯式資料庫
-
1.3.1.1. NoSQL，代表不僅是SQL，還指全部放棄關係正規化的資料庫
-
1.3.1.2. 刪除關係約束可以提高效能、可擴充套件性和模式的靈活性
-
1.3.1.3. NoSQL一詞於1998年首次出現，但現代版本是由Eric Evans在21世紀00年代創造的
-
-
1.3.2. 鍵值儲存
-
1.3.2.1. 鍵值資料庫是一種非關聯式資料庫，它使用唯一標識每條記錄的鍵來檢索記錄
-
1.3.2.2. 類似於許多程式語言中提供的雜湊對映或字典資料結構，但具有潛在的可擴充套件性
-
1.3.2.3. 記憶體中的鍵值資料庫常用於Web和移動應用程式的快取對話資料儲存
-
1.3.2.4. 鍵值儲存也可以服務於需要高持久化的應用
-
-
1.3.3. 文件儲存
-
1.3.3.1. 文件儲存是一種專門的鍵值儲存
-
1.3.3.2. 文件是一個巢狀物件
-
1.3.3.3. 將每個文件視為一個JSON物件
1.3.3.3.1. 所有關係資料都可以儲存在同一個文件中
-
1.3.3.4. 文件儲存在集合中並透過鍵值檢索
1.3.3.4.1. 集合大致相當於關聯式資料庫中的表
-
1.3.3.5. 關聯式資料庫和文件儲存之間的一個主要區別是後者不支援連線
1.3.3.5.1. 意味著資料不能輕易規範化，即拆分到多個表中
-
1.3.3.6. 文件儲存通常不符合ACID，這與關聯式資料庫不同
-
1.3.3.7. 文件資料庫通常包含JSON的所有靈活性，並且不強制要求模式或型別
1.3.3.7.1. 模式具有高度的靈活性和表現力，還可以隨著應用程式的增加而發展
1.3.3.7.2. 文件資料庫成為管理和查詢的噩夢
-
1.3.3.8. 要對文件儲存進行分析，工程師通常必須執行全面掃描以從集合中獲取所有資料，或採用CDC策略將事件傳送到目標流
1.3.3.8.1. 全掃描方法可能對效能和成本都有影響
1.3.3.8.2. 掃描通常會減慢資料庫的執行速度，而且許多無伺服器雲產品對每次全面掃描都收取高額費用
-
-
1.3.4. 寬列資料庫
-
1.3.4.1. 寬列資料庫針對儲存大量資料進行了最佳化，具有高事務率和極低的延遲
-
1.3.4.2. 寬列資料庫可以支援PB級資料、每秒數百萬次請求和低於10毫秒的延遲
-
1.3.4.3. 在電子商務、金融科技、廣告技術、物聯網和實時個性化應用程式中廣受歡迎
-
1.3.4.4. 資料工程師必須瞭解他們所使用的寬列資料庫的操作特徵，以設定合適的配置、設計架構並選擇合適的行鍵來最佳化效能並避免常見的操作問題
-
-
1.3.5. 圖資料庫
-
1.3.5.1. 圖資料庫以數學圖形結構（作為節點和邊的集合）來儲存資料
-
1.3.5.2. Neo4j已經被證明是非常受歡迎的
-
1.3.5.3. 資料結構允許基於元素之間的連線性進行查詢
-
1.3.5.4. 根據底層圖資料庫引擎，圖資料庫利用專門的查詢語言
1.3.5.4.1. SPARQL、資源描述框架(Resource Description Framework，RDF)、圖形查詢語言(Graph Query Language，GQL)和Cypher
-
1.3.5.5. 圖資料可以重新編碼為關聯式資料庫中的行，這可能是一個合適的解決方案，具體取決於分析用例
1.3.5.5.1. 交易型圖資料庫也是為分析而設計的，但大型查詢可能會使生產系統過載
1.3.5.5.2. 當代基於雲的圖資料庫支援對大量資料的重讀和圖形分析
-
1.3.5.6. 將源系統的圖資料對映到現有的一個首選正規化中去
-
1.3.5.7. 在源系統本身中分析圖資料
-
1.3.5.8. 採用特定於圖的分析工具
-
-
1.3.6. 搜尋資料庫
-
1.3.6.1. 搜尋資料庫是一個非關聯式資料庫，用於探測你的資料的複雜度和直接的語義和結構特徵
-
1.3.6.2. 搜尋資料庫有兩個突出的用例：文字搜尋和日誌分析
-
1.3.6.3. 文字搜尋包括在文字體中搜尋關鍵詞或短語，對精確、模糊或語義相似的進行匹配
1.3.6.3.1. 日誌分析通常用於異常檢測、實時監控、安全分析和運營分析
-
-
1.3.7. 時間序列
-
1.3.7.1. 一個時間序列是由時間組成的一系列數值
1.3.7.1.1. 股票價格可能隨著一天中交易的進行而變化
1.3.7.1.2. 一個天氣感測器每分鐘都會測量大氣溫度
-
1.3.7.2. 任何定期或零星記錄的事件都是時間序列資料
-
1.3.7.3. 時間序列資料庫是為時間序列資料的檢索和統計流程而最佳化的
-
1.3.7.4. 時間序列資料庫解決了來自物聯網、事件和應用程式日誌、廣告技術和金融科技以及其他許多用例的不斷高速增長的資料量的需求
-
1.3.7.5. 時間序列資料庫經常利用記憶體緩衝來支援快速寫入和讀取
-
1.3.7.6. 區分測量資料和基於事件的資料，它們在時間序列資料庫中很常見
1.3.7.6.1. 測量資料是定期產生的，比如溫度或空氣質量感測器
1.3.7.6.2. 基於事件的資料是不規則的，每次事件發生時都會建立，例如，當運動感測器檢測到運動時
-
1.3.7.7. 時間序列的模式通常包含一個時間戳和一組小欄位
1.3.7.7.1. 資料是隨時間變化的，所以資料是按時間戳排序的
1.3.7.7.2. 這使得時間序列資料庫適用於操作分析，但不適合BI用例
-
2. API
2.1. API現在是在雲中、SaaS平臺以及公司內部系統之間交換資料的一種標準且普遍的方式
2.2. 許多型別的API存在於網路中，但我們主要感興趣的是圍繞HTTP構建的介面，HTTP是網路和雲中最流行的型別
2.3. API只是內部的一個簡單包裝，提供保護系統不受使用者請求影響所需的最低功能
2.4. REST
-
2.4.1. 目前主流的API正規化
-
2.4.2. REST是描述性狀態遷移的意思
-
2.4.3. 構建HTTP網路的API實踐和理念由Roy Fielding在2000年的博士論文中提出
-
2.4.4. REST是圍繞HTTP動詞建立的，比如GET和PUT
-
2.4.5. 主要觀點之一是互動是無狀態的
-
2.4.5.1. 每個REST呼叫都是獨立的
-
2.4.5.2. REST呼叫可以改變系統的狀態，但這些改變是全域性的，適用於整個系統而不是當前的會話
-
-
2.4.6. 資料提供商經常提供各種語言的客戶端庫，特別是Python語言
-
2.4.7. 各種服務和開源庫已經出現，以API互動並管理資料同步
2.5. GraphQL
-
2.5.1. GraphQL是在Facebook建立的，作為應用資料的查詢語言，並代替通用REST API
-
2.5.2. GraphQL則提供了在單個請求中檢索多個資料模型的可能性
2.6. Webhook
-
2.6.1. Webhook是一種簡單的基於事件的資料傳輸模式
-
2.6.2. 資料來源可以是一個應用程式的後端，一個網頁，或一個移動應用程式
-
2.6.3. 當指定的事件在源系統中發生時，將觸發對資料消費者託管的HTTP端點的呼叫
-
2.6.4. webhook經常被稱為反向API
2.7. RPC和gRPC
-
2.7.1. 遠端過程呼叫(Remote Procedure Call，RPC)通常用於分散式計算
- 2.7.1.1. 允許你在一個遠端系統上呼叫一個程式
-
2.7.2. gRPC是2015年在谷歌內部開發的一個遠端過程呼叫庫，後來作為一個開放標準釋出
-
2.7.2.1. gRPC是圍繞協議緩衝區開放資料序列化標準建立的，也是由谷歌開發的
-
2.7.2.2. gRPC強調透過HTTP/2進行有效的雙向資料交換
-
2.7.2.3. 效率指的是諸如CPU利用率、功耗、電池壽命和頻寬等方面
-
2.7.2.4. gRPC規定了比REST更具體的技術標準
-
2.7.2.5. gRPC允許使用常見的客戶端庫，並允許工程師開發適用於各種gRPC互動程式碼的技能集
-