ruby - 写密集型特征的架构

Question

我在当前项目中使用由 Oracle 数据库和 memcached 支持的 Ruby on Rails。

有一个非常常用的功能，它依赖于单个数据库 View 作为数据源，并且该数据源内部有其他数据库 View 和表。

这是一个虚拟数据库 View ，能够从一个地方访问所有内容，而不是物化数据库 View 。

大多数情况下，如果用户正在使用他们希望更新的功能，那么让数据保持最新很重要。

从这个 View 获取数据时，我将安全表内部连接到 View (安全表不是 View 本身的一部分)，其中包含一些我们用来在更细粒度级别上控制数据访问的字段。例如，安全表有 user_id, prop_1, prop_2 列，其中 prop_1, prop_2 是数据库 View 中可用的列，user_id 是已记录的在用户。一些用户在安全表中有相同的属性，比如 prop_1 = 1 和 prop_2 = 1，但也可以像其他用户一样有 prop_1 但有不同的 prop_2 像 prop_1 = 2 和 prop_2 = 1。 prop_1 和 prop_2 有很多不同的组合，可以将它们视为另一个表的 FK，因此可能有很多条目。

现在在应用程序上检索记录的时间将近 10 秒，非常慢。我正在考虑替代方法。

我首先想到的是物化 View ，但由于用户经常更新，它可能不是最佳选择，因为刷新 View 可能需要时间。

我想到的第二件事是缓存，使用 prop_1 和 prop_2 组合作为底层数据的复合键，因为许多用户拥有相同的组合，无论谁具有相同的组合可以访问相同的数据。

但是，这种方法可能需要更多的代码重写和逻辑来保存和检索片段中的数据，而不是像在数据库 View 中那样从一个位置使用一个查询。

根据您的经验，您是如何解决相同/相似问题的？或者我可以尝试更好的方法吗？

Answer 1

如果没有更多关于您的观点的信息，很难给出一个好的答案，但我会试一试。

首先，我质疑使用一个非常复杂的 View 。这很难调整，而且经常会导致性能问题，所以如果可以在应用程序中将其拆分，那将是我的第一个赌注。

其次，您是否查看了包含安全过滤器的查询的执行计划(解释计划)？它使用合理的索引吗？如果没有，请创建它们。例如，也许安全属性未编入索引？

第三种选择可能是使用 PL/SQL 并调用一个类似于 View 的存储过程。这使您可以更好地控制数据库，从而可以控制查询并将其拆分为多个步骤，但要获得与今天相同的结果。

最后，您可以重写 View 以获得更好的性能。一个经常被忽视的功能是 WITH 子句，它可以在主查询之前运行查询并将结果用作表。它帮助我显着提高了复杂 View 的性能。

DBMS_RLS 很酷，但可能很贵，它需要企业版，如果您也需要单独的许可证，我不会感到惊讶。我会首先寻求程序化解决方案。