在小子集上密集操作时构建内存索引并绕过数据库是一个好主意吗？

Question

我正在开发一个程序来自动找到最佳轮班分配，但会受到很多限制。我正在使用grails，即有关工人、轮班和分配的数据将保存在 DBMS 中。

对于优化本身，我必须非常集中地处理一小部分数据（来自大约 5 个不同表的总共大约 600 行）。我将不得不迭代并搜索各种子子集数十次以计算适应度函数、更改一些值、再次计算适应度、起泡、冲洗、重复，也许数百次。

现在，虽然搜索和迭代正是 DBMS 的用途，但我相信在这种情况下，数百个 DB 请求的开销会使实际完成的工作相形见绌，即使对于像 HSQLDB 这样的内存 DBMS 也是如此。因此，相反，我计划在开始时将整个子集放入内存中，为我必须要做的查找构建我自己的索引（主要是 HashMap），然后只使用这些索引，远离数据库直到我已经完成并将我的结果写入它。

这是一种合理的方法吗？有更好的想法吗？

Answer 1

我假设您必须向数据库发出数百条命令？ DB里面的代码没有办法执行吗？

我最担心的是诚信；确保您正确处理锁定。您可能希望将版本号存储在某个地方，这样您就不需要在处理期间锁定整个数据集。在更新事务中，您首先要确保版本号与您开始阅读时的版本号相同。

最后，对它进行基准测试？在过去一年左右的时间里，我做了一些应用程序，每个请求都有类似的非常密集的计算过程。使用进程内对象来表示数据比每次请求访问数据库效率要高几个数量级。但是每个应用程序都是不同的，可能会有一些没有考虑到的事情会影响它。