问题标签 [document-oriented-db]

我在 MongoDB 中表示数据时遇到问题。我正在使用这种模式设计，其中日期和单词的组合是唯一的。

有固定数量的日期，大约 200 个；每个日期可能有 100k+ 字；和 100k+ 用户。

我用这样的算法插入记录：

然而，这种模式导致了非常大的集合，并且糟糕的性能非常糟糕。我在四个集合中的每一个中都插入了不同的信息，因此这是对数据库的大量操作。

我正在考虑以这样的格式表示数据，其中设置了单词和用户数组。

这背后的想法是减少数据库操作的数量。因此，对于算法的每个循环，我只为每个集合执行一次更新。但是，我不确定如何对此执行更新/更新，因为在算法的每个循环中，我可能需要插入一个新单词、用户或两者。

任何人都可以推荐一种更新此文档的方法，或者任何人都可以建议替代模式吗？

谢谢

假设以下场景（使用关系数据库），

在实际场景中，会有大量订单（数量不断增加）。将其转换为支持基于文档的数据库的最佳方法是什么？有一个更改货币代码和名称的选项，如果将货币添加为订单的子项，它会在所有订单中自动更新吗？

由于 MySQL 数据库的规范化，我遇到了一些性能问题。

我的大多数使用数据库的应用程序都需要执行一些繁重的嵌套查询，在我的情况下这需要很多时间。带有索引的查询可能需要 2 秒才能运行。没有索引大约 45 秒。

几个月前我遇到的一个解决方案是使用更快、更线性的基于文档的数据库，在我的例子中是 Solr，作为主数据库。一旦 MySQL 数据库中的某些内容发生更改，Solr 就会收到通知。

这真的很棒。使用 Solr 数据库的所有查询只用了大约3ms。

数字看起来不错，但我遇到了一些问题。

• 庞大的数据库

MySQL 数据库大约 200mb，Solr db 包含大约 1.4Gb 的数据。每次我需要更改表/列时，都需要重新索引数据库，在此示例中需要 12 多个小时。

• 很难在不弄湿的情况下同时渲染 Solr 对象和 Active Record (MySQL) 对象。

视图依赖于某个对象。它不关心它自己的对象是 Active Record 对象还是 Solr 对象，只要它可以调用其上的一组属性即可。

像这样。

我的问题是从 Solr 返回的数据是这样的。

这迫使我构建一个可以传递给视图的活动记录对象。

我的问题

有没有更好的方法来解决问题？某种可以快速处理复杂查询的超级快速主只读数据库会很好。

我有 Orm 框架的经验，我开始了解 NoSql 数据库解决方案的结构。我将继续使用一些基于对象模型的示例。

我有以下文档模型，我想考虑一些场景处理。

1. 用几个标签保存帖子
2. 显示带有帖子计数的标签列表
3. 更新标签

关于我的场景，我脑海中几乎没有出现任何问题。

帖子类是一个将使用标签保存的文档。在 RDBMS 中，Tag 和 Post 具有多对多关系，但我知道它在 NoSql 中没有任何关系，因此 post 对象与整个成员一起保存。因此显示带有 post 计数场景的标签列表将导致整个 post 项中的大量查询在每个查询中都付出了一些努力，所以在这种情况下我不会失去 NoSql 功能的所有好处吗？

更新一个标签名会不会造成一些复杂的工作？我必须查询整个帖子项目并发现它具有该标签名称并对其进行更新。顺便说一句，它需要多文档事务和长流程，因此失败会导致我的数据库不一致，因为 NoSql 中不支持多文档事务，所以我该如何处理？

我并不是要展示 NoSql 对 RDBMS(Sql) 系统的缺点。我只是想了解我对这个场景的想法是否正确，可能有些东西我错过了，或者看起来很糟糕的事情并不像我想象的那样糟糕。我需要可扩展性，这就是我对 NoSql 解决方案感兴趣的原因。

假设我有大量异构 JSON 文档（即命名键值映射）和这些文档所附加到的类层次结构（即命名集）。我需要建立一个数据结构，允许：

1. 对 JSON 文档的 CRUD 操作。
2. 按 ID快速检索 JSON 文档。
3. 非常快速地检索附加到某个类的所有 JSON 文档。
4. 编辑类层次结构：添加/删除类，重新排列它们。

我最初提出了将 JSON 文档存储在面向文档的数据库（如 CouchDB 或 MongoDB）中并将类层次结构存储在 RDF 存储（如 4store）中的想法。1,2然后4自然地计算出来，并3通过维护存储中每个类的附加文档 ID 列表来解决。

但后来我发现 RDF 存储实际上可以完成按 ID 检索 JSON 文档的面向文档的部分。乍一看这似乎是正确的，但我仍然担心2and 3。是否存在能够以面向文档的数据库的服务文档的速度检索文档（节点）的 RDF 存储？3它服务于类似查询的速度有多快？我听说过一些关于 RDF 存储速度慢、具体化问题等的信息。

是否有一个 RDF 存储也可以像 CouchDB 一样方便地按 ID 随意检索对象？使用面向文档的存储和 RDF 存储来存储、检索和编辑类似 JSON 的对象有什么区别？

我需要在一个小型数据库（64MB）上做一些基准测试，我需要弄清楚用 PyMongo 将整个 Mongo 集合提取到 python 对象中的最聪明的方法是什么？在 JavaScript 中，有 toArray() 方法，但我在 python 中找不到类似的东西。提前致谢！

最近，我在业余时间一直在使用 Couch DB 进行大量工作，并且非常喜欢使用它。我发现它比使用关系数据库灵活得多，但也不是没有缺点。

一个很大的缺点是缺乏动态查询/视图生成......因此，您必须做大量工作来规划和证明您的视图，因为您不能像使用 SQL 那样将逻辑放入应用程序代码中.

例如，我基于一个 JSON 文档模板编写了一个登录方案，看起来有点像这样：

为了防止创建重复帐户，我编写了一个非常基本的视图来生成用户名列表以作为键查找：

这对我来说似乎相当有效。我认为这比拖出整个文档列表（甚至只是减少每个文档的字段数量）要好得多。所以我做了完全相同的事情来生成一个电子邮件地址列表：

你能看出我要问这个问题吗？

在关系数据库（使用 SQL）中，只需对同一张表进行两次查询。这种技术（将视图等同于 SQL 查询的结果）会在某种程度上类似吗？

然后是性能/效率问题......这两个视图真的应该只是一个吗？还是使用带有键且没有关联值的 Couch DB 视图是一种有效的做法？考虑到上面的示例，这两个视图都将在登录方案之外使用......如果我需要生成用户名列表，我可以在没有额外开销的情况下检索它们。

你怎么看？

前提：更新语句是无害的，因为驱动程序默认情况下以一种消息传递方式工作（只要getLastError不使用）。

问题以下片段是在 mongodb 中进行大容量插入的最佳方法吗？是否可以折叠第 2 步和第 3 步？

编辑：旧的越野车形式，见下文

我有一种感觉没有办法退出操作 3，因为$操作员需要在更新的查询部分的查询字段中启动。阿米特？亚美特？

如果这是做事的最佳方式，我可以在我的代码中发挥创意并在更新操作上发疯吗？

编辑：新表格

我的逻辑中有一个错误，谢谢盖茨。如果可能的话，仍然想折叠更新：D

注意：$addToSet在这种情况下没有用，因为它进行元素匹配，所以无法mutable像 C++ OO 按位比较用语那样表达数组中的哪些元素

问题毫无意义数据模型错误。请投票关闭（OP）。

过去我一直在使用 MySQL 和 MsSQL。现在我也在使用 MongoDB，我发现它在处理文档哪些字段不断变化方面非常灵活——非常适合敏捷开发。

由于面向文档的数据库似乎更方便开发人员使用，并且在读取访问方面也更快，我可以举一些例子说明哪种用例比另一种更适合哪种情况？

我正在使用 PHP 的重载，我想要做的是；当我调用对象时，它看起来像这样。

为此，我使用 __get 和 __call 函数。它们看起来像这样：

但是，我想知道 person 和 name 的变量名，因为它可以随时改变。我试着这样做：

他们被保存了，但是当我添加另一行时，它只是将它添加到数组中。调用函数后它不会清理。我试图在 __call 处清空数组，但这没有帮助。我想谷歌这个，但到目前为止..我不走运。

PHP中是否有本机函数？

——阅读太多？停在这里，剩下的只是更多的解释——

但是 __call 发送数组并将您发送到另一个处理真实函数的类。

原因： 我有 5 个程序员习惯了 mongoDB 类，我们正在将大型代码库从 MongoDB 更改为另一个 DB。通过此修复，我们将能够一次更改整个代码库的数据库，而无需麻烦地构建查询。我们只是在函数类中进行查询。（调用 __call 时访问）。但是，今天的数据库查询的典型行如下所示：

这条线连接到一个数据库，在该数据库内它连接到帐户。但是，我们有一些“特殊”变量，例如 $core。它看起来像这样：

那个不连接到同一个数据库。

我们需要的是能够在对象内部构建一行对象，这是动态的。它需要找到所调用的名称，因此我们可以将它们放入查询中。仅适用于一条线路，而不是所有线路。它基本上是基于密钥的数据库上的基于文档的基础架构，有很多黑客攻击。:-D

非常感谢！