问题标签 [document-database]

我有一个申请。它将其对象图写入 Mongo。对于某些集合，我们希望规范化数据并将其镜像到关系数据库（SQL Server 或 SQLite）。

我在想最好的方法是通过集合上的 MapReduce 工作。这是正确的方法吗？这可能吗？如果这有所作为，我们将在 Windows 上运行。

更新

我正在寻找的只是关于 JavaScript 中的 MapReduce 作业是否是解决此问题的最佳方法的一般指导。假设我有一个包含两个字段的对象，FirstName并且LastName. 当我将其写入集合时，我需要关系数据库中的一行（它有两列FirstName和LastName）。

当然，我可以在写入集合时将其写入应用程序中的 SQL 表。但我认为也许更好的地方是在数据库中。如果需要，这将允许我在将数据写入关系数据库之前对其进行整形。

现在我已经详细阐述了一些问题，我可以看到其他一些我没有明确提出但相关的问题。运行 MapReduce 作业的 JavaScript 甚至可以访问 Mongo 之外的任何内容吗？是沙盒吗？并且将这样做作为 MapReduce 工作会影响写入性能（我猜不是，而是 IANAE，因此是问题）。

我在 RavenDB 中序列化/反序列化时遇到了一些问题。我存储数据没有问题，但在查询文档时遇到问题。

我有一个相当复杂的 Account 类，它是从 Entity Framework v4.3 POCO 生成器生成的：

当我查询我的对象并将它们作为列表返回时，我得到一个 .NET 反射错误“对象与目标类型不匹配”。

我认为这可能是因为当我保存它时，我还有其他嵌套类和可空值也被序列化，但我发现我可以创建一个名为 AccountWrapper 的“包装器”类，如下所示：

在这里，我将手动使用 JSON.NET（是的，与 RavenDB Buid 960 一起提供的相同的 .dll）来填充 SerializedText 字段，然后将其存储到 RavenDB。这个过程会奏效！我会从 RavenDB 中获取 AccountWrapper 对象，然后手动反序列化 SerializedText 的内容。这让我相信默认（反）序列化过程可能存在问题。

所以我的问题是，有没有一种方法可以在存储/加载文档时手动覆盖 RavenDB 上的序列化/反序列化功能？如果是这样，有人可以告诉我一个如何做到这一点的干净例子吗？然后我可以让它使用标准JsonConverter.Serialize()作为 JSON.NET 的一部分

显然，使用 AccountWrapper 是一个坏主意，因为我无法索引需要查询的“真实”数据。

（下面的异常的完整堆栈跟踪）

我正在考虑一种设置，其中我将实体存储在文档数据库（例如 CouchDB）和图形数据库（例如 Neo4j）中。基本原理是将每个实体信息（数据、blob、值、复杂的内部结构）存储在文档数据库中，同时将实体关系（父、子、关联实体）存储在图形数据库中。

有没有人做过/看到/被这样的设置咬过？我应该期待什么样的问题？首先想到的是两阶段提交。但是备份在这里也有问题。

我什么时候想使用文档数据存储以及何时使用键值数据存储？

谢谢！

看到最后的结果

我想使用文档数据库（出于各种原因）——可能是 CouchDB 或 MongoDB。但是，我的多文档交易也需要 ACID。

但是，我确实计划使用“仅添加”模型 - 更改作为新文档添加（添加是添加，更新是添加副本+转换数据，删除是添加具有相同 ID + 删除标志的空文档）。我会定期对数据库运行压缩以删除非当前文档。

考虑到这一点，以下想法是否存在漏洞：

维护正在进行的当前事务的集合。此集合将保存带有正在进行的事务的事务 ID（GUID + 时间戳）的文档。

它有点像 MVCC，有点像 Git。我通过我知道在我开始之前设法完成的事务来设置检索上下文。我通过保留“正在进行的交易”而不是“交易修订”的列表来避免单一序列（因此单一执行）。而且，当然，我避免阅读未提交的事务并提供冲突回滚。

那么 - 这有什么漏洞吗？我的表现会受到严重影响吗？

编辑1：拜托拜托-不要敲打“如果您需要多文档交易，请不要使用文档数据库”。我知道，出于其他原因，我还是需要一个文档数据库。

Edit2：添加时间戳以避免来自检索事务开始后开始的事务的数据。可能会将时间戳更改为序列 ID。

Edit3：这是我想到的另一种算法 - 它可能比上面的更好：

新算法 - 更容易理解（这次可能更正:)）

我们开始时文件是否已提交？
如果我们在当前执行的事务中看到具有事务 ID 的文档——它是在我们开始检索之前开始但当时尚未提交的事务——所以我们不想要它。如果我们看到一个事务 ID >= top transaction ID 的文档——它是在我们开始检索之后开始的事务——所以我们不想要它。

文档是最新的（最新版本）吗？
如果我们看到一个不在当前事务 ID 中的文档（事务在我们开始之前开始）并且是 < 顶级事务 ID（在我们开始之后开始的事务） - 那么有一个事务在我们过去完成提交使这个文件过时了——所以我们不想要它。

为什么排序不会受到伤害？
因为我们将排序添加为最后一个子句，所以我们总是会首先看到真正的排序工作。对于每个真正的排序“桶”，我们可能会得到多个文档，这些文档代表不同版本的模型对象。但是，模型对象之间的排序顺序仍然存在。

为什么计数器不让事务串行执行（一次一次）？
因为这不是 RDBMS——我们并没有真正的事务，所以我们不会像“选择更新”那样等待事务提交。另一个事务可以在我们完成后立即进行原子更改。

压缩：
有时必须进行一次压缩——获取所有真正旧的文档并将它们删除到另一个数据存储中。这不应该影响任何正在运行的检索或事务。

优化：

1. 将条件放入查询本身。
2. 将事务 ID 添加到所有索引。
3. 确保具有相同模型对象 ID 的文档不会被分片到不同的节点。

费用是多少？
假设我们想要多个文档版本用于历史记录和审计，额外的成本是自动更新计数器、创建交易记录、“密封”每个模型对象的先前版本（标记为过时）并删除交易文档。这不应该太大。请注意，如果上述假设不成立，则额外成本相当高，尤其是对于检索而言。

结果：

我已经实现了上述算法（修改后的算法略有改动）。从功能上讲，它正在工作。但是，性能（至少在主从复制拓扑中具有 3 个节点的 MongoDB 上，没有 fsync 但在“提交”结束之前需要复制）是非常糟糕的。我一直在阅读我刚刚从不同线程中写入的内容。我在事务集合上获得了持续的集合锁，而我的索引跟不上持续的翻转。对于具有 10 个馈线线程的微小事务，性能上限为 20 TPS。

简而言之 - 不是一个好的通用解决方案。

在我看来，当您创建一个 Mongo 文档并且有一个{key: value}有时不会有值的字段时，您有两个选择：

1. 写入{key: null}即在字段中写入空值
2. 根本不要将密钥存储在该文档中

这两个选项都很容易查询，一个是您查询，{key : null}另一个是您查询{key : {$exists : false}}。

我真的想不出这两个选项之间的任何差异会对应用程序场景产生任何影响（除了选项 2 的存储量略少）。

谁能告诉我是否有任何理由更喜欢这两种方法中的任何一种，为什么？

编辑

在问了这个问题之后，我还想到索引在这两种情况下的行为可能不同，即可以为选项 2 创建一个稀疏索引。

我需要通过几个模型的视图来做一些计算。例子：

假设在老师的观点上，我需要汇总 gold_stars、silver_stars 和 brown_stars 的数量。聚合视图中的值的最干净的方法是什么？我猜我会使用 after_update 回调，但我不确定是否有更好的方法。

更新

我想要的是老师显示他所有的学生总共有多少颗金星，然后是银，然后是铜。

编辑

原来我正确地存储了文档，所以这个问题的开头部分不正确，可能是因为我对 RavenDB 缺乏经验。但是，我仍然有在单元测试中使用 EmbeddableDocumentStore 时能够打开 RavenDB Management Studio 的问题。

在使用 NUnit 进行单元测试期间，我似乎遇到了在 EmbeddableDocumentStore 中存储文档的问题。为了查看我是否真的在存储我正在尝试连接到嵌入式数据库的文档。

当试图打开 url http://computername:8080/（由于某种原因 raven db 总是使用我的电脑上的计算机名）时，浏览器加载栏只是旋转，如果我停止单元测试并再次尝试 url Chrome 只是给出我无法连接的消息。这是上下文的一些代码。

我的测试项目的根目录中还有 Raven.Studio.xap 文件。

我正在使用 VS2012 和 .Net 4.5，如果有区别的话。

我有一组实体，它们都是从抽象类派生的

当我持久化所有实体时，我想将Name字段用作键，因此我覆盖DocumentKeyGenerator并提供了这样的实现：

当我第一次持久化实体列表时它工作正常，但如果我想再次持久化它们，我会遇到异常

我刚开始使用 RavenDB，所以我不明白我做错了什么？

我一直在做一个项目，用户可以创建简单的模板并开发他的网站页面。他可以保存它们并在完成后将其放到互联网上。现在我的问题

1. 当用户在他的模板上工作时，他可以保存他完成的工作副本并稍后返回（类似于起草电子邮件）。
2. 用户保存的这个工作通过解析模板页面当前保存在xml文件中。
3. 我正在考虑一种替代方法，将整个页面本身存储在文档数据库中，针对唯一的用户 ID，这样就不需要进行任何解析并减少负载和时间。

现在我的问题

1. 我认为使用文档数据库 或 nosql 而不是 xml 可能吗？
2. 如果是的话，哪一个更灵活且易于维护？
3. 我正在使用 php 和 mysql 进行其他操作，所以我需要 doc DB 来存储用户创建的模板的 html。