31–40 of 96 posts
You mention that some of these solution could be used in the Financial industry. I would be cautious of using these, especially since some are eventually consistent. If you are just tracking data these may be fine though.
> While SQL databases are insanely useful tools, their tyranny of ~15 years is coming to an end This shit, AGAIN? Really? No, they are not.
Yea, I knew the post would be vacuous when I hit "tyranny", but I guess the flourishes makes good HN bait to speak in sweeping terms like that. There's little about on-disk consistency and data loss risks, scale characteristics yet there's coverage of the wire protocol? Meh. Sure, I'm glad to have a lot of these tools available, the bad old days of rolling your stuff with Berkeley DB or NDBM seem safely behind us but…
I'm old enough to remember somebody being threatened with firing for using SQL, because of it's bad performance compared with seeking. :)
My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated). However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See: http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...
Where couchdb has some immense possibilities is in distributed applications, not only server side, but also mobile phones and browsers. Since you can write and contain an entire webapp inside of couchdb, you can technically replicate the entire app to your mobile phone, and it'd work offline or online. And if you need your app on another platform--as long as it has couchdb, you can just replicate it there.
I never see this mentioned in any overviews of comparison for couchdb.
The sticking point right now, though, is that couchdb isn't on very many mobile platforms. There has only been experiments with writing couchdb on top of HTML5's localStore, and jChris et al are working on Couchdb for android.
Earlier quoted context omitted.
I'd rather know about these superficialities than know nothing at all.
I agree. And I think superficiality is different than generality or summary. It's a summary. And I appreciate the effort of some one taking the time to put their work online.
K.
Apples vs Oranges vs Strawberries vs Pineapple vs Grapes Apples usually stay crispy unless baked. Good in pies. Oranges can be sour (or sweet). Do not bake. Strawberries are red. Good in pies, advise against baking. Pineapples are rough on the outside. Good fresh, baked, grilled, fried, debatable on pizza. Grapes come in many colors and sizes. Great fresh or turned into alcoholic beverages. (Not the worst introductio…
Perhaps it is. I still hope that it's useful :)
Proverbial Apples to Oranges problem
My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated). However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See: http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...
This is probably the biggest misunderstanding of couchdb, imo. The versioning system in couchdb is only there to make the seamless replication possible. There's no guarantee that previous versions will exist at a future time, like in git. Where couchdb has some immense possibilities is in distributed applications, not only server side, but also mobile phones and browsers. Since you can write and contain an entire web…
Keep up the good work!
You mention that some of these solution could be used in the Financial industry. I would be cautious of using these, especially since some are eventually consistent. If you are just tracking data these may be fine though.
I agree with that, but you know, it's very hard to find good examples. :) I'm open to better suggestions :)
- Facebook designed it for inbox feature - - SOLR/Lucene is being integrated - recently Sequoia backed Riptano - see http://www.riptano.com/
Under protocols you may want to specify MongoDB's as BSON and Cassandra's as Thrift. That would be more helpful than "binary/custom". Updated: Also Redis's main selling point is it's extensive data structure/operations support. "Blazingly fast" really depends on what your workload is and what you're comparing it against.
Protocols: great idea, thanks man, amended it! Blazing fast: I mean compared to the other four.
In memory operations are fast in many databases. Redis's default configuration (vm-enabled no) just only does operations in memory (with an occasional sync to disk). That's terrible durability but fantastic performance. Most databases, including Redis, can be configured for either that sort of high-performance/low-durability or the opposite. It's just that their default settings/behaviors vary widely.
My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated). However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See: http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...
thanks. latest version of the article is here now http://blog.couchone.com/post/632718824/simple-document-vers...
> While SQL databases are insanely useful tools, their tyranny of ~15 years is coming to an end This shit, AGAIN? Really? No, they are not.
With AppEngine at Google, MongoDB at Disqus, Cassandra at Facebook and Redis at Github you can definitely say that SQL databases are one of many options available today and don't dominate like they did 5 years ago.