FAWN: A Fast Array of Wimpy Nodes
Paper ID: 188 (14 pages)
Abstract The power draw of these clusters is becoming an in-
creasing fraction of their cost—-up to 50% of the three-
This paper presents a new cluster architecture for low- year total cost of owning a computer. The density of the
power data-intensive computing. FAWN couples low- data centers that house them is in turn limited by their
power embedded CPUs to small amounts of local ﬂash ability to supply and cool 10–20 kW of power per rack
storage, and balances computation and I/O capabilities to and up to 10–20 MW per datacenter . Future data
enable efﬁcient, massively parallel access to data. centers may require as much as 200 MW , and data
The key contributions of this paper are the principles of centers are being constructed today with dedicated elec-
the FAWN architecture and the design and implemen- trical substations to feed them.
tation of FAWN-KV—a consistent, replicated, highly These challenges necessitate the question: Can we
available, and high-performance key-value storage system build a cost-effective cluster for data-intensive workloads
built on a FAWN prototype. Our design centers around that uses less than a tenth of the power required by a
purely log-structured datastores that provide the basis for conventional architecture, but that still meets the same
high performance on ﬂash storage, as well as for replica- size, availability, throughput, and latency requirements?
tion and consistency obtained using chain replication on a In this paper, we present the FAWN architecture—a
consistent hashing ring. Our evaluation demonstrates that Fast Array of Wimpy Nodes—that is designed to address
FAWN clusters can handle roughly 400 key-value queries this question. FAWN couples low-power, efﬁcient embed-
per joule of energy—two orders of magnitude more than ded CPUs with ﬂash storage to provide efﬁcient, fast, and
a disk-based system. cost-effective access to large, random-access data. Flash
is signiﬁcantly faster than disk, much cheaper than the
1 Introduction equivalent amount of DRAM, and consumes less power
Large-scale data-intensive applications, such as high- than both. Thus, it is a particularly suitable choice for
performance key-value storage systems are growing FAWN and its workloads. FAWN creates a well-matched
in both size and importance; they now are critical system architecture around ﬂash: each node can use the
parts of major Internet services such as Amazon (Dy- full capacity of the ﬂash without memory or bus bottle-
namo ), LinkedIn (“Voldemort” ), and Facebook necks, but does not waste excess power.
(memcached ). To show that it is practical to use these constrained
The workloads these systems support share several nodes as the core of a large system, we have designed
characteristics: they are I/O, not computation, intensive, and built the FAWN-KV cluster-based key-value store,
requiring random access over large datasets; they are which provides storage functionality similar to that used
massively parallel, with thousands of concurrent, mostly- in several large enterprises [9, 29, 23]. FAWN-KV is de-
independent operations; their high load requires large signed speciﬁcally with the FAWN hardware in mind, and
clusters to support them; and the size of objects stored are is able to exploit the advantages and avoid the limitations
typically small, e.g. 1 KB values for thumbnail images, of wimpy nodes with ﬂash memory for storage.
100s of bytes for wall posts, twitter messages, etc. The key design choice in FAWN-KV is the use of a
The clusters that serve these workloads must provide log-structured per-node data store called FAWN-DS that
both high performance and low cost operation. Unfortu- provides high performance reads and writes using ﬂash
nately, small random-access workloads are particularly memory. This append-only data log provides the basis
ill-served by conventional disk-based or memory-based for replication and strong consistency using chain replica-
clusters. The poor seek performance of disks makes disk- tion  between nodes. Data is distributed across nodes
based systems inefﬁcient in terms of both system per- using consistent hashing, with data split into contiguous
formance and performance per watt. High performance ranges on disk such that all replication and node insertion
DRAM-based clusters, storing terabytes or petabytes of operations involve only a fully in-order traversal of the
data, are both expensive and consume a surprising amount subset of data that must be copied to a new node. Together
of power—two 2 GB DIMMs consume as much energy with the log structure, these properties combine to pro-
as a 1 TB disk. vide fast failover on node insertion, and they minimize the
time the database is locked during such operations—for a the frequency.
single node failure and recovery, the database is blocked Worse yet, running fast processors below their full
for at most 100 milliseconds. capacity draws a disproportionate amount of power:
We have built a prototype 21-node FAWN cluster using
Dynamic power scaling on traditional systems is sur-
500 MHz embedded CPUs. Each node can serve up to
prisingly inefﬁcient. A primary energy-saving beneﬁt
1700 256 byte queries per second, exploiting nearly all of
of dynamic voltage and frequency scaling (DVFS) was
the raw I/O capability of their attached ﬂash devices, and
its ability to reduce voltage as it reduced frequency ,
consumes under 5 W when network and support hardware
but modern CPUs already operate near minimum voltage
is taken into account. The FAWN cluster achieves 364
at the highest frequencies. In addition, transistor leakage
queries per second per Watt—two orders of magnitude
currents quickly become a dominant power cost as the
better than traditional disk-based clusters.
frequency is reduced .
In Section 5, we compare a FAWN-based approach
Even if processor energy was completely proportional
to other architectures, ﬁnding that the FAWN approach
to load, non-CPU components such as memory, moth-
provides signiﬁcantly lower total cost and power for a
erboards, and power supplies have begun to dominate
signiﬁcant set of large, high-query-rate applications.
energy consumption , requiring that all components
2 Why FAWN? be scaled back with demand. As a result, running a sys-
tem at 20% of its capacity may still consume over 50%
The FAWN approach to building well-matched cluster of its peak power . Despite improved power scaling
systems has the potential to achieve high performance technology, systems remain most power-efﬁcient when
and be fundamentally more power-efﬁcient than conven- operating at peak power.
tional architectures for serving massive-scale I/O and data- A promising path to energy proportionality is turning
intensive workloads. We measure system performance machines off entirely . Unfortunately, these techniques
in queries per second and measure power-efﬁciency in do not apply well to our workloads: key-value systems
queries per Joule (equivalently, queries per second per must often meet service-level agreements for query re-
Watt). FAWN is inspired by several fundamental trends: sponse throughput and latency of hundreds of millisec-
Increasing CPU-I/O Gap: Over the last several onds; the inter-arrival time and latency bounds of the re-
decades, the gap between CPU performance and I/O band- quests prevents shutting machines down (and taking many
width has continually grown. For data-intensive comput- seconds to wake them up again) during low load .
ing workloads, storage, network, and memory bandwidth Finally, energy proportionality alone is not a panacea:
bottlenecks often cause low CPU utilization. systems ideally should be both proportional and efﬁcient
FAWN Approach: To efﬁciently run I/O-bound data- at 100% load. In this paper, we show that there is signiﬁ-
intensive, computationally simple applications, FAWN cant room to improve energy efﬁciency, and the FAWN
uses wimpy processors selected to reduce I/O-induced approach provides a simple way to do so.
idle cycles while maintaining high performance. The re-
duced processor speed then beneﬁts from a second trend: 3 Design and Implementation
CPU power consumption grows super-linearly with We describe the design and implementation of the sys-
speed. Techniques to mask the CPU-memory bottle- tem components from the bottom up: a brief overview
neck come at the cost of energy efﬁciency. Branch pre- of ﬂash storage (Section 3.2), the per-node FAWN-DS
diction, speculative execution, and increasing the amount data store (Section 3.3), and the FAWN-KV cluster key-
of on-chip caching all require additional processor die value lookup system (Section 3.4.1), including caching,
area; modern processors dedicate as much as half their replication, and consistency.
die to L2/3 caches . These techniques do not increase
the speed of basic computations, but do increase power
3.1 Design Overview
consumption, making faster CPUs less energy efﬁcient. Figure 1 gives an overview of the entire FAWN system.
FAWN Approach: A FAWN cluster’s slower CPUs ded- Client requests enter the system at one of several front-
icate more transistors to basic operations. These CPUs ends. The front-end nodes forward the request to the
execute signiﬁcantly more instructions per joule than their back-end FAWN-KV node responsible for serving that
faster counterparts: multi-GHz superscalar quad-core pro- particular key. The back-end node serves the request from
cessors can execute 100 million instructions per joule, its FAWN-DS data store and returns the result to the front-
assuming all cores are active and avoid stalls or mispre- end (which in turn replies to the client). Writes proceed
dictions. Lower-frequency single-issue CPUs, in contrast, similarly.
can provide over 1 billion instructions per joule—an order The large number of back-end FAWN-KV storage
of magnitude more efﬁcient while still running at 1/3rd nodes are organized into a ring using consistent hash-
table that supports store, lookup, and delete.1
FAWN-DS is designed speciﬁcally to perform well on
1 ﬂash storage: all writes to the data store are sequential,
and reads require a single random access. To provide
this property, FAWN-DS maintains an in-memory hash
Front-end table (Hash Index) that maps keys to an offset in the
1 append-only Data Log on the ﬂash (Figure 2a). This
2 1 log-structured design is similar to several append-only
Responses ﬁlesystems [30, 13], which avoid random seeks on mag-
netic disks for writes.
Figure 1: FAWN-KV Architecture.
Mapping a Key to a Value. Each FAWN-DS vnode
uses its in-memory Hash Index to map 160-bit keys to a
ing. As in systems such as Chord , keys are mapped value in the Data Log. The maximum number of entries
to the node that follows the key in the ring (its successor). in the hash index limits the number of key-value pairs
To balance load and reduce failover times, each physical the node can store. Limited memory on the FAWN nodes
node joins the ring as a small number (V ) of virtual nodes is therefore precious. FAWN-DS conserves memory by
(“vnodes”). Each physical node is thus responsible for V allowing the Hash Index to infrequently be wrong, requir-
different (non-contiguous) key ranges. The data for each ing another (relatively fast) random read from ﬂash to ﬁnd
virtual node is stored using FAWN-DS. the correct entry.
To map a key using the Hash Index, FAWN-DS extracts
3.2 Understanding Flash Storage two ﬁelds from the 160-bit key: the i low order bits of the
Flash provides a non-volatile memory store with several key (the index bits) and the next 15 low order bits (the key
signiﬁcant beneﬁts over typical magnetic hard disks for fragment). FAWN-DS uses the index bits to index into the
random-access, read-intensive workloads—but it also in- Hash Index, which contains 2i hash buckets. Each bucket
troduces several challenges. These characteristics of ﬂash in the Hash Index is six bytes: a 15-bit key fragment, a
underlie the design of the FAWN-KV system described valid bit, and a 4-byte pointer to the corresponding value
throughout this section: stored in the Data Log.
After locating a bucket using the index bits, FAWN-DS
1. Fast random reads: ( 1 ms), up to 175 times compares the key fragment from the key to that stored
faster than random reads on magnetic disk [24, 28]. in the hash bucket. If the key fragments do not match,
2. Low power consumption: Flash devices consume FAWN-DS uses standard hash chaining to pick another
less than one watt even under heavy load, whereas bucket. If the fragments do match, FAWN-DS reads the
mechanical disks can consume over 10 W at load. data entry from the Data Log. This in-memory compari-
3. Slow random writes: Small writes on ﬂash are very son helps avoid incurring multiple accesses to ﬂash for a
expensive. Updating a single page requires ﬁrst eras- single key lookup without storing the full key in memory:
ing an entire erase block (128 KB–256 KB) of pages, There is a 1 in 215 chance of a collision in which the bits
and then writing the modiﬁed page in its entirety. As match for different entries.
a result, updating a single byte of data is as expensive Each entry in the Data Log contains the full key, data
as writing an entire block of pages . length, and a variable-length data blob. Upon retrieving
the entry, FAWN-DS compares the full 160-bit key to
Modern devices improve random write performance the one in the entry. If they do not match (a collision),
using write buffering and preemptive block erasure. These FAWN-DS continues chaining through the Hash Index
techniques improve performance for short bursts of writes, until it locates the correct value.
but recent studies show that sustained random writes still
Reconstruction. Using this design, the Data Log con-
perform poorly on these devices .
tains all the information necessary to reconstruct the hash
These performance problems motivate log-structured
index from scratch. As an optimization, FAWN-DS check-
techniques for ﬂash ﬁlesystems and data structures [25,
points the hash index by periodically writing it to ﬂash.
26, 17]. These same considerations inform the design
The checkpoint includes the Hash Index plus a pointer
of FAWN’s node storage management system, described
to the last log entry. After a failure, FAWN-DS uses
the checkpoint as a starting point to reconstruct the in-
3.3 The FAWN Data Store memory Hash Index quickly.
FAWN-DS is a log-structured key-value store that runs on 1 We differentiate data store from database to emphasize that we do
each virtual node. It acts to clients like a disk-based hash not provide a transactional or relational interface.
160-bit Key Log Entry Datastore List Data in original range Datastore List Atomic Update
Data in new range
Key Len Data of Datastore List
In-memory Scan and Split
Hash Index Data Log
KeyFrag Valid Offset are appended
(a) (b) (c)
Figure 2: (a) FAWN-DS appends writes to the end of the data region. (b) Split requires a sequential scan of the
data region, transferring out-of-range entries to the new store. (c) After scan is complete, the data store list is
atomically updated to add the new store. Compaction of the original store will clean up out-of-range entries.
Vnodes and Semi-random Writes. Each virtual node periodically Compact a data store to clean up stale or or-
in the FAWN-KV ring has a single FAWN-DS ﬁle that phaned entries created by Split, Store, and Delete.
contains the data for that vnode’s hash range. A physical The design of FAWN-DS ensures that these mainte-
node therefore has a separate data store ﬁle for each of nance functions work well on ﬂash, requiring only scans
its virtual nodes, and FAWN-DS appends new or updated of one data store and sequential writes into another. We
data items to the appropriate data store. Sequentially ap- brieﬂy discuss each operation in turn.
pending to a small number of ﬁles is termed semi-random Split parses the data log entries sequentially, writing
writes. Prior work by Nath and Gibbons observed that the entry in a new data store if its key falls in the new
with many ﬂash devices, these semi-random writes are data store’s range. Merge writes every log entry from
nearly as fast as a single sequential append . We take one data store into the other data store; because the key
advantage of this property to retain fast write performance ranges are independent, it does so as an append. Split and
while allowing key ranges to be stored in independent ﬁles Merge propagate delete entries into the new data store.
to speed the maintenance operations described below. We
show in Section 4 that these semi-random writes perform Compact cleans up entries in a data store, similar to
sufﬁciently well. garbage collection in a log-structured ﬁlesystem. It skips
entries that fall outside of the data store’s key range, which
3.3.1 Basic functions: Store, Lookup, Delete may be left-over after a split. It also skips orphaned entries
that no in-memory hash table entry points to, and then
Store appends an entry to the log, updates the corre-
skips any delete entries corresponding to those entries. It
sponding hash table entry to point to this offset within the
writes all other valid entries into the output data store.
data log, and sets the valid bit to true. If the key written
already existed, the old value is now orphaned (no hash 3.3.3 Concurrent Maintenance and Operation
entry points to it) for later garbage collection.
Lookup retrieves the hash entry containing the offset, All FAWN-DS maintenance functions allow concurrent
indexes into the data log, and returns the data blob. read and write access to the data store. Stores and
Delete invalidates the hash entry corresponding to deletes only modify hash table entries and write to the
the key by clearing the valid ﬂag and writing a Delete en- end of the log.
try to the end of the data ﬁle. The delete entry is necessary The maintenance operations (Split, Merge, and
for fault-tolerance—the invalidated hash table entry is not Compact) sequentially parse the data log, which may
immediately committed to non-volatile storage to avoid be growing due to deletes and stores. Because the log
random writes, so a failure following a delete requires is append-only, a log entry once parsed will never be
a log to ensure that recovery will delete the entry upon changed. These operations each create one new output
reconstruction. data store logﬁle. The maintenance operations therefore
run until they reach the end of the log, and then brieﬂy
3.3.2 Maintenance: Split, Merge, Compact
lock the data store, ensure that all values ﬂushed to the
Inserting a new vnode into the ring causes one key range old log have been processed, update the FAWN-DS data
to split into two, with the new vnode taking responsibility store list to point to the newly created log, and release the
for the ﬁrst half of it. A vnode must therefore Split lock (Figure 2c). The lock must be held while writing
its data store into two ﬁles, one for each range. When in-ﬂight appends to the log and updating data store list
a vnode departs, two adjacent key ranges must similarly pointers, which typically takes 20–30 ms at the end of a
be Merged into a single ﬁle. In addition, a vnode must Split or Merge (Section 4.3).
Figure 3: FAWN-KV Interfaces – Front-ends manage
back-ends, route requests, and cache responses. Back-
ends use FAWN-DS to store key-value pairs.
3.4 The FAWN Key-Value System Figure 4: Consistent Hashing with 5 physical nodes
Figure 3 depicts FAWN-KV request processing. Client and 2 virtual nodes each.
applications send requests to front-ends using a standard
put/get interface. Front-ends send the request to the back- When a back-end node joins, it obtains the list of front-
end vnode that owns the key space for the request. The end IDs. Each of its virtual nodes uses this list to deter-
back-end vnode satisﬁes the request using its FAWN-DS mine which front-end to contact to join the ring, one at a
and replies to the front-ends. time. We chose this design so that the system was robust
In a basic FAWN implementation, clients link against a to front-end node failures: The back-end node identiﬁer
front-end library and send requests using a local API. (and thus, what keys it are responsible for) is a deter-
Extending the front-end protocol over the network is ministic function of the back-end node ID. If a front-end
straightforward—for example, we have developed a drop- node fails, data does not move between back-end vnodes,
in replacement for the memcached distributed memory though vnodes may have to attach to a new front-end.
cache that enables a collection of FAWN nodes to appear The FAWN-KV ring uses a 160-bit circular ID space
as a single, robust memcached server. for vnodes and keys. Vnode IDs are the hash of the con-
3.4.1 Consistent Hashing: Key Ranges to Nodes catenation of the (node IP address, vnode number). Each
vnode owns the items for which it is the item’s successor
A typical FAWN cluster will have several front-ends and
in the ring space (the node immediately clockwise in the
many back-ends. FAWN-KV organizes the back-end vn-
ring). As an example, consider the cluster depicted in
odes into a storage ring-structure using consistent hash-
Figure 4 with ﬁve physical nodes, each of which has two
ing, similar to the Chord DHT . FAWN-KV does not
vnodes. The physical node A appears as vnodes A1 and
use DHT routing—instead, front-ends maintain the entire
A2, each with its own 160-bit identiﬁers. Vnode A1 owns
node membership list and directly forward queries to the
key range R1, vnode B1 owns range R2, and so on.
back-end node that contains a particular data item.
Consistent hashing provides incremental scalability
Each front-end node manages the vnode membership
without global data movement: adding a new vnode
list and queries for a large contiguous chunk of the key
moves keys only at the successor of the vnode being
space (in other words, the circular key space is divided
added. We discuss below (Section 3.4.4) how FAWN-KV
into pie-wedges, each owned by a front-end). A front-end
uses the single-pass, sequential Split and Merge oper-
receiving queries for keys outside of its range forwards
ations in FAWN-DS to handle such changes efﬁciently.
the queries to the appropriate front-end node. This design
either requires clients to be roughly aware of the front- 3.4.2 Caching Prevents Wimpy Hot-Spots
end mapping, or doubles the trafﬁc that front-ends must FAWN-KV caches data using a two-level cache hierarchy.
handle, but it permits front ends to cache values without a Back-end nodes implicitly cache recently accessed data
cache consistency protocol. in their ﬁlesystem buffer cache. While our current nodes
The key space is allocated to front-ends by a single (Section 4) can serve about 1700 queries/sec from ﬂash,
management node; we envision this node being repli- they serve 55,000 per second if the working set ﬁts com-
cated using a small Paxos cluster , but we have not pletely in buffer cache. The FAWN front-end maintains a
(yet) implemented this. Because there are typically 80 small, high-speed query cache that helps reduce latency
or more back-end nodes per front-end node, the amount and ensures that if the load becomes skewed to only one
of information this management node maintains is small or a few keys, those keys are served by a fast cache instead
and changes infrequently—a list of 125 front-ends would of all hitting a single back-end node.
sufﬁce for a 10,000 node FAWN cluster.2
2 We do not use consistent hashing to determine this mapping because
the number of front-end nodes may be too small to achieve good load FAWN-KV offers a conﬁgurable replication factor for
balance. fault tolerance. Items are stored at their successor in the
Figure 6: Lifecycle of a put with chain replication—
Figure 5: Overlapping Chains in the Ring – Each puts go to the head and are propagated through the
node in the consistent hashing ring is part of R = 3 chain. Gets go directly to the tail.
2. The new vnode must receive a copy of the R ranges
ring space and at the R−1 following virtual nodes. FAWN of data it should now hold, one as a primary and
uses chain replication  to provide strong consistency R − 1 as a replica.
on a per-key basis. Updates are sent to the head of the 3. The front-end must begin treating the new vnode
chain, passed along to each member of the chain via a as a head or tail for requests in the appropriate key
TCP connection between the nodes, and queries are sent ranges.
to the tail of the chain. By mapping the chain replication 4. Vnodes down the chain may free space used by key
to the consistent hashing ring, each virtual node in FAWN- ranges they are no longer responsible for.
KV is part of R different chains: it is the “tail” for one
chain, a “mid” node in R − 2 chains, and the “head” for The ﬁrst step, key range splitting, occurs as described
one. Figure 5 depicts a ring with six physical nodes, where for FAWN-DS. While this operation actually occurs con-
each has two virtual nodes (V = 2), using a replication currently with the rest (the split and data transmission
factor of three. In this ﬁgure, node C1 is thus the tail for overlap), for clarity, we describe the rest of this process
range R1, mid for range R2, and tail for range R3. as if the split had already taken place.
Figure 6 shows a put request for an item in range R1. After the key ranges have been split appropriately, the
The front-end routes the put to the key’s successor, vnode node must become a working member of R chains. For
A1, which is the head of the replica chain for this range. each of these chains, the node must receive a consistent
After storing the value in its data store, A1 forwards this copy of the data store ﬁle corresponding to the key range.
request to B1, which similarly stores the value and for- The process below does so with minimal locking and en-
wards the request to the tail, C1. After storing the value, sures that if the node fails during the data copy operation,
C1 sends the put response back to the front-end, and sends the existing replicas are unaffected. We illustrate this
an acknowledgment back up the chain indicating that the process in detail in Figure 7 where node C1 joins as a new
response was handled properly. middle replica for range R2.
For reliability, nodes buffer put requests until they re-
ceive the acknowledgment. Because puts are written to
an append-only log in FAWN-DS and are sent in-order
along the chain, this operation is simple: nodes maintain
a pointer to the last unacknowledged put in their data
store, and increment it when they receive an acknowledg-
ment. By using a purely log structured data store, chain
replication with FAWN-KV becomes simply a process of
streaming the growing dataﬁle from node to node.
Gets proceed as in chain replication—the front-end
directly routes the get to the tail of the chain for range R1, Figure 7: Phases of join protocol on node arrival.
node C1, which responds to the request. Chain replication
ensures that any update seen by the tail has also been Phase 1: data store pre-copy. Before any ring mem-
applied by other replicas in the chain. bership changes occur, the current tail for the range (vn-
3.4.4 Joins and Leaves ode E1) begins sending the new node C1 a copy of
When a node joins a FAWN-KV ring: the data store log ﬁle. This operation is the most time-
consuming part of the join, potentially requiring hundreds
1. The new vnode causes one key range to split into of seconds. At the end of this phase, C1 has a copy of the
two. log that contains all records committed to the tail.
Phase 2: Chain insertion, inconsistent. Next, as work. In addition to assuming fail-stop, we assume that
shown in Figure 7, the front-end tells the head node B1 the dominant failure mode is a node failure or the failure
to point to the new node C1 as its successor. B1 immedi- of a link or switch, but our current design does not cope
ately begins streaming updates to C1, and C1 relays them with a communication failure that prevents one node in
properly to D1. D1 becomes the new tail of the chain. a chain from communicating with the next while leaving
At this point, B1 and D1 have correct, consistent views each able to communicate with the front-ends. We plan to
of the data store, but C1 may not: A small amount of time augment the heartbeat exchange to allow vnodes to report
passed between the time that the pre-copy ﬁnished and their neighbor connectivity.
when C1 was inserted into the chain.
To cope with this, C1 logs updates from B1 in a tem- 4 Evaluation
porary data store, not the actual data store ﬁle for range We begin by characterizing the I/O performance of a
R2, and does not update its in-memory hash table. During wimpy node. From this baseline, we then evaluate how
this phase, C1 is not yet a valid replica. well FAWN-DS performs on this same node, ﬁnding that
Phase 3: Log ﬂush and play-forward. After it was its performance is similar to the node’s baseline I/O capa-
inserted in the chain, C1 requests any entries that might bility. To further illustrate the advantages of FAWN-DS’s
have arrived in the time after it received the log copy and design, we compare its performance to an implementa-
before it was inserted in the chain. The old tail E1 pushes tion using the general-purpose Berkeley DB, which is not
these entries to C1, who adds them to the R2 data store. optimized for ﬂash writes.
At the end of this process, C1 then merges (appends) the After characterizing individual node performance, we
temporary log to the end of the R2 data store, updating then study a prototype FAWN-KV system running on a 21
its in-memory hash table as it does so. The node locks node cluster. We evaluate its power efﬁciency, in queries
the temporary log at the end of the merge for 20–30ms to per second per watt, and then measure the performance
ﬂush in-ﬂight writes. effects of node failures and arrivals. In the following
After phase 3, C1 is a functioning member of the chain section, we then compare FAWN to a more traditional
with a fully consistent copy of the data store. This process datacenter architecture designed to store the same amount
occurs R times for the new virtual node—e.g., if R = 3, of data and meet the same query rates.
it must join as a new head, a new mid, and a new tail for
one chain. Evaluation Hardware: Our FAWN cluster has 21
Joining as a head or tail: In contrast to joining as a back-end nodes built from commodity PCEngine Alix 3c2
middle node, joining as a head or tail must be coordinated devices, commonly used for thin-clients, kiosks, network
with the front-end to properly direct requests to the vnode. ﬁrewalls, wireless routers, and other embedded applica-
The process for a new head is identical to that of a new tions. These devices have a single-core 500 MHz AMD
mid. To join as a tail, a node joins before the current Geode LX processor with 256 MB DDR SDRAM oper-
tail and replies to put requests. It does not serve get ating at 400 MHz, and 100 Mbit/s Ethernet. Each node
requests until it is consistent (end of phase 3)—instead, contains one 4 GB Sandisk Extreme IV CompactFlash
its predecessor serves as an interim tail for gets. device. A node consumes 3 W when idle and a maximum
of 6 W when deliberately using 100% CPU, network and
Leave: The effects of a voluntary or involuntary ﬂash. The nodes are connected to each other and to a 40 W
(failure-triggered) leave are similar to those of a join, Atom-based front-end node using two 16-port Netgear
except that the replicas must merge the key range that the GS116 GigE Ethernet switches.
node owned. As above, the nodes must add a new replica
Evaluation Workload: FAWN-KV targets read-
into each of the R chains that the departing node was a
intensive, small object workloads for which key-value
member of. This replica addition is simply a join by a
systems are often used. The exact object sizes are, of
new node, and is handled as above.
course, application dependent. In our evaluation, we
Failure Detection: Nodes are assumed to be fail-stop show query performance for 256 byte and 1 KB values.
. Each front-end exchanges heartbeat messages with We select these sizes as proxies for small text posts,
its back-end vnodes every thb seconds. If a node misses user reviews or status messages, image thumbnails, and
f dthreshold heartbeats, the front-end considers it to have so on. They represent a quite challenging regime for
failed and initiates the leave protocol. Because the Join conventional disk-bound systems, and stress the limited
protocol does not insert a node into the chain until the memory and CPU of our wimpy nodes.
majority of log data has been transferred to it, a failure
during join results only in an additional period of slow- 4.1 Individual Node Performance
down, not a loss of redundancy. We benchmark the I/O capability of the FAWN nodes
We leave certain aspects of failure detection for future using iozone  and Flexible I/O tester . The ﬂash
Seq. Read Rand Read Seq. Write Rand. Write 60
28.5 MB/s 1872 QPS 24 MB/s 110 QPS MTron Mobi
Table 1: Baseline CompactFlash statistics for 1 KB
Write Speed in MB/s
entries. QPS = Queries/second. 40
DS Size 1 KB Rand Read 256 B Rand Read 30 Intel X25-M
(in queries/sec) (in queries/sec)
10 KB 50308 55947 20
125 MB 39261 46079 Sandisk Extreme IV
250 MB 6239 4427 10
500 MB 1975 2781
1 GB 1563 1916 1 2 4 8 16 32 64 128 256
2 GB 1406 1720 Number of Database Files (Log-scale)
3.5 GB 1125 1697
Table 2: Random read performance of FAWN-DS. Figure 8: Sequentially writing to multiple FAWN-DS
ﬁles results in semi-random writes.
is formatted with the ext2 ﬁlesystem and mounted with
Put Speed: In FAWN-KV, each FAWN node has R ∗V
the noatime option to prevent random writes for ﬁle
FAWN-DS ﬁles: each virtual node is responsible for its
access . These tests read and write 1 KB entries, the
own data range, plus the number of ranges it is a replica
lowest record size available in iozone. The ﬁlesystem I/O
for. A physical node receiving puts for different ranges
performance is shown in Table 1.
will concurrently append to a small number of ﬁles (“semi-
4.1.1 FAWN-DS Single Node Benchmarks random writes”). Good semi-random write performance
is central to FAWN-DS’s per-range data layout that en-
Lookup Speed: This test shows the query throughput ables single-pass maintenance operations. We therefore
achieved by a local client issuing queries for randomly evaluate its performance using three ﬂash-based storage
distributed, existing keys on a single node. We report devices.
the average of three runs (the standard deviations were Semi-random performance varies widely by device.
below 5%). Table 2 shows FAWN-DS 1 KB and 256 byte Figure 8 shows the aggregate write performance obtained
random read queries/sec as a function of the DS size. If when inserting 2GB of data using three different ﬂash
the data store ﬁts in the buffer cache, the node serves drives, as the data is inserted into an increasing number
35–55 thousand queries per second. As the data store of ﬁles. The relatively low-performance CompactFlash
exceeds the 256 MB of RAM available on the nodes, a write speed slows with an increasing number of ﬁles. The
larger fraction of requests go to ﬂash. 2008 Intel X25-M, which uses log-structured writing and
FAWN-DS imposes modest overhead from hash preemptive block erasure, retains high performance with
lookups, data copies, and key comparisons, and it must up to 256 concurrent semi-random writes for the 2 GB
read slightly more data than the iozone tests (each stored of data we inserted; the 2007 Mtron Mobi shows higher
entry has a header). The resulting query throughput, how- performance than the X25-M that drops somewhat as the
ever, remains high: tests using 1 KB values achieved number of ﬁles increases. The key take-away from this
1,125 queries/sec compared to 1,872 queries/sec from the evaluation is that Flash devices are capable of handling
ﬁlesystem. Using the 256 byte entries that we focus on the FAWN-DS write workload extremely well—but a
below achieved 1,697 queries/sec from a 3.5 GB datas- system designer must exercise care in selecting devices
tore. By comparison, the raw ﬁlesystem achieved 1,972 that actually do so.
random 256 byte reads per second using Flexible I/O.
4.1.2 Comparison with BerkeleyDB
Alix Node Performance
Queries/sec Idle Power Active Power Queries/J To understand the beneﬁt of FAWN-DS’s log structure,
1697 3W 4W 424 we compare with a general purpose disk-based database
that is not optimized for Flash. BerkeleyDB provides
Bulk store speed: The log structure of FAWN-DS a simple put/get interface, can be used without heavy-
ensures that data insertion is entirely sequential. As a weight transactions or rollback, and performs well versus
consequence, inserting two million entries of 1 KB each other memory or disk-based databases. We conﬁgured
(2 GB total) into a single ﬁle sustains an insert rate of BerkeleyDB using both its default settings and using the
23.2 MB/s (or nearly 24,000 entries per second), which is reference guide suggestions for Flash-based operation .
96% of the raw speed that the ﬂash can be written. The best performance we achieved required 6 hours (B-
Queries per second
9000 30000 256 B Get Queries
8000 20000 1 KB Get Queries
Queries per second
0 10 20 30 40 50 60
5000 1 FAWN-DS File Time (seconds)
3000 Figure 10: Query throughput on 21-node FAWN-KV
2000 8 FAWN-DS Files system for 1 KB and 256 B entry sizes.
0 0.2 0.4 0.6 0.8 1 devices is worse than purely sequential writes, it still
Fraction of Put Requests achieves higher throughput than pure random read perfor-
Figure 9: FAWN supports both read- and write- When the put-ratio is low, the query rate is limited by
intensive workloads. Small writes are cheaper than the get requests. As the ratio of puts to gets increases,
random reads due to the FAWN-DS log structure. the faster puts signiﬁcantly increase the aggregate query
rate. A pure write workload would require frequent clean-
ing, reducing the throughput by half—still faster than the
Tree) and 27 hours (Hash) to insert seven million, 200 get rate. In the next section, we mostly evaluate read-
byte entries to create a 1.5GB database. This corresponds intensive workloads because it represents the worst-case
to an insert rate of 0.07 MB/s. scenario for FAWN-KV.
The problem was, of course, small writes: When the
BDB store was larger than the available RAM on the 4.2 FAWN-KV System Benchmarks
nodes (< 256 MB), both the B-Tree and Hash implemen-
In this section, we evaluate the query rate and power draw
tations had to ﬂush pages to disk, causing many writes
of our 21-node FAWN-KV system.
that were much smaller than the size of an erase block.
That comparing FAWN-DS and BDB seems unfair System Throughput: To measure query throughput,
is exactly the point: even a well-understood, high- we populated the KV cluster with 20 GB of values, and
performance database will perform poorly when its write then measured the maximum rate at which the front-end
pattern has not been speciﬁcally optimized to Flash’s char- received query responses for random keys. We disabled
acteristics. Unfortunately, we were not able to explore front-end caching for this experiment. Figure 10 shows
using BDB on a log-structured ﬁlesystem, which might that the cluster sustained roughly 36,000 256 byte gets
be able to convert the random writes into sequential log per second (1,700 per second per node) and 24,000 1 KB
writes. Existing Linux log-structured ﬂash ﬁlesystems, gets per second (1,100 per second per node)—roughly
such as JFFS2 , are designed to work on raw ﬂash, 80% of the sustained rate that a single FAWN-DS could
but modern SSDs, compact ﬂash and SD cards all include handle with local queries. The ﬁrst reason for the differ-
a Flash Translation Layer that hides the raw ﬂash chips. It ence was load balance: with random keys, some back-end
remains to be seen whether these approaches can speed up nodes received more queries than others, slightly reducing
naive DB performance on ﬂash, but the pure log structure system performance.3 Second, this test involves network
of FAWN-DS remains necessary even if we could use overhead and request marshaling and unmarshaling.
a more conventional backend: it provides the basis for
System Power Consumption: Using a WattsUp 
replication and consistency across an array of nodes.
power meter that logs power draw each second, we mea-
4.1.3 Read-intensive vs. Write-intensive Workloads sured the power consumption of our 21-node FAWN-KV
cluster and two network switches. Figure 11 shows that,
Most read-intensive workloads have at least some writes. when idle, the cluster uses about 83 W, or 3 watts per node
For example, Facebook’s memcached workloads have and 10 W per switch. During gets, power consumption
a 1:6 ratio of application-level puts to gets . We increases to 99 W, and during insertions, power consump-
therefore measured the aggregate query rate as the fraction
of puts ranged from 0 (all gets) to 1 (all puts) on a single 3 This problem is fundamental to random load-balanced systems. A
node (Figure 9). recent in-submission manuscript by Terrace and Freedman devised a
mechanism for allowing queries to go to any node using chain replica-
FAWN-DS can handle more puts per second than gets,
tion; in future work, we plan to incorporate this to allow us to direct
because of its log structure. Even though semi-random queries to the least-loaded replica, which has been shown to drastically
write performance across eight ﬁles on our CompactFlash improve load balance.
Power (in Watts) 99 W 1
100 83 W 91 W
CDF of Query Latency
Gets Idle Puts
0 50 100 150 200 250 300 350 0.4 No Split 891us 26.3ms
Time (in seconds) Split (Low) 863us 491ms
0.2 Split (High) 873us 611ms
Figure 11: Power consumption of 21-node FAWN-KV
system for 256 B values during Puts/Gets. 0
100 1000 10000 100000 1e+06
Query Latency (us)
Split sent Split finished
Get Query Latency (Max Load)
1600 During Split (Low Load)
Queries per second
1400 During Split (High Load)
Figure 13: CDF of query latency under normal and
Get Query Rate (Full load) split workloads.
0 100 200 300 400 500
Split sent Split finished
shows query throughput during a split started at time
Queries per second
500 t=50 when the request rate is high—about 1600 gets per
300 second. During the split, throughput drops to 1000-1400
200 queries/sec. Because our implementation does not yet
Get Query Rate (Low load)
0 resize the hash index after a split, the post-split query rate
0 100 200 300 400 500
is slightly reduced, at 1425 queries/sec, until the old data
store is cleaned.
Figure 12: Get query rates during background split The split duration depends both on the size of the log
for high load (top) and low load (bottom). and on the incoming query load. Without query trafﬁc,
the split runs at the read or write speed of the ﬂash device
(24 MB/s), depending on how much of the key range
tion is 91 W.4 Peak get performance reaches about 36,000 is written to a new ﬁle. Under heavy query load the
256 B queries/sec for the cluster, so this system, excluding split runs at only 1.45 MB/s—the random read queries
the frontend, provides 364 queries/joule. greatly reduce the rate of the split reads and writes. In
The front-end has a 1 Gbit/s connection to the backend Figure 12(bottom) we repeat the same experiment but
nodes, so the cluster requires about one low-power front- with a lower external query rate of 500 queries/sec. At low
end for every 80 nodes—enough front-ends to handle the load, the split has very little impact on query throughput,
aggregate query trafﬁc from all the backends (80 nodes * and the split itself takes only half the time to complete.
1500 queries/sec/node * 1 KB / query = 937 Mbit/s). Our
Impact of Split on query latency: Figure 13 shows
prototype front-end uses 40 W, which adds 0.5 W per node
the distribution of query latency for three workloads: a
amortized over 80 nodes, providing 330 queries/joule for
pure get workload issuing gets at the maximum rate (Max
the entire system.
Load), a 500 requests per second workload with a con-
4.3 Impact of Ring Membership Changes current Split (Split-Low Load), and a high-rate request
workload with a concurrent Split (Split-High Load).
Node joins, leaves, or failures require existing nodes to
In general, accesses that hit buffer cache are returned in
merge, split, and transfer data while still handling puts and
300µs including processing and network latency. When
gets. We discuss the impact of a split on query throughput
the accesses go to ﬂash, the median response time is
and query latency on a per-node basis; the impact of
800µs. Even during a split, the median response time
merge and compact is similar.
remains under 1 ms.
Query throughput during Split: In this test, we split Most key-value systems care about 99.9th percentile
a 512 MB FAWN-DS data store ﬁle while issuing random latency guarantees as well as fast average-case perfor-
get requests to the node from the front-end. Figure 12(top) mance. During normal operation, request latency is very
4 Flash writes and erase require higher currents and voltages than
low: 99.9% of requests take under 26.3ms, and 90% take
under 2ms. During a split with low external query load,
reads do, but the overall put power was lower because FAWN’s log-
structured writes enable efﬁcient bulk writes to ﬂash, so the system the additional processing and locking extend 10% of re-
spends more time idle. quests above 10ms. Query latency increases brieﬂy at the
end of a split when the datastore is locked to atomically System / Storage QPS Watts Queries/sec
add the new datastore. The lock duration is 20–30 ms on Embedded Systems
average, but can rise to 100 ms if the query load is high, Alix3c2 / Sandisk(CF) 1697 4 424
increasing queuing delay for incoming requests during Soekris / Sandisk(CF) 334 3.75 89
this period. The 99.9%-ile response time is 491 ms.
For a high-rate request workload, the incoming request Desktop / Mobi(SSD) 5800 83 69.9
rate is occasionally higher than can be serviced during MacbookPro / HD 66 29 2.3
the split. Incoming requests are buffered and experience Desktop / HD 171 87 1.96
additional queuing delay: the 99.9%-ile response time is Table 3: Query performance and efﬁciency for differ-
611 ms. Fortunately, these worst-case response times are ent machine conﬁgurations.
still on the same order as those worst-case times seen in
production key-value systems .
With larger values (1KB), query latency during Split ulated 16-port gigabit Ethernet switch (10 W), achieved
increases further due to a lack of ﬂash device parallelism— 240 queries per joule. As expected from the small idle-
a large write to the device blocks concurrent independent active power gap of the desktop (64 W idle, 83 W ac-
reads, resulting in poor worst-case performance. Modern tive), the system had little room for “scaling down”—the
SSDs, in contrast, support and require request parallelism queries/Joule became drastically worse as the load de-
to achieve high ﬂash drive performance ; a future creased. The idle power of the desktop is dominated by
switch to these devices could greatly reduce the effect of ﬁxed power costs, while half of the idle power consump-
background operations on query latency. tion of the 3-node FAWN cluster comes from the idle (and
under-populated) Ethernet switch.
5 Alternative Architectures Table 3 extends this comparison to clusters of sev-
When is the FAWN approach likely to beat traditional ar- eral other systems.5 As expected, systems with disks
chitectures? We examine this question in two ways. First, are limited by seek times: the desktop above serves
we examine how much power can be saved on a conven- only 171 queries per second, and so provides only 1.96
tional system using standard scaling techniques. Next, we queries/joule—two orders of magnitude lower than a fully-
compare the three-year total cost of ownership (TCO) for populated FAWN. This performance is not too far off from
six systems: three “traditional” servers using magnetic what the disks themselves can do: they draw 10 W at load,
disks, ﬂash SSDs, and DRAM; and three hypothetical providing only 17 queries/joule. Low-power laptops with
FAWN-like systems using the same storage technologies. magnetic disks fare little better. The desktop (above) with
an SSD performs best of the alternative systems, but is
5.1 Characterizing Conventional Nodes still far from the performance of a FAWN cluster.
We ﬁrst examine a low-power, conventional desktop node
5.2 General Architectural Comparison
conﬁgured to conserve power. The system uses an Intel
quad-core Q6700 CPU with 2 GB DRAM, an Mtron Mobi A general comparison requires looking not just at the
SSD, and onboard gigabit Ethernet and graphics. queries per joule, but the total system cost. In this section,
we examine the 3-year total cost of ownership (TCO),
Power saving techniques: We conﬁgured the system
which we deﬁne as the sum of the capital cost and the
to use DVFS with three p-states (2.67 GHz, 2.14 GHz,
3-year power cost at 10 cents per kWh.
1.60 GHz). To maximize idle time, we ran a tickless Linux
kernel (version 2.6.27) and disabled non-system critical Because the FAWN systems we have built use several-
background processes. We enabled power-relevant BIOS year-old technology, we study a theoretical 2008 FAWN
settings including ultra-low fan speed and processor C1E node using a low-power Intel Atom CPU; private commu-
support. Power consumption was 64 W when idle with nication with a large manufacturer indicates that such a
only system critical background processes and 83-90 W node is feasible, consuming 6-8W and costing ∼$150 in
with signiﬁcant load. volume. We in turn give the beneﬁt of the doubt to the
server systems we compare against—we assume a 1 TB
Query throughput: Both raw (iozone) and FAWN-DS disk exists that serves 300 queries/sec at 10 W.
random reads achieved 5,800 queries/second, which is the Our results indicate that both FAWN and traditional
limit of the ﬂash device. systems have their place—but for the small random access
The resulting full-load query efﬁciency was 70 workloads we study, traditional systems are surprisingly
queries/Joule, compared to the 424 queries/Joule of a absent from much of the solution space, in favor of FAWN
fully populated FAWN cluster. Even a three-node FAWN nodes using either disks, SSDs, or DRAM.
cluster that achieves roughly the same query throughput
as the desktop, including the full power draw of an unpop- 5 The Soekris is a ﬁve-year-old embedded communications board.
Queries GB TCO TCO
System Cost W QPS Joule Watt GB QPS 10000
5-1 TB HD $5K 250 1500 6 20 1.1 3.85 1000 FAWN + Disk
Dataset Size in TB
160 GB SSD $8K 220 200K 909 0.7 53 0.04
64 GB DRAM $3K 280 1M 3.5K 0.2 58 0.003 100
FAWN + SSD
1 TB Disk $350 15 250 16 66 0.4 1.56 DR
32 GB SSD $550 7 35K 5K 4.6 17.8 0.02 ion
2 GB DRAM $250 7 100K 14K 0.3 134 0.002 Tra FAWN + DRAM
Table 4: Traditional and FAWN node statistics 0.1
0.1 1 10 100 1000
Query Rate (Millions/sec)
Key to the analysis is a question: why does a cluster Figure 14: Solution space for lowest 3-year TCO as a
need nodes? The answer is, of course, for both storage function of dataset size and query rate.
space and query rate. Storing a DS gigabyte dataset with
query rate QR requires N nodes:
Small datasets, high query rates: FAWN+DRAM
DS QR costs the fewest dollars per queries/second, keeping in
N = max , qr
mind that we do not examine workloads that ﬁt entirely
in L2 cache on a traditional node. This somewhat coun-
With large datasets with low query rates, the number terintuitive result is similar to that made by the intelligent
of nodes required is dominated by the storage capacity RAM project, which coupled processors and DRAM to
per node: thus, the important metric is the total cost per achieve similar beneﬁts  by avoiding the memory wall.
GB for an individual node. Conversely, for small datasets The FAWN nodes can only accept 2 GB of DRAM per
with high query rates, the per-node query capacity dictates node, so for larger datasets, a traditional DRAM system
the number of nodes: the dominant metric is queries provides a high query rate and requires fewer nodes to
per second per dollar. Between these extremes, systems store the same amount of data (64 GB vs 2 GB per node).
must provide the best tradeoff between per-node storage Middle range: FAWN+SSDs provide the best balance
capacity, query rate, and power cost. of storage capacity, query rate, and total cost. As SSD
Table 4 shows these cost and performance statistics for capacity improves, this combination is likely to continue
several candidate systems. The “traditional” nodes use expanding into the range served by FAWN+Disk; as SSD
200W servers that cost $3,000 each. Traditional+Disk performance improves, so will it reach into DRAM terri-
pairs a single server with ﬁve 1 TB high-speed disks ca- tory. It is therefore conceivable that FAWN+SSD could
pable of 300 queries/sec, each disk consuming 10 W. become the dominant architecture for a wide range of
Traditional+SSD uses two PCI-E Fusion-IO 80 GB Flash random-access workloads.
SSDs, each also consuming about 10 W (Cost: $3k). Tra- Are traditional systems obsolete? We emphasize that
ditional+DRAM uses eight 8 GB server-quality DRAM this analysis applies only to small, random access work-
modules, each consuming 10 W. FAWN+Disk nodes use loads. Sequential-read workloads are similar, but the
one 1 TB 7200 RPM disk: FAWN nodes have fewer con- constants depend strongly on the per-byte processing re-
nectors available on the board. FAWN+SSD uses one quired. Traditional cluster architectures retain a place
32 GB Intel SATA Flash SSD, consuming 2 W ($400). for CPU-bound workloads, but we do note that architec-
FAWN+DRAM uses a single 2 GB, slower DRAM module, tures such as IBM’s BlueGene successfully apply large
also consuming 2 W. numbers of low-power, efﬁcient processors to many su-
Figure 14 shows which base system has the lowest cost percomputing applications —but they augment their
for a particular dataset size and query rate, with dataset wimpy processors with custom ﬂoating point units to do
sizes between 100 GB and 10 PB and query rates between so. Finally, of course, our analysis assumes that clus-
100 K and 1 billion per second. The dividing lines repre- ter software developers can engineer away the human
sent a boundary across which one system becomes more costs of management—an optimistic assumption for all
favorable than another. architectures. We similarly discard issues such as ease of
Large datasets, low query rates: FAWN+Disk has the programming, though we ourselves selected an x86-based
lowest total cost per GB. While not shown on our graph, wimpy platform precisely for ease of development.
a traditional system wins for exabyte-sized workloads if
it can be conﬁgured with sufﬁcient disks per node (over
6 Related Work
50), though packing 50 disks per machine poses reliability FAWN follows in a long tradition of ensuring that sys-
challenges. tems are balanced in the presence of scaling challenges
and of designing systems to cope with the performance ﬂash’s performance characteristics follow a long line of
challenges imposed by hardware architectures. research [10, 24, 43, 26, 28]. Past solutions to these prob-
System Architectures: JouleSort  is a recent lems include the eNVy ﬁlesystem’s use of battery-backed
energy-efﬁciency benchmark; its authors developed a SRAM to buffer copy-on-write log updates for high per-
SATA disk-based “balanced” system coupled with a low- formance , followed closely by purely ﬂash-based
power (34 W) CPU that signiﬁcantly out-performed prior log-structured ﬁlesystems .
systems in terms of records sorted per joule. A major High-throughput storage and analysis: Recent work
difference with our work is that the sort workload can be such as Hadoop or MapReduce  running on GFS 
handled with large, bulk I/O reads using radix or merge has examined techniques for scalable, high-throughput
sort. FAWN targets even more seek-intensive workloads computing on massive datasets. More specialized exam-
for which even the efﬁcient CPUs used for JouleSort are ples include SQL-centric options such as the massively
excessive, and for which disk is inadvisable. parallel data-mining appliances from Netezza . As
The Gordon  hardware architecture pairs an array opposed to the random-access workloads we examine for
of ﬂash chips and DRAM with low-power CPUs for low- FAWN-KV, these systems provide bulk throughput for
power data intensive computing. A primary focus of massive datasets with low selectivity or where indexing
their work is on developing a Flash Translation Layer in advance is difﬁcult. We view these workloads as a
suitable for pairing a single CPU with several raw ﬂash promising next target for the FAWN approach.
chips. Simulations on general system traces indicate that Distributed Hash Tables: Related cluster and wide-
this pairing can provide improved energy-efﬁciency. Our area hash table-like services include Distributed data
work leverages commodity embedded low-power CPUs structure (DDS) , a persistent data management
and ﬂash storage, enabling good performance on ﬂash layer designed to simplify cluster-based Internet services.
regardless of FTL implementation. FAWN’s major points of differences with DDS are a re-
Considerable prior work has examined ways to tackle sult of FAWN’s hardware architecture, use of ﬂash, and
the “memory wall.” The Intelligent RAM (IRAM) project focus on power efﬁciency—in fact, the authors of DDS
combined CPUs and memory into a single unit, with a noted that a problem for future work was that “disk seeks
particular focus on energy efﬁciency . An IRAM-based become the overall bottleneck of the system” with large
CPU could use a quarter of the power of a conventional workloads, precisely the problem that FAWN-DS solves.
system to serve the same workload, reducing total system These same differences apply to systems such as Dy-
energy consumption to 40%. FAWN takes a themati- namo  and Voldemort . Systems such as Box-
cally similar view—placing smaller processors very near wood  focus on the higher level primitives necessary
ﬂash—but with a signiﬁcantly different realization. Simi- for managing storage clusters. Our focus was on the
lar efforts, such as the Active Disk project , focused lower-layer architectural and data-storage functionality.
on harnessing computation close to disks. Schlosser et Sleeping Disks: A ﬁnal set of research examines how
al.  proposed obtaining similar beneﬁts from coupling and when to put disks to sleep; we believe that the FAWN
MEMS with CPUs. approach compliments them well. Hibernator , for
Databases and Flash: Much ongoing work is exam- instance, focuses on large but low-rate OLTP database
ining the use of ﬂash in databases. Recent work con- workloads (a few hundred queries/sec). Ganesh et al.
cluded that NAND ﬂash might be appropriate in “read- proposed using a log-structured ﬁlesystem so that a strip-
mostly, transaction-like workloads”, but that ﬂash was ing system could perfectly predict which disks must be
a poor ﬁt for high-update databases . This work, awake for writing . Finally, Pergamum  used
along with FlashDB , also noted the beneﬁts of a log nodes much like our wimpy nodes to attach to spun-down
structure on ﬂash; however, in their environments, us- disks for archival storage purposes, noting that the wimpy
ing a log-structured approach slowed query performance nodes consume much less power when asleep. The system
by an unacceptable degree. In contrast, FAWN-KV’s achieved low power, though its throughput was limited
sacriﬁces range queries by providing only primary-key by the wimpy nodes’ Ethernet.
queries, which eliminates complex indexes: FAWN’s sep-
arate data and index can therefore support log-structured 7 Conclusion
access without reduced query performance. Indeed, with FAWN pairs low-power embedded nodes with ﬂash stor-
the log structure, FAWN’s performance actually increases age to provide fast and energy efﬁcient processing of
with a higher percentage of writes. random read-intensive workloads. Effectively harnessing
Filesystems for Flash: Several ﬁlesystems are spe- these more efﬁcient but memory and compute-limited
cialized for use on ﬂash. Most are partially log- nodes into a usable cluster requires a re-design of many
structured , such as the popular JFFS2 (Journaling of the lower-layer storage and replication mechanisms. In
Flash File System) for Linux. Our observations about this paper, we have shown that doing so is both possible
and desirable. FAWN-KV begins with a log-structured ﬁle system. In Proc. USENIX Annual Technical Conference, Jan.
per-node datastore to serialize writes and make them fast 1995.
on ﬂash. It then uses this log structure as the basis for  L. Lamport. The part-time parliament. ACM Trans. Comput. Syst., 16
(2):133–169, 1998. ISSN 0734-2071.
chain replication between cluster nodes, providing relia-  J. MacCormick, N. Murphy, M. Najork, C. A. Thekkath, and L. Zhou.
bility and strong consistency, while ensuring that all main- Boxwood: abstractions as the foundation for storage infrastructure. In
tenance operations—including failure handling and node Proc. 6th USENIX OSDI, Dec. 2004.
insertion—require only efﬁcient bulk sequential reads and  Memcached. A distributed memory object caching system. http:
writes. By delivering over an order of magnitude more
 D. Myers. On the use of NAND ﬂash memory in high-performance
queries per Joule than conventional disk-based systems, relational databases. M.S. Thesis, MIT, Feb. 2008.
the FAWN architecture demonstrates signiﬁcant potential  S. Nath and P. B. Gibbons. Online Maintenance of Very Large Ran-
for many I/O intensive workloads. dom Samples on Flash Storage. In Proc. VLDB, Aug. 2008.
 S. Nath and A. Kansal. FlashDB: Dynamic self-tuning database for
References NAND ﬂash. In Proc. ACM/IEEE Intl. Conference on Information
Processing in Sensor Networks, Apr. 2007.
 Flexible I/O Tester. http://freshmeat.net/projects/  Netezza. Business intelligence data warehouse appliance. http://
fio/. www.netezza.com/, 2006.
 L. A. Barroso and U. H¨ lzle. The case for energy-proportional com-
o  M. Polte, J. Simsa, and G. Gibson. Enabling enterprise solid state
puting. Computer, 40(12):33–37, 2007. disks performance. In Proc. Workshop on Integrating Solid-state Mem-
 BerkeleyDB Reference Guide. Memory-only or Flash con- ory into the Storage Hierarchy, Mar. 2009.
ﬁgurations. http://www.oracle.com/technology/  Project Voldemort. A distributed key-value storage system. http:
html.  S. Quinlan and S. Dorward. Venti: A new approach to archival stor-
 W. Bowman, N. Cardwell, C. Kozyrakis, C. Romer, and H. Wang. age. In Proc. USENIX Conference on File and Storage Technologies
Evaluation of existing architectures in IRAM systems. In Workshop on (FAST), pages 89–101, Jan. 2002.
Mixing Logic and DRAM, 24th International Symposium on Computer  E. Riedel, C. Faloutsos, G. A. Gibson, and D. Nagle. Active disks for
Architecture, June 1997. large-scale data processing. IEEE Computer, 34(6):68–74, June 2001.
 A. M. Caulﬁeld, L. M. Grupp, and S. Swanson. Gordon: Using Flash  S. Rivoire, M. A. Shah, P. Ranganathan, and C. Kozyrakis. JouleSort:
Memory to Build Fast, Power-efﬁcient Clusters for Data-intensive Ap- A balanced energy-efﬁcient benchmark. In Proc. ACM SIGMOD, June
plications. In Proc. ASPLOS, Mar. 2009. 2007.
 J. S. Chase, D. Anderson, P. Thakar, A. Vahdat, and R. Doyle. Manag-  M. Rosenblum and J. K. Ousterhout. The design and implementation
ing energy and server resources in hosting centers. In Proc. 18th ACM of a log-structured ﬁle system. ACM Transactions on Computer Sys-
Symposium on Operating Systems Principles (SOSP), Oct. 2001. tems, 10(1):26–52, 1992.
 P. de Langen and B. Juurlink. Trade-offs between voltage scaling and  S. W. Schlosser, J. L. Grifﬁn, D. F. Nagle, and G. R. Ganger. Filling
processor shutdown for low-energy embedded multiprocessors. In Em- the memory access gap: A case for on-chip magnetic storage. Techni-
bedded Computer Systems: Architectures, Modeling, and Simulation, cal Report CMU-CS-99-174, Carnegie Mellon University, Nov. 1999.
 F. B. Schneider. Byzantine generals in action: implementing fail-stop
 J. Dean and S. Ghemawat. MapReduce: Simpliﬁed data processing processors. ACM Trans. Comput. Syst., 2(2):145–154, 1984. ISSN
on large clusters. In Proc. 6th USENIX OSDI, Dec. 2004. 0734-2071.
 G. DeCandia, D. Hastorun, M. Jampani, G. Kakulapati, A. Lakshman,  I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan.
A. Pilchin, S. Sivasubramanian, P. Vosshall, and W. Vogels. Dynamo: Chord: A scalable peer-to-peer lookup service for Internet applica-
Amazon’s highly available key-value store. In Proc. SOSP, Oct. 2007. tions. In Proc. ACM SIGCOMM, Aug. 2001.
 F. Douglis, F. Kaashoek, B. Marsh, R. Caceres, K. Li, and J. Tauber.  M. W. Storer, K. M. Greenan, E. L. Miller, and K. Voruganti. Perga-
Storage alternatives for mobile computers. In Proc1st USENIX OSDI, mum: Replacing tape with energy efﬁcient, reliable, disk-based
pages 25–37, Nov. 1994. archival storage. In Proc. USENIX Conference on File and Storage
 L. Ganesh, H. Weatherspoon, M. Balakrishnan, and K. Birman. Op- Technologies, Feb. 2008.
timizing power consumption in large scale storage systems. In Proc.  N. Tolia, Z. Wang, M. Marwah, C. Bash, P. Ranganathan, and X. Zhu.
HotOS XI, May 2007. Delivering energy proportionality with non energy-proportional sys-
 A. Gara, M. A. Blumrich, D. Chen, G. L.-T. Chiu, et al. Overview of tems – optimizing the ensemble. In Proc. HotPower, Dec. 2008.
the Blue Gene/L system architecture. IBM J. Res and Dev., 49(2/3),  R. van Renesse and F. B. Schneider. Chain replication for supporting
May 2005. high throughput and availability. In Proc. 6th USENIX OSDI, Dec.
 S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google ﬁle system. 2004.
In Proc. SOSP, Oct. 2003.  WattsUp. .NET Power Meter. http://wattsupmeters.com.
 S. D. Gribble, E. A. Brewer, J. M. Hellerstein, and D. Culler. Scalable,  M. Weiser, B. Welch, A. Demers, and S. Shenker. Scheduling for
distributed data structures for internet service construction. In Proc. ˙
reduced CPU energy. In Proc1st USENIX OSDI, pages 13–23, Nov.
4th USENIX OSDI, Nov. 2000. 1994.
 Intel. Penryn Press Release. http://www.intel.com/  M. Wu and W. Zwaenepoel. eNVy: A non-volatile, main memory
pressroom/archive/releases/20070328fact.htm. storage system. In Proc. ASPLOS, Oct. 1994.
 Iozone. Filesystem Benchmark. http://www.iozone.org.  D. Zeinalipour-Yazti, S. Lin, V. Kalogeraki, D. Gunopulos, and W. A.
 JFFS2. The Journaling Flash File System. http://sources. Najjar. Microhash: An efﬁcient index structure for ﬂash-based sensor
redhat.com/jffs2/. devices. In Proc. FAST, Dec. 2005.
 B. Johnson. Facebook, personal communication, Nov. 2008.  Q. Zhu, Z. Chen, L. Tan, Y. Zhou, K. Keeton, and J. Wilkes. Hiberna-
 R. H. Katz. Tech titans building boom. IEEE Spectrum, Feb. 2009. tor: Helping disk arrays sleep through the winter. In Proc. SOSP, Oct.
 A. Kawaguchi, S. Nishioka, and H. Motoda. A ﬂash-memory based 2005.