SQL Azure 是否适合即席密集型 SQL 处理？答案

【问题标题】：Is SQL Azure suitable for adhoc intensive SQL processing?SQL Azure 是否适合即席密集型 SQL 处理？
【发布时间】：2011-10-11 13:49:41
【问题描述】：

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

我的场景如下：

我有一个 32Gb 的数据库，其中包含一个数据表。该表包含使用几何数据类型定义的空间数据，以及相关属性的各种列。我需要对这些数据执行一些一次性处理，其中涉及执行一系列计算量很大的查询（就像大多数空间查询一样！）

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

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

我了解 SQL Azure 平台旨在提供灵活的容量（在存储方面），并且还可以扩展以适应例如交易数量增加。引用的典型示例应用程序似乎是为经历快速增长或波动需求的 Web 应用程序/商店提供数据库后端。但是，我还没有找到很多细节是 SQL Azure 是否适合容纳单独的长时间运行的查询，串行执行。

只是为了清楚 -

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

如果有人对使用 SQL Azure 进行此类活动有任何经验，或者可以提出替代方案，我将不胜感激！

【问题讨论】：

@Mitch - 根据stackoverflow.com/faq - “...如果您的问题一般涵盖... •特定的编程问题 •软件算法 •程序员常用的软件工具 •独特的问题编程专业……那么您来对地方了！”
抱歉 - 在我完成写作之前提交了最后一条评论。我认为我的问题基于这些规则是有效的，但是如果您可以推荐另一个更适合该问题的论坛，那么我将非常感激。谢谢。

标签： sql geometry cloud spatial azure-sql-database

【解决方案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 实例来执行这些一次性计算。

【讨论】：

感谢您的回复 - 我感觉可能是这种情况。我曾短暂考虑过使用 Amazon EC2 服务，但我的印象是设置这个环境比简单的 AQL Azure DB 更麻烦。但是，我会再次查看 AWS。谢谢。
你可以在任何服务上设置一个带有 sql 实例的非云虚拟机——尽管你显然需要弄清楚这是如何获得许可的（怀疑你可以使用评估许可证来做到这一点但这可能并不完全合法！）有一些关于 SQL Server 即服务（私有云）的帖子 - 请参阅 blogs.technet.com/b/sqlman/archive/2011/04/11/…

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

几点/问题：

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

鉴于您迄今为止所说的以及我过去在大型数据库中遇到的问题，我会质疑 SQL Server 是否是一种合适的存储技术。诚然，它适用于基于事务的查询，但您只有一个数据库表。这意味着整个“关系数据库”方面都会消失，除非它是自引用的（这会产生一个其他问题的世界，所以我现在将忽略它并假设情况并非如此）。当然，有一些方法可以确保在使用 NoSQL 存储处理数据时不会遇到竞争条件，我无法想象事务是绝对必要的。在进行计算时，如果存储结果失败，则重试。最坏的情况，你重新计算。

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

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

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

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

您需要考虑将 32GB 数据传输到云端的时间。加载 SQL 数据库可能需要相当长的时间，并且您需要以某种方式将数据获取到那里。取决于您将数据传输到云端的速度，以及您是否可以在数据全部到位之前开始处理。

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

但是，我认为这里没有足够的信息来进行该调用。真正的大问题是是否有机会并行处理以及您估计处理在单台机器上需要多长时间。下一个要回答的问题是构建需要多长时间与您必须花费多少时间。

从您的 cmets 关于将数据库锁定数天的情况来看，我认为假设您现在可能正在遇到数据库问题并不过分。根据您期望在未来进行的额外处理，您可能别无选择，只能评估 NoSQL 选项。

我不想在这里给出“视情况而定”的答案，但如果您提供一些额外的细节，我很乐意更新此内容，让您更好地了解该去哪里以及该做什么。

【讨论】：