本文由golang教程欄目給大家介紹關于《Go rqlite作者告訴你：開發數據庫軟件，算法多重要！》，希望對需要的朋友有所幫助！

編寫數據庫程序是一項迷人的工作。在過去的兩年里，我一直深度參與開源數據庫的開發，而數據庫編程可能是作為一個軟件開發者所能完成的最有啟發性的項目了。

然而，真正令人震驚的是, 在過去的 6 年里，我對數據庫的態度發生了很大的變化。 從一開始不感興趣的狀態，到現在我開始認為數據庫系統是軟件工程的一個巔峰。

不知道什么是更好的

在我的職業生涯的大部分時間里, 我對數據庫的唯一經驗就是閱讀有關它們的資料。 通常是在想當枯燥的背景下 — 打開任何一本有關數據庫的本科教科書，就能明白我的意思。 通常你會看到如下表格，作為關系型數據庫的典型用例：

你能再多讀些無聊的東西嗎？如果這些都是關于數據庫的，我不想和它們有任何關系。重點是什么？軟件比這酷多了，對吧？所以我在很長一段時間里完全避免了與數據庫有關的任何事情

您永遠不會忘記您的第一次CRUD應用

2009年，經過多年的寫作 嵌入式軟件, Linux 設備驅動程序, 和 網絡軟件, 我發現自己領導的團隊需要構建一個基于web的系統。你看，這個 AWS 云計算已經到來，基于云計算的許可技術 MAC 地址 不再有效。我的團隊必須建立一個 許可門戶 用于我們新的基于EC2的軟件設備。因為我們在這方面有很多經驗 Python, 我們選擇了 Django, 運行在 MySQL. 發生了一些新的事情。實際上，我是從數據庫開始工作的。

隨著我國平原地區的發展CRUD應用程序繼續運行，我開始意識到數據庫是多么重要——它對我們的系統是多么重要。如果我們丟失了數據庫，我們的軟件開發就白費了。如果數據庫損壞了數據，我們客戶的設備可能會未經許可，他們的網絡將停止運行。如果數據庫不能正常運行，成千上萬的人將同時受到影響。但這些事情都沒有發生過。數據庫始終工作。它從不讓我們失望。我印象深刻。
后來我發現了外鍵約束，唯一約束，引用完整性，索引，（記住，在這個時候我什么都不知道關于這些事情）-數據庫可以通過各種方式幫助我構建一個更健壯的系統。我終于意識到現代數據庫是驚人的-數據庫是世界上最無聊的東西直到你真的必須用它們來構建一個系統。

你也永遠不會忘記你的第一個搜索系統

到2012年，我領導了一個團隊，建立了一個大型索引和搜索系統基礎上的大型鍵值數據庫，帶有彈性搜索在其核心。看看elasticsearch這樣的系統能做什么 —— 一個建立在世界級索引這項技術——即使其下有TB級的日志數據，也讓人大開眼界。
到現在為止，我甚至看到數據庫和搜索系統也失敗了，但我被數據庫技術迷住了。到2014年，我加入了一個小型專門團隊，開發[開源時間序列數據庫]的核心(github.com/influxdata/influxdb).

我學到的

算法真的很重要

只有在數據庫開發中才有大O分析真的活過來了。數據庫是程序員仍然需要循環、排序和過濾數百萬對象的少數應用程序之一。這是少數幾個在CS課上學到的很多枯燥材料都很重要的地方之一。

其他許多軟件開發都不是這樣。寫入啟動ROM固件？不，算法對我來說從來都不重要。調諧器設備驅動程序? 不，沒關系。網絡設備管理軟件? CRUD應用程序？幾乎不所有這些學科都需要不同的技能和知識。大多數時候，我只是在面試中討論了運行時的復雜性。
但隨著數據庫的發展，這一切都發生了變化。實際上看到一個系統返回正確的結果，但是由于算法的改變，只在以前的一小部分時間內，看到它發生在您的代碼中，在您構建的系統中，這是一件美妙的事情。

表現也很重要

軟件中有一個老故事是這樣的：程序員編寫的一些代碼的運行速度比以前的版本快十倍。他展示了它，但有人指出，它產生的數據與正確的數據略有不同。“但是速度快了十倍。”程序員指出。“好吧，如果它不需要是正確的，我可以制作一個完全不占用空間、運行速度無限快的版本”，另一個回答說。
這個道德故事一直對我影響很大。正確總是比什么都重要。這是真的。但這也讓我相信，項目之所以有價值，僅僅是因為它們產生了正確的結果。

對于數據庫，情況并非如此。
性能不僅僅是一項功能。這是一個要求。那些愿意為數據庫掏錢的人經常這樣做，因為他們擁有大量的數據。如果數據庫在這種情況下不能很好地執行—如果它不能快速有效地返回結果—那么它可能根本不工作。

你認為寫系統很復雜嗎？

我認為開發數據庫最讓我震驚的是查詢引擎變得如此復雜。我有很多構建系統的經驗，可以將數據寫入并存儲到磁盤。使這些系統運行良好可能是一項重大挑戰。
但這種復雜性通常比查詢引擎的復雜性要小得多。一個靈活的查詢系統——有效地構建一個系統來回答問題，當你不知道問題會是什么的時候——需要認真的設計思想。查詢計劃器必須有效。查詢系統必須支持許多正交需求——按某些維度過濾，按其他維度分組，連接來自不同表的數據——有時還支持來自外部源的數據。最后，查詢系統必須高效且性能良好。這導致了設計和實現中抽象和優化之間的緊張關系，這需要真正的技巧才能很好地管理。

在現實世界中，它必須被操作

任何重要的數據庫都必須支持備份、恢復、碎片管理和監視等基本操作。
如果我，作為一個嚴肅的操作員，不能備份你的數據庫，我不能使用它，就這么簡單。數據庫接受寫操作的速度有多快并不重要。在查詢過程中，它的內存占用有多小并不重要。如果我不能保護數據庫中的數據不受數據庫創建者您無法控制的故障的影響，我將永遠無法舒適地運行它。
當然，有很多方法可以備份數據庫，而不需要數據庫的合作。但內置方法通常是最好的。這也是我向 rqlite v2.0.如果我想讓任何人認真地使用rqlite，我必須解決現實世界中的問題，即系統可能完全失敗，并將數據拖得很長時間。

因此，在設計和實現數據庫時，從一開始就要構建操作支持。將其作為設計的基本部分。您的用戶將為此感謝您。

答案通常是“視情況而定”

當您第一次開始使用數據庫時，尤其是作為一名操作員，您經常會問這樣的問題：系統可以以什么速率索引？它對查詢的響應速度有多快？我需要多少磁盤空間？一塊碎片能有多大，而且還能正常工作？我怎樣才能加快速度？所有人都毫無保留地問。我過去常常自己做。
也許你可以和數據庫程序員談談，問他們這些問題。而你經常——也許永遠——得到的回答是：這取決于你。你必須基準，你必須衡量。聽到這個消息可能會很惱火，而且可能看起來像是在逃避責任。

但事實并非如此。
現在，當我聽到這樣的問題時，我會微笑。太天真了。
索引率可能取決于數據的大小，而不僅僅是文檔或數據點的數量。這可能取決于批處理、數據的基數、數據庫是否群集、數據中的哪些列和字段被索引、是新數據還是對現有數據的更新、運行數據庫的機器、RAM、IO性能以及使用的復制。
控制性能的變量永遠不會結束。
對于查詢，可能取決于時間序列數據的時間范圍。它取決于命中的記錄數、查詢的字段數、是否涉及范圍掃描、數據是否索引、使用的索引類型、可能訪問的碎片數、數據是否為本地數據。以及機器的特點。它有貨嗎？它正在進行維護嗎？網絡忙嗎？

所以答案總是, 視情況而定。 數據庫設計者是誠實的。 他們可以知道他們建立的系統的一切， 但仍然不知道您的問題的答案。

編程遺愿清單

如果給那些希望提高編程能力的開發人員一條建議的話，那就是加入數據庫開發團隊。因為數據庫開發，我的編程技能大大提高了——這是一次美妙的編碼體驗。

原文地址：https://www.philipotoole.com/what-i-learned-from-programming-a-database/

譯文地址：https://learnku.com/go/t/64605