分布式数据库上的应用开发与集中式数据库是有较大的不同的 ，很多用惯了Oracle的用户可能不太能够理解这个。前几天一个传统行业ISV的朋友打电话问我两款分布式数据库上的应用开发问题，问我是不是某一款分布式数据库开发时候可以像Oracle一样不用考虑分区表的问题，而另外一个要考虑。我的回答是，二者之间可能会有些区别，但是本质上分布式数据库上的应用开发与在集中式数据库上还是有较大的差别的，与在Oracle上开发应用是不同的。针对任何一种分布式数据库，在应用开发上都需要根据该数据库的特性进行特定的设计。今天我们来聊聊基于GaussDB分布式数据库，应用开发方面需要注意一些什么问题。
使用分布式数据库之前，我们先要理解一些分布式数据库与集中式数据库不同的地方。比如说分区表和数据分片的差异。有些数据库可以不考虑分片问题，RDBMS会自动根据分区去分布数据。而Gaussdb需要通过制定分片策略来适应业务的需求，因此在Gaussdb上做应用开发的时候，需要认真思考数据的分片策略。经常JOIN的表，其分片策略最好是一致的，这样可以提高这些表之间做连接查询的性能，因为跨节点表连接操作的成本是很高的。
在创建分布式数据库的表的时候，要注意几个问题，一个是DISTRIBUTE BY HASH子句，选择合适的分片键，分片键最好与业务是有关系的，SQL语句的WHERE条件如果不带分片键，那么这些语句会下发到所有的DN上去执行，形成扫描放大的效果，增加数据库开销。DISTRIBUTE还可以是复制，也就是说把一张表复制到多个DN上。这种复制的目的是为了让一些相对静态的参照表能够在多个DN上存在，从而提高某些业务表与参照表JOIN时的性能(可以本地JOIN，不需要跨DN JOIN)。开发人员在分布式数据库上设计表的时候，要考虑好这些因素。
另外在分布键的选择上，应使用取值较为离散并且分布较为均匀的字段作为分布键，以便数据能够均匀分布到各个DN中。其次要尽量选择查询中的关联条件作为分布键，这样可保证 JOIN任务的相关数据分布在相同的DN上，减少DN间数据的流动代价。分布键使用的列长度不要太长，过长会带来较高的计算开销。另外分布键如果使用多列，尽可能不要使用过多的列，华为的官方建议是复合分布键不超过3列。
TO GROUP子句也是集中式数据库开发者容易忽略的，这个GROUP是DN的节点组，某个节点组是在Gaussdb中用来控制数据分布与复制的。如果一个复杂的应用涉及的表很多，把业务打散到多个DN节点上，那么我们可以考虑先把DN分组，然后把这些表也进行分组，创建到不同的DN GROUP中，那么可以避免表分布过于分散，读放大影响太大，也有助于降低网络的延时，从而提高系统的响应速度。
在上面一个表里还需要注意的是GTM FREE，这是用惯了ORACLE的开发者容易忽略的技术。分布式数据库因为分布式事务的问题，其应对高并的分布式事务因为全局事务管理器的问题，会有一定的性能损失。如果你的某个业务模块SHARDING特性很明显，可以容忍最终结果一致性，那么你可以选择使用GTM FREE，从而提高并发能力，降低交易延时。实际上证券、银行等领域的核心交易如果应用进行针对性改造，都可以从GTM FREE中受益。
数据类型的选择也是以往我们使用ORACLE的时候不太考虑的，而当我们使用分布式数据库的时候，如果应用需要我们精打细算，那么选择较为高效的数据类型也是十分关键的。其实在早些年我们做Oracle优化的时候，也做过精打细算的考虑，使用和C语言兼容的数据类型，不要使用类似Numeric这样的数据类型，还是可以细微降低系统开销的。因为篇幅问题，这个话题我就不展开讨论了。
对于一些官方最 佳实践的推荐，我们也应该充分考虑。分布式数据库与集中式数据库不同的就是元数据的管理要复杂得多。元数据缓冲必须保证在多个分布式的节点中强一致性同步，类似位置缓冲的命中率对SQL解析的性能影响较大。索引对数据写入的并发性能影响也要大于集中式数据库。这些最 佳实践虽然不是必须遵守的，不过遵照这些规则适当优化自己的应用对于系统总体性能的保证还是十分关键的。
虽然命名规则对于对象名长度的约束是小于64，不过考虑到元数据缓冲的问题，这些命名短一些可能更好一些，我还没有仔细研究高斯的元数据缓冲是否和Oracle以及OB一样是变长缓冲，如果是变长缓冲则越短越有助于元数据访问的性能提升。
我们在使用Oracle的时候，索引使用是肆意的，这个毛病在使用分布式数据库的时候要改改了。华为官方给出了索引使用的一些建议。首先我们必须合理设计组合索引，尽可能避免冗余的索引，在分布式数据库中，过多的索引数量会引发写操作的性能问题。复合索引的字段数也不宜过多，特别是字段总长度尽可能不要超过200。而对于某张表的唯一性索引也不宜创建过多，以避免数据校验的开销过大。
时间关系，今天我们先讨论到此吧。如果我们要选择使用分布式数据库无论是使用Gaussdb还是其他数据库，都不能按照以前使用Oracle等集中式数据库那样肆无忌惮，必须考虑到分布式数据库的特性，从源头上避免应用使用的问题，确保关键应用能在分布式数据库上有较好的性能。
