6

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

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

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

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

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

4

4 回答 4

3

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

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

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

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

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

于 2013-11-13T12:23:52.213 回答
2

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

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

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

于 2013-11-13T10:52:19.057 回答
1

自从这篇文章发布以来，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。

于 2014-09-19T15:57:29.350 回答
1

也许有点跑题了。

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

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

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

于 2014-09-22T13:45:34.210 回答