宽表设计最佳实践

主键

一行中的列会分为主键和非主键。主键可以由多个列组成。主键有以下几个特征：

• 主键的Schema不可修改：主键在创建Lindorm宽表时就已经确定，建表后主键的列不可以增加、删除、更换顺序，更不能修改数据类型。因此，在建表前需要合理规划主键。主键的设计对数据请求性能至关重要。

• 主键具有唯一性：所有主键共同组成了一行RowKey，RowKey在一张表里是唯一的。因此，通过提供完整的主键即可确定表中的唯一一行。

• 主键即聚簇索引：在Lindorm宽表中，数据按照主键的顺序存储。例如在示例表orders中，channel列的值相等的行会存放在一起。在channel列的值相等的情况下，再按照id列的值排列。在id列的值相等的情况下，再按照ts排列。

  通过主键即聚簇索引的特性，可以实现更高效的查询。在查询时，Lindorm与MySQL类似，遵循最左匹配原则。您可以指定尽量多的主键等值来缩小查询范围，在设计表的主键时，您可以把常用的等值查询条件放在主键的最左边。如果查询语句中对某个主键设置了范围查询，则最左匹配立即终止，即使其他的主键为等值查询，后续主键的扫描也无法利用存储顺序，需要进行大量的过滤来匹配范围查询。

  以示例表orders为例，查询语句如下：

  -- 需要读取所有channel=alipay且id>a0089的数据来匹配符合ts=1705786502068这个条件的行。
  SELECT * FROM orders WHERE channel=="alipay" AND id > 'a0089' AND ts = 1705786502068;  

  如果未指定最左边的主键，查询其他主键，尽管查询条件中指定了主键，也仍然是全表扫描，如下所示：

  -- 这是一个全表扫查询
  SELECT * FROM orders WHERE id = 'a0089';

  在上述语句中，查询条件指定了一个主键id，但该主键位于所有主键的中间位置，因此系统仍然需要过滤所有的行来匹配id= 'a0089'的行，效率非常低。如果该查询是主要查询，那么在设计该表的主键时，建议将id列放在最靠左的主键中，或为id列创建一张索引表来加速查询。

非主键

Lindorm支持动态定义非主键，即非主键无需定义在Schema中，您可以写入任意列名的非主键，与HBase使用方式类似。详细的使用说明，请参见动态列。同时，Lindorm支持使用通配符来定义非主键列，例如定义*_str列为STRING类型，则所有列名以_str结尾的、数据类型为STRING的列都可以写入。详细介绍请参见通配符列。

Lindorm支持非主键列的更新，数据写入时无需指定所有非主键列，但至少需要指定一个非主键列，不支持仅写入主键。由于Lindorm宽表的存储是主键有序，如果没有在非主键列上建立索引，直接将其作为过滤条件会造成全表扫描，此类查询默认会被Lindorm拒绝。因此，如果需要高效查询非主键，您可以限定主键范围，或为非主键列建立索引。

-- 未限定主键，仅使用非主键列作为查询条件，该请求将扫描全表
SELECT * FROM table WHERE location = 'shanghai'; 

-- 限定主键的扫描，会扫描所有channel='alipay'的行，并过滤出location = 'shanghai'的行
SELECT * FROM table WHERE location = 'shanghai' and channel='alipay'; 

预分区

由于Lindorm支持自动分区，因此您在建表时无需定义分区范围。在写入数据的过程中，系统会自动分裂分区。如果您对数据分布有需求，可以在建表时指定预分区个数，系统会将表的Region分布在多台机器上，分散读写。需要注意的是，建表指定的分区个数只是初始表的Region个数，在数据写入过程中，系统仍然会对Region进行分裂。如果要在建表的时候指定预分区，请参见CREATE TABLE。

如果您一开始写入量便很大，或计划使用Bulkload批量导入数据，建议您建表时设置适合数据分布的预分区，防止一开始写入时便导致单台服务器超出负载。

• 如果您使用SQL或HBase API写入数据，可以在建表时指定预分区数量为节点数×4。初始分区并不是数量越多越好，因此建议您根据需求设置合适的分区个数。

• 如果您使用Bulkload批量导入数据，建议在建表时指定预分区数量为数据量（GB）÷8，以便数据能够分散导入到每个Region中，并且不会导致每个Region的数据量过大而触发分裂。

您还需要注意预分区的Region范围是否符合数据写入规律，否则即使预分区数量再多，写入或导入数据时，数据倾斜至少数几个分区中也会导致性能与预期不符。

热点

在分布式系统中，关键在于确保数据请求能够均匀地分布在每个Region上，这样系统就能够实现水平扩展，承载更多的数据量或请求。然而，当系统出现热点时，可能会导致单台机器成为性能瓶颈。

• 单行热点：频繁读写单行数据可能会产生单行热点。由于对同一行的请求始终会被发送到同一台服务器上，因此这台服务器的性能上限决定了整个系统的性能上限，此时无法通过水平扩展解决热点问题，只能通过升级单机配置来处理更多的请求，所以在宽表的设计时需要考虑热点问题，尽量避免单行热点的产生。

• 小范围热点：如果频繁读写一个很小范围内的数据，可能会造成小范围热点。由于Lindorm是按照主键的范围进行分区的，所以小范围的数据很可能分布在同一个分区，那么请求也可能都被发送到同一台服务器上，尽管Lindorm的热点自愈功能能够识别小范围的热点，并通过自动分裂Region将热点Region中的数据分散到不同的节点中，但是您仍然可以选择更加分散的主键来避免小范围请求。以示例表orders为例，您可以对id列使用HASH函数后进行存储，从而尽可能地避免热点问题。

• 主键递增写热点：如果主键的值是递增的，则代表主键的值始终在增长。由于Lindorm是按照主键的范围进行分区的，即使Region发生分裂，后续写入的数据也只会存储在分裂出的子Region的下半部分，流量无法分散。例如示例表orders中，id是递增的，而满足channel=alipay条件的订单写入量非常大，那么即使Region_3能分裂成Region_3_a和Region_3_b两部分，承担写入流量的也只有Region_3_b。由于递增写热点的问题无法从系统层面解决，因此，建议您在设计主键时尽可能避免主键递增的情况，且主键的第一列不能是递增的值。

  重要

  如果您是使用Cassandra等使用HASH分区设计的系统将数据迁移到Lindorm，需注意，在Cassandra等系统中的第一列为HASH分区键，如果该列的值是递增的，那么经过HASH函数处理后，这些值将会被均匀地分散至每个分区中，但如果把该递增的主键迁移至Lindorm，则会出现严重的热点问题。

点查和范围查询

Lindorm宽表有两类常见查询：点查和范围查询。

SELECT * FROM orders WHERE channel='alipay' AND id='a0001' AND ts=1705786502000;
SELECT * FROM orders WHERE channel='alipay' AND id='a0001' AND ts IN (1705786502000, 1705786502222, 1705786502333);
SELECT * FROM orders WHERE channel='alipay' AND id IN ('a0001', 'a0002', 'a0003') AND ts IN (1705786502000, 1705786502222, 1705786502333);
SELECT * FROM orders WHERE channel IN ('alipay', 'wechat', 'unionpay') AND id IN ('a0001', 'a0002', 'a0003') AND ts IN (1705786502000, 1705786502222, 1705786502333);

SELECT * FROM orders;
SELECT * FROM orders WHERE channel='alipay';
SELECT * FROM orders WHERE channel='alipay' AND id='1705786502001';
SELECT * FROM orders WHERE channel='alipay' AND id IN ('a0001', 'a0002', 'a0003');
SELECT * FROM orders WHERE channel IN ('alipay', 'wechat', 'unionpay') AND id IN ('a0001', 'a0002', 'a0003');

ORDER BY查询请求

Lindorm宽表的数据是按主键排序的，即使SELECT语句中不添加ORDER BY子句，系统也会按照主键顺序返回查询结果。但如果查询请求命中索引表，则默认按照索引表的顺序返回。同时，索引表中的数据排列为索引列的顺序，所以索引列的顺序决定了该查询的返回顺序。

ORDER BY的列遵循最左匹配原则，如果想要高效地排序，则不能跳过左边的主键字段直接在ORDER BY语句中使用中间的主键字段进行排序。在ORDER BY子句中使用中间的主键或者非主键进行排序时，会涉及大量的排序计算，因此建议您将需要排序的主键放在最左边，或为需要排序的非主键创建二级索引。此外，如果您希望查询结果倒序排列（ORDER BY DESC），建议在建表时添加DESC关键字，可以保证数据的倒序存储，以便获得最佳的查询性能。关于ORDER BY的使用，请参见如何在较大结果集中使用ORDER BY。

Count查询请求

Lindorm是基于LSM-Tree存储结构的NoSQL数据库，由于存在多版本更新、删除标记（deletemarker）等数据（即数据可能存在多次修改、删除），因此底层存储并没有在元数据中记录表的行数。如果您想要精确查询表的行数，则需要扫描全表，表越大则耗时越长。如果您只需要获取一张表的预估行数，请参见如何统计表行数。

如果Count请求有限定条件，那么查询耗时则取决于限定条件下需要扫描的表数据的多少，例如SELECT count(*) FROM table WHERE channel = 'alipay'会读取所有满足channel = 'alipay'的行进行统计。