A multi-threaded, persistent key/value store server and client with networking over a custom protocol.

Quick start

• Build: cargo build
• Run server: unifier-server -h

  unifier-server 0.1.0
  
  USAGE:
    unifier-server [OPTIONS]
  
  FLAGS:
      -h, --help       Prints help information
      -V, --version    Prints version information
  
  OPTIONS:
          --addr <IP:PORT>          Sets the listening address [default: 127.0.0.1:4000]
          --engine <ENGINE-NAME>    Sets the storage engine [possible values: kvs, sled]
  

  Note: If --engine is specified, then ENGINE-NAME must be either "kvs", in which case the built-in engine is used, or "sled", in which case sled is used. If this is the first run (there is no data previously persisted) then the default value is "kvs"; if there is previously persisted data then the default is the engine already in use. If data was previously persisted with a different engine than selected, it will print an error.
• Run client: unifier-client -h

  unifier-client 0.1.0
  
    USAGE:
    unifier-client <SUBCOMMAND>
  
  FLAGS:
      -h, --help       Prints help information
      -V, --version    Prints version information
  
  SUBCOMMANDS:
      get    Get the string value of a given string key
      rm     Remove a given string key
      set    Set the value of a string key to a string
  

Why unifier (unity.kv)?

• Multi-threaded: many threads are created within a process, executing independently but concurrently sharing process resources to finish tasks in a much faster way. This efficiency comes from the unity of threads.
• Traits for intergration:
  • Two key-value store engines. KvsEngine trait defines the storage interface. KvStore implements KvsEngine for the kvs storage engine and SledKvsEngine implements KvsEngine for the sled storage engine.
  • Three threadpool implementations. ThreadPool trait contains methods that create a new thread pool to spawn the specified number of threads, and that spawn a function into the threadpool. NaiveThreadPool implements ThreadPool and spawns a new thread every time the spawn method is called. RayonThreadPool implements ThreadPool using a data parallelism library called rayon. And SharedQueueThreadPool implements ThreadPool using a shared queue.
  • Different kinds of engines and threadpools to choose is the unity of implementations.
• Built on top of open-source projects and online tutorials, this is the unity of crates and experiences.
• I have been playing Assassin's Creed Unity recently. :)

Benchmark

Compared with sled (a concurrent embedded key-value database), kvs engine takes samller space and offers faster speed. The benchmark results are as follows:

Testing

cargo test --test cli

• server_cli_version
• client_cli_version
• client_cli_no_args
• client_cli_invalid_subcommand
• test client_cli_invalid_get
• client_cli_invalid_rm
• client_cli_invalid_set
• cli_log_configuration
• cli_wrong_engine
• cli_access_server_kvs_engine
• cli_access_server_sled_engine

cargo test --test kv_store

• remove_non_existent_key
• remove_key
• get_non_existent_value
• get_stored_value
• overwrite_value
• concurrent_get
• concurrent_set
• compaction

cargo test --test thread_pool

• naive_thread_pool_spawn_counter
• shared_queue_thread_pool_spawn_counter
• rayon_thread_pool_spawn_counter
• shared_queue_thread_pool_panic_task

Thanks to https://github.com/pingcap/talent-plan