我在Azure SQL数据仓库中有超过5亿条记录。我正在尝试做一些基准测试，以便了解以哪种方式保存记录。 Rowstore或Columnstore。我不会将表与其他表联系起来，它不是一个分析事实表。两个表都作为循环分发，它们都包含17个分区。它们都有45列。当我查询总和两列时，我希望Columnstore表的性能比rowstore好得多，但实际情况是我从Rowstore得到的总和结果大约是2.5分钟，而列存储大约是10分钟。我不使用任何过滤器或分组。另一方面，当我查询count（*）时，columnar table比rowstore执行得更好。
编辑
虽然我不能与你分享所有细节，因为它是私人的，这里有一些只是为了了解正在发生的事情。我在smallrc和100DWU上运行查询。表加载一个CTAS并包含来自多个表的预加入信息，并将从我们的内部应用程序通过自定义协议（排序/组/过滤器/分页）提供查询。域名是赌博，从45列我们有43个可以用作过滤器。输出集通常包含3到4列加上两个sum列，每个查询不超过1000行。我通过EventDate每月对两个表进行分区，假设每个月都有一个新分区。大多数情况下，我的查询包含EventDate作为过滤器。我的Rowstroe表除了包含与columnstore相同的分区外，还包含EventDate作为聚簇索引。添加EventDate作为columnstore的辅助索引有所改进，但性能仍然远远落后于rowstore。 EventDate采用int格式，值模式为yyyyMMdd（20180101）。
每个DW optimized for elasticity有60个分布，而DW optimzied for compute的较低偏差也有60个分布。
SQL Server的列存储基于行计数创建行组（例如，与Parquet相反，其中行组基于磁盘大小创建）。理想情况下，行组应该有1M行（请参阅@GregGalloway添加的link），但如果行组在单个批量加载中至少加载了100k行，则行组可以获得COMPRESSED。当行组未压缩时，它以行格式存储在增量存储中（它们是常规B树，具有MD /访问开销，因为它们是列存储索引的一部分。请注意，您不能指定索引，因为它们是集群列存储索引的一部分）。
我假设你在60个发行版中有500M行，即每个发行版8.3M行;假设您的分区是同构的，有17个分区，每个分区大约有490k行。
批量加载到分区表时，您需要注意加载的内存要求/资源类，因为批量加载之上的排序迭代器不会溢出，因此它只会向批量加载提供大量的行可以排序。
确保你的index has good quality。如果您只对表进行聚合而没有太多过滤，那么1分区是理想的，即使您进行过滤也要记住，如果您的数据在right order中加载，那么就可以了。
您应该确保每个分区至少有几百万行，并且您具有COMPRESSED行组以获得良好的性能。根据您的扫描结果，您在OPEN行组（delta商店）中拥有大部分（如果不是全部）列存储数据。
在计数（*）的情况下，你的意思是什么？
这些运行还冷或暖吗？如果它是计数的热运行（*）CS可能只是抓住行组MD并增加行数 - 尽管在这两种情况下编译的计划都显示全表扫描。