那些成功的數據庫公司沒有一家是通過性能比競爭對手更快而成功的。
作者：JORDAN TIGANI，DuckDB 公司 MotherDuck 聯合創始人&CEO
本文和封面來源：https://motherduck.com/，愛可生開源社區翻譯。
本文約 4500 字，預計閱讀需要 15 分鐘。
論數據庫性能崇拜
從我在西雅圖的家到我們在舊金山的辦公室大約需要 4.5 小時。假設您建造了一架高超音速飛機，其最高速度比普通波音 737-MAX 快 10 倍（無論是否有額外的防風靠窗座椅）。當你考慮乘 Uber 去機場、排隊安檢、登機、在停機坪上滑行、起飛和降落、等待登機口、等待行李以及乘優步去辦公室之後，你就已經完成了一些驚人的壯舉工程，但可能只縮短了 20% 的總行程時間。很好，但我仍然參加不上上午 10 點的會議。
數據庫行業一直專注於製造更快的飛機。與此同時，安檢隊伍越來越長，行李也經常丟失。如果您的數據位於有點不穩定的 CSV 文件中，或者您想要提出的問題很難用 SQL 表述，那麼可能理想的查詢優化器也無法幫助您。
性能是像我這樣的數據庫迷用來衡量數據庫的最常見指標，並且像體育迷一樣，我們傾向於選擇我們支持的球隊來對抗其他球隊。如果您最喜歡的數據庫贏得了基準性能測試戰爭，那麼您就有了在飲水機旁邊吹牛的權利。您可以炫耀那些有博客文章統計支持的數據，向任何願意傾聽的人證明您最喜歡的數據庫是冠軍。
一般來說，根據性能（特別是通用基準測試）選擇數據庫是一個糟糕的方法。您最好根據易用性、生態系統、更新速度或其與工作流程的集成程度來做出決策。最好的情況是，性能是完成某些任務所需時間的時間點視圖；然而，最壞的情況是，它會導致您針對錯誤的事情進行優化。
基準大戰結束
2019 年，GigaOm發佈了比較雲數據倉庫的基準測試報告。他們在三大雲供應商以及 Snowflake 上運行 TPC-H 和 TPC-DS。結果？Azure 數據倉庫是迄今爲止最快的，其次是 Redshift。Snowflake 和 BigQuery 遠遠落後。
當時，我正在研究 BigQuery，很多人都嚇壞了…… 我們怎麼會比 Azure 慢那麼多呢？然而，結果與我們從用戶那裏得到的印象並不相符。每次客戶對我們與 Azure 進行正面評估時，他們最終都會選擇 BigQuery。當時的市場結果幾乎與基準相反：Snowflake 和 BigQuery 最終的銷量比 Redshift 好得多，而 Redshift 的銷量比 Azure 好得多。
如果基準測試與客戶體驗不匹配，那麼要麼基準測試做錯了，基準測試測試了錯誤的東西，要麼最終證明性能並不那麼重要。我們進行了很多探索，這不是第一次。GigaOm 人員非常擅長運行基準測試，而且方法也很合理。他們運行的基準測試 TPC-H 和 TPC-DS 是行業標準，並且被廣泛的引用。它們是我們自己在內部運行的基準，用於判斷性能，雖然人們可能會對數據大小或其與現實世界工作負載的相關性提出異議，但它們是最好的測試報告。
因此，如果基準很好地體現了性能，而客戶最終在很大程度上購買了在基準上表現不佳的系統，那麼它會讓您相信也許還有比性能更重要的事情。
快意味着什麼？
在我從事雲數據庫工作的 15 年中，我注意到整個行業的一種反智模式：構建數據庫的人往往非常關注某人單擊“運行”按鈕和實際運行之間的時間。很容易理解爲什麼數據庫人員只關注數據庫服務器的相應時間；畢竟那是他們能掌控的範圍。但真正對用戶產生影響的是完成一項任務所需的時間，這兩個時間這不是一回事。
在 BigQuery 中，我們將 JDBC 驅動程序的構建外包給了一家專門構建數據庫連接器的公司。如果您不熟悉 JDBC，它們提供了程序員和商業智能工具用來連接數據庫的通用接口。當時讓一位知名專家構建界面是有意義的。
幾年後，在無數客戶投訴之後，我們意識到 JDBC 驅動程序中的錯誤正在影響性能。從我們的角度來看，查詢運行得很快，只需一兩秒。但是驅動程序輪詢查詢完成並提取結果的方式使得查詢看起來花費了幾秒鐘甚至幾分鐘的時間。當存在大量查詢結果時，這種影響會加劇，因爲即使用戶不需要查看所有結果，驅動程序通常也會一次一頁地拉取所有結果。有時他們甚至會因爲內存不足而崩潰。
我們的工程師花了很多年的時間來提高查詢速度，將查詢時間縮短了幾分之一秒。但我們大多數用戶使用的連接器增加的延遲就已經遠遠超過我們節省的延遲。更重要的是，我們對這個事實完全視而不見。Google 沒有人真正使用 JDBC 驅動程序，雖然我們每天晚上都在運行着全套基準測試，但這些基準測試實際上並沒有反映出我們的用戶所看到的端到端性能。
就像醉漢在路燈下尋找鑰匙一樣，我們只關注我們可以在服務器上測量的性能。用戶看到的查詢時間對我們來說是不可見的，我們認爲這是其他人的問題。要真正解決問題，而不僅僅是處理問題，需要我們重新構建對性能的看法。
表現是主觀的
性能必須從用戶的角度而不是數據庫的角度來衡量。這是一個用戶體驗問題，就像任何用戶體驗問題一樣，不能用一個數字來描述。這讓很多人感到驚訝，因爲他們認爲性能就像賽車一樣是客觀的事情。僅僅因爲您可以說蘭博基尼比普銳斯更快，他們相信您也應該能夠說我的數據庫比您的數據庫更快。但就像蘭博基尼可能無法讓我比普銳斯（或自行車，如果有交通）更快地工作一樣，數據庫的實際工作負載將決定哪一個更快。
主觀性受到了不好的批評；人們將其與這樣的說法聯繫起來：“好吧，沒有辦法知道哪一個更好，所以我們選擇哪一個並不重要。” 但僅僅因爲福特 F150 皮卡和特斯拉 Roadster 之間的差異是主觀的，並不意味着我對兩者的體驗是相同的。數據庫也是同樣的道理；如果我們說 Clickhouse 和 Redshift 之間的性能差異是主觀的，並不意味着它們是等效的。這只是意味着哪一個更快取決於它們的使用方式。
幾年前，Clickhouse 發佈了 Clickbench，該基準測試表明 Clickhouse 比他們測試的幾十個數據庫更快。這讓我感到驚訝，因爲當時我在 SingleStore 工作，我們相信我們的速度比 Clickhouse 快得多。在深入研究基準之後，我們發現該基準沒有執行任何 JOIN，因此在單個表中進行操作，並且還嚴重依賴於對不同項目進行計數。
雖然您可能認爲發佈僅執行單表掃描的基準測試很俗氣，但 Clickbench 實際上在代表許多實際工作負載方面做得相當好。如果您進行大量日誌分析並需要計算網站的不同用戶，這可能是性能的良好代理。也就是說，如果您使用星型模式運行更傳統的數據倉庫工作負載，Clickbench 將會產生誤導。
供應商基準往往關注供應商做得好的事情。下圖是來自“公平基準測試被認爲很困難” 的圖表，描述了典型的供應商基準測試結果。
數據庫基準測試存在大量陷阱，經驗表明基準測試通常在捕獲廣泛的用戶感知性能方面表現不佳。例如，BigQuery 在基準測試中表現得很差，但很多人的實際體驗是性能很神奇。BigQuery 親自表現得很好，因爲它沒有任何旋鈕，並且在很大程度上是自我調整的。高度調優的 SingleStore 實例在大多數任務中都會壓垮 BigQuery，但是您有時間花在調優架構上嗎？當您添加新的工作負載時會發生什麼？
DuckDB 網站曾經有一個免責聲明，上面寫着：“請不要抱怨性能，我們在努力提高速度之前會先關注正確性。” 並非所有數據庫都採用相同的方法。你可以通過去掉安全氣囊、牽引力控制、潰縮區、排放控制等安全裝置來讓汽車跑得更快。但大多數人不想這樣駕駛汽車。數據庫也不例外；如果刪除溢出檢查、不刷新寫入、爲某些操作提供近似結果或不提供 ACID 保證，則可以使它們更快。一些在這些基準測試中表現良好的系統應用了這些捷徑，但除非在受控環境下，否則我不想使用它們。
未來的變化
當您選擇數據庫時，該數據庫在該時間點並沒有凍結。您可能最終會堅持自己的決定數年。從現在到明年，數據庫的性能和功能將會發生很大變化，從現在到五年後更是如此。
因此，一個非常重要的變量不僅是數據庫現在可以做什麼，還在於未來一年能夠做什麼。如果數據庫中的錯誤導致您選擇競爭對手，那麼在短短几周內，如果該錯誤已被修復，那麼這將看起來是一個愚蠢的原因。這對於性能來說也是如此。如果兩個不同的數據庫以不同的速度改進，那麼您最好選擇移動速度更快的數據庫。未來的你會感謝你。
沒有魔豆
如果你採用一堆數據庫，所有這些數據庫都得到積極維護，並迭代它們幾年，性能將會趨於一致。如果 Clickhouse 正在應用一種能夠使其在掃描速度方面具有優勢的技術，那麼 Snowflake 可能會在一兩年內擁有這種優勢。如果 Snowflake 添加增量物化視圖，BigQuery 很快就會跟進。隨着時間的推移，重要的性能差異不太可能持續存在。
儘管這些公司的工程師都很聰明，但他們都沒有任何魔法或無法在其他地方複製的東西。每個數據庫都使用不同的技巧來獲得良好的性能。一種可能將查詢編譯爲機器代碼，另一種可能將數據緩存在本地 SSD 上，第三種可能使用專門的網絡硬件進行洗牌。只要有時間，任何人都可以實施所有這些技術。如果它們運作良好，它們可能會出現在任何地方。
Fivetran 的首席執行官 George Fraser 發表了一篇有趣的文章，比較了主要數據倉庫供應商隨時間的表現；雖然 2020 年的分散程度相當大，但到 2022 年，它們會更加緊密地聚集在一起。2020 年最快 8 秒，最慢 18 秒，2022年有 3 家廠商在 7 秒左右，最慢 9 秒。
當然，這條規則需要注意的是，架構差異很難克服。與共享磁盤相比，無共享數據庫處於劣勢，Redshift 花了很多年才切換到主要共享磁盤架構。依賴於將元數據持久保存到對象存儲的 Lakehouse 將很難快速更新；這是內置於模型中的。但這些類型的差異往往會體現在利潤率上。例如，從長遠來看，Redshift 沒有比 Snowflake 更快或更慢的根本原因。
問題出在椅子和鍵盤之間以及鍵盤和數據庫之間
對於用戶來說，衡量性能的重要指標是他們提出問題和得到答案之間的時間；這可能與數據庫運行查詢所花費的時間有很大不同。
如果你退後一步，從他們的角度思考，你可以使用更多的手段來實現最大限度地縮短問題提出和回答之間的時間的目標。您可以更輕鬆地提出問題。您可以更輕鬆地將查詢結果轉換爲他們可以理解的內容。當他們沒有提出正確的問題時，您可以幫助他們獲得反饋。您可以幫助他們瞭解數據何時出現問題。您可以幫助他們在正確的位置以正確的形式獲取所需的數據，以便能夠首先提出問題。雖然這些通常不被認爲是性能問題，但與更好的查詢計劃相比，改進可以在更大程度上加快分析師和數據工程師的工作流程。
Snowflake 在使編寫查詢變得更容易方面做得非常出色。儘管許多 SQL 方言都堅持語法一致，並且應該有“一種方法”來完成所有事情，但 Snowflake 設計者的目標是讓用戶鍵入的 SQL “正常工作”。例如，在 Snowflake SQL 中，如果要計算兩個日期之間的差異，可以使用 DATEDIFF 或 TIMEDIFF；兩者都適用於任何合理的類型。您可以指定粒度，也可以不指定。您可以圍繞粒度使用引號，也可以不使用引號。因此，如果您只是輸入查詢，只要可以收集意圖，它就應該“正常工作”。這是分析師喜歡 Snowflake 的原因之一，因爲他們不必花時間在文檔中查找內容。
數據並不總是採用方便查詢的格式。世界上大量的數據都存儲在 CSV 文件中，其中許多文件的結構很差。儘管如此，大多數數據庫供應商並沒有認真對待它們。在 BigQuery 中，我編寫了第一個 CSV 拆分器，當發現它是一個比預期更棘手的問題時，我們派了一位新的研究生工程師來解決這個問題。它從來都不是很好，無法進行推理，並且如果不同的文件具有稍微不同的模式，就會感到困惑。事實證明，CSV 解析實際上很困難。
如果使用兩個不同數據庫的兩名工程師需要讀取 CSV 數據並計算結果，則能夠最輕鬆地正確提取 CSV 文件的工程師可能會第一個得到答案，無論他們的數據庫執行查詢的速度有多快。因此，CSV 文件推斷可以被視爲一項性能功能。
數據庫處理結果的方式對用戶體驗有着巨大的影響。例如，很多時候人們運行“SELECT *”查詢來嘗試瞭解表中的內容。根據數據庫系統的架構方式，此查詢可以是瞬時的（返回第一頁和遊標，如 MySQL），對於大型表可能需要數小時（如果必須在服務器端複製表，如 BigQuery） ），或者可能會耗盡內存（如果它嘗試將所有數據拉入客戶端）。客戶端是否與服務器有長時間運行的連接，這可能會出現網絡中斷的問題？或者它們進行輪詢，這可能意味着查詢可以在輪詢週期之間完成，並使查詢顯得更慢？
綜上所述
最成功的數據庫公司沒有一家是通過比競爭對手更快而取得成功的。Redshift 曾一度稱霸，而讓 Snowflake 進入市場的是可維護性，而不是基準測試的性能。以性能爲主要賣點的數據庫在市場上表現不佳。讓工作變得容易完成的數據庫表現要好得多。
總結一下：
- 沒有魔豆；除非架構存在差異，否則性能將隨着時間的推移而趨於一致。
- 數據庫引擎以截然不同的速度發展；行動最快的人將是最後的勝利者。
- 當心最關心性能的數據庫供應商；從長遠來看，這會減慢他們的速度。
- 沒有單一的數據庫性能指標；“快速”數據庫可能會嚴重影響您的工作負載。
- 數據庫的重要特徵是從想法到答案的速度，而不是從查詢到結果的速度。
更快的查詢顯然比更慢的查詢更可取。但如果您選擇數據庫，最好確保您是根據原始速度以外的因素做出決定的。
更多技術文章，請訪問：https://opensource.actionsky.com/
關於 SQLE
SQLE 是一款全方位的 SQL 質量管理平臺，覆蓋開發至生產環境的 SQL 審覈和管理。支持主流的開源、商業、國產數據庫，爲開發和運維提供流程自動化能力，提升上線效率，提高數據質量。