karmi

Part practical demonstration of differences between lexical and semantic search in Elasticsearch, with a Sentence Transformer model and the Quora dataset, part text embeddings explanation using Saussure's theory of language.

Have a look here: https://github.com/elasticsearch/elasticsearch-rails/tree/ma... -- it offers a "repository" based approach to persistence. An "ActiveRecord-like" pattern is being actively working on in the `persistence-model` branch (https://github.com/elasticsearch/elasticsearch-rails/pull/91)

Try http://codeclimate.com

Link to the Ember Data adapter: https://github.com/karmi/ember-data-elasticsearch/, link to the gist with Goliath proxy for Twitter @Anywhere authentication: https://gist.github.com/3369662#file_proxy.rb

That's legitimate concern -- you can of course put an Nginx proxy in front of elasticsearch to deny DELETE requests (see eg. http://www.elasticsearch.org/tutorials/2012/03/21/deploying-...)

But wait for an article at the http://elasticsearch.org blog with an example of a more sophisticated, Ruby-based proxy.)

Check out the example application as well: https://github.com/karmi/ember-data-elasticsearch/tree/maste...

Also, don't forget to check the ecosystem around elasticsearch: clients, integration, Puppet & Chef manifests/recipes, etc: http://www.elasticsearch.org/guide/appendix/clients.html

Cubism is pretty easy to work with, or? See my heavily annotated sketch of continuous polling with Cubism; http://bl.ocks.org/2689616

Running ElasticSearch on AWS is pretty easy, see http://www.elasticsearch.org/tutorials/2012/03/21/deploying-...

While I understand where you're coming from, Max, this is really dangerous delusion. Couch just lost the drive it had in the beginning, for whatever reasons, crazy focus on "data liberation" and cell phones included.

That said, I agree with @dasil003 above that Couch played a irreplaceable role in getting people on the NoSQL track. I speak from my own experience. Compared to Mongo, Couch allowed me to wrap my head about design differences in the NoSQL world.

It's sad to see Couch fade into obscurity, but hey!, it's initial drive, it's original story (cf. the Rubyfringe video of Damien's talk), is an important part of "NoSQL archeology" for me.

> Each modification generates a new version of the document. (...) we don’t need it, and there’s no way to disable it (...)

Note that there's a `_revs_limit` setting available: <http://wiki.apache.org/couchdb/HTTP_database_API>. It's very beneficial for a use case like yours.

(Though I've seen CouchDB performing rather poorly when taking really heavy read/write load or compacting big datasets, on occasion.)