以 Gravity 無痛提高資料庫的併發查詢能力
懶惰鬼的資料庫強化手段
您是否已經發現，當資料庫有大量併發查詢的需求，一味擴大資料庫系統的硬體規模和數量，顯然沒有太大的幫助。因此，這時必須採用「讀寫分離」或是進一步實現更精準的「資料快取」，才能滿足併發查詢所需的效能。
但是，要實現讀寫分離所需的資料複寫（Replication）或是打造資料快取（Cache），想不弄髒手很困難。在不想動既有程式架構、改造資料庫叢集的情況下，我們又有什麼方法可以快速且無痛的實現？
更重要的是，不要造成「既有資料庫的負擔」。
在過往案例中，客戶就以 Gravity 快速打造了各類資料庫系統的資料複寫（Replication）以實現讀寫分離，並利用了內建的資料快照（Data Snapshot）和資料中繼（Data Relay）的機制，讓資料查詢節點在數量擴展增加或資料還原時，不但更為快速，且完全不影響原有的資料庫系統效能。
無痛且快速實現具高擴展性的讀寫分離
採用 Gravity 實現複寫（Replication），無需涉及資料庫叢集系統（Cluster）、主從架構（Master/Slave）的搭建，所以落實讀寫分離機制非常容易，在不改動既有資料庫的情況下，能快速提高資料庫的併發查詢能力。
Gravity 會監控既有資料庫的資料變更事件，並進行即時的資料抄寫和複製工作，以確保每個副本都與原始資料庫資料一致。而且，由於外部查詢都是在唯獨的副本（Replica）資料庫上作業，併發數再高也不會衝擊既有資料庫的效能。
值得一提，當擴展新的副本時，其資料的抄寫會從 Gravity 內的資料快照（Data Snapshot）匯出，不會跟原始資料庫拉取，因此無論副本規模如何擴展，也不會影響原始資料庫效能。更由於不涉及資料庫叢集系統建置，每個副本資料庫之間沒有任何關聯性，隨時新增、離線或是移除，都不影響整個複寫機制的運作，相當彈性。
一些傳統複寫解決方案之所以資料庫還原、回復速度慢，一方面是還原時需要從原始資料庫拉取資料，被原始資料庫效能所限制；另一方面，是因為採用日誌、事件朔源的方式，導致需要處理回放大量事件才能還原出最後資料結果。
Gravity 快照機制能夠改善這樣的問題，除了完全省去從日誌還原的時間而進行快速副本重建之外，在資料抄寫和副本回復的過程中，也完全不影響既有資料庫的正常業務運作及效能。
只選擇特定資料進行高效率快取
在許多客戶的實際場景下，並不是整個資料庫的資料都會被大量查詢，因此針對整個資料庫進行一對一複寫工作，創造出多個完整副本，就顯得浪費資源而沒有意義，甚至因為資料量大，也讓副本資料庫的效能表現受到影響。因此只對「特定資料」進行複寫，創造資料快取，以滿足特定查詢需要，就顯得特別重要。
Gravity 提供「欄位」的資料選擇，在此顆粒度下，可以選擇特定資料表中的特定欄位進行快取，而不用複製整個資料表，大幅減少佔用的空間和資源，讓資料快取更容易實現。
註：一些客戶更進階的用法，是將不同資料表的資料合併到快取資料庫同一個資料表中，得到資料關聯和聚合的效果，大量降低查詢複雜度，讓併發查詢的能力更近一步得到提升。
使用異質資料庫實現讀寫分離和快取可行嗎？
當然可以。Gravity 支援多種資料庫，如 MySQL、MongoDB、PostgreSQL、MSSQL 及 Oracle 等，可以因應需求，同一時間將資料從原始資料庫抄寫至多個不同類型的資料庫上。
在過往的一些客戶場景中，原始資料庫採用的是 Oracle，除了對原始資料庫抄寫多個副本以實現讀寫分離來改善併發查詢外，也同時會將 Oracle 資料抄寫一份資料至 MongoDB 這類 NoSQL，以便更豐富的資料處理和其他應用。
在某些更複雜的客戶環境下，因為資料庫系統更多元，更取決於各應用程式習慣或需要什麼樣的資料庫系統，甚至將 Gravity 當作資料在不同資料庫系統之間轉換和遷移（Data Migration）的工具。
導入 Gravity 的其他好處？
想要提升資料庫的寫入能力嗎？需要有效率跨雲的資料轉移和抄寫？又或是想實現資料即時熱備份和備援？欲知更多 Brobridge Gravity 的好處和功能，以及全方位的資料庫系統讀寫強化方案，歡迎與我們寬橋（Brobridge）聯絡。
