问题标签 [document-oriented-db]

今天刚得知Adobe Air有本地SQL数据库，很棒；然而，我们一直在创建 XML 和 JSON 文件来处理几乎所有的事情。与其重新构建我们的应用程序以获得一些新功能，不如使用嵌入式面向文档的数据库来简单地索引我们现有的数据文件似乎很有用。

所以问题是：让嵌入式面向文档的数据库在 Adob​​e Air 运行时中运行的最简单方法是什么？

我想使用面向文档的数据库来存储来自提要的数据。有时该提要包含地理空间数据，我希望能够对其进行搜索。我找到了 GeoCouch，但想知道它是否与 CouchDb 主线的功能保持同步。

如果 GeoCouch 是一次性的，那么是否有更好的面向文档的数据库，其中包含地理空间功能？

我一直在寻找适用于 Windows桌面程序的面向文档的数据库。MongoDB 似乎是迄今为止最好的一个，因为与 CoachDB 相比，它更小（11MB）且更简单（这是另一种选择，但它似乎更复杂，下载大小几乎为 50MB），但不幸的是，在 32 位Windows MongoDB 中的数据库大小限制为 2GB，他们不打算随时修复此限制。

你有什么建议吗？要求：

1. 开源；
2. 无模式，采用 BSON/JSON 格式；
3. 易于部署到 Windows 机器。

非常感谢！

是否有任何文档数据库，类似于 MongoDB，在ASP.NET Web 应用程序中运行，并且可以在没有任何独特机器配置的服务器上托管？

我问这个是因为我目前使用的托管服务提供商只支持 SQL Server 2008 作为数据库，但我想从文档数据库中运行我的网站。

（或者我最好使用专门的数据库主机，例如MongoHQ）？

新的面向文档的数据库概念，并有一些与订单和订单处理相关的高级问题。

一个人如何在这个世界上捕捉到一个订单？订单是否只是Orders集合中的新文档？会order_item涉及到product另一个文件中列出的内容吗？还是假设order_item将被复制并插入到订单文档中，因此可能难以报告product随时间推移的总销售量？

如何解决缺乏交易并保持完整性

抱歉，虽然渴望理解，但对我来说很新……将所有这些待售的“东西”封装为“对象”并在服务器和客户端等之间移动它们听起来非常有吸引力……如果这确实是合理的。只需要一些帮助概念化大局的注意事项。

我想使用面向文档的数据库存储大量 JSON 文档，所有文档都具有非常相似的模式（尽管不相同）。

一个示例文档：

是否有任何系统（CouchDB 等）使用压缩（任何类型的）来避免一遍又一遍地存储密钥字符串（例如“firstName”）？

当有数百万个文档时，我的动机是最小化磁盘上数据库的大小，特别是当某些重复键比“firstName”长得多时。

谢谢你的想法！

W

编辑：在考虑了更多之后，我想我要问的是一个更通用的压缩系统的特定情况，其中压缩字典（部分？）在文档存储中的多个压缩文档之间共享（并且可能建立在时间）。然后，这将处理的不仅仅是 JSON 密钥的压缩。

做起来会很有趣！

目前，我正在使用带有 Mysql 的 Rails 作为后端。不幸的是，我的应用程序已经扩展了在启动时没有预料到或预见到的数据。现在，随着数据库中条目的增加，我面临着很多性能问题，并且由于享受关系逻辑而引发的大量查询，ActiveRecord 受到了打击。

我已经到了想要为享受适当的关系模型的优势而付出代价的地步。由于速度受到重创，我不得不对像 Mongo DB 这样的面向文档的模型进行研究，发现它们提供的速度可以补偿关系特性。

我的问题是，如何从关系模型慢慢迁移到文档模型。也许，我会存储我的临时模式或返回的表，并将它们作为批量文档即时转储，而不是建立一个适当的面向文档的数据库（至少在初始阶段）。空间对我来说不是问题。我现在只关心时间。但是，我不能在一次扫描中做到这一点。我想知道如何解决这个问题，之前解决过此类问题的任何链接/参考将不胜感激。

我目前正在考虑如何最好地将网络爬取结果存储在数据库中。在另一个问题中，建议将面向文档的数据库用于网络爬虫项目：python 中的网络爬虫数据库？

现在我想知道 map/reduce 是否是这种分类和价值生成的正确方法。至少它似乎能够做这样的事情（地图仅用于分类，如年份或作者，地图/减少用于计算数值，我目前想不出一个例子）。

但是，map-reduce / DocumentStores 是否也能够为我提供给定单词的正确文档？在关系数据库中，我必须在某些表上使用 JOIN，然后获取包含这些单词的文档：

我猜 DocumentStores 不能进行这样的操作，因为它们不支持全文索引并且不打算有很多引用/关系。

更好的选择是混合多个系统吗？例如，一个用于按单词搜索，一个用于按不同值（如果存在）搜索（如出版年份、作者……）？我认为 DocumentStores 对于存储元数据并不是那么糟糕，因为有时有特定的值，有时没有（如果需要，只要一个服务器的文档太多，DocumentStores 很容易在多个服务器上使用）。然而，我不确定实现搜索文档集合（包括网页、pdf、图像，它们总是具有不同的元数据，但通常还需要全文索引）的最佳方法是什么。

提出一个明确的问题：我应该将另一个数据库系统与 DocumentStores 一起使用，单独使用 DocumentStores（如何快速搜索单词？）还是单独使用另一个 DB 系统？

PS：此类问题的另一个例子是网页之间的链接，它也不能很好地保存在 DocumentStores 中。但是，OrientDB 可能会解决这个问题，因为它似乎结合了图形数据库和面向文档的数据库。

听说mongodb用了很多内存，但是我内存不多，我需要在512M的VPS上运行2或3个应用程序，我想知道有没有其他选择，有易于使用的API，和nodejs绑定，轻量级.

假设我们有下一个数据结构：

我们的想法是尽可能获得最佳的读取性能。让我们假设按名称搜索的优先级，因此我们确保名称的升序索引（实际上我已经编写了一个原型和索引大大提高了搜索速度。这将搜索时间从 1-2 秒减少到 0,1 秒对于一百万个非常大的文档。）这个想法是以某种方式索引嵌套数组字段，但问题在于他们在这里写的内容，这在某种程度上是不可能的。我正在尝试使用mongodb-csharp组合来实现它，但我建议我们不要指定语言。我看到的可能的增加选项是什么：

1. 以我还不知道的方式实现这个索引。
2. 为这些数组嵌套字段再创建一个集合并在其中对其进行索引。
3. 其他选项。

请分享您的观点和想法。