OpenAtom Pika 来了！

Pika 是一个基于硬盘存储、完全兼容 Redis 协议、解决 Redis 由于存储数据量巨大而导致内存容量瓶颈的 KV 数据库。由奇虎360 基础架构组和 DBA 联合开发，秉承共享开放的开源精神，项目组 2016年前后便将 Pika 源代码在 Github上进行了开源，项目也得到了多家互联网厂商的青睐并应用在了生产环境中。近期，360 正式将 Pika 捐赠给了国内以开源为主题的非营利性组织——开放原子开源基金会（以下简称开源基金会），为确保社区的延续性，项目名称定为 OpenAtom Pika （以下简称Pika ），接下来将继续投入相关的开发资源以及共同激活开发者社区，以推动中国 KV 数据库的开源生态发展。

Pika 开源至今，吸引了数以千计的开发者，包括新浪、快手、斗鱼, 喜马拉雅，学而思网校, 货拉拉等互联网头部企业均基于此，输出了成功的应用案例。单个部署支撑了数十亿数据的快速存取。

为存储降本而研发——“360 做了从0到1的突破”

大多开源项目的诞生，最初都指向了解决商业问题的现实诉求，Pika 亦是如此。Pika 的研发初衷之一，就是为了节省 360公司高昂的数据存储成本。

对于 360 这类技术型互联网企业而言，随着业务量的不断发展扩张，其对于 Redis 速查 KV 缓存型数据库需求越来越高。但高内存同样意味着将面临系统启动恢复时间长、一主多从代价大、以及硬件成本过贵等问题。

基于这一难题，360 DBA 和基础架构组便在硬盘存储的完全兼容Redis协议之上，联合开发了这款 Pika 系统。360 技术人员表示，Pika在提供和Redis一样的存储接口的前提下，不仅可以实现将数据存在磁盘上的持久化存储，其还可以像Redis一样主从备份，支持全同步和增量同步。

基于以上核心优势，5年多来，360现已有2000+的主从实例以及近10套基于 codis 的pika 集群在运行，覆盖公司80%以上业务, 其中便包括C端用户十分熟悉的360安全浏览器、360搜索、360安全云盘和花椒直播等。

有业内人士评价，Pika 极大减少服务器资源的占用，增强了数据的可靠性。对于类 Redis 存储，Pika 项目做了从0到1的突破。

Pika 加入开放原子开源基金会

在加入开放原子开源基金会后, Pika 希望能够有更多的开发者进来参与到项目中，并将近几年实际使用中发现的行业趋势、技术瓶颈、基础突破进行规划、管理，有效的促进项目更快的发展，力争成为全球化的KV数据库项目标杆。

在应用场景上, 企业上云、应用云原生是大势所趋。Pika 目前的设计是针对本地 SSD 做优化的设计。 但是随着企业的上云, 存储计算分离的架构会在两三年内成为标准，目前可以看到很多云厂商的数据库产品已经在这条道路上演进。那么随着云原生的发展, Pika 也需要在这个赛道成为核心的基础设施架构。

针对云盘存储的使用场景，社区需要考虑针对云厂商上的云存储进行优化。目前已经有不少的用户将Pika 跑在云盘上, 云盘相对于本地盘提供了更大的磁盘空间和更低的存储成本, 但是与之带来相应的缺点是云盘的延迟和吞吐均不如本地盘。 很多本地盘的特性比如顺序写高于随机写的能力在云存储上也不存在,那么在这种场景下Pika 如何去针对云存储进行优化设计会成为下一阶段的研发重点。

在计算存储分离的趋势下, Pika 的主备结构其实可以基于共享存储做一写多读的架构, 那么这样可以进一步减少存储成本, 原本 Pika 的主备模式在磁盘空间上需要2个副本, 但是基于云存储的一写多读架构, 只读节点就可以不需要自己的存储, 按需从底层的共享存储去获得需要的数据即可。这种存储与计算分离的架构一方面解决了单机pika数据库存储容量受限的核心痛点，基于云原生的基础设施能够独立弹性扩缩计算与存储节点，另一方面也规避了基于hash进行数据分片的分布式架构引入的无法全局scan、处理事务问题复杂的痛点。这个也是目前数据库解决读扩展问题的重要演进方向。

在加入开放原子开源基金会以后, 360 还继续保持开放、共建的原则继续提供为 Pika 开源生态贡献力量, 并与基金会共同发起了 Make Pika Great Again 的社区激活计划，与新浪、快手、斗鱼、喜马拉雅、学而思网校、货拉拉等企业以及优秀的个人 DBA 开发者，共同将项目的未来开发计划、优化框架、社区治理做好规划，打造国际标杆型的 KV 数据库。也欢迎各位开发者积极参与社区。

请感兴趣的朋友点击左下角“原文链接”，或扫描下方二维码，关注 “Pika开源社区” 官方微信公众号，了解更多关于Pika项目信息~