AWS SimpleDb与Azure DocumentDb有什么不同？如何两者相差到ElasticSearch

Question

在

1. 扩展能力方面，
2. 性能，
3. 维护，
4. 易于使用/学习曲线
5. 成本，

在顺序的意义，但不介意一般的答案，因为我明白我可能要求太多:)

感谢

编辑：我在找一个数据库，将作为单一的权威数据存储和我需要存储到索引用于各种商业原因的文件的所有属性。因此，我知道其他解决方案不会做我想找的。

Answer 1

tl; dr;如果您正在使用JavaScript并构建浏览器应用程序，那么node.js和DocumentDB就是天堂中的一个匹配项。如果您使用.NET和/或其他Azure服务，则DocumentDB受到青睐。如果您使用其他AWS服务，那么SimpleDB可能会更好。

我知道像这样的问题对Stack Overflow来说并不理想，但我经常看到像这样的答案中的价值，而且我对SO的最流行答案基本上是以证据为依据的知情意见。我没有使用SimpleDB，但是在决定DocumentDB之前，我已经研究过它。我很快就拒绝了它......尽管在决定使用DocumentDB之前，我确实认真考虑了AWS Lambda。所以：

1. 可扩展性。 DocumentDB具有非常直接和明确的缩放模型 - 如果每秒需要更多空间或更多操作，则添加更多收集。 SimpleDB的缩放模型是相似的，除了不太直截了当，因为您添加了重载的域以提供类型分离（思考表）和可伸缩性。您可以根据需要调整比例。

2. 性能。由于我从来没有构建过任何东西，所以我不能说SimpleDB的性能。不过，我对DocumentDB的性能印象非常深刻。对于简单的基于ID的读取，延迟时间小于10毫秒，而且查询的延迟和吞吐量令人印象深刻。我们当前应用程序的DocumentDB实现在功能上等价的MongoDB/node.js实现的1/4时间内返回复杂的n维聚合（在DocumentDB上使用documentdb-lumenize在存储过程中完成）。您必须对您的实际应用程序进行自己的性能测试，才能得出明确的答案。

3. 维护。两者比传统数据存储都要多得多。只有那么多旋钮才能维持其中任何一个。 SimpleDB默认地理分布你的数据。您必须在DocumentDB中手动执行相同的操作。可能，但更难。 DocumentDB具有良好的导入/导出工具，其备份解决方案即将大幅升级。

4. 易用性/学习曲线。如果你是JavaScript程序员，比DocumentDB有很多推荐。 DocumentDB本身使用JSON。 SimpleDB使用XML。DocumentDB具有使用JavaScript编写的支持ACID的存储过程。你需要将SimpleDB和别的东西结合起来（Lambda可能，但是XML/JavaScript不匹配会使得它不够理想）来获得相同的结果。两者都允许使用SQL，但DocumentDB也允许使用JavaScript本机查询。

   有一个巨大的心态障碍，你将不得不克服，才能在DocumentDB中获得成功。尽管它们都通过添加更多的域/集合来扩展，但SimpleDB域在概念上更贴近表。 DocumentDB团队选择“收集”这个词是不幸的，因为它们更类似于分区，不应该被认为是表格。最难的部分是习惯于将所有不同的数据类型存储在同一个集合中。一旦你了解了这一点，我发现DocumentDB的方法令人耳目一新，并且非常灵活。我可以高效地建模继承和类型混合。集合不分区有一个目的 - 可扩展性。域用于可伸缩性和数据类型分离，这在实践中实际上更难。

5. 成本。这里不多说。两者都允许您逐渐扩大成本。对于非常小的实现，DocumentDB可能更昂贵，因为使用的最小单位是单个集合，最低为25美元/月。你必须做你自己的建模/假设分析，以确定哪些对你来说会更便宜。请注意，Azure一般都处于积极态势，甚至在某些情况下推动AWS降低价格。我的直觉是，对于大多数应用来说，它们的成本大致相当。

其他的想法：

• 你写道， “我需要存储到索引文件的所有属性”。 DocumentDB的一个非常好的功能是可以指定索引的大小默认情况下，每个字段都被索引为每字段3个字节的散列索引，这非常节省空间。我不知道SimpleDB是否具有相同的功能。

• 这有点像比较苹果和橘子。我认为DocumentDB在其数据模型中类似于MongoDB或CouchDB，而在其使用执行模型中使用VoltDB（尽管VoltBD sprocs是用Java编写的）。 SimpleDB更像是一个简单的XML对象存储。如果你已经有了一个大的XML思维模式，那么它可能会更容易些，但我认为现在有更多的人使用JSON比XML更好。

• 在JavaScript中编写启用ACID的存储过程是一项杀手级功能，只有DocumentDB具有。有人说存储过程的日子已经结束了;你应该把所有这样的逻辑放在你的应用服务器层。如果你实现了一个简单的CRUD API，那可能是，但几乎每个应用程序都需要某种事务，每次更改多行。在数据存储中没有事务支持的情况下，这是令人难以理解的难题。即使您的NoSQL数据库实现了相当于事务的处理，实施的开销也会消除您通过选择NoSQL而不是SQL获得的任何开发/性能/可伸缩性优势。

• DocumentDB的用户定义的函数和触发器（也用JavaScript编写）可能很有用，尽管我相信触发器实现在这个时候是残缺不全的，而我自己还没有发现UDF的用法。

• DocumentDB内置附件支持。您需要在AWS上手动与S3等效集成。

• DocumentDB具有地理索引和运算符。

• SimpleDB的每个文档限制1K是一个严重的限制。这告诉我，它的设计主要是为了记录或作为S3的索引，而不是一个完整的文档存储。 DocumentDB的限制是512K。

如果与SimpleDB的比较就像苹果橙子一样，那么与ElasticSearch的比较就像是消防车的苹果。我对ElasticSearch的印象是关于全文搜索和分析。我不认为这是空间/执行/ api高效率作为主要交易商店。建立在Lucene之上，它的设计不具备可靠性/耐用性，成为您的主要商店。此外，即使托管，它也更像是IaaS产品，DocumentDB和SimpleDB是真正的PaaS产品。 ElasticSearch的维护将更高。