Question

我的Oracle数据库包含一些简单的，很少更改的数据（更改它需要几个月甚至几年）。但它经常访问（每天数百次）。我认为在数据库中持续访问它是昂贵的。

编辑：我正在考虑另一种存储这些数据的方法，而不是存储在数据库中，例如，将其存储在我的应用程序缓存中，但我对数据一致性感到困惑。我怎样才能有效地做到这一点？

编辑：我原来的问题太笼统了。我想更清楚地解释一下：

我有一张包含以下内容的表：

MinValue       MaxValue       PackageID
1                4             1
5                10            2
11               50            3

当客户向我们的服务发送请求时，它会发送金额，然后我们的服务必须确定此请求属于哪个包。这取决于数量，并可能因业务需求而改变（正如我之前提到的，很少改变）。

我使用此查询执行此操作：

select packageid from vmeet_temp where amount between minvalue and maxvalue

是的，确实有效。但由于我是一个没有经验的程序员，我怀疑是否有更有效的方式来归档这个。

所以我的问题是：为了我们的需要，我们应该将这些信息存储在数据库中吗？如果没有，哪个解决方案要去？

Answer 1

将其存储在一个表中，让DBMS担心它。它具有缓存功能，并且擅长确保经常使用的数据存储在内存中，因此无需转到磁盘。如果您真的想要，可以将数据加载到您的应用程序中 - 您将面临数据过时的（小）风险。但一般来说，让DBMS担心它，它会适合你。

如果表只有10行，并且行的大小适中（每行最多几百个字节），那么DBMS可能不会因为使用索引而烦恼，即使你创建了一个 - 它知道它会直接使用表格会更简单，更有效。即使是头脑简单的优化者也能做到这一点。显然，如果你使用错误提示的索引来使用它，那么你就可以支付性能损失。如果留给自己的设备，优化器不太可能使用索引。

Answer 2

首先，@ Jonathan Leffler是正确的，数据库非常擅长缓存有限数据的简单查询。因此，如果数据库服务器没有出现压力迹象，例如高CPU利用率或磁盘I / O，那么事情可能就好了。如果是，Oracle会management views告诉您哪些查询消耗的处理能力最强。

关于缓存，如果您只有一台服务器并且基础表通过同一个应用程序更新，则可以使用直写策略。如果是多服务器设置，则需要使用消息传递来刷新每个服务器上的缓存。如果数据未通过应用程序更新，则需要使用后写策略来检查或了解数据何时更改并刷新缓存。

如果性能是您真正关心的问题，我建议您专注于负载测试，以使用JMeter等工具识别瓶颈。通过迭代更多线程来强调每次记录性能指标 - 通常是页面响应时间 - 并在Excel中绘制出来。如果你看到一条指数线，你就发现了一个瓶颈。退出一些并开始在代码中添加计数器以查看减速的位置。您可能会发现它与您询问的数据无关。

Answer 3

我建议您查看11g中的客户端结果缓存。

一个例子是here

"This feature enables client-side caching of SQL query result sets in memory. The client result cache is completely transparent to ODP.NET applications, and its cache of result set data is automatically kept consistent with any session or database server side changes that would alter the results.

.NET applications calling the same query multiple times see improved performance since query results are retrieved locally. Local client processing is faster than making database round trips to re-execute a query and fetch results. If applications are frequently running the same queries, they will experience a significant performance improvement when their results are cached on the client, as well as a reduction in database server load."

Answer 4

即使数据库数据很少，缓存也是一个好主意。它适用于此类情况 - 很少更新数据。它确实可以加快速度，因为在很多情况下你甚至不需要去DB。

这是一篇描述.NET中缓存的文章

http://msdn.microsoft.com/en-us/library/aa478965.aspx

如果您的应用程序运行缓慢，您需要使用分析器进入，并找出瓶颈所在的位置......

Answer 5

相对于典型系统将执行的其他数据访问，任何命中小表的查询都不太可能是昂贵的。

通过缓存来优化此查询可能需要相当大的努力（正如其他答案所示）。

作为一名缺乏经验的程序员，您可能希望通过以下引用来实现您的自我：

过早优化是其根源所有的邪恶

存储很少更改数据但经常访问，这是解决方案吗？

5 个答案: