Go rqlite作者告诉你：开发数据库软件，算法多重要！

藏色散人

发布时间：2022-01-22 09:19:49

5286人浏览过

来源于learnku

转载

本文由golang教程栏目给大家介绍关于《go rqlite作者告诉你：开发数据库软件，算法多重要！》，希望对需要的朋友有所帮助！

编写数据库程序是一项迷人的工作。在过去的两年里，我一直深度参与开源数据库的开发，而数据库编程可能是作为一个软件开发者所能完成的最有启发性的项目了。

然而，真正令人震惊的是, 在过去的 6 年里，我对数据库的态度发生了很大的变化。从一开始不感兴趣的状态，到现在我开始认为数据库系统是软件工程的一个巅峰。

不知道什么是更好的

在我的职业生涯的大部分时间里, 我对数据库的唯一经验就是阅读有关它们的资料。通常是在想当枯燥的背景下 — 打开任何一本有关数据库的本科教科书，就能明白我的意思。通常你会看到如下表格，作为关系型数据库的典型用例：

ID	FIRST	LAST	TITLE	DEPARTMENT
1	Robert	Kelly	Director	Marketing
2	Tom	Burke	Representative	Sales
3	John	Smith	Vice President	Sales

你能再多读些无聊的东西吗？如果这些都是关于数据库的，我不想和它们有任何关系。重点是什么？软件比这酷多了，对吧？所以我在很长一段时间里完全避免了与数据库有关的任何事情

您永远不会忘记您的第一次CRUD应用

2009年，经过多年的写作嵌入式软件, Linux 设备驱动程序, 和网络软件, 我发现自己领导的团队需要构建一个基于web的系统。你看，这个 AWS 云计算已经到来，基于云计算的许可技术 MAC 地址不再有效。我的团队必须建立一个许可门户用于我们新的基于EC2的软件设备。因为我们在这方面有很多经验 Python, 我们选择了 Django, 运行在 MySQL. 发生了一些新的事情。实际上，我是从数据库开始工作的。

随着我国平原地区的发展CRUD应用程序继续运行，我开始意识到数据库是多么重要——它对我们的系统是多么重要。如果我们丢失了数据库，我们的软件开发就白费了。如果数据库损坏了数据，我们客户的设备可能会未经许可，他们的网络将停止运行。如果数据库不能正常运行，成千上万的人将同时受到影响。但这些事情都没有发生过。数据库始终工作。它从不让我们失望。我印象深刻。
后来我发现了外键约束，唯一约束，引用完整性，索引，（记住，在这个时候我什么都不知道关于这些事情）-数据库可以通过各种方式帮助我构建一个更健壮的系统。我终于意识到现代数据库是惊人的-数据库是世界上最无聊的东西直到你真的必须用它们来构建一个系统。

你也永远不会忘记你的第一个搜索系统

到2012年，我领导了一个团队，建立了一个大型索引和搜索系统基础上的大型键值数据库，带有弹性搜索在其核心。看看elasticsearch这样的系统能做什么 —— 一个建立在世界级索引这项技术——即使其下有TB级的日志数据，也让人大开眼界。
到现在为止，我甚至看到数据库和搜索系统也失败了，但我被数据库技术迷住了。到2014年，我加入了一个小型专门团队，开发[开源时间序列数据库]的核心(github.com/influxdata/influxdb).

我学到的

算法真的很重要

只有在数据库开发中才有大O分析真的活过来了。数据库是程序员仍然需要循环、排序和过滤数百万对象的少数应用程序之一。这是少数几个在CS课上学到的很多枯燥材料都很重要的地方之一。

其他许多软件开发都不是这样。写入启动ROM固件？不，算法对我来说从来都不重要。调谐器设备驱动程序? 不，没关系。网络设备管理软件? CRUD应用程序？几乎不所有这些学科都需要不同的技能和知识。大多数时候，我只是在面试中讨论了运行时的复杂性。
但随着数据库的发展，这一切都发生了变化。实际上看到一个系统返回正确的结果，但是由于算法的改变，只在以前的一小部分时间内，看到它发生在您的代码中，在您构建的系统中，这是一件美妙的事情。

表现也很重要

软件中有一个老故事是这样的：程序员编写的一些代码的运行速度比以前的版本快十倍。他展示了它，但有人指出，它产生的数据与正确的数据略有不同。“但是速度快了十倍。”程序员指出。“好吧，如果它不需要是正确的，我可以制作一个完全不占用空间、运行速度无限快的版本”，另一个回答说。
这个道德故事一直对我影响很大。正确总是比什么都重要。这是真的。但这也让我相信，项目之所以有价值，仅仅是因为它们产生了正确的结果。

PNG Maker

利用 PNG Maker AI 将文本转换为 PNG 图像。

下载

对于数据库，情况并非如此。
性能不仅仅是一项功能。这是一个要求。那些愿意为数据库掏钱的人经常这样做，因为他们拥有大量的数据。如果数据库在这种情况下不能很好地执行—如果它不能快速有效地返回结果—那么它可能根本不工作。

你认为写系统很复杂吗？

我认为开发数据库最让我震惊的是查询引擎变得如此复杂。我有很多构建系统的经验，可以将数据写入并存储到磁盘。使这些系统运行良好可能是一项重大挑战。
但这种复杂性通常比查询引擎的复杂性要小得多。一个灵活的查询系统——有效地构建一个系统来回答问题，当你不知道问题会是什么的时候——需要认真的设计思想。查询计划器必须有效。查询系统必须支持许多正交需求——按某些维度过滤，按其他维度分组，连接来自不同表的数据——有时还支持来自外部源的数据。最后，查询系统必须高效且性能良好。这导致了设计和实现中抽象和优化之间的紧张关系，这需要真正的技巧才能很好地管理。

在现实世界中，它必须被操作

任何重要的数据库都必须支持备份、恢复、碎片管理和监视等基本操作。
如果我，作为一个严肃的操作员，不能备份你的数据库，我不能使用它，就这么简单。数据库接受写操作的速度有多快并不重要。在查询过程中，它的内存占用有多小并不重要。如果我不能保护数据库中的数据不受数据库创建者您无法控制的故障的影响，我将永远无法舒适地运行它。
当然，有很多方法可以备份数据库，而不需要数据库的合作。但内置方法通常是最好的。这也是我向 rqlite v2.0.如果我想让任何人认真地使用rqlite，我必须解决现实世界中的问题，即系统可能完全失败，并将数据拖得很长时间。

因此，在设计和实现数据库时，从一开始就要构建操作支持。将其作为设计的基本部分。您的用户将为此感谢您。

答案通常是“视情况而定”

当您第一次开始使用数据库时，尤其是作为一名操作员，您经常会问这样的问题：系统可以以什么速率索引？它对查询的响应速度有多快？我需要多少磁盘空间？一块碎片能有多大，而且还能正常工作？我怎样才能加快速度？所有人都毫无保留地问。我过去常常自己做。
也许你可以和数据库程序员谈谈，问他们这些问题。而你经常——也许永远——得到的回答是：这取决于你。你必须基准，你必须衡量。听到这个消息可能会很恼火，而且可能看起来像是在逃避责任。

但事实并非如此。
现在，当我听到这样的问题时，我会微笑。太天真了。
索引率可能取决于数据的大小，而不仅仅是文档或数据点的数量。这可能取决于批处理、数据的基数、数据库是否群集、数据中的哪些列和字段被索引、是新数据还是对现有数据的更新、运行数据库的机器、RAM、IO性能以及使用的复制。
控制性能的变量永远不会结束。
对于查询，可能取决于时间序列数据的时间范围。它取决于命中的记录数、查询的字段数、是否涉及范围扫描、数据是否索引、使用的索引类型、可能访问的碎片数、数据是否为本地数据。以及机器的特点。它有货吗？它正在进行维护吗？网络忙吗？

所以答案总是, 视情况而定。数据库设计者是诚实的。他们可以知道他们建立的系统的一切，但仍然不知道您的问题的答案。