存储小的、交替的、每隔几个小时更新的公共数据的最佳方式？

Question

我的问题的本质是有太多的解决方案，我想在围绕它建立基础设施之前，找出哪一个在利弊中胜出。

(为了这个论坛的目的而简化)这是一个拍卖网站，其中五个拍卖被存储在排名#1-5中，#1是当前的特色拍卖。其他四个只是简单的“在甲板上”。在几个小时或完成拍卖后，#2-5移动到#1-4，新的#5被选择为#5

我使用的是专用服务器，并且我一直在考虑只将数据存储在servlet中，或者可能在数据库中为每个auction...like "isFeatured = 1“添加一列布尔值。

可以说，读取数据的频率比写入数据的频率高出大约5 times+，这就是为什么我倾向于使用好的旧SQL。

Answer 1

当您可以使用ORDER BY和TOP或类似的简单查询从DB检索相关拍卖时，请尝试以下操作。如果没有出现性能问题，那么使用KISS就可以了。

否则，当这5次拍卖在一段时间内有效时，将它们缓存到内存中。例如，让一个单例来处理这些拍卖，并提供更新方法。也许你想使用缓存库。在必要时更新这些Top5，但直接从内存中提供它们，而不会影响数据库或其他类似的开销。

Answer 2

你想要什么样的规模？有多少应用程序服务器需要访问数据？

我想你可能把事情搞得更复杂了。只需使用数据库，尝试一下ACID，然后转到您需要处理的任何其他方面。:P

Answer 3

你看过SQLite吗？它允许“良好的旧SQL”，而不需要设置单独的数据库服务器。只要数据不是太大(公平地说，我没有测试大小限制，但我略读了一下博客文章，其中提到了使用SQLite快速处理几十MB大小的文件，并且没有问题)，您就应该没问题。

它并不是满足所有需求的完美解决方案(坦率地说，我有时发现dynamic typing很麻烦)，但由于它依赖于本地存储的文件，因此读取将比启动网络连接与更“传统”的RDBMS对话要快得多。