AWS SimpleDb 与 Azure DocumentDb 有何不同？两者与 ElasticSearch 有何不同
How does AWS SimpleDb differ to Azure DocumentDb? How do both differ to ElasticSearch
相对于
- 可扩展性，
- 表现，
- 维护，
- 易用性/学习曲线
- 成本，
按重要性排序，但不介意笼统的回答，因为我很感激我可能要求太多了:)
谢谢
编辑： 我正在寻找一个数据库作为单一的权威数据存储，出于各种业务原因，我需要存储文档的所有属性进行索引。因此我知道其他解决方案不会满足我的要求。
tl；博士；如果您正在使用 JavaScript 并构建浏览器应用程序，那么 node.js 和 DocumentDB 是天作之合。如果你正在使用 .NET and/or 其他 Azure 服务，那么 DocumentDB 是首选。如果您正在使用其他 AWS 服务，那么 SimpleDB 可能会更好。
我知道像这样的问题对于 Stack Overflow 来说并不理想，但我经常看到这样的答案的价值，而我在 SO 上最受欢迎的答案本质上是有证据支持的知情意见。我没有使用过 SimpleDB，但在决定使用 DocumentDB 之前我研究过它。我很快就拒绝了它……尽管在决定使用 DocumentDB 之前我确实认真地看了 AWS Lambda。所以：
可扩展性。 DocumentDB 有一个非常直接和明确的缩放模型——如果您需要每秒更多 space 或更多操作，请添加更多集合。 SimpleDB 的扩展模型是相似的，除了不太直接，因为您添加了过载的域以提供类型分离（想想表）和可扩展性。您可以根据需要进行扩展。
性能。由于我从未在其上构建过任何东西，因此我无法对 SimpleDB 的性能发表任何评论。但是，DocumentDB 的性能给我留下了深刻的印象。对于简单的基于 id 的读取，延迟不到 10 毫秒，我获得了令人印象深刻的查询延迟和吞吐量。我们当前应用程序的 DocumentDB 实现 returns 复杂的 n 维聚合（使用 documentdb-lumenize 在 DocumentDB 上的存储过程中完成）的时间是功能等效 MongoDB/node.js 实现的 1/4。您必须对您的实际应用程序进行自己的性能测试才能在此处获得明确的答案。
维护。两者都比传统的数据存储更自由。只是没有那么多旋钮可以用来维护它们中的任何一个。 SimpleDB 默认按地理分布您的数据。您必须在 DocumentDB 中手动执行等效操作。可能，但更难。 DocumentDB 有很好的 import/export 工具，他们的备份解决方案即将显着升级。
易用性/学习曲线。如果您是 JavaScript 程序员，那么 DocumentDB 有很多值得推荐的地方。 DocumentDB 本机使用 JSON。 SimpleDB 使用 XML。 DocumentDB 具有使用 JavaScript 编写的支持 ACID 的存储过程。您需要将 SimpleDB 与其他东西结合使用（也许是 Lambda，但 XML/JavaScript 不匹配会使它不太理想）以获得等效的东西。两者都允许使用 SQL 但 DocumentDB 还允许 Java 脚本本机查询。
要成功使用 DocumentDB，您必须克服一个巨大的思维障碍。尽管它们都通过添加更多 domains/collections 进行扩展，但 SimpleDB 域在概念上更接近表。 DocumentDB 团队选择 "collection" 这个词是不幸的，因为它们更类似于分区，不应被视为表。困难的部分是习惯将所有不同数据类型存储在同一个集合中的想法。一旦你克服了这个问题，我就会发现 DocumentDB 的方法令人耳目一新，而且非常灵活。我可以有效地对继承和类型混合进行建模。集合和分区只有一个目的——可伸缩性。域用于可伸缩性和数据类型分离，这在实践中实际上更难。
成本。这里不多说。两者都可以让您逐渐降低成本。对于非常小的实现，DocumentDB 可能更昂贵，因为最小的使用单位是单个集合，最低 25 美元/月。您必须自己进行 modeling/what-if 分析，以确定哪个对您来说更便宜。请注意，Azure 总体上非常激进，甚至在某些情况下甚至推动 AWS 降低价格。我的直觉是，对于大多数应用程序，它们的成本大致相等。
其他想法：
你写了，"I need all attributes of the documents stored to be indexed"。 DocumentDB 的一个非常好的功能是您可以指定索引的大小默认情况下，每个字段都被索引到每个字段 3 字节的哈希索引中，这是非常高效的 space。不知道SimpleDB有没有等价物
这有点像比较苹果和橘子。我认为 DocumentDB 在其数据模型中类似于 MongoDB 或 CouchDB，在其使用执行模型中类似于 VoltDB（尽管 VoltBD 存储过程是在 Java 中编写的）。 SimpleDB 更像是一个简单的 XML 对象存储。如果你已经有了很大的 XML 心态，那么它可能会更容易，但我认为今天使用 JSON 的人比 XML 多。
在Java脚本中编写支持 ACID 的存储过程是只有 DocumentDB 才有的杀手级功能。有人说存储过程的时代已经结束；您应该将所有此类逻辑放在应用程序服务器层中。如果您实现一个简单的 CRUD API，那可能是，但几乎每个应用程序都需要某种事务，一次更改不止一行。如果数据存储中没有事务支持，这很难正确地完成。即使您确实使用 NoSQL 数据库实现了等效的事务，实现的开销也会消耗掉您通过选择 NoSQL 而不是 SQL 获得的任何 development/performance/scalability 优势].
DocumentDB 的用户定义函数和触发器（也是用 JavaScript 编写的）可能会有用，尽管我相信触发器的实现在此时此刻已瘫痪而且我还没有找到我自己还没有使用 UDF。
DocumentDB 具有内置附件支持。您需要手动将 S3 与 AWS 上的等效项集成。
DocumentDB 具有地理索引和运算符。
SimpleDB 的每个文档 1K 限制是一个严重的限制。这告诉我它主要是为日志记录或作为 S3 的索引而设计的，而不是成熟的文档存储。 DocumentDB 的限制是 512K。
如果说与 SimpleDB 的比较就像苹果与橙子的比较，那么与 ElasticSearch 的比较就像苹果与消防车的比较。我对 ElasticSearch 的印象是全文搜索和分析。我认为作为主要的交易商店 space/execution/api 效率不高。它建立在 Lucene 之上，并不是为了让 reliability/durability 成为您的主要商店而设计的。此外，即使托管，它也更像是一种 IaaS 产品，而 DocumentDB 和 SimpleDB 是真正的 PaaS 产品。 ElasticSearch 的维护成本会更高。
相对于
- 可扩展性，
- 表现，
- 维护，
- 易用性/学习曲线
- 成本，
按重要性排序，但不介意笼统的回答，因为我很感激我可能要求太多了:)
谢谢
编辑： 我正在寻找一个数据库作为单一的权威数据存储，出于各种业务原因，我需要存储文档的所有属性进行索引。因此我知道其他解决方案不会满足我的要求。
tl；博士；如果您正在使用 JavaScript 并构建浏览器应用程序，那么 node.js 和 DocumentDB 是天作之合。如果你正在使用 .NET and/or 其他 Azure 服务，那么 DocumentDB 是首选。如果您正在使用其他 AWS 服务，那么 SimpleDB 可能会更好。
我知道像这样的问题对于 Stack Overflow 来说并不理想，但我经常看到这样的答案的价值，而我在 SO 上最受欢迎的答案本质上是有证据支持的知情意见。我没有使用过 SimpleDB，但在决定使用 DocumentDB 之前我研究过它。我很快就拒绝了它……尽管在决定使用 DocumentDB 之前我确实认真地看了 AWS Lambda。所以：
可扩展性。 DocumentDB 有一个非常直接和明确的缩放模型——如果您需要每秒更多 space 或更多操作，请添加更多集合。 SimpleDB 的扩展模型是相似的，除了不太直接，因为您添加了过载的域以提供类型分离（想想表）和可扩展性。您可以根据需要进行扩展。
性能。由于我从未在其上构建过任何东西，因此我无法对 SimpleDB 的性能发表任何评论。但是，DocumentDB 的性能给我留下了深刻的印象。对于简单的基于 id 的读取，延迟不到 10 毫秒，我获得了令人印象深刻的查询延迟和吞吐量。我们当前应用程序的 DocumentDB 实现 returns 复杂的 n 维聚合（使用 documentdb-lumenize 在 DocumentDB 上的存储过程中完成）的时间是功能等效 MongoDB/node.js 实现的 1/4。您必须对您的实际应用程序进行自己的性能测试才能在此处获得明确的答案。
维护。两者都比传统的数据存储更自由。只是没有那么多旋钮可以用来维护它们中的任何一个。 SimpleDB 默认按地理分布您的数据。您必须在 DocumentDB 中手动执行等效操作。可能，但更难。 DocumentDB 有很好的 import/export 工具，他们的备份解决方案即将显着升级。
易用性/学习曲线。如果您是 JavaScript 程序员，那么 DocumentDB 有很多值得推荐的地方。 DocumentDB 本机使用 JSON。 SimpleDB 使用 XML。 DocumentDB 具有使用 JavaScript 编写的支持 ACID 的存储过程。您需要将 SimpleDB 与其他东西结合使用（也许是 Lambda，但 XML/JavaScript 不匹配会使它不太理想）以获得等效的东西。两者都允许使用 SQL 但 DocumentDB 还允许 Java 脚本本机查询。
要成功使用 DocumentDB，您必须克服一个巨大的思维障碍。尽管它们都通过添加更多 domains/collections 进行扩展，但 SimpleDB 域在概念上更接近表。 DocumentDB 团队选择 "collection" 这个词是不幸的，因为它们更类似于分区，不应被视为表。困难的部分是习惯将所有不同数据类型存储在同一个集合中的想法。一旦你克服了这个问题，我就会发现 DocumentDB 的方法令人耳目一新，而且非常灵活。我可以有效地对继承和类型混合进行建模。集合和分区只有一个目的——可伸缩性。域用于可伸缩性和数据类型分离，这在实践中实际上更难。
成本。这里不多说。两者都可以让您逐渐降低成本。对于非常小的实现，DocumentDB 可能更昂贵，因为最小的使用单位是单个集合，最低 25 美元/月。您必须自己进行 modeling/what-if 分析，以确定哪个对您来说更便宜。请注意，Azure 总体上非常激进，甚至在某些情况下甚至推动 AWS 降低价格。我的直觉是，对于大多数应用程序，它们的成本大致相等。
其他想法：
你写了，"I need all attributes of the documents stored to be indexed"。 DocumentDB 的一个非常好的功能是您可以指定索引的大小默认情况下，每个字段都被索引到每个字段 3 字节的哈希索引中，这是非常高效的 space。不知道SimpleDB有没有等价物
这有点像比较苹果和橘子。我认为 DocumentDB 在其数据模型中类似于 MongoDB 或 CouchDB，在其使用执行模型中类似于 VoltDB（尽管 VoltBD 存储过程是在 Java 中编写的）。 SimpleDB 更像是一个简单的 XML 对象存储。如果你已经有了很大的 XML 心态，那么它可能会更容易，但我认为今天使用 JSON 的人比 XML 多。
在Java脚本中编写支持 ACID 的存储过程是只有 DocumentDB 才有的杀手级功能。有人说存储过程的时代已经结束；您应该将所有此类逻辑放在应用程序服务器层中。如果您实现一个简单的 CRUD API，那可能是，但几乎每个应用程序都需要某种事务，一次更改不止一行。如果数据存储中没有事务支持，这很难正确地完成。即使您确实使用 NoSQL 数据库实现了等效的事务，实现的开销也会消耗掉您通过选择 NoSQL 而不是 SQL 获得的任何 development/performance/scalability 优势].
DocumentDB 的用户定义函数和触发器（也是用 JavaScript 编写的）可能会有用，尽管我相信触发器的实现在此时此刻已瘫痪而且我还没有找到我自己还没有使用 UDF。
DocumentDB 具有内置附件支持。您需要手动将 S3 与 AWS 上的等效项集成。
DocumentDB 具有地理索引和运算符。
SimpleDB 的每个文档 1K 限制是一个严重的限制。这告诉我它主要是为日志记录或作为 S3 的索引而设计的，而不是成熟的文档存储。 DocumentDB 的限制是 512K。
如果说与 SimpleDB 的比较就像苹果与橙子的比较，那么与 ElasticSearch 的比较就像苹果与消防车的比较。我对 ElasticSearch 的印象是全文搜索和分析。我认为作为主要的交易商店 space/execution/api 效率不高。它建立在 Lucene 之上，并不是为了让 reliability/durability 成为您的主要商店而设计的。此外，即使托管，它也更像是一种 IaaS 产品，而 DocumentDB 和 SimpleDB 是真正的 PaaS 产品。 ElasticSearch 的维护成本会更高。