umgeher/leveled
0
Fork 0
Code Issues Pull requests Releases Activity Actions

Clean-up readme

Browse source
This commit is contained in:
martinsumner 2017-02-02 11:16:21 +00:00
parent 3330b39b73
commit cbe663ebb6
1 changed files with 5 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

11
README.md
View file

@ -2,18 +2,17 @@
## Introduction ## Introduction
LevelEd is a work-in-progress prototype of a simple Key-Value store based on the concept of a Log_Structured Merge Tree, with the following characteristics: LevelEd is a work-in-progress prototype of a simple Key-Value store based on the concept of Log-Structured Merge Trees, with the following characteristics:
- Optimised for workloads with larger values (e.g. > 4KB) and non-trivial proportion of PUT activity (e.g. > 20% by comparison with GET activity). - Optimised for workloads with larger values (e.g. > 4KB).
- Supporting of values split between metadata and body, and allowing for HEAD requests which have lower overheads than GET requests. - Supporting of values split between metadata and body, and allowing for HEAD requests which have lower overheads than GET requests.
- Trade-offs are made to reduce the intensity of disk workloads, accepting the potential for consequent increases in CPU time and median latency.
- Support for tagging of object types and the implementation of alternative store behaviour based on type. - Support for tagging of object types and the implementation of alternative store behaviour based on type.
- Support for low-cost clones without locking to provide for scanning queries, specifically where there is a need to scan across keys and metadata (not values). - Support for low-cost clones without locking to provide for scanning queries, specifically where there is a need to scan across keys and metadata (not values).
- Written in Erlang as a message passing system between Actors. - Written in Erlang as a message passing system between Actors.
The store has been developed with a focus on being a potential backend to a Riak KV database, rather than as a generic store. The primary aim of developing (yet another) Riak backend is to examine the potential to reduce the broader costs providing sustained throughput in Riak i.e. to provide equivalent throughput on cheaper hardware. It is also anticipated in having a fully-featured pure Erlang backend may assist in evolving new features through the Riak ecosystem which require end-to-end changes. The store has been developed with a focus on being a potential backend to a Riak KV database, rather than as a generic store. The primary aim of developing (yet another) Riak backend is to examine the potential to reduce the broader costs providing sustained throughput in Riak i.e. to provide equivalent throughput on cheaper hardware. It is also anticipated in having a fully-featured pure Erlang backend may assist in evolving new features through the Riak ecosystem which require end-to-end changes.
The store is not expected to be 'faster' than leveldb (the primary fully-featured Riak backend available today), nor offer improvements in all use cases - especially where values are small. The store is not expected to be 'faster' than leveldb (the primary fully-featured Riak backend available today), but it is likely in some cases to offer improvements in throughput.
## More Details ## More Details
@ -33,6 +32,6 @@ At the initiation of the project I accepted that making a positive contribution
The target at inception was to do something interesting, something that articulates through working software the potential for improvement to exist by re-thinking certain key assumptions and trade-offs. The target at inception was to do something interesting, something that articulates through working software the potential for improvement to exist by re-thinking certain key assumptions and trade-offs.
[Initial volume tests](VOLUME.md) indicate that it is at least interesting, with substantial improvements in both throughput and tail latency when compared to eleveldb - in scenarios expected to be optimised for leveled. Note, to be clear, this is statement falls well short of making a general claim that it represents a 'better' Riak backend than eleveldb. [Initial volume tests](docs/VOLUME.md) indicate that it is at least interesting, with substantial improvements in both throughput and tail latency when compared to eleveldb - in scenarios expected to be optimised for leveled. Note, to be clear, this is statement falls well short of making a general claim that it represents a 'better' Riak backend than leveldb.
More information can be found in the volume testing section. More information can be found in the [volume testing section](docs/VOLUME.md).