SQL Azure是否适合特殊密集型SQL处理？

Question

我正在寻找一些关于SQL Azure是否适合一次性，短期密集处理一批SQL数据的平台的指导。 （即“数据处理”）

我的方案如下：

我有一个包含单个数据表的32Gb数据库。该表包含使用geometry数据类型定义的空间数据，以及相关属性的各个列。我需要对这些数据执行一些一次性处理，这涉及执行一系列计算成本高昂的查询（因为大多数空间查询似乎都是！）

当我在自己的服务器上对数据的子集测试这些查询时，他们花了几个小时才完成。我希望，如果我尝试在本地对整个数据集执行它们，它会将我的SQL Server锁定几天（或者可能会死于尝试），这是我试图避免的情况。

所以我正在寻找一个短期替代方案，我可以将这些查询设置为在其他地方执行，并在完成时检索已处理的表。

据我所知，SQL Azure平台旨在提供灵活的容量（就存储而言），并且还可以扩展以适应例如：交易数量增加。引用的典型示例应用似乎是为经历快速增加或波动的需求的Web应用/商店提供DB后端。 但是，我无法找到许多细节的是SQL Azure是否适合于容纳单个长时间运行的查询，并以串行方式执行。

要清楚 -

• 我希望这是一次性的操作。或许，也许每年都要进行一次。
• 处理完成后，我无意继续“在云中”托管数据 - 我想检索已处理的数据集并再次在现场托管。
• 从平台获取/返回数据的便利性显然非常重要，因为我不打算永久地“迁移”任何东西。如果我理解正确，您无法将数据库备份/还原到Azure，并且编写数据脚本会非常痛苦。
• 我对Management Studio感到满意，任何允许我将其用作界面来运行查询并对结果进行抽查的平台都是有益的。

如果有任何人有使用SQL Azure进行此类活动的经验，或者可能建议替代方案，我将非常感激！

Answer 1

我真的不确定SQL Azure是否适合这项任务 - 在存储方面没有问题，但我不知道它的架构对于长时间运行的任务有多好。特别是，见：

  

SQL Azure数据库提供了一个大型多租户数据库   共享资源上的服务。为了提供良好的体验   所有SQL Azure数据库客户，您与服务的连接可能   由于以下条件而被关闭：

     

  
• 资源使用过多
  
• 长时间运行的查询
  
• BEGIN TRAN和END TRAN之间的长期单笔交易   语句
  
• 空闲连接
  

     

这与SQL Server的内部部署实例的工作方式不同。

来自：http://msdn.microsoft.com/en-us/library/ee730903.aspx

所以我担心SQL Azure可能不适用于您的长查询 - 除非您可以将它们分解为大量简短查询。

如果SQL Azure无法为您工作，那么您可能更好地在某处（可能是AWS实例？）部署单独的SQL实例来执行这些一次性计算。

Answer 2

这取决于工作量的性质。你提到“执行一系列计算成本高昂的查询”;但是，我不清楚你是否有很多小但重复的命令或一个需要在整个批处理期间工作的大工作。前者可能在SQL Azure中使用连接重试逻辑的形式，而后者可能不会。无论哪种情况，您还可以考虑在.NET中重构处理逻辑。

实际上，由于SQL Azure限制机制，大多数批处理活动在云中作为工作进程重新设计;基本上.NET代码将在Windows Azure中运行，从SQL Azure读取所需的数据，在内存中执行所需的计算并将结果保存在SQL Azure中。根据工作负载的类型，这可能是最好的方法，因为您可以以一种可以很好地扩展的方式进行设计;因此可能会显着缩短总执行时间（假设您可以将数据处理逻辑拆分为较小的部分，并在.NET而不是SQL Azure中执行）。

关于将数据备份/还原到内部部署服务器，您有一些不涉及数据脚本的选项。如果您决定尝试在.NET中进行重构，我们可以进一步讨论这些选项。

Answer 3

几点/问题：

1. 您正在执行的代码是用T-SQL还是其他编程语言编写的？
2. 处理可以并行执行，还是必须顺序执行？
3. 目前的瓶颈在哪里？它是在计算或数据检索/存储中吗？

鉴于您到目前为止所说的内容以及我过去在大型数据库中遇到的问题，我会质疑SQL Server是否是一种合适的存储技术。没错，它适用于基于事务的查询，但您只有一个数据库表。这意味着整个“关系数据库”方面除了它自我引用（这将创建一个其他问题的世界，因此我将暂时忽略它，并假设情况并非如此）时，它会走出窗口。当然有办法确保在使用NoSQL存储处理数据时不会遇到竞争条件，我无法想象事务是绝对必要的。进行计算时，如果结果存储失败，则重试。最糟糕的情况是，重做计算。

单个表中SQL Server的32 GB数据是很多数据，我猜测那里可能存在某种索引。如果没有正确配置SQL Server（使用大量物理轴并在其间拼接数据），由于磁盘I / O，您可以轻松地在SQL中遇到主要性能问题。

微软能够比普通的SQL开发人员更好地扩展SQL Azure的机会非常好，因为他们知道应该如何完成。但是，这并不意味着吞吐量没有限制或者查询/添加数据的速度有多快。

我的建议是研究使用Azure Tables（基本上是NoSQL表），因为它允许您跨多个节点对数据进行分区。此分区允许您将其保留的数据量扩展到100TB，同时不会影响查询的速度。

此外，一个32GB的SQL Azure数据库每月花费400美元，而拥有500万个存储事务的40GB Azure Table存储只需花费11美元/月。您将不得不添加工作节点的“成本”，但理论上它们应该是等价的。因此，Tables选项每月更便宜，但如果它是支持项目的业务，那么成本可能远远低于进入它的开发时间。

您需要考虑将32GB数据传输到云中的时间。加载SQL数据库可能需要一段时间，而且您需要在某种程度上获取数据。取决于您将数据传输到云中的速度有多快，以及是否可以在完全处理之前开始处理。

我认为你会遇到的问题是，为了使用Azure Tables而不是SQL Azure，你需要做出一些权衡。您可能需要将数据转换为Azure表，然后编写处理代码等。在一天结束时，它可能不值得。

但是，我认为此处尚未提供足够的信息来进行此调用。真正重要的问题是，是否有机会并行化处理以及您估计处理在一台机器上需要多长时间。接下来要回答的问题是构建需要多长时间以及需要多长时间才能完成。

根据您关于将数据库锁定数日的评论来判断，我认为您现在可能遇到的数据库问题并不合适。根据您将来期望的额外处理，您可能没有选择，只能评估NoSQL选项。

我不想在这里给出一个“依赖”的答案，但是如果你提供一些额外的细节，我会很乐意更新这个，让你更好地了解去哪里和做什么。