Posts

Showing posts from March, 2018

tldr: FaRM

Image
Part of the tldr series , which summarizes papers I'm currently reading. Inspired by the morning paper . Optimistic Concurrency Control + FaRM [2015] Dragojević et al.  Introduction Before FaRM, distributed transactions were thought of as convenient for programmers, but slow. However, FaRM guarantees 90-100 million transactions/second on 90 machines! Those transactions are replicated 3 times (by default) and persistent. What is FaRM and how did it accomplish this?  Systems often have to make tradeoffs between availability, consistency, performance, and simplicity. However, FaRM is a main memory platform for data centers that doesn't compromise on any of these because it minimizes network, storage, and CPU bottlenecks by: Assuming the whole dataset can fit in RAM, so no disk I/O Using non-volatile RAM, so no disk I/O Using a one-sided RDMA for a fast network Bypassing the OS kernel for fast network access Designing transaction and replication protocols optimized

tldr: Zookeeper

Image
Part of the tldr series , which summarizes papers I'm currently reading. Inspired by the morning paper . ZooKeeper: Wait-free coordination for Internet-scale systems (2010)  Hunt et. al Introduction ZooKeeper is a widely-used coordination service for large-scale, distributed applications developed at Yahoo!. The authors designed ZooKeeper as a coordination kernel for developers to implement their own coordination primitives. The API manipulates wait-free data objects , which makes it more high performing and fault tolerant. Additionally, the authors chose to guarantee both  FIFO client ordering of operations and linearizable writes for efficiency and usefulness to developers. The ZooKeeper service interface  Clients submit requests through the ZooKeeper API. Each method in the API has a synchronous version, for executing a single operation, and an asynchronous version, for executing tasks in parallel.  A session starts when a client connects to ZooKeeper and clien