Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Serenity feature and ideas discussion (poll) #7

Open
pmwkaa opened this issue Jul 31, 2015 · 2 comments
Open

Serenity feature and ideas discussion (poll) #7

pmwkaa opened this issue Jul 31, 2015 · 2 comments

Comments

@pmwkaa
Copy link
Owner

pmwkaa commented Jul 31, 2015

Hi everyone,
This is an open discussion about features and commands that would be nice to have next in Serenity.

So, here are some ideas:

Storage procedures

  • JavaScript instead of Lua (i think this only make sense to be node.js compatible)
  • Lua (luajit)

Extend compatibility

  • MSET
  • MGET
  • SCAN
  • INCR/DECR (highly efficient disk-readless implementation)
  • Redis transaction model

Replication

  • master-slave compatible, support Redis Sentinel
  • Clusterization: work in a different way (region-based, raft, autosharding, distributed transactions and so on)

Protocols

  • additional memcache support

Anything Else?

  • Taking in account Serenity storage capabilities
@pyrossh
Copy link

pyrossh commented Jul 31, 2015

Scripting support should use lua since all redis like database ledisdb, nodb support lua scripting. Then all lua scripts would be it would be portable.

I think extending other redis commands is a good idea but might not as fast as other redis commands like the zrange in ledisdb is 10 times slower than the one in redis since it has to range query rocksdb unlike redis which employs skiplists for that

@dumblob
Copy link

dumblob commented Jun 6, 2019

Storage procedures: definitely Lua (it's easier to integrate and mainly maintain and it's compatible with the whole Redis ecosystem)

Extend compatibility: extending compatibility is always good - I'd say though, that until Redis-compatible transactions are not available, Serenity won't find a broad adoption

Replication: this is a difficult topic as the current Redis supports only sharding ("partitioning"), but without (!) any cross-shard transaction support which draws sharding basically unusable for standard persistent storage DBs.

So I can imagine partitioning in Sophia/Serenity as division of the key space among several instances of Sophia running e.g. on different physical machines in different geographical locations while supporting cross-partition transactions. Without transactions it doesn't make much sense to have explicit support for partitioning as the app using Sophia/Serenity can do this key space division quite easily itself. Also Sophia/Serenity shall in this case support automated transparent repartitioning in runtime (to accommodate for dynamic scaling).

Protocols: in my opinion memcache is not necessary - what would be the use case?

Anything Else?: Yes, taking in account Sophia/Serenity storage capabilities, i.e. "extensions to the Redis protocol" is definitely a good idea, but in my opinion has the lowest priority as if one wants that, than she can right from the beginning use Sophia and not Serenity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants