AWS SimpleDb与Azure DocumentDb有何不同?两者与ElasticSearch有何不同?<

Question

就

而言

1. 可伸缩性、
2. ,
3. 维护,
4. 易用性/学习曲线
5. ,

按重要性排序，但不介意给出一个大致的答案，因为我很感激，我可能要求太多了:)

感谢编辑:我正在寻找一个数据库，将作为单一的权威数据存储，我需要存储的文档的所有属性被索引为各种业务原因。因此，我知道其他解决方案不会做我正在寻找的。

Answer 1

我知道像这样的问题不是Stack Overflow的理想选择，但我经常在这样的答案中看到价值，我在SO上最受欢迎的答案本质上是有证据支持的知情意见。我没有使用过SimpleDB，但在决定使用DocumentDB之前，我研究了一下。我很快就拒绝了……尽管在决定使用DocumentDB之前，我确实认真地看了一下AWS Lambda。所以:

1. 可伸缩性． DocumentDB有一个非常直接和明确的缩放模型——如果需要更多的空间或每秒更多的操作，可以添加更多的集合。SimpleDB的扩展模型与之相似，只是没有那么直接，因为您添加了重载的域，以提供类型分离(如表)和可伸缩性。

性能

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

维护

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的数据模型和使用执行模型的voldb(尽管volbd进程是用Java编写的)。SimpleDB感觉更像是一个简单的XML对象存储。如果你已经有了一个大的XML思维，那么它可能会更容易，但我认为现在使用JSON的人比使用XML的人多。

• 在JavaScript中编写支持acid的存储过程是只有DocumentDB具有的杀手级特性． 有人说存储过程的时代结束了;您应该将所有这些逻辑放在应用程序服务器层中。如果您实现一个简单的CRUD API，可能是这样，但几乎每个应用程序都需要某种事务，其中一次更改多个行。如果没有数据存储中的事务支持，要正确地做到这一点是非常困难的。即使你用NoSQL数据库实现了与事务相同的功能，实现的开销也会消耗掉你选择NoSQL而不是SQL所带来的开发/性能/可伸缩性优势。

• DocumentDB的用户定义函数和触发器(也用JavaScript编写)可能是有用的，尽管我认为触发器实现在这个时刻是残破的，我还没有找到udf自己的用途。

• DocumentDB内置附件支持． 您需要手动与S3集成以获得AWS上的等效。

• DocumentDB有地理索引和操作符.

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

如果比较SimpleDB就像苹果对橘子，那么比较ElasticSearch就像苹果对火车头。我对ElasticSearch的印象是它完全是关于全文搜索和分析的。我不认为作为主要事务性存储的空间/执行/api效率高。它建立在Lucene的基础上，并没有被设计成具有可靠性/耐用性的主要存储。此外，即使在托管时，它也更像是一个IaaS产品，而DocumentDB和SimpleDB是真正的PaaS产品。使用ElasticSearch，维护成本会高得多。