Scaling Memcache at Facebook

By R. Nishtala, Hans Fugal, S. Grimm, Marc Kwiatkowski, Herman Lee, Harry C. Li, Ryan McElroy, Mike Paleczny, Daniel Peek, Paul Saab and 3 more. Symposium on Networked Systems Design and Implementation, 2013

970 citations recorded by the source corpus.

View Paper: https://www.semanticscholar.org/paper/28f13ebe8e17fdb4c2500c515759a3ee0c2783ce

How researchers see this paper

The researchers whose trusted networks rank it highest, strongest advocate first. Every researcher gets a different order.

Citations in the corpus

f4: Facebook's Warm BLOB Storage System (2014, background): “The importance of simplicity in the design of a system for keeping its deployment stable crops up in many systems within Facebook [41] and was reinforced by our experience with f4.”
IX: A Protected Dataplane Operating System for High Throughput and Low Latency (2014, background): “As requests between service tiers of datacenter applications often consist of small packets, common NIC hardware optimizations, such as TCP segmentation and receive side coalescing, have a marginal impact on packet rate.”
WiscKey (2016, background): “Many proposed techniques seek to overcome the scalability bottlenecks of in-memory key-value stores, such as Masstree [Mao et al. 2012], MemC3 [Fan et al. 2013], Mem-cache [Nishtala et al. 2013], MICA [Lim et al. 2014], and cLSM [Golan-Gueta et al. 2015].”
FaRM: Fast Remote Memory (2014, unknown): “A cluster with one hundred machines can hold tens of terabytes of main memory, which is sufficient to store all the data for many applications or at least to cache the applications' working sets [11] [38] [39].”
In-Memory Big Data Management and Processing: A Survey (2015, background): “Twitter adopts similar optimizations on its distributed version of Memcached, called Twemcache.”
Gorilla: A Fast, Scalable, In-Memory Time Series Database (2015, methodology): “We also considered a separate Memcache [20] based write-through cache but rejected it as appending new data to an existing time series would require a read/write cycle, causing extremely high traﬃc to the memcache server.”
Using RDMA efficiently for key-value services (2014, methodology): “Therefore, our design, similar to choices made by Facebook and others [22], sacrifices transport-level retransmission for fast common case performance at the cost of rare application-level retries.”
Twine: A Unified Cluster Management System for Shared Infrastructure (2020, methodology): “We deploy a highly optimized version of memcache [30] on tens of thousands of machines.”
Decentralized task-aware scheduling for data center networks (2014, background): “This has even been observed in production data centers (e.g., Bing [4, 18], Cosmos [7], Facebook [22]) which typically have modest average data center utilization.”
Homa: a receiver-driven low-latency transport protocol using network priorities (2018, background): “esssage has a dedicated connection. However, this approach results in an explosionofconnectionstate. Evenasingleconnectionfor each application-server pair is problematic for large-scale applications ([22] x3.1, [11] x3.1), so it is probably not realistic to use multiple connections. No setup phase o”
TAO: Facebook's Distributed Data Store for the Social Graph (2013, methodology): “TAO and memcache share most of the client stack described by Nishtala et al. [21].”
Fastpass (2014, background): “Current solutions are approximations of full control, based on estimates and assumptions about request RTTs, and solve the problem only partially [28, 37].”
CockroachDB: The Resilient Geo-Distributed SQL Database (2020, background): “Over the years, many systems with reduced consistency levels have been proposed with the goal of overcoming the scalability challenges of traditional relational database systems [5, 15, 19, 32, 35, 44, 61, 64, 71].”
Design Guidelines for High Performance RDMA Systems (2016, background): “Note that the header overhead of 20–26 bytes is comparable to the common size of data items used in services such as memcached [25] and RPCs [15].”
IncBricks: Toward In-Network Computation with an In-Network Cache (2017, methodology): “Based on previous studies [15, 40], the workload is conﬁg-ured with (1) a Zipﬁan distribution [3] of skewness 0.99; (2) 95%/5% read/write ratio; (3) 1 million keys with 1024B value size; (4) two deployments: within-cluster and cross-cluster.”