<分区>
数据库是记忆化的合理数据结构吗？当需要缓存极其大量的数据时，一个普通的软件主动将其维护在内存中可能是不合理的。数据库可以很容易地存储计算结果供以后使用，这意味着可以随时停止和启动计算，而不会影响程序的进度。如果数据库是共享的，处理也可以分布在多个系统(计算机集群)之间。
我唯一的保留意见是，查询数据库造成的延迟可能会影响算法性能，尤其是当算法非常快速地处理许多排列时。当然，只有在算法/应用程序的空间复杂度极高(千兆字节)时才需要数据库内存。有什么想法吗？
<分区>
数据库是记忆化的合理数据结构吗？当需要缓存极其大量的数据时，一个普通的软件主动将其维护在内存中可能是不合理的。数据库可以很容易地存储计算结果供以后使用，这意味着可以随时停止和启动计算，而不会影响程序的进度。如果数据库是共享的，处理也可以分布在多个系统(计算机集群)之间。
我唯一的保留意见是，查询数据库造成的延迟可能会影响算法性能，尤其是当算法非常快速地处理许多排列时。当然，只有在算法/应用程序的空间复杂度极高(千兆字节)时才需要数据库内存。有什么想法吗？
最佳答案
如果您担心在单台机器上处理大数据，答案几乎肯定是不!而在现代硬件上，如果答案不是不，那么要么是计算的模式，否则计算应被裁定为不可行。但是有几个变体可以发挥作用。
记忆化的好处在于重新计算的成本比获取以前的答案要高。但是，如果您的答案适合 RAM，那么使用数据库就没有好处，因为将存储保存在内存中会更快。因此，数据库唯一有趣的情况是答案不适合 RAM。
为了便于讨论，我们假设每个键/值对占用高达 640 个字节。让我们假设您有 64 GB 的 RAM 可用。因此，为了使其不适合 RAM，您需要超过 1 亿个事实，这些事实是随机创建/访问的。但是，让我们考虑实际的硬件。这些事实，当它们不适合 RAM 时，存储在硬盘驱动器中。硬盘驱动器以 6k RPM 或每秒 100 次的速度旋转。这使得获取/存储随机数据的时间平均为 1/200 秒(平均而言，您必须旋转一半才能找到数据)。因此，在您填充数据结构后，再次随机访问它需要 1 亿 * 0.005 秒 = 500,000 秒，也就是将近 590 天。我们花了数年时间才访问数据(更不用说创建数据了)，这已经非常接近硬件故障的平均间隔时间了。 (顺便说一句，我们可以在这里利用一些并行性，硬盘驱动器可以一次查找他们正在查找的多个磁盘扇区，但这是有限的，不会拯救你。)
道德是随机访问磁盘上的大型数据集是不可行的。即使你在它前面放一个数据库。硬盘驱动器不是 RAM，不应将其视为 RAM。
但一切并没有丢失。
数据库有意义的场景是您对分布式计算的建议。如果你的计算步骤很昂贵，内存调用相对较少，并且数据可以放在内存中，那么数据库就非常方便。对数据库的调用会很快(东西在内存中)，你不能简单地将东西保存在本地硬盘上(你的数据分布在多台机器上以使用 CPU，因此没有共享硬盘)，并且数据库可能只是因为它在那里很方便。 (我以前就是这样用过数据库的，很开心。)
但是在这种情况下，数据库只是一个键/值存储。虽然 SQL 数据库可以工作，但您可能需要考虑非 SQL 解决方案。一旦你选择了无 SQL 解决方案，你就可以选择数据存储，无论你有多少数据，数据都被分片，这样所有数据都适合 RAM。 (是的，你也可以对关系数据库进行分片。eBay 是我所知道的一家公司的一个很好的例子，但是一旦你这样做了，你往往会失去它的“关系”部分。是的，我知道有几家公司声称不是这样，他们的声明带有重要的警告。)
事实上，当您进行 Google 搜索时，您正在运行的只是这种分片数据存储，其中包含的内容本质上是对许多问题的内存答案，这些问题涉及哪些页面与哪些关键字匹配，以及哪些页面最匹配相关的。没有内存，他们永远做不到。但如果他们不得不去硬盘驱动器寻找答案，他们也永远无法真正做到这一点。 (他们也不使用 SQL...)
关于数据库内存？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10081247/