Simple key-value store abstraction and implementations for Go (Redis, Consul, etcd, bbolt, BadgerDB, LevelDB, Memcached, DynamoDB, S3, PostgreSQL, MongoDB, CockroachDB and many more)

gokv

GoDoc Build Status Go Report Card codecov GitHub Releases Mentioned in Awesome Go

Simple key-value store abstraction and implementations for Go

Contents

  1. Features
    1. Simple interface
    2. Implementations
    3. Value types
    4. Marshal formats
    5. Roadmap
  2. Usage
  3. Project status
  4. Motivation
  5. Design decisions
  6. Related projects

Features

Simple interface

Note: The interface is not final yet! See Project status for details.

type Store interface {
    Set(k string, v interface{}) error
    Get(k string, v interface{}) (found bool, err error)
    Delete(k string) error
    Close() error
}

There are detailed descriptions of the methods in the docs and in the code. You should read them if you plan to write your own gokv.Store implementation or if you create a Go package with a method that takes a gokv.Store as parameter, so you know exactly what happens in the background.

Implementations

Some of the following databases aren't specifically engineered for storing key-value pairs, but if someone's running them already for other purposes and doesn't want to set up one of the proper key-value stores due to administrative overhead etc., they can of course be used as well. In those cases let's focus on a few of the most popular though. This mostly goes for the SQL, NoSQL and NewSQL categories.

Feel free to suggest more stores by creating an issue or even add an actual implementation - PRs Welcome.

For differences between the implementations, see Choosing an implementation.
For the GoDoc of specific implementations, see https://www.godoc.org/github.com/philippgille/gokv#pkg-subdirectories.

Again:
For differences between the implementations, see Choosing an implementation.
For the GoDoc of specific implementations, see https://www.godoc.org/github.com/philippgille/gokv#pkg-subdirectories.

Value types

Most Go packages for key-value stores just accept a []byte as value, which requires developers for example to marshal (and later unmarshal) their structs. gokv is meant to be simple and make developers' lifes easier, so it accepts any type (with using interface{} as parameter), including structs, and automatically (un-)marshals the value.

The kind of (un-)marshalling is left to the implementation. All implementations in this repository currently support JSON and gob by using the encoding subpackage in this repository, which wraps the core functionality of the standard library's encoding/json and encoding/gob packages. See Marshal formats for details.

For unexported struct fields to be (un-)marshalled to/from JSON/gob, the respective custom (un-)marshalling methods need to be implemented as methods of the struct (e.g. MarshalJSON() ([]byte, error) for custom marshalling into JSON). See Marshaler and Unmarshaler for JSON, and GobEncoder and GobDecoder for gob.

To improve performance you can also implement the custom (un-)marshalling methods so that no reflection is used by the encoding/json / encoding/gob packages. This is not a disadvantage of using a generic key-value store package, it's the same as if you would use a concrete key-value store package which only accepts []byte, requiring you to (un-)marshal your structs.

Marshal formats

This repository contains the subpackage encoding, which is an abstraction and wrapper for the core functionality of packages like encoding/json and encoding/gob. The currently supported marshal formats are:

More formats will be supported in the future (e.g. XML).

The stores use this encoding package to marshal and unmarshal the values when storing / retrieving them. The default format is JSON, but all gokv.Store implementations in this repository also support gob as alternative, configurable via their Options.

The marshal format is up to the implementations though, so package creators using the gokv.Store interface as parameter of a function should not make any assumptions about this. If they require any specific format they should inform the package user about this in the GoDoc of the function taking the store interface as parameter.

Differences between the formats:

Roadmap

  • Benchmarks!
  • CLI: A simple command line interface tool that allows you create, read, update and delete key-value pairs in all of the gokv storages
  • A combiner package that allows you to create a gokv.Store which forwards its call to multiple implementations at the same time. So for example you can use memcached and s3 simultaneously to have 1) super fast access but also 2) durable redundant persistent storage.
  • A way to directly configure the clients via the options of the underlying used Go package (e.g. not the redis.Options struct in github.com/philippgille/gokv, but instead the redis.Options struct in github.com/go-redis/redis)
    • Will be optional and discouraged, because this will lead to compile errors in code that uses gokv when switching the underlying used Go package, but definitely useful for some people
  • More stores (see stores in Implementations list with unchecked boxes)
  • Maybe rename the project from gokv to SimpleKV?
  • Maybe move all implementation packages into a subdirectory, e.g. github.com/philippgille/gokv/store/redis?

Usage

First, download the module you want to work with:

  • For example when you want to work with the gokv.Store interface:
    • go get github.com/philippgille/gokv@latest
  • For example when you want to work with the Redis implementation:
    • go get github.com/philippgille/gokv/redis@latest

Then you can import and use it.

Every implementation has its own Options struct, but all implementations have a NewStore() / NewClient() function that returns an object of a sctruct that implements the gokv.Store interface. Let's take the implementation for Redis as example, which is the most popular distributed key-value store.

package main

import (
    "fmt"

    "github.com/philippgille/gokv"
    "github.com/philippgille/gokv/redis"
)

type foo struct {
    Bar string
}

func main() {
    options := redis.DefaultOptions // Address: "localhost:6379", Password: "", DB: 0

    // Create client
    client, err := redis.NewClient(options)
    if err != nil {
        panic(err)
    }
    defer client.Close()

    // Store, retrieve, print and delete a value
    interactWithStore(client)
}

// interactWithStore stores, retrieves, prints and deletes a value.
// It's completely independent of the store implementation.
func interactWithStore(store gokv.Store) {
    // Store value
    val := foo{
        Bar: "baz",
    }
    err := store.Set("foo123", val)
    if err != nil {
        panic(err)
    }

    // Retrieve value
    retrievedVal := new(foo)
    found, err := store.Get("foo123", retrievedVal)
    if err != nil {
        panic(err)
    }
    if !found {
        panic("Value not found")
    }

    fmt.Printf("foo: %+v", *retrievedVal) // Prints `foo: {Bar:baz}`

    // Delete value
    err = store.Delete("foo123")
    if err != nil {
        panic(err)
    }
}

As described in the comments, that code does the following:

  1. Create a client for Redis
    • Some implementations' stores/clients don't require to be closed, but when working with the interface (for example as function parameter) you must call Close() because you don't know which implementation is passed. Even if you work with a specific implementation you should always call Close(), so you can easily change the implementation without the risk of forgetting to add the call.
  2. Call interactWithStore(), which requires a gokv.Store as parameter. This method then:
    1. Stores an object of type foo in the Redis server running on localhost:6379 with the key foo123
    2. Retrieves the value for the key foo123
      • The check if the value was found isn't needed in this example but is included for demonstration purposes
    3. Prints the value. It prints foo: {Bar:baz}, which is exactly what was stored before.
    4. Deletes the value

Now let's say you don't want to use Redis but Consul instead. You just have to make three simple changes:

  1. Replace the import of "github.com/philippgille/gokv/redis" by "github.com/philippgille/gokv/consul"
  2. Replace redis.DefaultOptions by consul.DefaultOptions
  3. Replace redis.NewClient(options) by consul.NewClient(options)

Everything else works the same way. interactWithStore() is completely unaffected.

Project status

Note: gokv's API is not stable yet and is under active development. Upcoming releases are likely to contain breaking changes as long as the version is v0.x.y. You should use vendoring to prevent bad surprises. This project adheres to Semantic Versioning and all notable changes to this project are documented in RELEASES.md.

Planned interface methods until v1.0.0:

  • List(interface{}) error / GetAll(interface{}) error or similar

The interface might even change until v1.0.0. For example one consideration is to change Get(string, interface{}) (bool, error) to Get(string, interface{}) error (no boolean return value anymore), with the error being something like gokv.ErrNotFound // "Key-value pair not found" to fulfill the additional role of indicating that the key-value pair wasn't found. But at the moment we prefer the current method signature.

Also, more interfaces might be added. For example so that there's a SimpleStore and an AdvancedStore, with the first one containing only the basic methods and the latter one with advanced features such as key-value pair lifetimes (deletion of key-value pairs after a given time), notification of value changes via Go channels etc. But currently the focus is simplicity, see Design decisions.

Motivation

When creating a package you want the package to be usable by as many developers as possible. Let's look at a specific example: You want to create a paywall middleware for the Gin web framework. You need some database to store state. You can't use a Go map, because its data is not persisted across web service restarts. You can't use an embedded DB like bbolt, BadgerDB or SQLite, because that would restrict the web service to one instance, but nowadays every web service is designed with high horizontal scalability in mind. If you use Redis, MongoDB or PostgreSQL though, you would force the package user (the developer who creates the actual web service with Gin and your middleware) to run and administrate the server, even if she might never have used it before and doesn't know how to configure them for high performance and security.

Any decision for a specific database would limit the package's usability.

One solution would be a custom interface where you would leave the implementation to the package user. But that would require the developer to dive into the details of the Go package of the chosen key-value store. And if the developer wants to switch the store, or maybe use one for local testing and another for production, she would need to write multiple implementations.

gokv is the solution for these problems. Package creators use the gokv.Store interface as parameter and can call its methods within their code, leaving the decision which actual store to use to the package user. Package users pick one of the implementations, for example github.com/philippgille/gokv/redis for Redis and pass the redis.Client created by redis.NewClient(...) as parameter. Package users can also develop their own implementations if they need to.

gokv doesn't just have to be used to satisfy some gokv.Store parameter. It can of course also be used by application / web service developers who just don't want to dive into the sometimes complicated usage of some key-value store packages.

Initially it was developed as storage package within the project ln-paywall to provide the users of ln-paywall with multiple storage options, but at some point it made sense to turn it into a repository of its own.

Before doing so I examined existing Go packages with a similar purpose (see Related projects), but none of them fit my needs. They either had too few implementations, or they didn't automatically marshal / unmarshal passed structs, or the interface had too many methods, making the project seem too complex to maintain and extend, proven by some that were abandoned or forked (splitting the community with it).

Design decisions

  • gokv is primarily an abstraction for key-value stores, not caches, so there's no need for cache eviction and timeouts.
    • It's still possible to have cache eviction. In some cases you can configure it on the server, or in case of Memcached it's even the default. Or you can have an implementation-specific Option that configures the key-value store client to set a timeout on some key-value pair when storing it in the server. But this should be implementation-specific and not be part of the interface methods, which would require every implementation to support cache eviction.
  • The package should be usable without having to write additional code, so structs should be (un-)marshalled automatically, without having to implement MarshalJSON() / GobEncode() and UnmarshalJSON() / GobDecode() first. It's still possible to implement these methods to customize the (un-)marshalling, for example to include unexported fields, or for higher performance (because the encoding/json / encoding/gob package doesn't have to use reflection).
  • It should be easy to create your own store implementations, as well as to review and maintain the code of this repository, so there should be as few interface methods as possible, but still enough so that functions taking the gokv.Store interface as parameter can do everything that's usually required when working with a key-value store. For example, a boolean return value for the Delete method that indicates whether a value was actually deleted (because it was previously present) can be useful, but isn't a must-have, and also it would require some Store implementations to implement the check by themselves (because the existing libraries don't support it), which would unnecessarily decrease performance for those who don't need it. Or as another example, a Watch(key string) (<-chan Notification, error) method that sends notifications via a Go channel when the value of a given key changes is nice to have for a few use cases, but in most cases it's not required.
    • Note: In the future we might add another interface, so that there's one for the basic operations and one for advanced uses.

  • Similar projects name the structs that are implementations of the store interface according to the backing store, for example boltdb.BoltDB, but this leads to so called "stuttering" that's discouraged when writing idiomatic Go. That's why gokv uses for example bbolt.Store and syncmap.Store. For easier differentiation between embedded DBs and DBs that have a client and a server component though, the first ones are called Store and the latter ones are called Client, for example redis.Client.
  • All errors are implementation-specific. We could introduce a gokv.StoreError type and define some constants like a SetError or something more specific like a TimeoutError, but non-specific errors don't help the package user, and specific errors would make it very hard to create and especially maintain a gokv.Store implementation. You would need to know exactly in which cases the package (that the implementation uses) returns errors, what the errors mean (to "translate" them) and keep up with changes and additions of errors in the package. So instead, errors are just forwarded. For example, if you use the dynamodb package, the returned errors will be errors from the "github.com/aws/aws-sdk-go package.
  • Keep the terminology of used packages. This might be controversial, because an abstraction / wrapper unifies the interface of the used packages. But:
    1. Naming is hard. If one used package for an embedded database uses Path and another Directory, then how should be name the option for the database directory? Maybe Folder, to add to the confusion? Also, some users might already have used the packages we use directly and they would wonder about the "new" variable name which has the same meaning.
      Using the packages' variable names spares us the need to come up with unified, understandable variable names without alienating users who already used the packages we use directly.
    2. Only few users are going to switch back and forth between gokv.Store implementations, so most user won't even notice the differences in variable names.
  • Each gokv implementation is a Go module. This differs from repositories that contain a single Go module with many subpackages, but has the huge advantage that if you only want to work with the Redis client for example, the go get will only fetch the Redis dependencies and not the huge amount of dependencies that are used across the whole repository.

Related projects

  • libkv
    • Uses []byte as value, no automatic (un-)marshalling of structs
    • No support for Redis, BadgerDB, Go map, MongoDB, AWS DynamoDB, Memcached, MySQL, ...
    • Not actively maintained anymore (3 direct commits + 1 merged PR in the last 10+ months, as of 2018-10-13)
  • valkeyrie
    • Fork of libkv
    • Same disadvantage: Uses []byte as value, no automatic (un-)marshalling of structs
    • No support for BadgerDB, Go map, MongoDB, AWS DynamoDB, Memcached, MySQL, ...
  • gokvstores
    • Only supports Redis and local in-memory cache
    • Not actively maintained anymore (4 direct commits + 1 merged PR in the last 10+ months, as of 2018-10-13)
    • 13 stars (as of 2018-10-13)
  • gokv
    • Requires a json.Marshaler / json.Unmarshaler as parameter, so you always need to explicitly implement their methods for your structs, and also you can't use gob or other formats for (un-)marshaling.
    • No support for Consul, etcd, bbolt / Bolt, BadgerDB, MongoDB, AWS DynamoDB, Memcached, MySQL, ...
    • Separate repo for each implementation, which has advantages and disadvantages
    • No releases (makes it harder to use with package managers like dep)
    • 2-7 stars (depending on the repository, as of 2018-10-13)

Others:

  • gladkikhartem/gokv: No Delete() method, no Redis, embedded DBs etc., no Git tags / releases, no stars (as of 2018-11-28)
  • bradberger/gokv: Not maintained (no commits in the last 22 months), no Redis, Consul etc., no Git tags / releases, 1 star (as of 2018-11-28)
    • This package inspired me to implement something similar to its Codec.
  • ppacher/gokv: Not maintained (no commits in the last 22 months), no Redis, embedded DBs etc., no automatic (un-)marshalling, 1 star (as of 2018-11-28)
    • Nice CLI!
  • kapitan-k/gokvstore: Not actively maintained (no commits in the last 10+ months), RocksDB only, requires cgo, no automatic (un-)marshalling, no Git tags/ releases, 1 star (as of 2018-11-28)
Owner
Philipp Gillé
Software engineer, progressive, cosmopolitan, globalist, futurist, technology maximalist - interested in #technology #innovation #blockchain #bitcoin #lightning
Philipp Gillé
Comments
  • Implement combiner package

    Implement combiner package

    Implements a combiner package that allows you to create a gokv.Store which forwards its call to multiple implementations at the same time. So for example you can use memcached and s3 simultaneously to have 1) super fast access but also 2) durable redundant persistent storage.

    Usage is included in the godoc. At the moment, we are missing unit tests for the new package.

  • Use Mage as build tool

    Use Mage as build tool

    With this PR we migrate from the Bash and PowerShell scripts for building/testing to Mage. This way it doesn't matter anymore on which platform you work with gokv - instead of running either the PowerShell or the Bash script, mage <target> should always work.

    Some build targets still make use of pre-existing scripts, but others are replaced:

    • mage update runs the existing build/update-deps.ps1/.sh scripts for updating the dependencies of all modules
    • mage build builds all modules via existing build/build.ps1/.sh scripts
    • mage test ... is a full reimplementation of build/test.sh in Go / in the magefile. There was no PowerShell script for running the tests on Windows, so this is a big win.
      • mage test all keeps the old behavior of testing all modules
      • mage test redis (or similar) tests just the given module, which was not implemented in the Bash script
    • mage clean deletes any code coverage output files

    Some scripts were simply removed and we don't need Mage targets for them:

    • combine-coverage.sh isn't necessary anymore. It seems that when coverage.txt files are present in various directories, Codecov can now handle all of them, without us having to combine them into a single file first
    • tidy.ps1 is not used anymore. The update-deps scripts already include a tidy step.
  • Add license scan report and status

    Add license scan report and status

    Your FOSSA integration was successful! Attached in this PR is a badge and license report to track scan status in your README.

    Below are docs for integrating FOSSA license checks into your CI:

  • Add implementation for MySQL

    Add implementation for MySQL

    While PostgreSQL is more popular among Gophers and maybe generally among projects with higher requirements (performance, features), MySQL is still the most popular open source relational database (management system).

    It's SQL, so not a key-value store, but that doesn't keep us from creating a table like Item with a k text column as primary key and v blob column, or something like that.

    It might be of use for people who already run MySQL and want to use gokv for simple key-value storage.

    Also, TiDB is compatible with the MySQL protocol, so as long as there aren't any major differences (some required client-side configuration for example) and it works, this would be a plus (TiDB is a popular "NewSQL" databases).

  • Upgraded Hazelcast Go Client to v1.3.0

    Upgraded Hazelcast Go Client to v1.3.0

    Hi Philipp, thanks for this cool project and including Hazelcast as an option to your users.

    We've released Hazelcast Go Client v1.3.0 last month with important bug fixes (and new cool features!). Here's what was changed since v1.2.0:

    • https://github.com/hazelcast/hazelcast-go-client/releases/tag/v1.2.1
    • https://github.com/hazelcast/hazelcast-go-client/releases/tag/v1.3.0

    This PR upgrades Hazelcast Go Client v1.2.0 to v1.3.0,

    Starting with v1.3.0, we added support for the Near Cache, which keeps the map entries in memory and helps tremendously with read heavy workloads: https://pkg.go.dev/github.com/hazelcast/hazelcast-go-client#Map I am sure that's a feature your users can benefit from.

    In your Hazelcast related code, you have this remark:

    // TODO: When a Hazelcast server dies and the client creates new connections to the new server, // does the map still work or do we need to get the map from the client again?

    The answer is: Hazelcast Go Client handles this internally, no need to get the map again.

    I also noticed that logging is turned off for the Hazelcast client with config.Logger.Level = logger.OffLevel In case you'd like to customize the output or use a different logger, It is possible to override it: https://pkg.go.dev/github.com/hazelcast/[email protected]/logger#hdr-Using_a_Custom_Logger

    The gokv API is very clean and easy to use, but I would strongly suggest adding context support to it. Hazelcast Go Client supports it for all of its API, and it turned out to be a useful feature for our own users.

    In case you'd like to join, we have our own Slack channel at: https://hazelcastcommunity.slack.com/channels/go-client You can get an invite at: https://slack.hazelcast.com/

    Thanks again for your work!

  • Add expiration support

    Add expiration support

    #86

    Defines two new interfaces:

    type SetterWithExp interface {
    	SetExp(k string, v interface{}, exp time.Duration) error
    }
    

    and

    type Cache interface {
    	Store
    	SetterWithExp
    }
    

    implemented for

    • Redis
    • Memcached
    • Freecache
    • Hazelcast
    • BadgerDB
    • etcd
  • Close stores/clients and delete local files after tests

    Close stores/clients and delete local files after tests

    Closes #40.

    The test doesn't delete anything when the test server runs in Docker, because the containers are ephemeral (--rm) anyway (at least they're started that way on Travis CI and they should be started that way locally as well).

    One future improvement could be to also delete all key-value pairs / buckets / tables from the cloud services, because only testing with the emulators isn't enough, so every now and then the real cloud services are tested with the existing test code. When the key-value pairs aren't deleted in that case, this can lead to storage costs.

  • Add gokv.Store implementation for Apache Ignite

    Add gokv.Store implementation for Apache Ignite

    Apache Ignite seems to be one of the most popular multi-model open source databases. It has a key-value store mode, which seems to be meant to be used as cache, but Apache Ignite seems to be doing everything in-memory first, and then use their "durable memory" or "persistence" components to achieve durability.

    The key-value store mode is JCache compliant, see:

    Is Ignite a key-value store?

    Yes. Ignite provides a feature rich key-value API, that is JCache (JSR-107) compliant and supports Java, C++, and .NET.

    And: https://ignite.apache.org/use-cases/database/key-value-store.html

    The latter link includes the following bullet point regarding the JCache specification:

    • Pluggable Persistence

    So this seems to be the optimal way to use Ignite, but on the other hand there don't seem to be any Go packages for JCache. But then again, Ignite supports the Redis protocol (see here), has its own binary protocol (see here) and even a REST API (see here).

    • https://ignite.apache.org/index.html
    • https://apacheignite.readme.io/docs
    • https://apacheignite.readme.io/docs/data-grid
    • https://apacheignite.readme.io/docs/jcache
    • https://apacheignite.readme.io/docs/durable-memory
    • https://apacheignite.readme.io/docs/distributed-persistent-store
  • S3: don't require attempt to create bucket in s3.NewClient

    S3: don't require attempt to create bucket in s3.NewClient

    A service will fail with s3.NewClient() at https://github.com/philippgille/gokv/blob/master/s3/s3.go#L228-L231 when a service does not have permission to create an S3 bucket resulting in error:

    AccessDenied: Access Denied
    	status code: 403, request id: EPNQB6MRQ3KGSD2P, host id: nUu8pPdr5eWKjAn6PLg2fuNxyZnflz+UcwnnfUn3584LfcMTqCCQcV95Nw+Nb7k1B8l9hxmkrEo=
    

    In this use case, the bucket has already been created elsewhere, so the service has limited s3.GetObject, s3.PutObject, s3.DeleteObject type permissions.

    A non-breaking fix could be an option like https://github.com/philippgille/gokv/pull/101 provides to skip the create bucket attempt. While I recognize the create bucket attempt is there to ease usability, testing, and compatibility with non-S3 services, it does run counter to least-privilege and least-surprise patterns.

    Another non-breaking fix could be to change the logic in s3.NewClient() for origS3 to see if the bucket already exists before creating with ListBuckets, but that can also result in a 403 for this use case. You could also just handle the 403 errors from CreateBucket, ListBuckets, etc by not failing and attempting to proceed with the client.

    A breaking fix I would propose would be to default to no unnecessary S3 calls in s3.NewClient() and to explicitly pass the option in if you wanted to try creating, listing, validating the bucket first.

    Thank you for this very cool module I stumbled upon :)

  • Expose more features in the Hazelcast client

    Expose more features in the Hazelcast client

    As per https://github.com/philippgille/gokv/pull/112, since hazelcast-go 1.3 there's now near-cache in the Go library, so we can expose that in the gokv implementation. We can also give the user more control over the logger.

    Regarding the other points in the description, that's taken care of (the "TODO" comment and the GitHub Actions improvement), or will be taken care of in a future major change (context param).

  • s3: Add option to bypass CreateBucket

    s3: Add option to bypass CreateBucket

    Multiple simultaneous calls (use case was multiple gokv-backed CLI utilities in a pipeline) to NewClient causes an error:

    A conflicting conditional operation is currently in progress against this resource.
    

    This occurs for S3 CreateBucket. Relying on the error to be awss3.ErrCodeBucketAlreadyOwnedByYou is fine, but the operation will still block other callers. This patch provides a mechanism to bypass bucket creation.

Examples and code to assign a name to your MongoDB, MySQL, PostgreSQL, RabbitMQ, and redis connection.
Examples and code to assign a name to your MongoDB, MySQL, PostgreSQL, RabbitMQ, and redis connection.

your connection deserves a name ?? When your app interacts with an external system, assign a name to the connection. An external system in this contex

Dec 14, 2022
Go-mongodb - Practice Go with MongoDB because why not

Practice Mongo DB with Go Because why not. Dependencies gin-gonic go mongodb dri

Jan 5, 2022
Go Memcached client library #golang

About This is a memcache client library for the Go programming language (http://golang.org/). Installing Using go get $ go get github.com/bradfitz/gom

Jan 8, 2023
expressive DynamoDB library for Go

dynamo is an expressive DynamoDB client for Go, with an easy but powerful API. dynamo integrates with the official AWS SDK.

Dec 29, 2022
Go driver for PostgreSQL over SSH. This driver can connect to postgres on a server via SSH using the local ssh-agent, password, or private-key.

pqssh Go driver for PostgreSQL over SSH. This driver can connect to postgres on a server via SSH using the local ssh-agent, password, or private-key.

Nov 6, 2022
GoBigdis is a persistent database that implements the Redis server protocol. Any Redis client can interface with it and start to use it right away.

GoBigdis GoBigdis is a persistent database that implements the Redis server protocol. Any Redis client can interface with it and start to use it right

Apr 27, 2022
Golang client for redislabs' ReJSON module with support for multilple redis clients (redigo, go-redis)

Go-ReJSON - a golang client for ReJSON (a JSON data type for Redis) Go-ReJSON is a Go client for ReJSON Redis Module. ReJSON is a Redis module that im

Dec 25, 2022
Redis client Mock Provide mock test for redis query

Redis client Mock Provide mock test for redis query, Compatible with github.com/go-redis/redis/v8 Install Confirm that you are using redis.Client the

Dec 27, 2022
Bxd redis benchmark - Redis benchmark tool for golang

使用 redis benchmark 工具, 测试 10 20 50 100 200 1k 5k 字节 value 大小,redis get set 性能。 r

Jan 22, 2022
Mongo Go Models (mgm) is a fast and simple MongoDB ODM for Go (based on official Mongo Go Driver)
Mongo Go Models (mgm) is a fast and simple MongoDB ODM for Go (based on official Mongo Go Driver)

Mongo Go Models Important Note: We changed package name from github.com/Kamva/mgm/v3(uppercase Kamva) to github.com/kamva/mgm/v3(lowercase kamva) in v

Jan 2, 2023
Books-rest api - Simple CRUD Rest API architecture using postgresql db with standard Library

books-rest_api Simple CRUD Rest API architecture using postgresql db with standa

Feb 8, 2022
A MongoDB compatible embeddable database and toolkit for Go.
A MongoDB compatible embeddable database and toolkit for Go.

lungo A MongoDB compatible embeddable database and toolkit for Go. Installation Example Motivation Architecture Features License Installation To get s

Jan 3, 2023
The MongoDB driver for Go

The MongoDB driver for Go This fork has had a few improvements by ourselves as well as several PR's merged from the original mgo repo that are current

Jan 8, 2023
The Go driver for MongoDB
The Go driver for MongoDB

MongoDB Go Driver The MongoDB supported driver for Go. Requirements Installation Usage Bugs / Feature Reporting Testing / Development Continuous Integ

Dec 31, 2022
Qmgo - The Go driver for MongoDB. It‘s based on official mongo-go-driver but easier to use like Mgo.

Qmgo English | 简体中文 Qmgo is a Go driver for MongoDB . It is based on MongoDB official driver, but easier to use like mgo (such as the chain call). Qmg

Dec 28, 2022
💲 Golang, Go Fiber, RabbitMQ, MongoDB, Docker, Kubernetes, GitHub Actions
💲 Golang, Go Fiber, RabbitMQ, MongoDB, Docker, Kubernetes, GitHub Actions

Bank Projeto para simular empréstimos financeiros em um banco para clientes Tecnologias Utilizadas Golang MongoDB RabbitMQ Github Actions Docker Hub D

Dec 9, 2022
Go-odm, a Golang Object Document Mapping for MongoDB.
Go-odm, a Golang Object Document Mapping for MongoDB.

A project of SENROK Open Source Go ODM Go-odm, a Golang Object Document Mapping for MongoDB. Table of contents Features Installation Get started Docum

Nov 4, 2022
Golang MongoDB Integration Examples

Get Program Get a copy of the program: git clone https://github.com/hmdhszd/Go

Feb 1, 2022
Redis powered simple OTS service - contains two endpoints, to create and find a secret

Onetimesecret This is a simple service that stores and finds your secret. Small but powerfull service - does not have any unnesseccery dependencies. H

Aug 20, 2022