Evaluate existing storage abstractions and other DBs

[philippgille]

This issue consists of two kind of seperate tasks, but they're very related to each other:

1. Existing storage abstractions
2. Other DBs

Existing storage abstractions

The wall package contains the interface StorageClient and expects it as parameter so the middleware factory functions. It's meant as an abstraction for storage client implementations backed by some distributed or embedded DB / KV store.

It currently has two very ln-paywall-specific methods, but this will probably change in #16:

type StorageClient interface {
	WasUsed(string) (bool, error)
	SetUsed(string) error
}

The storage package contains implementations for Redis, bbolt (formerly known as Bolt DB) and a simple Go map.

This is home-grown and might not offer the best performance and robustness as professionally created storage abstractions.

I looked for existing abstractions and there aren't many, but they should be evaluated:

• Docker's libkv: Consul, Etcd, Zookeeper (Distributed store) and BoltDB (local store)
• A fork of libkv, apparently by the former libkv maintainer, valkeyrie: Consul, Etcd, Zookeeper, Redis (Distributed store) and BoltDB (local store)

Other existing, but not popular or well-maintained ones:

• gokvstores
• gokv drivers

Other DBs

Every DB has its pros and cons, and it's always very dependent on the use case which DB is the fastest.

So more DBs should be implemented temporarily, then benchmarked with real use of ln-paywall middleware and then only the DBs that make the most sense should be supported (to not overwhelm developers who want to use ln-paywall with too many storage options).

We should look at least at:

• Distributed
  • Google's groupcache: Distributed without needing a seperate server like Redis, but focused on caches (write once, read many), so maybe not a good fit depending on how ln-paywall uses the storage (which might change in A client can cheat if the backend has multiple endpoints with different prices #16)
  • etcd: Not advertised as general KV store, but can be used as one
  • TiKV: Originally created to complement TiDB, but recently became a project in the CNCF
  • Memcached
  • Riak
  • LedisDB: Similar to Redis, with several backing storages
• Embedded
  • BadgerDB: Very similar to bbolt / Bolt DB, where bbolt is generally faster for reads, and Badger is generally faster for writes. So this depends on how the storage is used by ln-paywall.
  • LevelDB / goleveldb
  • RocksDB / gorocksdb

And even if we only need KV, we should look at popular general NoSQL or even SQL DBs as well:

• MongoDB
• CockroachDB
• RethinkDB

And maybe even some DB-as-as-Service options from the big three cloud providers: AWS, Azure, GCP. This is especially useful if companies want to use ln-paywall but don't want to deal with the administration of a DB, or if they're already using one of the cloud providers anyway, so they're most comfortable in using their products, because they trust them and they know they work well.