现在只要是个数据库都肯定会说自己是具有HTAP能力的，让选择数据库的朋友有了选择恐惧症。实际上选择数据库用一句最简单的话说就是只选对的，不选最好的。再好的数据库产品，不符合你的应用，运维等方面的需求，对你来说都不合适。话是简单，但是做起来并不容易。很多时候，适合不适合你，只有用了才知道。面对各种宣传，确实很难做出判断，哪怕说我测试一下，数据库这种复杂的IT基础设施，测试也不那么容易做好做对。
按照上面的说法，难道我们还真的无法去判断和分析一个数据库到底是不是真正具有HTAP能力呢？也不完全是这样的，我们可以从HTAP数据库应该具有的几个重要特征入手，去加以分析。为了没有做广告的嫌疑，今天的分析里面不会提及具体针对某些数据库产品的比较，仅仅提出一些分析的原则。
首先要看TP/AP能力是不是原生融合的，也就是一个SQL引擎可以智能化处理TP/AP能力，最起码TP/AP用用的入口是统一的，一套数据，多种处理引擎的模式虽然也能解决一些TP/AP的问题，不过两个引擎很难做统一资源管理，在某些时候会产生相互干扰，如果AP业务严重影响了TP业务的稳定性，那么就会引发大问题的。
原生融合实际上对SQL引擎和优化器的要求很高，如果SQL引擎存在一些BUG或者有些考虑不周的地方，就可能会引起TP/AP负载被错误识别，引起不必要的麻烦，因此SQL引擎支持HINT是十分必要的，而且在HINT中最好一些针对TP/AP识别，只读副本使用，弱复制一致性数据读取，资源限制等方面的支持。
其次是具有行存为主，列存为辅或者行列混合存储的存储机制。一个数据的写入一定是行存储，不过必须具备数据通过列模式提供查询的能力。或者数据采用折中的方式，采用范围分片后的行列混合存储模式，既照顾TP应用的行访问需求，也满足AP应用负载的列访问需求。
很多数据库也号称是行存列存都支持的，不过一张表只能建为行存表或者列存表，那么这种行列存储能力对于HTAP的支持是打了折扣的，一份行存数据必须转储到列存表中，才能更好的支持OLAP业务负载。HTAP的准实时数据仓库应用能力就无法实现了。
第三个重要能力是OLTP/OLAP负载的隔离性，这两种负载不能相互影响，应该有一定的资源隔离和资源限制能力。能够对一些开销较大，执行时间超长的OLAP负载限定资源使用，避免造成对OLTP的太大的影响。
可以按需挂起/恢复后台OLAP工作任务，临时修改某个或者某些OLAP负载的资源限制等，都是HTAP能力精细化的体现。一个优秀的HTAP系统，底层资源管理和任务调度做的好坏是关键。
第四个重要能力是资源扩展的能力，计算能力，存储能力，IO吞吐能力等都不存在严重的瓶颈，可以随时进行扩展，以满足日益增长的业务需要。不管是通过MPP节点扩展还是只读节点扩展，只要这种扩展能力对你的业务场景是有效的，都是可以接受的，并不限于某种架构。
第五个重要能力是SQL能力，SQL能力主要是考察SQL引擎和CBO优化器的能力。支持的SQL标准，特别是统计函数，分析函数，窗口函数等的支持能力。并行扫描的能力，算子下推的能力，索引类型的支持等都是重要的考察内容。SQL引擎不能对表连接的数量以及表的规模有任何限制，也不能要求建表的时候必须指定SHARDING KEY。
第六个重要能力是容灾能力，这个能力和你的应用对高可用，灾备的要求要相匹配。可以实现自动化复制，自动化切换，最小的RTO/RPO，甚至零数据丢失是最佳的选择。
第七个重要能力是接口能力，是否能够提供C语音、JDBC、ODBC/OLEDB等多种接口，支持你所是使用的主要编程语言等也是极为重要的，这对于你今后的应用开发与应用迁移十分重要。现在的数据库产品十分庞杂，有些数据库产品甚至只提供一个JDBC引擎就敢发布了。
此外易部署，易管理、可观测能力强、生态工具齐全、数据类型支持、字符集支持等因素也是你需要去考虑的因素。如果你还需要从老数据库上迁移数据和应用到新系统，那么与你原有数据库的SQL语法兼容性、数据复制工具、数据迁移工具的完备性与符合度等也是你必须考虑的因素。
数据库选型是个既复杂又简单的事情，如果你能根据自己的实际情况，应用场景去做理性的分析，不难找到一个相对靠谱的选择。我上面提的一些点有些可能值得你去参考，有些可能也不一定适合你的现状，总之，只有了解现状，才能做出正确的选择。
