編寫資料庫程式是一項迷人的工作。在過去的兩年裡，我一直深度參與開源資料庫的開發，而資料庫程式設計可能是作為一個軟體開發者所能完成的最有啟發性的專案了。
然而，真正令人震驚的是, 在過去的 6 年裡，我對資料庫的態度發生了很大的變化。 從一開始不感興趣的狀態，到現在我開始認為資料庫系統是軟體工程的一個巔峰。
在我的職業生涯的大部分時間裡, 我對資料庫的唯一經驗就是閱讀有關它們的資料。 通常是在想當枯燥的背景下 — 開啟任何一本有關資料庫的本科教科書，就能明白我的意思。 通常你會看到如下表格，作為關係型資料庫的典型用例：
| ID | FIRST | LAST | TITLE | DEPARTMENT |
|---|---|---|---|---|
| 1 | Robert | Kelly | Director | Marketing |
| 2 | Tom | Burke | Representative | Sales |
| 3 | John | Smith | Vice President | Sales |
你能再多讀些無聊的東西嗎？如果這些都是關於資料庫的，我不想和它們有任何關係。重點是什麼？軟體比這酷多了，對吧？所以我在很長一段時間裡完全避免了與資料庫有關的任何事情
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
以上就是Go rqlite作者告訴你：開發資料庫軟體，演演算法多重要！的詳細內容，更多請關注TW511.COM其它相關文章！