哈布羅夫斯克的居民們大家好。 第一組課程今天開始 。 在這方面，我們想向您介紹一下本課程的公開網路研討會是如何進行的。
В 我們討論了SQL資料庫在雲端和Kubernetes時代面臨的挑戰。 同時，我們研究了 SQL 資料庫在這些挑戰的影響下如何適應和變異。
舉辦了網路研討會 ，EPAM Systems 的 Google Cloud 實踐交付經理。
當樹還小的時候...
首先，讓我們回想一下上世紀末 DBMS 的選擇是如何開始的。 不過，這並不會很難，因為當年 DBMS 的選擇就開始了，結束了 神諭.
在 90 世紀 2 年代末和 XNUMX 年代初，工業可擴展資料庫基本上沒有選擇。 是的，IBM DBXNUMX、Sybase 和其他一些資料庫來了又去，但總的來說，它們在 Oracle 的背景下並不那麼引人注目。 因此，那個時代工程師的技能在某種程度上與存在的唯一選擇連結在一起。
Oracle DBA 必須能夠：
- 從分發包安裝 Oracle Server；
- 配置 Oracle 伺服器：
- 初始化.ora；
- 監聽器.ora；
- 創造：
- 表空間；
- 方案;
- 用戶；
— 執行備份和復原；
——進行監測；
— 處理次優請求。
同時，Oracle DBA 也沒有特殊要求：
- 能夠選擇最佳的 DBMS 或其他技術來儲存和處理資料；
- 提供高可用性和水平可擴展性（這並不總是 DBA 的問題）；
- 對學科領域、基礎設施、應用程式架構、作業系統有良好的了解；
- 載入和卸載數據，在不同的 DBMS 之間遷移數據。
總的來說，如果我們談論當時的選擇，它類似於 80 年代末蘇聯商店的選擇：
如今
當然，從那時起，樹木長大了，世界發生了變化，變成了這樣：
DBMS市場也發生了變化，從Gartner的最新報告可以清楚看到：
這裡應該指出的是，越來越受歡迎的雲端已經佔據了自己的利基。 如果我們閱讀同一份 Gartner 報告，我們會看到以下結論：
- 許多客戶正在將應用程式遷移到雲端。
- 新技術首先出現在雲端中，事實上它們不會遷移到非雲端基礎設施。
- 按量付費的定價模式已變得司空見慣。 每個人都想只為他們使用的東西付費，這甚至不是一種趨勢，而只是一個事實的陳述。
現在怎麼辦？
今天我們都在雲端。 我們面臨的問題是選擇問題。 即使我們只討論本地格式的 DBMS 技術的選擇，它也是巨大的。 我們還有託管服務和 SaaS。 因此，選擇只會變得一年比一年困難。
除了選擇問題之外，還有 限制因素:
- 價格。 許多技術仍然需要花錢；
- 技能。 如果我們談論自由軟體，那麼技能問題就出現了，因為自由軟體需要部署和操作它的人有足夠的能力；
- 功能性的。 並非所有在雲端中可用且建置的服務（即使是在同一個 Postgres 上）都具有與本地 Postgres 相同的功能。 這是一個需要了解和理解的重要因素。 此外，這個因素比了解單一 DBMS 的某些隱藏功能更重要。
現在對 DA/DE 的期望：
- 對主題領域和應用程式架構有很好的理解；
- 能夠根據手邊的任務正確選擇適當的 DBMS 技術；
- 在現有限制的情況下選擇實施所選技術的最佳方法的能力；
- 執行資料傳輸和遷移的能力；
- 實施和操作選定解決方案的能力。
下面的例子 基於GCP 示範如何根據資料結構選擇一種或另一種處理資料的技術：
請注意，PostgreSQL 未包含在架構中，這是因為它隱藏在術語下 雲端SQL。 當我們使用Cloud SQL時，我們需要再次做出選擇：
應該注意的是，這種選擇並不總是明確的，因此應用程式開發人員通常會受到直覺的指導。
合計：
- 走得越遠，選擇的問題就越緊迫。 即使您只專注於 GCP、託管服務和 SaaS，也只會在第四步中提到 RDBMS（Spanner 就在附近）。 另外，第4步出現了PostgreSQL的選擇，旁邊還有MySQL和SQL Server，即 一切都有很多，但你必須選擇.
- 我們絕不能忘記在誘惑的背景下的限制。 基本上每個人都想要一把扳手，但它很貴。 因此，典型的請求如下所示： “請為我們製作一個 Spanner，但就 Cloud SQL 的價格而言，你們是專業人士！”
我們該做什麼？
在不聲稱是最終真理的情況下，讓我們說以下內容：
我們需要改變我們的學習方式：
- 按照以前教授 DBA 的方式進行教學是沒有意義的；
- 僅僅了解一種產品已經不夠了；
- 但在某個層面上要了解幾十個是不可能的。
您不僅需要知道產品的價格，而且還需要：
- 其應用程式的用例；
- 不同的部署方式；
- 每種方法的優點和缺點；
- 類似和替代產品，以做出明智的最佳選擇，而不是總是偏愛熟悉的產品。
您還需要能夠遷移資料並了解與 ETL 整合的基本原理。
真實案例
最近，有必要為行動應用程式建立一個後端。 當工作開始時，後端已經開發完畢並準備好實施，開發團隊在這個專案上花了大約兩年的時間。 制定了以下任務：
- 建構 CI/CD；
- 審查架構；
- 將其全部投入運作。
該應用程式本身就是微服務，Python/Django 程式碼是直接在 GCP 中從頭開始開發的。 至於目標受眾，假設有兩個區域——美國和歐盟，流量透過全球負載平衡器分配。 所有工作負載和計算工作負載都在 Google Kubernetes Engine 上運作。
至於數據，有3種結構：
- 雲儲存;
- 資料儲存;
- 雲端 SQL (PostgreSQL)。
有人可能想知道為什麼選擇 Cloud SQL？ 說實話，這樣的問題近年來引起了某種尷尬的停頓——有一種感覺，人們對關係資料庫變得害羞了，但儘管如此，他們仍然繼續積極地使用它們;-)。
就我們的案例而言，選擇 Cloud SQL 的原因如下：
- 如前所述，該應用程式是使用 Django 開發的，它有一個用於將持久性資料從 SQL 資料庫映射到 Python 物件的模型 (Django ORM)。
- 該框架本身支援相當有限的 DBMS 列表：
- PostgreSQL；
- 瑪麗亞資料庫；
- MySQL；
- 甲骨文；
- SQLite的。
因此，從這個清單中相當直觀地選擇了 PostgreSQL（好吧，實際上不是 Oracle 可供選擇）。
缺少什麼：
- 該應用程式僅在 2 個地區部署，第三個地區出現在計劃中（亞洲）；
- 該資料庫位於北美地區（愛荷華州）；
- 客戶方面擔心可能 存取延遲 來自歐洲和亞洲以及 打擾 在役 如果 DBMS 停機。
儘管Django本身可以並行處理多個資料庫，並將它們分為讀取和寫入，但應用程式中並沒有那麼多寫入（90％以上是讀取）。 總的來說，一般來說，如果可以的話 歐洲和亞洲主要基地的唯讀副本，這將是一個折衷的解決方案。 那麼，這有什麼複雜的呢？
困難在於客戶不想放棄使用託管服務和 Cloud SQL。 Cloud SQL 的功能目前還很有限。 Cloud SQL 支援高可用性 (HA) 和唯讀副本 (RR)，但相同 RR 僅在一個區域支援。 在美洲區域建立資料庫後，您無法使用 Cloud SQL 在歐洲區域建立唯讀副本，儘管 Postgres 本身並不會阻止您這樣做。 與Google員工的通信毫無結果，最後以「我們知道問題所在並正在努力解決，總有一天問題會得到解決」的承諾告終。
如果我們簡要列出 Cloud SQL 的功能，它將如下所示：
1. 高可用性（HA）：
- 在一個區域內；
- 透過磁碟複製；
- 不使用 PostgreSQL 引擎；
- 可進行自動和手動控制 - 故障轉移/故障復原；
- 切換時，DBMS 有幾分鐘不可用。
2. 唯讀副本 (RR)：
- 在一個區域內；
- 雙機熱備；
- PostgreSQL 串流複製。
此外，按照慣例，在選擇技術時，您總是會面臨一些問題 限制:
- 客戶不想創建實體並使用 IaaS，除非透過 GKE；
- 客戶不想部署自助服務 PostgreSQL/MySQL；
- 好吧，總的來說，如果不是因為它的價格，Google Spanner 會很合適，但 Django ORM 無法使用它，但這是一件好事。
考慮到這種情況，客戶收到了後續問題： “你能做一些類似的事情，讓它像 Google Spanner 一樣，但也可以與 Django ORM 一起使用嗎？”
解決方案選項編號 0
我首先想到的是：
- 留在 CloudSQL 中；
- 區域之間不會有任何形式的內建複製；
- 嘗試將副本附加到現有 Cloud SQL by PostgreSQL；
- 在某處以某種方式啟動 PostgreSQL 實例，但至少不要觸及 master。
唉，事實證明這是無法做到的，因為無法訪問主機（它完全在不同的項目中）- pg_hba 等，並且在超級用戶下也無法訪問。
解決方案選項編號 1
經過進一步反思，考慮到先前的情況，想法有所改變：
- 我們仍然試圖留在 CloudSQL 中，但我們正在切換到 MySQL，因為 Cloud SQL by MySQL 有一個外部主伺服器，它：
— 是外部 MySQL 的代理程式；
- 看起來像是 MySQL 實例；
- 專為從其他雲端或本地遷移資料而發明。
由於設定 MySQL 複製不需要存取主機，因此原則上一切正常，但非常不穩定且不方便。 當我們更進一步時，它變得完全可怕，因為我們用terraform部署了整個結構，突然發現外部master不受terraform支援。 是的，Google 有一個 CLI，但由於某種原因，這裡的所有東西時不時都能工作 - 有時它被創建，有時它沒有創建。 也許是因為 CLI 是為了外部資料遷移而發明的，而不是為了副本。
事實上，此時很明顯Cloud SQL根本不適合。 正如他們所說，我們已竭盡全力。
解決方案選項編號 2
由於不可能保留在 Cloud SQL 框架內，因此我們嘗試制定折衷解決方案的要求。 結果要求如下：
- 在 Kubernetes 中工作，最大限度地利用 Kubernetes（DCS，...）和 GCP（LB，...）的資源和功能；
- 雲中缺乏大量不必要的東西（例如 HA 代理）的鎮流器；
- 能夠在主 HA 區域運行 PostgreSQL 或 MySQL； 在其他區域 - 來自主區域 RR 的 HA 加上其副本（為了可靠性）；
- multi master（我本來不想聯絡他，但也不是很重要）
.
由於這些要求，p合適的 DBMS 和綁定選項:
- MySQL 加萊拉；
- 蟑螂資料庫；
- PostgreSQL 工具
:
- pgpool-II；
——帕特羅尼。
MySQL 加萊拉
MySQL Galera 技術由 Codership 開發，是 InnoDB 的插件。 特點：
- 多主；
- 同步複製；
- 從任意節點讀取；
- 記錄到任意節點；
- 內建HA機制；
- Bitnami 提供了 Helm 圖表。
蟑螂數據庫
根據描述，這東西絕對是炸彈，是用 Go 寫的開源專案。 主要參與者是Cockroach Labs（由Google的人創立）。 此關係 DBMS 最初設計為分散式（開箱即用的水平擴展）和容錯能力。 該公司的作者概述了「將 SQL 功能的豐富性與 NoSQL 解決方案所熟悉的水平可訪問性相結合」的目標。
一個不錯的好處是支援 post-gress 連線協定。
pgpool
這是 PostgreSQL 的一個附加元件，實際上是一個接管所有連接並處理它們的新實體。 它有自己的負載平衡器和解析器，並在 BSD 許可證下獲得許可。 它提供了充足的機會，但看起來有些可怕，因為新實體的存在可能會成為一些額外冒險的來源。
帕特羅尼
這是我最後看到的一件事，事實證明，我的目光並沒有白費。 Patroni 是一個開源實用程序，本質上是一個 Python 守護進程，可讓您透過各種類型的複製和自動角色切換自動維護 PostgreSQL 叢集。 事實證明，這件事非常有趣，因為它與立方體整合得很好，並且沒有引入任何新實體。
最後選擇了什麼？
這個選擇並不容易：
- 蟑螂數據庫 - 火，但黑暗；
- MySQL 加萊拉 - 也不錯，很多地方都用它，但MySQL；
- pgpool — 很多不必要的實體，與雲端和 K8s 的整合式馬馬虎虎；
- 帕特羅尼 - 與 K8s 完美集成，沒有不必要的實體，與 GCP LB 集成良好。
於是，選擇權落在了帕特羅尼身上。
發現
是時候簡單總結一下了。 是的，IT 基礎架構的世界已經發生了巨大的變化，而這只是一個開始。 如果說以前雲端只是另一種類型的基礎設施，那麼現在一切都不同了。 而且，雲端中的創新不斷出現，它們將會出現，也許它們只會出現在雲端，只有這樣，透過新創公司的努力，它們才會轉移到本地。
至於SQL，SQL將會存在。 這意味著您需要了解 PostgreSQL 和 MySQL 並能夠使用它們，但更重要的是能夠正確使用它們。
來源： www.habr.com