Question

我已经阅读了很多关于 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子句中包含许多数学运算符的最快查询？

干杯，布雷特

Answer 1

具有动态系数（权重）的查询类型将要求在每次查询时扫描整个表。 SQL数据库引擎在这里不会对您有所帮助，因为查询优化器实际上无法做任何事情。

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

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

以最快的速度进行表格/行扫描
高度并行化操作的能力

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

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

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

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

Answer 2

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

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

由于此问题很容易并行化，因此您可能希望根据Map-Reduce原则查看某些内容。

Answer 3

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

MongoDB（我非常喜欢）更倾向于面向文档的工作负载，虽然你的里程可能会有所不同，但这可能不是这类工作的最佳解决方案（只要你的大多数工作集适合内存，它就会非常快）。

Answer 4

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

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

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

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

云架构堆栈意见 - EC2与Azure

4 个答案: