【IT168 技术】虽然新技术不断涌现，但在进行数据库选型时，大部分企业还是会优先考虑关系型数据库(RDBMS)。因为针对大多数的应用场景，关系型数据库都体现了充分的适用性与可靠性。正如数据库专家盖国强所言，对于大部分行业用户而言，集中式OLTP技术仍然是当下唯一可行的技术选择。

　　近日，浪潮正式发布了数据库产品K-DB 11g，定位于一款企业级关键业务的数据库，由浪潮和韩国Tmax公司共同研发，专为天梭K1定制优化的数据库，虽然其前身在韩国市场已经拥有超过1175个商用案例，但对于国内众多DBA来说，K-DB 11g依然是陌生的，甚至可以说是神秘的。K-DB究竟是一款什么样水准的数据库产品?截止老鱼写这篇文章之时，北京市档案局、哈尔滨银行、内蒙古交通厅等用户已经完成了对该产品的测试，并即将在生产环境中采用。

　　K-DB 11g作为一个标准的关系型数据库，从技术上分析首先要解决以下几个问题：

　　1、高性能：这个性能并非单纯指能否获得很高的测评指标，而体现在峰值业务压力下能否长时间保持平稳的输出能力，以及能否支持硬件平台的线性扩展;

　　2、高可用：一个动不动就需要重启的数据库显然会给运维带来极大的麻烦，因此数据库要有足够的容错特性和自我故障检测和修复的能力;

　　3、高安全：对于数据库选型，呼声最高的也是企业级产品最重要的一点就是安全性，现在爆出越来越多安全事故，导致数据泄露的问题层出不穷，如果安全无法保证，功能再强大，也是一个0;

　　4、高兼容：一个数据库要想很好的使用，必须和周围的开发工具和接口很好的融合在一起，没有这些接口的话那么其他第三方工具在使用过程中就会有很多问题。并直接影响到开发商包括ISV这些厂商愿不愿意用这个数据库，这也是影响数据库能否被广泛使用的关键因素;

　　5、易管理：一款优秀的数据库应该有良好的管理特性，DBA能够方便地运用多年积累管理经验以及使用运维工具对数据库进行日常管理，如果能够与主流数据库采用相同的备份管理策略以及相似的工具软件，并提供相似的硬件体系架构，那无疑会更好;

　　那么K-DB是如何做的?今天老鱼在这篇文章中一一为大家揭秘。

　　K-DB体系架构设计

　　先来说说K-DB体系架构设计，K-DB在体系架构设计上显然参考了业界主流数据库产品的诸多先进理念，下图我们可以看到K-DB在数据库核心层采用共享内存管理机制，Shared Cache、Buffer Cache以及Redo Log Buffer功能，并支持自动优化调整，同时也可根据管理员的需求进行手工的设置，因此无论是OLTP还是OLAP应用都可以根据自身特点进行内存的调优。

▲K-DB体系架构

　　而后台的工作进程负责处理数据库查询更新请求，采用了多进程多线程机制实现;IO进程用于协调共享内存和存储IO的读写优化策略，而KAS内置存储虚拟化技术能大幅降低数据库读写的IO瓶颈;集群管理进程负责集群节点之间的数据共享和同步，此项技术是实现共享磁盘式集群的关键，而共享内存同步算法的优劣将直接影响多节点RAC集群下性能的线性扩展。

　　同时，我们看到在外部接口层面，K-DB数据库提供多种数据库访问接口、管理工具为用户提供全面的数据库管理和使用。

　　多进程多线程的工作模式

　　数据库的工作进程负责处理外部SQL请求，传统的主流数据库采用多进程单线程的工作模式，因此Dedicate访问模式下表现性能优秀。但高并发访问量下，进程的创建与回收以及进程之间的通讯将为操作系统带来很大的负担。

　　而K-DB多进程多线程的工作模式能够有效降低因并发访模式下数据资源共享而引起的大量内存拷贝，也降低数据库对常规内存的容量需求，同时也能进一步减少了创建和回收工作进程的时间开销。该项技术目前在Oracle最新的12c版本上才予以实现。

　　异步写缓存技术

　　传统数据库采用工作进程将直接对数据文件进行读写，因此在高压力负载下，多个进程并发读写将导致存储设备的写竞争，这种情况类似于咱北京在下班的高峰期五环路堵得一塌糊涂一样。

　　K-DB有一个专属异步写缓存技术，所有的写文件请求将统一由一个专属线程进行调度排序，这个线程如同高速路上的交警一样，使得K-DB在高并发量下有效地提升了磁盘写性能。

　　Active Storage功能

　　众所周知，数据库的性能瓶颈往往产生在对IO设备的访问上，如为了保证数据一致性，同时帮助数据库实现故障的快速恢复，任何对增删改操作将直接写入日志文件，因此日志文件写入的效率将直接制约着整个数据库系统的运行效率。

　　K-DB提供了Active Storage功能，由数据库构建存储虚拟层，通过对存储资源池的条带化，消除存储中的热点盘，大幅度提升了数据库的并发读写能力，同时提供了RAID和Load balance功能，因此K-DB的整体性能在分布式的存储架构上获得IO性能的大幅提升。

　　优化器(Optimizer)

　　Oracle之所以能够胜出其他数据库的关键所在，是在于优化器的性能。那么什么是数据库的优化器呢?优化器是一套非常复杂的算法，相当汽车的“引擎”，性能好不好全看引擎的性能。

　　我们知道，Oracle 在执行一个SQL之前,首先要分析语句,然后再根据各种统计信息和要素，按照排列组合的原理，为其制定非常好的执行计划，最后再按执行计划去执行。制定语句执行计划的工作是由优化器来完成的。不同的情况,一条SQL可能有多种执行计划,但在某一时点,一定只有一种执行计划是最优的,花费时间是最少的。

　　比如在对只有30条记录的表进行查询操作的时候，数据库会直接进行全表扫描。但同样的查询语句在面对有300万行记录的表进行查询，全表扫描的执行效率会极其低下，采用索引方式将大大提升执行效率。

　　因此，优化器要能够综合查询时刻数据库的结构设计、数据量大小、当前内存共享数据的情况，找出非常好的的执行计划，这样的优化器称之为敏感的优化器。

　　K-DB能够应对高并发量的数据访问压力，实现根据业务的变化而自动的调优，数据库专家郑保卫在K-DB活动体验日上就谈到对K-DB优化器的感受：

　　“对数据来讲，80%到90%的性能是靠优化器能够正确的找出比较好的执行方式，其他10%是靠人去影响的。优化器越敏感，数据库运行处理的性能越强。而K-DB的性能优化器做得非常敏感，当我修改一些参数，包括用SQL语句上的提示来改变它的要素，K-DB的优化器能很快的识别到。”

　　数据库集群KRAC&KSC

　　数据库在高可用方面主要由三种模式，主备模式、集群模式和MPP模式。

　　K-DB数据库的KSC组件则实现了主备模式，与HA模式相比，KSC的备份节点将同时对外提供只读查询，因此我们可以利用这一特性实现生产库与查询库的读写分离;同时由于在任何时刻主备节点都处于对外工作的状态，因此出现主节点宕机而备用节点无法正常加载的风险将减小。

　　在集群模式下，K-DB数据库采用支持传统的共享磁盘式部署模式，多节点对外提供服务，支持标准文件系统、裸设备以及分布式存储架构，从测试结果来看，KRAC的工作效率线性度相当好，因此用户在使用K-DB数据库的集群模式下，能够实现计算节点的按需扩容。

　　在之前K-DB活动体验日中，Oracle ACE总监盖国强就曾进行了破坏性测试(亲手把网线拔下来)，从前端展示的曲线图可以看到性能出现短暂波动，之后保持持续且稳定的运行，尤其值得注意的是，主机恢复后还能重新构建集群，恢复原有负载，从现场的演示看，稳定性还不错。

　　管理工具

　　异构数据库迁移代码修改量很大，而K-DB在目前绝大多数场景中，无需要修改代码。从Oracle到K-DB的迁移工作，包含数据结构的比对、SQL语句检查等，都可以由工具软件自动完成。

　　对于企业级数据库而言，完善的备份和恢复功能是保证数据安全和完整性的关键，K-DB数据库支持主流数据库全部的备份恢复模式，包括冷热备份，增量备份，Flashback，误操作恢复等，因此DBA可以完全沿用相似的备份策略对K-DB进行管理。

　　同时，K-DB提供常用的管理工具，包括SQL执行程序kdSQL，GUI管理工具kdAdmin，逻辑备份导出导入工具kdExport/import和格式化数据文件加载工具kdLoader等

▲K-APM

　　为了方便DBA对数据库进行统一的监控，K-DB提供K-APM动态监控软件，利用图形化的界面实时反馈数据库各种层面的性能，对硬件平台的监控也整合到了K-APM中。

　　客观的说，K-DB管理工具肯定不及Oracle，比如不支持SQL Developer等，这是生态体系建设问题，Oracle已经做了多年，已构建起一个庞大的生态体系。这并不是技术上的问题，K-DB可以以数据库为中心逐渐去发展更多的合作伙伴，包括第三方工具来构建生态链的，这显然不是一两天就能实现的。

　　后记

　　关于浪潮K-DB 11g数据库的技术特性就揭秘到这里，通过上面的介绍，相信大家对K-DB从技术层面有了基本的认识，当然K-DB技术特性并不仅限于此，更多特性有待探索。

　　总之，K-DB有惊喜也有遗憾，另外，有一点老鱼要强调，K-DB是专为K1量身定做的，浪潮高层明确表示，不会推出X86版K-DB数据库，这意味着除了K1小机外，别的服务器也用不上。

　　老鱼建议大家在数据库选型中，根据自身业务特点和团队的技术背景，来选择适合自己的数据库产品。再啰嗦一句，对传统行业而言，开源技术虽然能够增加灵活性，降低成本，但缺乏有效的商业支持，当在管理、支持方面遇到问题时，很多开源产品的成本就会直线上升。