[这是一个连续系列的一部分，旨在提醒您使用基于文件的数据和数据库之间的问题。]
在我的上一篇文章中，我展示了如何使用简单的基于文本的格式来存储记录，以及这对读取/写入这些记录意味着什么。 在这样的系统中搜索意味着你有相当多的工作要做，因为你需要扫描整个文件。
这对我们没什么好处。 因此，我们需要引入索引。 索引实际上是一个非常简单的想法。 假设我们有原始文件，我们将有以下用户名索引:
基本上，索引中的第一列是用户名的值，这些值是经过排序的，因此搜索索引有一个与之相关的复杂度。 一旦我们这样做了，我们就有了记录号，我们可以用它来找到文件中的位置并读取整个记录。
总之，这是非常基本的，对吗？ 那么为什么我要用一整篇文章来讨论这个话题呢？
如果我们计划只做索引，那么索引的问题数据库异构同步 就很简单了 一次。 但是我们想更新它们，这导致了某些问题。 虽然上面的索引只显示了几条记录，但我们这里所说的实际数据量是一百万条记录。 这使我们的总索引大小约为16MB。 如果我们需要添加新的用户名会发生什么？ 在这种情况下，一个铁杆球迷的用户名是“棒球”？
为了维持秩序，我们必须把它放在前两个条目之间。 这就要求我们将其余的数据移动相同的量。 实际上，为了给索引添加一个条目，我们必须写16MB。
换句话说，因为文件不允许我们在没有大量昂贵的输入/输出的情况下从文件的中间动态地添加/移除数据，所以我们不能真正使用平面文件来实现这一点。 这并不奇怪，但是我想从最基本的开始，在我们发现为什么我们需要这些东西的时候，带我们进入复杂的层次。
因此，我们需要找到一种文件格式，这样我们就可以更新内容，而不必每次都打乱整个文件。 查看文献，我可以将平面文件方法与排序数组进行比较，它有相同的问题。 典型的解决方案是使用二叉查找树。 这样，我们总是在文件的开头有树根，并根据我们需要去的地方使用偏移量在文件中跳转。
在这种文件中搜索的代码如下所示:
请注意，这已经删除了所有的错误处理，虽然它给了我们想要的，但是这个解决方案有几个问题。
首先，如果我们想要有好的性能，我们需要在插入/删除时平衡树，这可能很复杂。 不仅如此，这还意味着我们实际要执行的文件操作数量相当高。 这不好，因为文件驻留在(非常慢的)硬件上，所以我们可能不想使用它。
相反，我们需要找到一种方法，使我们能够在文件中执行更少的搜索(在标准硬盘上大约需要10-20毫秒)，并且能够更好地处理并发工作(不会在磁盘头位置上争得太多)。 我们还需要确保当我们修改某些东西时，我们必须做的工作量是最小的。 在平衡树的情况下，平衡它的工作量可能非常大，而且你必须跳来跳去(因此，寻找)的地方数量是难以置信的。
在下一篇文章中，我们将在这里讨论持久算法选项，以及我们应该使用什么来存储数据。