#actor-model #cache #in-memory #data-store #cassandra #write

thingvellir

a concurrent, shared-nothing abstraction that manages an assembly of things

38 releases

0.0.14 Jun 26, 2024
0.0.13 Mar 29, 2024
0.0.11 Dec 19, 2023
0.0.9 Sep 1, 2023
0.0.0-alpha9 Mar 9, 2020

#132 in Concurrency

Download history 8521/week @ 2024-07-10 7248/week @ 2024-07-17 6472/week @ 2024-07-24 8780/week @ 2024-07-31 15324/week @ 2024-08-07 8270/week @ 2024-08-14 28353/week @ 2024-08-21 18935/week @ 2024-08-28 22971/week @ 2024-09-04 15567/week @ 2024-09-11 21865/week @ 2024-09-18 21706/week @ 2024-09-25 25978/week @ 2024-10-02 13833/week @ 2024-10-09 25856/week @ 2024-10-16 17392/week @ 2024-10-23

90,276 downloads per month

MIT license

170KB
3.5K SLoC

Þingvellir (thingvellir)

Build Status License Documentation Cargo

A rust library that allows you to build an in-memory write/read-through cache. It uses a sharded, shared-nothing actor model underneath ontop of tokio.

Given a struct, and an upstream, this abstraction handles the loading and committing of data. thingvellir is meant to sit in-front of a database (e.g. cassandra, or scylladb), providing a way to allow for in-memory caching of "hot" data within the database.

thingvellir exposes a key/value interface, abstracting away the database load and persist operations, allowing you to write your business logic as a simple struct that can be persisted to a database. Out of the box, thingvellir provides an upstream implementation, that will persist structs to cassandra, using a simple key/value schema, where the value is the CBOR serialized form, using serde.

thingvellir handles object expiry, as well allowing a bounded in-memory data-set (the # of keys the thingvellir will cache can be configured), and keys are able to be evicted as they expire (we use a random expiration probe similar to Redis), and also maintains a probabilistic LRU to evict keys if the cache is at capacity.

thingvellir coalesces reads and writes to the upstream data store. If your data model is amenable to delayed write durability (for example, counters that you are okay with data loss if the node crashes before data is committed upstream). Or a "hot" key might get queried a lot, or see a burst of queries, thingvellir will ensure that the upstream only sees a single read query. The write durability can be configured on a per-mutation basis, allowing for immediate commit, or delayed commit (depending on how much data-loss your application can tolerate.)

Dependencies

~5–33MB
~494K SLoC