Azure 上的列存储索引有何优势?

发布于 2024-12-28 12:57:50 字数 290 浏览 2 评论 0原文

我们目前在 Azure 上运行,并且有一个包含数亿行的表。该表是静态的,每周刷新一次。我们已经研究了 ColumnStore 索引,但不幸的是它还不是 Azure,所以下面是我的问题:

  • ColumnStore 索引在 Azure 中可用吗?
  • 如果不是,我们可以使用什么其他技术来获得相同的性能 ColumnStore 索引能带来什么好处?
  • 使用Azure表存储我们可以获得相同的查询性能吗?

我是 Azure 和列式数据库的新手,所以如果我问这些问题,请耐心等待..:)

We are currently running on Azure and we have a table with hundreds of millions of rows. This table is static and will be refreshed weekly. We've looked at ColumnStore index but unfortunately it is not Azure yet so below are my questions,

  • Will ColumnStore index be available in Azure?
  • if not what other technology can we use to get the same performance
    benefits as the ColumnStore index would provide?
  • Can we get the same query performance by using Azure Table Storage?

I'm a newbie to both Azure and Columnar databases so please bear me with me if I ask these questions.. :)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

宫墨修音 2025-01-04 12:57:50
  • 关于ColumnStore,如果您已经购买了License,可以向开发团队咨询或者在ScottGu 的博客。从那里,只有您才能了解任何功能发布。
  • Azure 数据库专为可扩展性而设计。您需要非常明智地使用分区键分区键就像一本书的索引,所以如果你想在书中搜索一些东西,你可以快速引用索引并快速到达页面。换句话说,您可以根据特定条件对数据进行分组并将其存储在单个分区中。因此,无论您有相同的条件,您的查询都只会命中一个分区。分区的问题是,对于一个表,您可以有任意数量的分区,但不一定所有分区都驻留在同一台计算机甚至同一场上。因此,当您对设计不当的 Azure 表发起查询时,它可能会命中多个服务器,从而导致性能不佳。了解现实世界:为 Windows Azure 表存储设计可扩展分区策略

希望您能得到您想要的东西。

  • About ColumnStore, if you have bought the license, you can check with development team or ask on blogs such as ScottGu's Blog. From there only you will come to know about any feature release.
  • Azure Database is designed for scalability. You will need to use the Partition Key very wisely. Partition Key is like index of book, so if you want to search something in book, you can quickly refer to the index and reach the page quickly. In other words, you can group data depending upon certain criteria and store it in a single partition. So where ever you have the same criteria, your query will hit only one partition. The thing with partitions is, for a table you can any number of partition, but it is not necessary that all the partition will reside on same machine or even same farm. So when you fire a query on badly designed Azure Table, it can hit more than one server, and thus bad performance. Read about Real World: Designing a Scalable Partitioning Strategy for Windows Azure Table Storage

Hope you get what you are looking for.

芯好空 2025-01-04 12:57:50

正如 Amar 指出的那样,请密切关注团队博客,了解最新的新功能公告。 SQL Azure 的目标是最终成为最先发现新功能的地方。然而,事情的实现还需要一段时间。

至于你的性能问题,没有简单的答案。 Windows Azure 资源是为扩展而设计的,不一定是为了高性能。因此,在设计解决方案时要考虑您的规模/容量目标。对于您的情况,我鼓励您考虑表存储,但这取决于访问频率以及您需要对数据进行查询的类型。如果您必须制作以不同方式建模的数据的冗余副本,或者甚至可能运行并行查询和聚合结果,请不要感到惊讶。这就是表存储的设计使用方式。它比 SQL Azure 更便宜,并且这种价格差异使得冗余的专用数据模型成为可能。

这种方法还必须权衡重新培训开发人员以停止使用 RDBMS 术语进行思考的成本。 :)

As Amar pointed out, keep an eye on the team blogs for the latest in new feature announcements. The goal for SQL Azure is for it to eventually be where new features are found first. However, it will still take awhile for things to get there.

As for your peformance question, there's no simple answer for this. Windows Azure resources are designed for scale, not necessarially high performance. So its to take your scale/capacity targets into account when designing solutions. For your situation, I would encourage you to conside table storage, but this will depend on frequency access and the types of queries you need to make on the data. Just do not be surprised if you have to mave redundant copies of your data that are modelled differently, or possibly even running parrallel queries and aggregating results. This is the way table storage was designed to be used. Its cheaper then SQL Azure and its this price difference that makes redundant specialized data models possible.

This approach also has to be weighed against the cost of retraining your developers to stop thinking in RDBMS terms. :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文