5

我正在实施一项服务，其中每个用户都必须拥有自己的 json/文档数据库。除了让用户通过示例查询 json 文档之外，数据库还必须支持涉及多个文档的 ACID 事务，因此我放弃了使用 Couch/Mongo 或其他 NoSQL 数据库（不能使用 RavenDB，因为它必须在 Unix 系统上运行）。

考虑到这一点，我一直试图想办法在 SQL 数据库之上实现它。到目前为止，这是我想出的：

CREATE TABLE documents (
  id INTEGER PRIMARY KEY,
  doc TEXT
);

CREATE TABLE indexes (
  id INTEGER PRIMARY KEY,
  property TEXT,
  value TEXT,
  document_id INTEGER
)

每个用户都有一个包含这两个表的数据库，并且用户必须声明他需要查询哪些字段，以便系统可以正确填充“索引”表。因此，如果用户“A”将其帐户配置为启用按“姓名”和“年龄”进行查询，则每次该用户插入具有“姓名”或“年龄”属性的文档时，系统也会向“索引”插入一条记录表，其中 'property' 列将包含 name/age ， 'value' 将包含属性值， 'document_id' 将指向相应的文档。

例如，假设用户插入以下文档：

'{"name" : "Foo", "age" 43}'

这将导致对“文档”表的插入和对“索引”表的另外两个插入：

INSERT INTO documents (id,doc) VALUES (1, '{"name" : "Foo", "age" 43}');
INSERT INTO indexes (property, value, document_id) VALUES ('name', 'foo', 1);
INSERT INTO indexes (property, value, document_id) VALUES ('age', '43', 1);

然后假设用户“A”向服务发送了以下查询：

'{"name": "Foo", "age": 43}' //(the queries are also json documents).

此查询将被转换为以下 SQL：

SELECT doc FROM documents
WHERE id IN (SELECT document_id FROM indexes
             WHERE document_id IN (SELECT document_id FROM indexes
                                   WHERE property = 'name' AND value = 'Foo')
             AND property = 'age' AND value = '43')

我的问题：

  • 知道用户可能能够在他的查询中使用大量条件（比如说 20-30 个 AND 条件），这会导致子查询嵌套非常高，以上 SELECT 查询在大多数数据库系统上的效率如何（ postgres，mysql ...）？
  • 上述解决方案对于最终将包含数百万/数十亿 json 文档的数据库是否可行？
  • 有没有更好的方法来满足我的要求？
  • 是否有可扩展的文档数据库可以进行涉及多个文档的 ACID 事务并在 Unix 系统上运行？
4

1 回答 1

5

您的indexes表是所谓的Entity-Attribute-Value.

EAV 表非常适合存储信息并在您知道实体时调用它。 （在您的情况下，当您知道 . 时查找所有indexes行document_id。）

但是反过来它们就很糟糕：提供属性-值组合来搜索实体。这正是您在最终查询中所拥有的。随着越来越多的实体共享相同的属性值组合（例如name=foo），查询性能会下降。

因此，要回答您的前两个问题：
1. 所写n的查询在搜索n属性时需要子查询。n随着增长，这将非常糟糕。
2. 随着记录数量的增加，它会下降，尤其是数百万/十亿条记录。

一般来说，如果你读到EAV，人们强烈建议你避开它。


而且，更糟糕的是，在 SQL 中并没有真正好的替代方案。优化搜索的标准方法是使用索引，它可以很容易地建模为排序数据集。但是您将需要许多索引：
-如果您搜索所有三列，则索引(fieldX, fieldY, fieldZ)非常好。
- 但是，如果您必须仅 fieldZ搜索.


如果您可以使用具有固定列数的传统表重新建模，并且有空间应用您需要的每个索引组合，那将是您最高效的模型。

如果您无法修复列数（新properties出现的所有时间）和/或您没有空间用于所有不同的索引组合，那么您似乎被 EAV 卡住了。这会起作用，但就“即时”结果而言，它的扩展性不会很好。

注意：如果你坚持使用 EAV，你测试过这个查询结构吗？

  SELECT
    document_id
  FROM
    indexes
  WHERE
       (property = 'name' AND value = 'Foo')
    OR (property = 'age'  AND value = '43' )
  GROUP BY
    document_id
  HAVING
    COUNT(*) = 2

这假设它(document_id, property, value)是唯一的。否则一个文件可能有('name', 'foo')两次，因此通过该COUNT(*)子句。

于 2012-06-25T16:00:39.117 回答