11–20 of 20 posts
Wah. I was hoping for something more interesting than S3 for persistence of the key / values...as kenneth seems to have very novel and interesting takes on things.
Unless I'm mistaken, it's using ElasticSearch, not S3. It's, effectively, a niche ElasticSearch API tailored to key/value storage.
Neat and I love the name! Who said elephants can't be agile & fast?
I was expecting something like a Solr or an ElasticSearch, but this is more an application that limits what you can get out of a more powerful backend. I don't see why I would want that other than to encourage devs to become experts on a key-value store instead of learning the more complex internals. That's pretty much shooting yourself in the foot in terms of extensibility and flexibility. Better to know ElasticSearch and use it as a KV store than the other way around.
Earlier quoted context omitted.
Unless I'm mistaken, it's using ElasticSearch, not S3. It's, effectively, a niche ElasticSearch API tailored to key/value storage.
Elastic for the searching, but S3 for the persistence it appears. AWS credentials are even "expected" per the readme.
Very cool, would be great to outline why one would use something like as opposed to say Riak.
Here all you need it S3(scales indefinitely) + 1 elasticache instance.
Very cool, would be great to outline why one would use something like as opposed to say Riak.
Earlier quoted context omitted.
To run Riak in production you need 5 servers. Here all you need it S3(scales indefinitely) + 1 elasticache instance.
Why 5? We have a riak cluster running of 3.
Very cool, would be great to outline why one would use something like as opposed to say Riak.
To run Riak in production you need 5 servers. Here all you need it S3(scales indefinitely) + 1 elasticache instance.
There are things that are missing that are nice about Riak. Mainly libraries, map reduce, 2i, and solr-like text search.
This project definitely interesting for what it is though.