说到高德，相信大家都不陌生，其作为全国第一家获得导航电子地图甲级测绘资质的民营企业、国内唯一拥有航空摄影甲级资质的民营企业，以及第一款全程采用明星语音导航的地图应用，拥有着过亿日活。也正因用户基数庞大，“高德地图”背后的数据存储、加密、快速检索和绝对安全格外重要。
但随着业务的发展，无论是存储成本，还是针对数据查询的性能、数据治理，都对高德提出了更高的要求。而如何让数据快速发挥出价值，带给用户最真实最实时的数据，还不会过度的浪费成本，也成为高德亟待解决的关键问题。
最后经过长时间的调研和测试对比，高德决定采用性价比极高的OceanBase来助力自己迈向新的数据时代。对此也有不少人疑惑，市场上提供的数据存储产品那么多，且各有特色，为什么高德会选择OceanBase呢？
高德其实经历了多种尝试
其实从年开始，高德就一直在做一件事，那就是去MongoDB。
过去高德有一些业务服务用的MongoDB做存储，但由于MongoDB的特性和设计特点，导致它偶尔会出现CPU占用很高，服务Pause无法正常提供服务。对于上游来说，就是会出现超时问题，如果访问量大且重试操作过多，带来的阶梯效应称得上是“毁灭级”的，服务基本会被打垮。而出现这种情况，很多时候其实并不是MongoDB本身的问题，因为它定义是分布式文档存储系统，通过Documents的方式来维护数据，理论上在关系型比较重的场景上确实不太适合。
后来高德服务相继迁移到XDB、Lindorm、ES。据悉，选择ES是因为成本低和稳定性高；选择Lindorm是因为其对于高德的异构场景、KeyValue场景和减少请求穿透到XDB的场景非常合适。
再后来就是数据库选型了。虽然OceanBase是NewSQL数据库，但是其保留了关系型数据库的特性，让高德以NewSQL的方式去管理数据，特别是在结构化数据量大的体系中，OceanBase在降本上非常具有优势。
看到这里可能大家会提出疑问：Lindorm和ES不也可以做这种存储吗？而且存储和检索都非常高效。事实上，从工具的角度来说，Lindorm和ES对高德而言都是加快检索和异构检索使用的，无法真正像关系型数据库那样去使用，往往后面都会存在一个数据库，会严重增加数据沉余和成本。
选择OceanBase的六大理由
正因为经历了上述的种种体验对比，高德最后经过权衡选择了更加合适的OceanBase：
第一，OceanBase是基于Paxos一致性协议实现的数据多副本存储(多版本并行提交)，满足多数派即可返回，最终一致性。
第二，它采用无共享的多副本架构，系统没有单点障碍，保证系统持续可用。即使单副本出现故障，也可以达到多数派可用。
第三，OceanBase是可以动态扩容的，扩容后分区表的数据会自动均衡到新节点上，对上层业务透明，节省迁移成本。
第四，OceanBase存储具有高度压缩的能力，数据可以压缩到原有数据到三分之一，对于存储量大的业务会极大降低存储成本。
第五，OceanBase作为准内存数据库，采用LSM-Tree存储引擎，增量数据操作内存，减少随机写，读写性能超传统关系型数据库，而且支持Hash和B+Tree。
第六，OceanBase也支持MySQL的协议，可以直接使用MySQL驱动访问，可以基本完全的将OceanBase当成分布式的MySQL使用。
看到这里，相信大家都已清楚高德为什么会选择与OceanBase合作了。而未来，高德也将在OceanBase的助力下，在降本和性能（涵盖AP场景）做出更大的突破。