SSDB VS redimo.go

I've used SSDB[0] in the past for some really stupid large datasets (20TB)_and it worked really well in production

[0] https://github.com/ideawu/ssdb

> Or wanting to shift the architecture entirely to avoid using memory-bound Redis as a queue with an overflow risk.

I wanted to use SSDB[1] instead of Redis for that reason, but it doesn't support the necessary data structures.

[1] https://github.com/ideawu/ssdb

There is also ssdb https://github.com/ideawu/ssdb

It's 2021 and we have extremely fast key-value lookups using LevelDB/RocksDB, but we're still using RAM-based caching tools [1] [2] [3]. It's time to consider RAM-based caching harmful, and start caching with SSDs for larger datasets and lower costs. For ex: SSDB [4]

[1] https://redis.io/

[2] https://memcached.org/

[3] https://news.ycombinator.com/item?id=29532552

[4] https://github.com/ideawu/ssdb#ssdb-vs-redis

Aside from this particular use-case, which is what most people here are talking about -- I had never heard of the SSDB project, but it interests me because I often use Redis for certain things it's able to do, aside from its in-memory storage, and sometimes the fact that the data is not stored on disk is a bit of a drawback for me, something I have to work around.

Did this for DynamoDB over the pandemic. Helped me learn both the Redis API and DynamoDB. https://github.com/dbProjectRED/redimo.go

Want to do the same thing with Postgres as well.

The Redis API and data structures are really nice and have been tuned to be useful in a wide variety of situations. Implementing these APIs is different concurrent, compute and storage models is a nice way to learn them and get options open.

The way that I learnt the ins and outs of DynamoDB (and there is a lot to learn if you want to use it effectively) is by implementing all the Redis data structures and commands on it. That helped understand both systems in one shot.

The key concept in Dynamo is that you use a partition key on all your bits of data (my mental model is that you get one server per partition) and you then can arrange data using a sort key in that partition. You can then range/inequality query over the sort keys. That’s the gist of it.

The power and scalability comes from the fact that each partition can be individually allocated and scaled, so as long as you spread over partitions you have practically no limits.

And you can do quite a bit with that sort key range/inequality thing. I was pleasantly surprised by how much of Redis I could implement: https://github.com/dbProjectRED/redimo.go

Running a Fly app backed by DynamoDB Global Tables is an option. DDB keeps a copy of your data in all the regions you specify, each Fly instance can connect to the nearest region, and writes are propagated with eventual consistency & last write wins.

And most Redis commands can be mapped to DDB, I worked on a lib to do that.

https://github.com/dbProjectRED/redimo.go

https://github.com/sudhirj/aws-regions.go

https://aws.amazon.com/dynamodb/global-tables/

Redimo this open source project from Sudhir Jonathan that provides a library that allows you to use the Redis API on DynamoDB and bridges the two and translates the Redis API operations into space / time / cost-efficient DynamoDB API calls. Redimo is especially well suited to serverless environments, since there is no pool of connections to handle and DynamoDB is purpose-built for near-zero management use. Read the detailed README.md file to understand the nuances of this project.