搜索引擎 : ClickHouse

    No comments 

 ClickHouse 介紹：

  • ClickHouse 是 2016 年由俄羅斯搜索引擎Yandex 內部項目開發的關聯型的 OLAP 數據庫。
  • ClickHouse 是 ClickStream 和 Data WareHouse 的組合。以極高的查詢速度和性能而聞名。
  • 許多公司如 Uber、Slack、Tesla、Tencent、Tiktok、Cloudflare 等都在生產中使用 ClickHouse。
  • 其中 Tiktok 更是 ClickHouse 深度使用者，並且 Tiktok 在 ClickHouse 基礎上做了更多的擴展，例如加入雲端的架構等等，推出另外款名稱為 ByteHouse 產品，功能更加強大，不過需要另外收費

OLAP 介紹：

概念：
OLAP 又稱為線上分析處理，主要是用於快速分析大數據的技術，利用多維的角度去分析數據，從而幫助用戶可更好的透過數據發現趨勢走向，做出基於數據資料的決策。

特點：
  • 多維數據分析 - 提供多維數據分析的功能，能以不同的維度對數據進行分析。例如可以按照時間、地區、產品類別等多個維度進行數據分析，以此深入了解數據之間的關係和趨勢。
  • 複雜分析功能 - 提供了包括分組、聚合、過濾和排序等操作。可以讓使用者根據具體的業務需求，進行多層次的分析，透過了解數據的細節來發現其中的模式和彼此間的關聯性。
  • 決策支持 - 廣泛應用於決策支持系統中，幫助使用者做出基於數據資料的決策。通過多維分析資料，讓使用者可以更好地理解企業的業務運作和趨勢，從而做出更明智的決策。
  • 快速查詢 - 系統通常具有快速查詢的能力，這是因為有預先聚集、快速索引和並行處理等技術。讓使用者可以在短時間內查詢大量數據，而不必擔心系統的速度問題。

Row-oriented 介紹：

  • 將每列的資料存成一組，顧名思義它會將同一列的數據連續的儲存起來變成同一組
  • 適合在需要有 transaction 並且會頻繁異動資料的場景中使用
  • MySQL、PostgreSQL 都屬於 Row-oriented 的資料庫

ID

Name

Age

Sex

1

Amy

25

Female

2

Jhon

30

Male

3

Mark

28

Male

從上表中可以看出列儲存模式的儲存方式，會將每一列的資料連續存成一組。這種設計可以讓你很快的得到一整列的資訊，例如只要知道 id 就可以快速取得整列的資訊，包含 Name、Age、Sex 欄位資料。
缺點為使用空間較大，因為需要紀錄整列的數據，所以成本會比較大。查詢部份，就算不是篩選全部的欄位，也會需要先掃描整列資料，再依語法過濾需要的欄位，所以當資料過於龐大時會很耗時間。

Columnar 介紹：

  • 行的儲存模式，會將來自同一行的資料儲存成一組
  • 其特性適合對大數據進行分析和複雜查詢
  • Cassandra、HBase、Clickhouse 都屬於 Columnar 的資料庫

               

從上圖可以看出 Columnar 是將一行一行的資料紀錄成一組，這種儲存方式在對於需要對資料做計算處理或是模糊搜尋的情境中，只需要針對特定的欄位去搜索就行了，不用像列儲存模式需要把整列資料全部掃描完才能夠做運算，所以速度會快比較快。

Row-oriented V.S Columnar：

Row-oriented
Columnar
比較兩個儲存模式執行上的差異，列儲存模式會先掃描整列資料，再篩選出需要使用的資料欄位，將資料去做統計報表分析，所以速度較慢。
行儲存模式，則不需要掃描全部資料，只需要取所需要的資訊就能完成查詢，所以在大數據資料分析上，行儲存模式查詢速度上會比列的儲存模式來的更快。

ClickHouse 和 MySQL 比較： 

 

ClickHouse

MySQL

儲存模式

Columnar

Row-oriented

資料庫類型

倉庫型數據(OLAP)

關聯式資料庫(OLTP)

索引差異

稀疏索引

B+ Tree

適用情境

大數據分析並且無需頻繁異動資料場景。

需即時更新資料並且有 transaction 需求場景。

分散式架構

原始設計就為分散式資料庫

需額外套件擴展實現

ClickHouse 優點：

  • 有完整的 DBMS 功能 - DBMS 全名又叫做資料庫管理系統，主要功能可以有效的管理和操作資料庫，確保資料的安全性、一致性和可用性，讓使用者可以很好的管理和控制資料庫。
  • 無須預先處理資料 - 可以直接處理原始數據資料，不需要再對資料做任何的預先處理或是轉換。意味著可以直接將即時生成的大量資料直接導入到 ClickHouse 中，就可以做查詢操作，而不用再等待資料處理完成後才能使用，使得資料轉移能更快速和便利。
  • 使用 Columnar 存儲模式 - Columnar 更適合用於大數據和有複雜查詢的情境來做使用，查詢速度會更加快速且有效率。
  • 充分的利用所有可用的資源 - 其底層技術可以同时利用多个 CPU 核心和磁碟資源來執行查詢的操作，以此加速數據查詢的處理速度。
  • 不依賴複雜生態系 - 不需要像其他分散式資料庫一樣，需要依賴過於複雜的生態系統，例如 Hadoop。可以獨立運作，並且更輕鬆的佈署和管理，減少系統的複雜性和維護的成本。

ClickHouse 缺點：

  • 不適合頻繁的資料異動 - 在 ClickHouse 中異動資料算是很耗效能的操作，當發生異動時不管是 delete 或是 update， ClickHouse 都需調整相關的索引值，並且重新規劃資料分區，所以要是頻繁的異動資料，會嚴重影響系統穩定性和可用性。
  • 異動資料為非同步操作 - ClickHouse 在實際更新時，並不會真的刪除資料，而是會新增一筆新的資料，並且將對應的原始的資料做刪除標記。ClickHouse 底層會不定時的批次處理需要刪除的資料，這樣就會導致資料在合併前，可能會出現資料重複的情況，要解決這個情況，就必須要要在查詢時另外做處理，例如下 Distinct 去重或是 ClickHouse 提供的 FINAL 和 OPTIMIZE 語法強制合併資料。 
  • 不支援 transaction - 因為上述所說缺點，導致 ClickHouse 無法支援 transaction。
  • 需要耗費大量的計算和儲存資源 - ClickHouse 不管是查詢單筆或是好幾千萬筆，都會用盡資源去查詢，如此就會導致當查詢筆數很少時，也需要耗費大量的資源。

安裝 ClickHouse 和 Tabix：

  • docker pull yandex/clickhouse-server
    - 拉取 ClickHouse 的 image 檔案
  • docker run -d -p 8123:8123 -p 9000:9000 --name clickhouse yandex/clickhouse-server
    - 啟動 ClickHouse 服務
  • 調整 clickhouse-server 的 config.xml 設定
    - 調整 ClickHouse config.xml 檔，啟用 Tabix GUI
ClickHouse 的安裝，目前實做是用 docker 來啟動 ClickHouse 的服務，先 pull clickhouse-server 的 image 並且預留 8123 和 9000 port 供 ClickHouse 使用。
這邊另外裝了 Tabix 套件，這個是 ClickHouse 的 GUI，可以讓使用者用介面方式去操作 ClickHouse 的資料，Tabix 可以直接透過修改 ClickHouse Config 設定就能建置起來。



上圖是 docker-compose.yml 有關 ClickHouse 的配置，這邊特別將 Config 印射出來，是因為 ClickHouse 相關內部的設定都可以在這邊做調整。

ClickHouse 在 Container 操作：

  1. 進入 ClickHouse 的 container
  2. 輸入 clickhouse-client 指令進入操作的命令列
  3. 輸入要查的 sql 語法
  4. 顯示查詢結果
  5. 顯示查詢的筆數、讀取速度、數據大小等資訊

ClickHouse 在 Tabix 操作：

可以使用 Tabix 已介面的方式操作 ClickHouse，使用 Tabix 前需要先登入，輸入自訂的連線名稱、連線 URL、帳號 (default) 密碼 (無)。
登入後就可以在上方輸入 sql 相關語法，執行後下方會出現查詢結果，包含查詢筆數、讀取速度、數據大小等資訊。 Tabix 特別的地方是可以將資訊轉換成圖表分析，如下圖。
 
 

ClickHouse 於 Laravel 應用：

  • glushkovds/phpclickhouse-laravel - 整合 clickHouse 到 Laravel 專案上

資料寫入：
Model 建置：
查詢、新增範例 (原生語法)：
 查詢、新增範例 (Model)：

參考資料：

API查詢語言 : GraphQL

    No comments 

 GraphQL 介紹：

  • GraphQL 是一種新的 API 標準，它提供了一種比 Restful API 更有效、更強大和更靈活的替代方案。
  • 由 Facebook 開發並開源，現在由來自世界各地的公司和個人所組成的大型社區來做維護。
  • GraphQL 本質上是一種基於 API 的查詢語言，現在大多數應用程序都需要從服務器中獲取數據，API 的職責就是提供與應用程序需求相匹配的存儲數據接口。
  • GraphQL 可以跨不同 DB 應用，而且可以在任何使用 API 的環境中來做使用，可以理解爲 GraphQL 是基於 API 之上的一層封裝，目的是爲了能更靈活去應對業務上的需求變化。

圖中表示 GraphQL 主要是做為伺服器端和客戶端的中介，透過 GraphQL 的轉譯讓前後端可以正常溝通。


GraphQL 數據操作：
查詢（Query）：
查詢透過 GraphQL Server 獲取所需要的數據。開發人員可以在查詢中來定義所需的數據字段，GraphQL Server 就會按照指定的結構返回相應的數據。
變更（Mutation）：
變更用於 GraphQL Server 修改數據，例如新增、更新或刪除資料。變更操作流程跟查詢語句很相似，但因為資料會異動的關係，通常會需要用戶先通過登入驗證，已確保安全性。
訂閱（Subscription）：
訂閱用於接收 GraphQL Server 即時的數據更新。當數據發生變化時，GraphQL Server  就會主動發送相關的更新給有做訂閱的對象，可以透過此機制來做相關的邏輯處理，例如：發送通知或即時更改畫面等等。 訂閱主要是靠 websocket 等協議，來推送變動的消息給訂閱的對象。

GraphQL 核心概念：

圖表模式 (Schema)：
  • 用來描述  GraphQL 數據模型中的業務數據，可以理解為操作語法的設計
  • 類型是 schema 最核心的東西，數據模型通過類型來做描述

類型 (Type)：
  • 標量類型 - 標量是類型系統中最小的單位。類似於程式語言中的基本  class。
  • 對象類型 - 僅有標量類型是不能滿足複雜抽象數據模型的需求，這時候可以使用對象類型來處理。可以通過對象模型來構建 GraphQL 中關於一個數據模型的形狀，同時還能聲明各模型間的內在關聯 (例如：一對多、一對一或多對多等關聯關係)。
  • 類型修飾符 - 類型系統僅僅只有類型定義是不夠的，還需要對類型進行更廣泛性的描述。類型修飾符就是用來修飾類型，以達到額外的數據類型要求控制。

 

Restful API 介紹：

概念：
RESTful API 是一種設計和構建 API 的軟體架構風格，主要目的在於實現 Web 服務的可用性、操作性和可擴展性。
  • 統一介面 -  Rest 架構的核心，統一介面能讓客戶端只需要關注實作，透過統一界面的定義，可以增加可讀性，也能讓開發人員更方便的使用。 RESTful API 會利用 URL 來定位資源，並通過 HTTP 方法來操作，包括新增、查詢、修改和删除，剛好對應 HTTP 協議提供的 GET、POST、PUT 和 DELETE 方法。  
  • Client-Server 架構 - 架構將用戶介面跟資料儲存做切割，使其方便兩者能獨立運作與維護，客戶端是負責請求和處理資料的元件，伺服器端則是負責儲存資料和處理請求的元件。
  • 無狀態 - Restful API 每次連線本身都攜帶足夠的資訊，而不用依賴於上次連線的狀態，這邊主要說明 Restful API 每個請求都是獨立的，沒有前後關係，伺服器端不會保存客戶端的狀態訊息。這樣做的好處是可以使每個請求變得簡單，更容易理解和處理，並且能更輕鬆的擴展和維護。
  • 可緩存性 - Restful API 會根據 API 請求和回應內容，決定是否能被緩存，增加使用效率客戶端和伺服器端可以協商快取內容，透過設定 HTTP 狀態碼，伺服器端可以告訴客戶端這個資料是否可以快取。
  • 分層系統 - 完整的系統可以由多個子元件疊加，客戶端不應該關心請求經過了多少中間層，只需關心請求的結果就可以了。系統可以分成多個層次，每一層獨立完成自己的任務。這樣的結構使得系統更容易維護，並且允許獨立替換不同層次。(例如，資料庫儲存層可以獨立於其他層，在不影響其他層的情況下進行替換或擴充)。
  • 代碼請求 - 這是一個可選原則，這個原則主要提倡伺服器端可以將客戶端的程式碼下載到本地來執行。這樣，客戶端可以根據伺服器端發送的程式碼來擴展它的功能。這個原則可以使客戶端程式碼變得更加靈活，並且可以透過伺服器端提供的程式碼來解決問題，而不必再等待下一個版本。

GraphQL 流程：

  1. 第一步，需要先設計所需數據模型，模型主要是用來定義的數據格式檢核，爲下一步查詢響應做準備。
  2. 第二步，客戶端會透過查詢語言，描述想要請求的數據對象，和具體需要的資料結構。
  3. 第三步，伺服器端的 GraphQL 通過客戶端傳過來的請求，根據請求的查詢條件和資料結構，組裝精確的數據回傳至客戶端，讓客戶端組成想呈現的頁面。

GraphQL 和 Restful 結構差異：

Restful API 其實是多個端點的服務，它會透過打多次不同的 API 來取的所需的資訊。圖中當 Restful API 要取得書和對應作者的資訊，它會透過兩個 API 來將資料湊齊。

GraphQL 則不同， 它是一個單一端點的服務，對外只提供了一個用於調用內部接口的端點，所有的請求都訪問這個唯一端點。圖中 GraphQL 可以定義要查詢的條件和回傳的資料結構，集中成一個請求來得到所需的資料。

            

Rest API call - 透過使用者資料的 API，取得回傳的使用者 ID 資訊，再利用 ID 資訊至取得地址的 API ，取得對應的使用者地址資料。
GraphQL API call - 直接透過對象類型的關聯，能直接取出使用者的個資和其地址資料，並且可以定義想要回傳的欄位格式。

GraphQL 和 Restful 比較：

 

REST

GraphQL

定義

用於定義 Client 與 Server 之間的資料交換的規則。

是一種查詢語言，用於建立和操作 API 的工具。

適合性

適用於明確定義資源的簡單資料。

適用於大型、複雜且相互關聯的資料來源。

資料存取

具有 URL 形式的多個端點來定義資源。

GraphQL 具有個單一的 URL 端點。

回傳資料

以 Server 定義的固定結構資料。

以 Client 定義的彈性結構資料。

資料結構化和定義方式

資料為弱類型。

後端需決定如何判讀格式化資料。

資料為強類型。

Client 會預先決定要接收的資料結構。

GraphQL 使用場景：

  • 多數據源整合 - GraphQL 適合應用在有多個不同數據源需要統整再一起的的情境。例如可能需要從多個數據庫、外部 API、內部服務等不同來源獲取需要的資料。它能夠將這些數據源的數據整合到一個統一的 API 中，客戶端就可以按照需求，查詢所需要的數據，而不用每個數據源都各自發一個獨立的請求。
  • 移動應用程序 - GraphQL 特別適合應用在 APP， GraphQL 能讓客戶端精確指定所需要的數據，這樣能減少 APP 過度傳輸資料和使用網路的流量。App 也經常會需要不同結構和大小的數據，GraphQL 能夠根據不同設備和用戶的需求提供最佳性能。
  • 複雜數據需求 - GraphQL 允許客戶端用一個複雜的查詢，就能檢索所有需要的資料，從而提高效率並減少過多的數據傳輸。
  • 實時數據需求 - 如果應用程序需要實時或即時更新的數據，GraphQL 具有優勢。使用 GraphQL 訂閱功能，可以讓客戶端 觀察數據的變化，當數據異動更新時，可以即時發出通知，這對於聊天應用和實時通知非常有用。

GraphQL 優點：

  • 精準獲取數據 - GraphQL 可以讓客戶端依照當前頁面所需的數據，精確的從資料庫取出所需資料，而不是獲取整包的資訊，再由前端來做過濾處理。
  • 減少網絡傳輸 - GraphQL 可以透過發送一次的請求，就能獲取來自各方面的資源數據，對比需要透過執行多次的 API 才能將資料組裝完成的流程，這個特性更能減少網絡傳輸次數，以此提高網頁處理效率和回應速度。
  • 靈活性和可擴展性 - GraphQL 具有靈活的查詢特性，可以讓客戶端依不同情境，添加對應的查詢條件和定義回傳數據類型，這樣可以使得 API 的擴展性跟靈活度都變高。
  • 類型系統 - GraphQL 具有強大的類型系統，透過定義 API 回傳數據結構，能使客戶端和伺服器端能夠更好地理解 API 的回傳的資料結構，從而減少資料格式回傳錯誤的發生。
  • 前後端獨立 - GraphQL 允許前端和後端團隊獨立開發，前端可以根據頁面的需求來查詢所需要的資料，而不再需要等待後端開發完 API 才能進行開發。

GraphQL 缺點：

  • 學習曲線 - 因為 GraphQL 涉及到比較復雜的類型系統、查詢語言和執行機制等概念。那會相對於當前專案使用的 RESTFUL API，上手難度會再更高一點。
  • 複雜性 - GraphQL 因為具有很好靈活性和可擴展性，所以也會使得 GraphQL 變得相對複雜。需要開發人員投入更多的精力來設計、實做和維護它。
  • 性能 - 雖然 GraphQL 可以減少網絡傳輸，但如果查詢語句過於複雜，或回傳的資料結構過於多層，就可能會導致查詢執行時間較長，從而影響 API 的響應時間。
  • 安全性 - 允許客戶端查詢所需的任何數據，那這樣可能會導致安全上的漏洞。例如數據洩露和暴露 API 中的敏感信息。因此，需要另外採取措施來確保 GraphQL  的安全性，例如建立授權機制等等。

GraphQL 與 Laravel 應用套件：

  • rebing/graphql-laravel - 整合了 GraphQL 到 Laravel，並且將前面所述的相關類型定義，轉換成 Laravel 裡面原本就有的語法，設定起來更直覺方便，無需在特地去學 GraphQL 原生的寫法，對象類型關聯的部份，也是直接使用 Laravel 原生 orm 關聯實做即可。
  • mll-lab/laravel-graphql-playground - 可直接在網頁上，執行 GraphQL 查詢測試，直觀的檢測 GraphQL 語法邏輯是否有問題，無需再使用 postman 程式語法結果，可以讓開發和除錯更便利快速。

GraphQL-Laravel 程式定義範例：

定義基本類型： 

定義查詢邏輯： 

設定 schema 關聯：

參考資料：

訂閱： 意見 (Atom)