full-text indexing does come with a cost, sometimes related to write speed.<br><br>depending on how you want to balance these factors, and if text-search is important (since it's your 8th point i'm not sure whether you can cross it out or not), you may consider:<br>
<br>. riak with riak-search [as already suggested];<br>. solr (<a href="http://lucene.apache.org/solr/">http://lucene.apache.org/solr/</a>)<br><br>both are fast, have a JSON interface, and should answer your needs.<br><br>
r.<br><br><br><div class="gmail_quote">2011/8/31 Joe Armstrong <span dir="ltr"><<a href="mailto:erlang@gmail.com">erlang@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Aug 31, 2011 at 4:09 PM, Kevin Smith <<a href="mailto:kevin@hypotheticalabs.com">kevin@hypotheticalabs.com</a>> wrote:<br>
> How important is queryability? Would you want to use qlc, SQL, MapReduce, or something else to write the queries?<br>
<br>
</div>Not really. My order of priorities is:<br>
<br>
1) Ease of install<br>
    "working out of the box" and "a few files" is important<br>
    I don't want lot's of files scattered all over the place<br>
    Entire database in one blob is nice (like SQLite)<br>
    should run forever on my machine without bothering me once installed<br>
2) Easy management<br>
    "it just works" - nice to have a web interface.<br>
3) Low storage overhead - don't be too profligate with storage<br>
4) Fast (ish) key-value storage. over 5K reads/writes/sec is fine<br>
5) Crash resiliant<br>
6) Can be controlled via a socket interface<br>
7) indexing or secondary keys<br>
8) full-text indexing<br>
9) Relational queries less important - I'm kind of used to Key-Value queries<br>
    and designing data structures round them<br>
<font color="#888888"><br>
/Joe<br>
</font></blockquote></div>