问题标签 [document-store]

我确实理解文档存储中并不真正需要关系，但对于某些事情它们仍然有用。还是我错了（在 RDBMS 上雪上加霜）？

例如：

假设我有一堆文件及其修订历史：

我应该为文件和所有修订添加用户对象CreatedBy，还是应该是引用用户文档的 ID？常见的做法是什么？

我在 RavenDB 网站上阅读了Backup and Restore文档并在我的代码中进行了尝试。

在文档中，我们有：

启动备份

在嵌入模式下运行时，您只需调用方法 DocumentDatabase.StartBackup()。

上面的代码行不会编译错误：

所以我尝试了这个只是为了测试：

代码编译但是当应用程序启动时我得到这个错误：

有人可以分享一些关于如何对在线嵌入式文档存储进行完整备份的工作代码吗？甚至可以不使用 RavenDB 服务器吗？

我唯一的选择是手动备份数据库文件夹？

我正在为（主要）Android 和 iOS 寻找无服务器嵌入式 noSQL 文档存储数据库。
为了简化，我需要一个基于文档的 SQLite ：P

MongoDB很棒，有很多驱动程序，但它需要一个服务器......
也许它的精简版本可能会很好......

非技术性的命名问题：

我有一个文档，其中包含对另一个文档的引用。大多数时候我访问它我需要引用文档中的几个字段，所以我将它们存储在引用旁边以避免查找。

蒙哥示例：

汽车

制作者

所以 auto.maker.name 不是主要来源——它永远不应该被改变，除非制造商的名字被改变了，这是昂贵但非常罕见的。

你怎么称呼这个领域？我见过的最好的是“缓存”，但它非常超载，特别是在谈论数据存储时。有更好的术语吗？

想知道哪种技术更适合网店的典型产品目录。我正在写关于企业环境中的 nosql 的硕士论文，并且我认为现在一直专注于文档存储。阅读大量推荐文档存储的文章，因为它具有为数千种不同产品建模所需的灵活性。但据我所知，像 Cassandra 这样的 Column-Family Stores 提供了同样的灵活性。

我最喜欢使用 cassandra 的想法是 nosql-database.org 对它的评价（标记为最有趣的功能）：

大规模可扩展、分区行存储、无主架构、线性扩展性能、无单点故障、跨多个数据中心和云可用区的读/写支持。API/查询方法：CQL 和 Thrift，复制：点对点，编写：Java，并发：可调一致性，杂项：内置数据压缩，MapReduce 支持，主/二级索引，安全特性。

最后，我专注于构建一个高度可用且可扩展的 Multishop 系统的原型，该系统利用多语言持久性，例如用于会话的 K/V 存储、用于产品目录的文档存储或列族存储，以及用于库存/定价的 RDBMS，例如Sadalage 和 Fowler 在他们的《NoSQL Destilled》一书中提到。

如果可能，请为您的答案提供科学论文或其他可靠来源。

谢谢！

我正在尝试从具有给定相当简单结构的文档中删除某些数据部分，随着项目的进行，这将变得比这更深更重：

我知道除了用更新的树替换整个树之外，没有办法从嵌套部分更新/删除部分。

例如，如果我想从文档数据中删除 key1，我需要使用不包含 key1 的副本更新文档数据部分

有没有更简单的方法可以从文档的根目录中删除一部分（如名称字段）而不用不包含名称键和值的自身副本更新整个文档？每次我需要删除部分数据时，是否必须深度复制和过滤文档？

我有一个使用 RavenDB 作为数据存储的 MVC4 应用程序。该应用程序具有 MVC/Web、域、数据和安全层。

我正在编写需要初始化数据库和访问 DocumentStore 的自定义成员资格和角色提供程序。我正在从安全层编写这些类，并且想使用单例 DocumentStore（在应用程序中设置），但我不知道如何访问它。

其他，我看到为 RavenDB 编写自定义提供程序的示例在 Provider.Initialize() 方法中创建新的 DocumentStore 实例，但这似乎违反了每个服务器拥有一个 DocumentStore 的规则。

目前，我在 Application_Start() 中创建了 RavenDB DocumentStore 的单个实例。我在处理 DocumentStore.Session(s) 的 MVC/Web 层中有一个基本控制器。

有没有办法做到这一点？我应该将我的安全逻辑移动到 MVC/Web 层以简化事情吗？

根据我所做的研究，我怀疑键值存储不是要走的路，但我想获得更多直接输入：

1. 确定键值存储是否甚至是我使用的可行解决方案。
2. 能够阐明我更喜欢文档存储的原因。

解释我的用例

我有一个包含许多“文档”的应用程序。这些当前存储在某种 CMIS 存储库中。然而，应用程序只有在这些文档被索引到 elasticsearch 之后才会与这些文档进行交互。这意味着所有的读取操作都会命中 elasticsearch，并且所有的写入操作都会更新 elasticsearch 和存储库。

请求的功能表明当前存储库过于严格，在该级别强制执行模型模式的理由为零。当然，这导致了对 NoSQL 选项的调查。

为了将这些“文档”填充到弹性搜索索引中，它们需要存在于某个地方，我必须能够在它们加载到索引时获取所有文件并对其进行分页（在此步骤中还会发生一些聚合以填充由现有字段构建的字段）。

现在，get all实际上是根据文档的类型分阶段完成的，但是这个要求可能是可以协商的，相反，一个简单的get all 类型就足够了，但并不理想。

在我对键值存储的理解中，存储对它存储的值一无所知，它们只能被一个键引用。这让我想知道当我不打算在任何地方维护完整的键列表时，我是否可以执行get all 。我已经看到一些键值存储支持使用字典作为键（redis）。我不确定这是否意味着我可以按类型查询（如果它是字典中的条目），或者我是否需要知道完整的字典才能获取值？

由于索引的填充只需要在弹性搜索失败时发生，因此性能不是我的首要任务（但它肯定不会受到伤害）。对我来说，MongoDB 似乎是一个近乎完美的选择。我可以存储文档并轻松按类型查询。

• 鉴于我的用例，文档存储似乎是一个不错的决定吗？
• 这也可以通过键值存储来合理解决吗？
• 使用一个比另一个有任何其他优势吗？

以防万一，对于文档存储，我一直在比较 CouchDB、Couchbase 和 MongoDB。对于键值存储，我一直在研究 Redis 和 BerkeleyDB。

我有以下情况：用户可以在网站上添加联系人（其他用户）。可选地，用户还可以将他的联系人组织成组。一个用户可以有许多电子邮件、地址和电话号码。

我想到了以下架构设计（文档存储/mongodb）。有什么方法可以改善这一点吗？我主要担心的是个人资料图片嵌入在文档中。我知道这不是一个好习惯，但为了这个特定目的（作业），我也必须在此处嵌入图片（blob/gridfs）。但我想知道如何改进这个模式。

考虑这张图片：

这本书说文档存储数据库与高度连接的域之间存在斗争，因为“聚合之间的关系不是数据模型中的一等公民，大多数聚合存储仅以嵌套映射的形式为聚合的内部提供结构。”。

此外：“相反，使用数据库的应用程序必须从这些扁平的、不连贯的数据结构中建立关系。”

对不起，我不明白这是什么意思。为什么文档存储数据库在基于高度关系的上下文中挣扎？