云架构堆栈意见 - EC2 与 Azure答案

【问题标题】：Cloud Architecture Stack Opinions - EC2 versus Azure云架构堆栈意见 - EC2 与 Azure
【发布时间】：2011-10-13 17:17:54
【问题描述】：

我阅读了许多关于 Amazon EC2 与 Microsoft Azure（以及 Google 的 App Engine）优缺点的博客和文章。但是，我正在尝试决定哪个更适合我的特殊情况。

我有一个数据集 - 可以被认为是格式的标准表：

[id]  [name]  [d0]  [d1]  [d2] .. [d63]
---------------------------------------
0     Name1   0.43 -0.22  0.11   -0.81
1     Name2   0.23  0.65  0.62    0.41
2     Name3  -0.13 -0.23  0.17    0.00
...
N     NameN   0.43 -0.23  0.12    0.01

我最终想做的事情（尽管我最终选择了堆栈）相当于SQL SELECT 声明，类似于：

SELECT name FROM [table] WHERE (d0*QueryParameter1) + (d1*QueryParameter1) +(d2*QueryParameter2) + ... + (dN*QueryParameterN) < 0.5

其中QueryParameter1,2,N 是运行时提供的参数，每次运行查询时都会更改（因此缓存是不可能的）。

我主要关心的是查询速度，所以我想知道哪个云堆栈选项可以提供最快的查询结果。

我可以通过多种方式做到这一点：

(1) 使用 SQL Azure，就像上面的查询一样。我已经尝试过这种方法，并且查询可能会像预期的那样很慢，因为 SQL 只给你一个实例。我可以启动多个 SQL 实例并对数据进行分片，但这很快就会变得非常昂贵。
(2) 使用 Azure 存储表。 Blogger 声称存储表总体上更快，但对于我的查询需求，这仍然是这种情况吗？
(3) 使用 EC2 并使用 MySQL 启动多个实例，可能会将分片合并到新实例中（但成本会增加）。
(4) 将 EC2 与 MongoDB 一起使用，据我了解，它比 MySQL 快。同样，这可能取决于查询的类型。
(5) Google AppEngine。我不太确定 GAE 如何使用这种查询结构，但我想这就是我寻找意见的原因。

我想找到最佳的堆栈组合来优化我的特定需求（上面的伪SQL 查询概述了）。

有人有这方面的经验吗？ 哪个堆栈选项会导致在WHERE 子句中包含许多数学运算符的最快查询？

干杯，布雷特

【问题讨论】：

标签： php .net azure amazon-ec2 cloud-hosting

【解决方案1】：

您使用动态系数（权重）的查询类型需要在每次查询时扫描整个表。 SQL 数据库引擎在这里帮不了您，因为查询优化器确实无能为力。

换句话说，您需要的不是 SQL 数据库，而是真正的“NoSQL”数据库，它真正优化了表/行访问以尽可能快的速度。所以你真的不应该尝试 SQL Azure 和 MySQL 来找出这部分答案。

此外，您的查询类型中的每一行都是完全相互独立的，因此它适用于简单的并行性。您选择的平台应该是您所选择的：

以最快的速度扫描表/行
能够高度并行化您的操作

您提到的每个平台都使您能够存储大量 blob 或类似表的数据，以实现非常快速的扫描检索（例如 Azure 中的表存储）。每个还使您能够“启动”多个实例以并行处理它们。这实际上取决于您最喜欢哪种编程环境（例如 Google/Amazon 中的 Java，Azure 中的 .NET）。本质上，它们都做同样的事情。

我个人推荐 Azure，因为您可以：

将大量数据存储在“表存储”中，针对快速扫描检索进行了优化，并进行了分区（例如超过 d0 范围）以实现最佳并行性
动态“启动”任意数量的计算实例以并行处理数据
用于同步结果排序的排队机制

Azure 以一种非常“简洁”的方式满足您的需求 - 为您提供足够的基础设施来完成您的工作，仅此而已。

【讨论】：

这是很棒的信息！它解决了我的很多问题。非常感谢。我认为我倾向于使用 Azure 表 - 正如你所说 - 使用并行性和我的偏好语言。
一个后续问题：如何将数据分片到多个实例上？例如，我们如何告诉一个 InstanceA 只查询带有 PartitionKeyA 的行，而告诉一个 InstanceB 只查询带有 PartitionKeyB 的行？（Sill 学习 Azure 的来龙去脉）。
@Brett，我还没有对已分区的 Azure 表数据集做太多事情（还没有那么多数据），所以我认为您需要在 SO 上发布另一个问题。我的直觉是创建多个队列，每个分区一个，然后让一个“馈送”实例从表中读取并将作业转储到不同的队列中，每个后端实例都从队列中馈送。跨度>

【解决方案2】：

问题不在于数学运算符或其数量，问题在于它们是参数化的 - 您实际上是在跨列进行加权平均，权重在运行时定义，因此必须计算操作并且无法推断。

即使在 SQL Server 中，此操作也可以并行化（这应该显示在执行计划中），但它不适合使用索引进行搜索优化，而这是大多数关系数据库真正大放异彩的地方。使用静态权重和索引计算列显然会执行得非常快。

因为这个问题很容易并行化，你可能想看看基于Map-Reduce 原则的东西。

【讨论】：

【解决方案3】：

目前 SQL Azure 和 Amazon RDS 都不能水平扩展（EC2 至少可以垂直扩展），但如果并且只有当您的数据可以以仍然可以执行查询的方式进行分区时，SQL Azure 即将推出的 SQL 联合功能可能值得一看并有助于做出明智的决定。

MongoDB（我非常喜欢）更适合面向文档的工作负载，尽管您的工作量可能会有所不同，但它可能不是此类工作的最佳解决方案（只要您的大部分工作集适合内存，它就会非常快)。

【讨论】：

我不认为 Mongo 有那么大的帮助 - Mongo 的速度非常快，因为它允许快速写入并且因为它为读取创建了索引 - 但是这个数据集不会有任何写入并且索引会对于这些特别的查询不是很有用（因为参数每次都会改变）。

【解决方案4】：

假设 QueryParameter0, QueryParameter1, ... , QueryParameterN 都是在运行时提供并且每次都不同，那么我认为任何平台都无法提供比其他任何平台显着的优势 -因为他们都无法利用任何预先计算的指标。

删除指标后，其他唯一影响速度的因素来自可用的处理能力 - 您已经知道 SQL Azure 选项的这一点，而对于其他选项，这几乎取决于您决定应用什么处理 -获取所有数据然后进行处理由您决定。

您可能会考虑的一个选项是您是否可以自己在实例上托管这些数据（例如，使用 Azure blob 或云驱动器），然后可以在自定义构建的辅助角色中处理数据。对于一般数据存储，我不会考虑这件事，但如果它只是一张表和一个查询，那么手工制作一个快速解决方案会很容易吗？

更新 - 刚刚也看到了 @Cade 的答案 - +1 表示他对并行化的建议。

【讨论】：