Gravity 也能打造分片機制，快速實現資料庫橫向擴展！
讓我們一起懶惰到底，懶人的資料庫系統改造神器
所謂資料分片（Sharding），就是將資料依據規則分別存放到多個資料庫節點，避免單一資料庫節點處理的資料量過大，導致效能瓶頸。以往使用資料分片的場景，多半是用於提昇資料寫入效率，以及有限範圍的資料查詢效率，讓資料庫橫向擴展變得可能。
而過去打造資料分片架構，不外乎兩種做法，一種是自行開發，針對資料進行分類，然後將資料寫到資料庫池中的其中一個節點；另一種是依賴資料庫系統原生支援的分片叢集（Sharding Cluster）機制，依據資料庫系統官方指南搭建資料庫叢集即可。
可無論是哪一種做法都相當麻煩，自行開發需要開發人員配合改造應用程式，引入分片演算法；而使用資料庫原生機制，則需要專業人員搭建和維護複雜的叢集架構，更重要的是，必須該資料庫有原生支援分片機制為前提。可以說，資料分片是許多人想要實現的機制，但都怯步於其麻煩的改造工作，或是令人不安的叢集維護工作。
我們能否有一個做法，不改造應用程式，不搭建、設定複雜的資料庫叢集機制，就能實現資料分片呢？這時 Brobridge Gravity 就可以幫上大忙。
利用 Gravity 實現資料分片
在使用 Gravity 實現資料分片時，應用程式無需自行實現各種分片的演算法，只需要將資料推送至 Gravity 的資料節點即可，隨後，即會依據資料的主鍵（Primary Key）進行 Hash 的計算工作，最後決定寫入至哪一個資料節點。
將資料推送至 Gravity 的方式有許多種，可以使用 Message Queue（如：Kafka、NATS 等）或是 Restful API，方便各類應用程式能快速進行串接。
一行程式都無需更改的做法
如果不方便改動應用程式，又想實現分片機制，可以搭配舊文「利用 Gravity 提升資料庫寫入效率」所提及的功能，保持資料庫連線方式和寫入介面不變，對 Gravity 進行資料推送。
這種作法的好處，在於能完全不動應用程式架構、程式碼的情況下，低風險的改造資料庫系統，讓資料庫得以橫向擴展，以增加效能表現。
分片機制的缺點和解決方法
雖然分片機制能帶來資料庫橫向擴展的可能，但因為分片機制會將資料分開存放於不同的資料節點，因此當我們要全範圍的查詢或提取資料時（如：跨資料庫關聯），就需要橫跨不同資料庫節點才能達成。也因為如此，在這類跨節點的資料讀取上，就可能會造成不方便或讀取效率的問題。
長久以來，這都是分片機制的缺點，在部分問題上，可以參考舊文「以 Gravity 快速實現跨資料庫的關聯查詢」來解決大量的跨節點查詢問題。如果是寫多讀少的情況，則可以自行撰寫程式去對每個節點一一進行查詢。
查詢的場景變化多端，複雜的查詢條件和工作，需要引入不同的解決方式。
Gravity 還有哪些功能？
想要讓資料抄寫到不同類型的資料庫嗎？想快速做更多的副本、更彈性的建立查詢快取嗎？想保護既有資料庫系統不要被壓垮嗎？欲知更多 Brobridge Gravity 的好處和功能，歡迎與我們寬橋（Brobridge）聯絡。
