Sharding support for ETS tables out-of-box.
Why might we need Sharding on ETS tables? Well, the main reason is to keep the lock contention under control, in order to scale-out ETS tables (linearly) and support higher levels of concurrency without lock issues; specially write-locks, which most of the cases might cause significant performance degradation.
Therefore, one of the most common and proven strategies to deal with these problems is Sharding or Partitioning; the principle is pretty similar to DHTs.
This is where Shards comes in. Shards is an Erlang/Elixir library compatible with the current ETS API, which implements Sharding or Partitioning on top of ETS tables, completely transparent and out-of-box.
See the getting started guide and the online documentation.
In your rebar.config:
{deps, [
{shards, "0.6.0"}
]}.In your mix.exs:
def deps do
[{:shards, "~> 0.6"}]
endCheck out the getting started guide to learn more about it.
-
Documentation - Hex Docs.
-
Blog Post - Transparent and out-of-box sharding support for ETS tables in Erlang/Elixir.
-
ExShards – Elixir wrapper for
shards; with extra and nicer functions. -
Nebulex – Distributed Caching framework for Elixir.
-
KVX – Simple Elixir in-memory Key/Value Store using
shards(default adapter). -
Cacherl Distributed Cache using
shards.
$ make test
You can find tests results in _build/test/logs, and coverage in
_build/test/cover.
NOTE:
shardscomes with a helperMakefile, but it is just a simple wrapper on top ofrebar3, therefore, you can do everything usingrebar3directly as well (e.g.:rebar3 do ct, cover).
$ make doc
NOTE: Once you run the previous command, a new folder
docis created, and you'll have a pretty nice HTML documentation.
Copyright (c) 2016 Carlos Andres Bolaños R.A.
Shards source code is licensed under the MIT License.
