 |
 |
On Mon, 12 Apr 2010, Jonathan Rochkind wrote: > So, as usual, the right tool for the job. If all you really need is a > key-value store on ID, then a "NoSQL" solution may be the right thing. But > if you need actual querrying and joining, then personally I'd stick with > rdbms unless I had some concrete reason to think a more complicated > "nosql"+solr solution was required. Certainly if you are planning on using > Solr _anyway_ because your application is a search engine of some type, that > would lessen the incremental 'cost' of a nosql+solr solution. I'm surprised that I keep hearing so much about "NoSQL" for key-value stores, and everyone seems to forget the *old* key-value stores, such as directory services (X.500 and LDAP, although that's actually the protocol used to query them, not the storage implementation). Yes, there are things that LDAP doesn't do so well (relationships being one of them), but it supports querying, you can adjust the matching by attribute (ie, this one's matched as a number, this one's matched as a string, this one's a case insensitive string ... I think some implementations have functionality to run the search term through a functions for things like soundex, so it might be possible add hooks for stemming and query expansion, etc.) I think that NoSQL got a lot of press because of Google having used it (and their having a *VERY* large data system -- but not everyone has that large of a system; also, Google did it 10+ years ago -- you can now through a lot more CPU and RAM at an RDBMS, so the point at which the database becomes a problem isn't the same as it was when Google first came out.) ... So, I think that there are cases where NoSQL is the right solution for the job, and I think there are times when an DRBMS is the right solution ... there are also plenty of times for flat file databases, XML, LDAP, and a slew of other storage standards. -Joe hmm ... now I'm going to have to try to bring back my attempt to put my catalogs into a directory service ... I have a feeling I'm going to run into issues with unit conversions when searching.