Azure 表存储的替代方案答案

【问题标题】：Alternatives to Azure Table StorageAzure 表存储的替代方案
【发布时间】：2013-11-24 23:52:36
【问题描述】：

我们一直在 Windows Azure 上使用混合架构，将大多数实体存储在 SQL Azure 数据库中，但将可能需要大量存储空间的任何东西都放入 Azure 表存储中。

不过，使用这种架构时，我们会遇到各种与 Azure 表存储相关的问题，在我看来，这充其量只是一个不成熟且不完整的产品。最大的限制是，出于所有实际目的，它是一个只写数据存储。共识是它的写入能力非常非常好，但是它的查询和索引能力非常有限（尽管users complaining and Microsoft promising 多年），我得出的结论是你应该基本上只尝试检索数据紧急情况下的 ATS。为一个复杂的、实时的、事务性的生产应用程序从中获取数据比它应该做的要困难得多。当然，有一些变通方法，比如维护多个数据副本，为每个副本使用不同的索引策略，或者拆分查询并并行运行它们，但是当云服务的全部目的是最小化它时，这就增加了复杂性。

也就是说，我们目前致力于 Azure，我想对替代方案和陷阱有一个很好的了解，最好是来自那些实际上已经在生产中走这条路的人。

我很清楚有很多 NoSQL 选项（例如，这个问题中列出的所有选项：What NoSQL solutions are out there for .NET?），我可以在 VM 或其他云中运行。但我特别想知道是否有任何适合 Azure 的 PAAS 模型。换句话说，如果我在 Azure 上，并且不想管理我自己的 VM，并且想要尽可能接近 ATS 承诺的几乎自动和几乎无限的可扩展性（尽管从未完全交付），那么有什么选择人们发现有价值的东西？ MongoDB/Azure wrapper 是一个简单可行的替代方案吗？还是我应该硬着头皮启动自己的虚拟机？还是切换到 AWS？还是坚持使用 Azure SQL？

（让您了解我们的大小要求：我们认为我们将需要存储超过 10 亿行。不是很大，但也不能忽略不计。）

【问题讨论】：

我完全理解您在查询 ATS 时所说的内容。不幸的是，我没有答案，但这正是我必须尽快考虑的事情，希望有人能回答你。我曾简要地研究过 MongoLab，但它们的价格似乎很高。
似乎没有人提到它，但 Azure 表存储只是一个键值存储。您不应该能够查询它或添加索引。

标签： azure nosql azure-table-storage

【解决方案1】：

我们也经历过类似的情况并研究了几个选项，其中提供了 Azure 和 nosql 选项。

我们采取的措施是使用 Azure Blob 存储和 Lucene.Net。我们在 Json 中序列化我们的对象，然后将它们保存在 AzureBlobs 中。

我们使用 Lucene.Net 创建索引，Lucene.Net 返回我们需要的数据来获取包含我们要搜索的数据的 blob。我们还没有在生产中使用这种组合进行开发，但在我们所做的测试中，它运行良好。

【讨论】：

【解决方案2】：

虽然Azure表存储不支持二级索引，也没有SQL的特性集，但并不是试图解决同样的问题。

我会避免使用 SQL Azure（或现在所谓的任何东西）并专注于构建一个使用 Azure 擅长的东西（blob、表和队列）的数据层。

我们发现表存储对于大型生产解决方案来说绰绰有余。在过去 18 个月左右的时间里，情况变得更好了。 .NET 客户端库的 v2 比 v1 好很多。

与大多数应用程序一样，将架构直接移植到云平台上并不是一个好主意。重新思考解决以前业务问题的方式，充分了解云中可用的功能，是通向成功的唯一途径。

我同意之前的一篇文章，如果您需要索引大量数据，像 Lucene 这样的东西可能会很好。我们发现很好地使用表和 blob 我们可以不用，但它绝对是您工具箱中的一个选项。

【讨论】：

我同意 Azure 表存储并未尝试解决 SQL Azure 中的相同问题。我的抱怨是它在试图解决的问题上做得很差:-)。我希望 MS 要么修复它，要么作为一流的 Azure 公民提供其他替代方案。
出于好奇，您是如何解决缺乏二级索引和极其有限的查询能力的？在我的朋友圈中，我没有发现任何人将 ATS 用于（基本上）紧急存储之外的任何东西，所以我很好奇围绕 ATS 构建的应用程序将如何工作，以及它是否会像我不得不想象会是这样。
我已经看到 Azure 表存储在多个任务关键型企业应用程序中被广泛使用。我们倾向于使用类似 CQRS 的架构，其中表存储是我们整体存储架构的一个方面。它不是试图成为一个关系数据库，而是一个键/值存储。
我知道人们正在使用它，而且显然是成功的。我只是对如何感到困惑。与其他替代方案相比，它的局限性非常有限——想想亚马逊的 DynamoDB。如果您要存储任何复杂的数据，您如何将这些数据取出？您是否只是将其存储n 次，每次都使用不同的索引，然后非常希望您已经设法预测所有排序需求，然后再将 2TB 数据复制到新表并使用？跨度>
就其价值而言，我们终于开始在我们的解决方案中使用 Azure 表存储，因为我们已经开始遇到 Azure SQL 的可扩展性问题。是的，基本上我们发现我们需要对数据进行“n”次排序，每次都根据我们需要查询它。那是一个 PITA，尤其是当您发现需要在其上运行的新查询并需要编写新的 ETL 以将数据转入新表时，但它非常便宜（如果您不计算编码时间），而且数量巨大可扩展。

【解决方案3】：

自此发布以来，Azure 在 NoSQL 方面取得了长足的进步。您现在可以从 Azure 中将 Raven 和 MongoDB 作为插件启动，他们最近宣布了“Azure DocumentDB”，这是他们自己的产品，.它是公开预览版 - 博客在这里：http://azure.microsoft.com/blog/2014/08/21/new-azure-services-and-updates-expand-openness-choice-and-flexibility/

更多信息和文档可在此处获得：http://azure.microsoft.com/en-gb/services/documentdb/

正如其他人所提到的，Lucene 作为一种可能的搜索/索引解决方案。我在 Azure 网站上有一个网站，它使用 Lucene 索引进行搜索，并且我已经能够直接在网站的网络空间上存储和查询索引，因此不需要专用 VM 或担心如何公开索引穿过电线。显然，如果您想维护多个 web 盒子（在缩放时），这可能会变得很棘手，但作为一种可能性，您可能值得知道。我的 Web 实例带有 50GB 的磁盘空间，其中只有一小部分被网站使用，因此 Lucene 索引将其使用。我从来没有听说过这是官方的策略，YMMV。

【讨论】：

我对 DocumentDB 感到非常兴奋，直到我读到 Ayene Rahien 对它的评论：ayende.com/blog/168034/azure-documentdb。它仍处于预览阶段，因此希望 MS 能够解决一些更明显的问题。但他们需要比使用 Table Storage 取得更快的进步。
我还通过 Azure Store 研究了 Raven 和 MongoDB 替代方案。我担心的是，它们的定价似乎与 Azure SQL 大致相同，具有相似的可扩展性目标。不过，我可能是错的 - 我很想听听其他在生产中运行过某种规模的人的意见。

【解决方案4】：

也许有点跑题了。

有几个用例，其中 ATS 是很好的工具。

一种情况是在常规 RDB 中存储通常存储为 XML (JSON) 序列化对象的元数据。这些是不需要索引的数据，而是结构化的。例如所有客户端元数据。使用 ATS 而不是 SQL 的原因是 ATS 能够随时随地添加、删除此类数据的列。因此，无论何时更改元数据结构，您都不需要遍历所有客户端记录、反序列化 XML (JSON)、重新创建数据树、将其序列化为 XML (JSON) 并将其存储回表中。太棒了。缺点是您必须保持元数据的扁平结构，而不是使用经典 XML (JSON) 序列化可以实现的树结构。

第二种情况是存储您不需要的 RDBM 中的数据，以防它们太多。例如，它可能是银行系统中超过 5 年的交易清单。这些是您实际需要存储的数据，但不是活动形式。这些数据会减慢您的连接/位置条件，并且您每天都不需要它们。您仍然可以取回这些数据或将它们移动到另一个 RDBM 中，以便每年进行一次离线分析。将数据存储在 ATS 中也比将它们留在 RDBM 中便宜得多。

【讨论】：