Go rqlite作者告訴你：開發資料庫軟體，演算法多重要！-Golang-PHP中文網

本文由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效能以及使用的複製。
控制性能的變數永遠不會結束。
對於查詢，可能取決於時間序列資料的時間範圍。它取決於命中的記錄數、查詢的欄位數、是否涉及範圍掃描、資料是否為索引、使用的索引類型、可能存取的碎片數、資料是否為本機資料。以及機器的特點。它有貨嗎？它正在進行維護嗎？網路忙嗎？

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