Pegasus 是小米云存储团队开发的一个分布式 Key-Value 存储系统，最初的动机是弥补 HBase 在可用性和性能上的不足。Pegasus 系统的 Server 端完全采用 C++ 语言开发，使用 PacificA 协议支持强一致性，使用 RocksDB 作为单机存储引擎。
与 HBase 比较
Pegasus 系统的最初目的就是弥补 HBase 的不足，从用户使用角度比较一下两者的区别：
-
数据模型：HBase 是表格模型，采用 Range 分片；Pegasus 是 Key-Value 模型，采用 Hash 分片。
-
接口：HBase 的 API 接口功能虽然很丰富，但是使用也更复杂；Pegasus 的接口简单，对用户更友好。
-
可用度：由于架构和实现的原因，HBase 的可用度通常达到99.95%就不错了；Pegasus 的可用度可以到达99.99%。
-
性能：由于分层架构，HBase 的读写性能不是太好，P99通常在几十甚至几百毫秒级别，而且GC问题会带来毛刺问题；Pegasus 的P99可以在几毫秒，满足低延迟的在线业务需求。
与 Redis 比较
其实Pegasus是不适合与Redis比较的，Redis是基于内存的缓存系统，与之比较性能肯定被吊打。但是我们发现，业务往往需要的不仅仅是性能，可能还有可用性、伸缩性等，所以比拼综合素质，Pegasus也是有其自身的优势的。
我们在与业务的沟通中发现，他们很多时候对数据的性能和可用性要求都很高。在系统选型时遇到这些问题：
-
HBase虽然可用性高也易伸缩，但是性能不够好。
-
Redis虽然性能好，但是需要大量内存，如果数据量太大，一台机器搞不定；如果采用分布式方案，譬如Redis Cluster或者Codis，在机器宕机故障情况下的可用性又不够，并且使用内存的成本也比较高。
-
一些用户想出了HBase+Redis的方案，即使用HBase做底层存储，使用Redis做上层缓存，写数据的时候同时更新HBase和Redis，读数据的时候先从Redis中读，如果读不到再从HBase中读；但是这样的缺点是：因为涉及两个系统，用户的读写逻辑会比较复杂，且同时写两个系统时容易出现一致性问题；一份数据要存储在HBase和Redis中，成本比较高；Redis机器宕机后造成部分缓存丢失，还是要从HBase读取，性能明显降低，服务质量下降甚至降级。
Pegasus 可以看做是 HBase 和 Redis 的结合体，它即保证高的可用度，又具有好的伸缩性，还具有相对不错的性能。如果业务对性能的要求不是太变态（譬如P99要求在1毫秒以内），那么可以考虑直接使用 Pegasus 。与 Redis 进行比较区别如下：
-
数据模型：两者都是 Key-Value 模型，但是 Pegasus 支持 (HashKey + SortKey) 的二级键。
-
接口：Redis 的接口更丰富，支持 List、Set、Map 等容器特性；Pegasus 的接口相对简单，功能更单一。
-
性能：Redis 性能比 Pegasus 好不少，Redis 是在几十或者几百微妙级别，Pegasus 是在毫秒级别。
-
伸缩性：Pegasus 伸缩性更好，可以很方便地增减机器节点，并支持自动的负载均衡；Redis 的分布式方案在增减机器的时候比较麻烦，需要较多的运维介入。
-
可用性：Pegasus 数据总是持久化的，系统架构保证其较高的可用性；Redis 在机器宕机后需要较长时间恢复，可用性不够好，还可能丢掉最后一段时间的数据。
-
成本：Pegasus 使用 SSD ，Redis 主要使用内存，从成本上考虑，Pegasus 显然更划算。
评论