请不要感到奇怪，HANA单表可以支持超大数据量

前言：

前几个月，光头强的StrongBear公司遇到一个真实的案例，客户的一张单表数据量达到HANA的单表数据量的上限了。猜猜是多少，就是达到了约20亿条，于是乎，系统报一系列错，Memory不够，拒绝服务之类的。可事实上，系统的总内存是足够的。

20亿条，对于常规系统而言，绝对不算少，可是这个就是HANA的天花板吗？

HANA最后还是可以利用它独特的分区来进行表的记录条数扩容。

HANA数据库针列型的表的记录数，其实是有预警的。

By default, HANA system will report below alert for each one hour.
Interval 1 hour
High: 1,900,000,000
Medium: 1,800,000,000
Low: 1,500,000,000

我们能看到，基于列类型的单表，当记录条数分别超过15亿、18亿、19亿，系统就会出具低、中、高级别的相应警告。

场景:

我们在文章：HANA Column Table行数到了极限…… 当中也列出了相应的情况。

为了让单表能存储更多的记录，同时业务代码不用作任何改动，还能保持系统性能基本不变。HANA可以直接对表进行dynamic分区（注：不是几种传统的分区，那样做，会临时产生停服时间，影响业务）。下边是一个使用Roundrobin分区的示例，那样势必影响当前数据的分布，影响业务。

CREATE COLUMN TABLE T123(id int);
ALTER TABLE t123 ADD (col2 varchar(32));
ALTER TABLE t123 PARTITION BY ROUNDROBIN PARTITIONS 8;

使用的最终的解决方案是这样子的：

ALTER TABLE "DEMO_STATISTICS" PARTITION BY RANGE (METRIC_TIMESTAMP) (PARTITION OTHERS DYNAMIC THRESHOLD 1500000000);

它只有一个限制条件，就是RANGE列这里是：METRIC_TIMESTAMP，必须是非空列。这个可以理解。同时，为了提高效率，你可以在此列创建索引。

如果是新上线的系统，没有任何数据，那么，还真是可以任意选择一种分区都可以将数据分布到多个分区上边。

上边的例子，就是只要当前表累积到15亿条，马上就会移到一个新的partition。而HANA可以支持多达16000个分区。所以在数据记录的行数上，只要你内存足够，基本上能到240000亿条。如果是这样的话，你还需要分布式吗？

上边的情形是针对列类型的表。还有行表，行表的限制又不一样，单个非分区的行表，它的记录行数受制于下边的计算公式：

1,945 GB/sizeof(row)

如果单行记录大小为：256个字节，我们可以估算出，行表记录上限为：

> 1945*1024*1024*1024/256
8,157,921,280 （81.5亿）

如果是1024字节，则为：

> 1945*1024*1024*1024/1024
2,039,480,320 (20亿)

这样看起来还好。

光头强让熊二看看他们系统中的某表的分布情况：

SELECT COUNT(*) FROM DEMO_STATISTICS;
COUNT(*)
4019656297

总计已经有了40亿条了。

再看看内存及分区情况：

Table Name            Memory Size In Total (B)
DEMO_STATISTICS        24348473114
DEMO_STATISTICS        22487063388
DEMO_STATISTICS        2054897656

大概几十G内存。性能自不用说，毕竟是内存数据库。在以HANA为主的系统里边，集中式应该能解决绝大部分应用中的规模化问题。

参考：

1、HANA系统限制：
https://help.sap.com/docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/20a760537519101497e3cfe07b348f3c.html