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