FAQs

Frequently Asked Questions

What's the relationship between Pelikan and CCommon?

Pelikan depends on ccommon. Pelikan provides standalone binaries such as pelikan_twemcache, pelikan_slimcache that are part of a cache cluster/service. CCommon provides a library that captures many low-level functionalities common among the binaries, and may be suitable for writing high-throughput, low-latency RPC service in general.

What OSes and build environments are supported?

We usually build our binaries with gcc 4.8, largely due to Twitter's internal toolchain support. Build is often done with Clang as well, although not as consistently tested as gcc.

Each release is always tested on CentOS and Mac OS X, and we try to make sure it works on the latest Ubuntu LTS release as well.

Unfortunately, the code base does not work on Solaris or Windows. We welcome community contribution to port the project to other OSes and will happily accept pull requests.

How does Pelikan cache compare to memcached/redis/...?

We envision Pelikan to have significant overlap, in terms of functionality, with many popular cache server implementations. After all, we are aiming to replace our use of Memcached (Twemcache) and Redis at Twitter with Pelikan. However, Pelikan is not a strict superset or subset of any of them. Without trying to be comprehensive, here are some notable similarities and differences:

• pelikan_twemcache fully replaces twemcache, and supports most of the commands specified by the memcached ASCII/text protocol. However, unlike memcached, pelikan_twemcache only has one worker thread per instance.
• pelikan_redis (in progress) will support a subset of data structures provided by Redis. However, we have no plan to add features such as master/slave replication, message queue, or on-disk data persistence. We also will manage memory using slabs/items instead of directly relying on external memory allocators.
• All binaries come with the ability to log each command for traffic analysis, which are not part of Memcached or Redis.
• pelikan_slimcache implements cuckoo hashing to store bounded-sized key/value pairs with minimum (~6-byte) overhead.
• Pelikan enforces the separation of data-plane and control-plane functionalities by using separate threads; further more, server and worker run on different threads as well, and there are no locks anywhere in our system.