问题标签 [document-database]

在此演示文稿中，有一张图表显示了随着数据变大，以下水平可扩展性上限：

键值 > 列族 > 文档数据库 > 图数据库

http://youtu.be/UodTzseLh04?t=13m36s

换句话说，随着数据变得更加连接（即复杂），您可以让数据库增长的限制越来越低。

与键值存储相比，为什么文档数据库的数据大小没有那么可扩展？我是否通过说“连接数据的自由度越大，数据分区越难”来回答我自己的问题？

（每个人通常都会问的“我正在尝试做的事情”部分：我有一个数据库，其架构大部分是树状的，但偶尔会有两个父节点。我在原型中使用了 Neo4j，但用于生产规模应用程序我需要更多地考虑分区。我将不得不使用 Mongo DB，因为图形数据库不容易分区，并且在 Mongo DB 中为我的“多父”关系编写代码将更加困难。所以我'我想知道是否值得加倍努力并使用键值存储 - 或者至少是列族存储）。

我正在做一个处理结构化文档数据库的项目。我有一个类别树（约 1000 个类别，每个级别最多约 50 个类别），每个类别包含数千个（例如，约 10000 个）结构化文档。每个文档都是一些结构化形式的几千字节数据（我更喜欢 YAML，但它也可能是 JSON 或 XML）。

该系统的用户执行几种类型的操作：

• 通过 ID 检索这些文件
• 通过文档中的一些结构化属性搜索文档
• 编辑文档（即添加/删除/重命名/合并）；每个编辑操作都应记录为带有一些注释的事务
• 查看特定文档的记录更改历史记录（包括查看更改文档的人员、时间和原因，获取早期版本 - 如果需要，可能会恢复到此版本）

当然，传统的解决方案是使用某种文档数据库（例如 CouchDB 或 Mongo）来解决这个问题——但是，这个版本控制（历史）事情让我产生了一个疯狂的想法——为什么我不应该使用git存储库作为此应用程序的数据库后端？

乍一看，可以这样解决：

• 类别 = 目录，文档 = 文件
• 通过 ID 获取文档 => 更改目录 + 读取工作副本中的文件
• 使用编辑评论编辑文档 => 由各种用户提交 + 存储提交消息
• 历史 => 正常的 git 日志和旧事务的检索
• search => 这是一个稍微棘手的部分，我想它需要定期将类别导出到关系数据库中，并为我们允许搜索的列建立索引

此解决方案中还有其他常见的陷阱吗？有没有人尝试过实现这样的后端（即任何流行的框架——RoR、node.js、Django、CakePHP）？这个解决方案是否对性能或可靠性有任何可能的影响——即是否证明 git 会比传统的数据库解决方案慢得多，或者会有任何可伸缩性/可靠性缺陷？我认为推/拉彼此存储库的此类服务器集群应该相当健壮和可靠。

基本上，告诉我这个解决方案是否有效以及为什么它会或不会有效？

开始设计跟踪费用的应用程序。使用 MongoDB 只是为了熟悉面向文档的数据库。

如果我从一个每天有一个文档的文档设计开始，并且该文档包含诸如每一美元的花费和金额等信息，我是否一定会朝着错误的方向开始？

我最终想对所有数据进行切片和切块，例如两个日期之间在 Target 花费了多少，一个月在餐馆花费了多少，诸如此类。

我的问题是，如果我从面向日间的设计开始，我会马上遇到任何麻烦吗？

开始使用文档数据库，我有一个关于设计决策的问题。我将插入包含多日金融交易的数据。不知道我是否应该将每笔交易都制作为文档，或者为所有数据制作一个文档，这将涵盖很多天。

该应用程序的主要用途是以多种方式分析数据，包括特定日期和日期范围。

做出这个决定有哪些考虑？

我正在使用 Neo4j 并试图找出 Orient 作为文档图数据库相对于 Neo4j 的优势。

在 Orientdb 中如何在 graphbdb 中具有文档数据库的功能？两种模式（图形和文档）的数据库是否使用相同的数据源？如果是这样，那么是否可以在 documentdb 中编辑数据并将其显示为 graphdb？

我与 Orientdb 合作过，似乎您可以将数据库作为 graphdb 或 documentdb 使用，所以我不明白在一个 db 中同时拥有两个数据库功能。我的意思是你可以选择有一个纯documentdb或纯graphdb，但不能是两者的混合，所以它可以是像Neo4j这样的graphdb或像Mongodb这样的documentdb。我需要知道我是否正确？

注意：我在输出中只提供了一些文档以保持帖子小而直观

源集合：

第 1 步：按 PostDate 分组

询问 ：

输出 ：

第 2 步：尝试实现这一目标：

我尝试的查询：

输出（错误）：

如何实现第 2 步？

我在 windows server 2008 R2 上使用 MongoDB，版本 2.4.8，我有奇怪的索引行为，我无法解释。这是我收藏中的结构示例：

另外，我为该集合创建了索引：

该索引的问题是我在使用该索引时得到了错误的项目计数。

当我发出这个请求时：

我得到以下结果：

在这里我们可以看到已经使用了索引，但是返回的项目数是“n”：19368。。这是错误的。它应该是 70986项符合该标准的集合。

为什么我确定应该是更多记录？好吧，这里的代码：

总数 = 70986

为了确保上面的查询不使用任何索引，让我们检查一下：

结果：

因此，对于我正在使用的 UnitModel 集合，标准：Sales: {$ne: null}, WithdrawnFromSale: false它应该是 mongo 返回的 70986 条记录。但正如你所看到的，我弄错了。

有人可以解释我为什么吗？可能是什么原因？

顺便提一句。当我删除该索引并使用以下索引时： db["UnitModel"].ensureIndex({ "WithdrawnFromSale": 1}) 它按预期工作。但是我不需要那个索引，这对我的情况来说不是最优的。

我对连接文档的“链接”一词感到困惑

在 OrientDB 页面http://www.orientechnologies.com/orientdb-vs-mongodb/它声明他们使用链接来连接文档，而在 MongoDB 中嵌入了文档。

由于在 MongoDB http://docs.mongodb.org/manual/core/data-modeling-introduction/中，也可以引用文档，因此我无法区分链接文档或引用它们。

I want to save data in CouchDB documents and as I am used to doing it in RDBMS. I want to create a field which can only contain a unique value in the database. If I now save a document and there is already a document with unique key I expect an error from CouchDB.

I guess I can use the document ID and replace the auto generated doc-id by my value, but is there a way to set other field as unique key holder. Any best practice regarding unique keys?

我正在为我的大学开发一个讨论论坛。为此，我使用 CouchDB 作为数据库来操作数据。

为了最大化我的数据库的性能，我在设计我的数据库的结构时发现了困难。

我想讨论设计文档数据库的良好做法。

1. 要么我们应该只将一个数据库设为 SQL 并设为“n”不。数据库中的文档。
2. 或者我们可以对数据库进行更多的 no 以扁平化我的数据库结构。这也减少了更多的 no。待开发的文件。