greg/hanoidb
1
0
Fork 0
Code Issues 10 Pull requests 3 Projects Releases Packages Wiki Activity

Status, numbers, uses and unicorns #20

New issue
Open
opened 2013-05-21 16:28:21 +00:00 by opensam · 1 comment
opensam commented 2013-05-21 16:28:21 +00:00 (Migrated from github.com)
Copy link

Hello,

hanoidb is cool for me : it "just works(TM)", it KISS heart, it may OTP and spawn rainbows. So first thank you contributors for this nice software.

I'd like to know more about the project status, real life use cases, QA feedback, fun and experiments.
I see the TODO file as a roadmap. But I don't understand its timescale or even if it is up-to-date.
I've heard about the existence of hanoidb riak rings but nothing more.

How "mature" is hanoidb today ? (it seems quite debug-ed)
What is its feature scope about data scale ? for example can a 4-cores node handle 2Terabytes of data ? under which latency, which concurrency, which R/W pattern ? max number of keys, max length of value, max whatelse ?
Are those hanoidb backed riak rings handling dozen of Terabytes ? How is the integration with riak working ? (failure handling, read repair, 2i, MP, etc)

Are there some success stories to be shared ? Which use cases, which numbers ?
I can't be the sole fan of this pure Erlang jewel ;-)

Side questions :
what are happy users of transactions saying ?
what are happy users of expiry saying ?
And where the project is heading ? (in case it has not yet reached perfection)

Thanks again

Hello, hanoidb is cool for me : it "just works(TM)", it KISS heart, it may OTP and spawn rainbows. So first thank you contributors for this nice software. I'd like to know more about the project status, real life use cases, QA feedback, fun and experiments. I see the TODO file as a roadmap. But I don't understand its timescale or even if it is up-to-date. I've heard about the existence of hanoidb riak rings but nothing more. How "mature" is hanoidb today ? (it seems quite debug-ed) What is its feature scope about data scale ? for example can a 4-cores node handle 2Terabytes of data ? under which latency, which concurrency, which R/W pattern ? max number of keys, max length of value, max whatelse ? Are those hanoidb backed riak rings handling dozen of Terabytes ? How is the integration with riak working ? (failure handling, read repair, 2i, MP, etc) Are there some success stories to be shared ? Which use cases, which numbers ? I can't be the sole fan of this pure Erlang jewel ;-) Side questions : what are happy users of transactions saying ? what are happy users of expiry saying ? And where the project is heading ? (in case it has not yet reached perfection) Thanks again
opensam commented 2014-03-10 18:30:33 +00:00 (Migrated from github.com)
Copy link

Bump. Anyone here for some feedback ?

Bump. Anyone here for some feedback ?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
krab-improve-specs
krab-backend-api
krab-add-expiry
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: greg/hanoidb#20
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?