benblack

I've recently discovered that when you know almost nothing about the problem someone is trying to solve it is both easy and attractive to speculate about how much better your solution is than the one reached by the people who have to solve it. Full time. For money. I see you have discovered the same. Great minds think alike?

- Lil' B

"In a replica set configuration, all reads and writes are routed to the master by default. In this scenario, consistency is guaranteed."

One would hope that reading and writing a single node database was consistent. This is table stakes for something calling itself a persistent store. Claiming partition tolerance in the above is the same as claiming availability. The former claim has been made. Rest left as exercise for the reader.

Namasté.

- Lil' B

I was not aware that BigTable worked that way, but it doesn't change my original point about "C != C". That a given NoSQL system is architected for both does not imply that such a design is always desirable or representative of the NoSQL database space. It is not and it is not. Thank you for your kind and compassionate suggestions about signing comments.

- Lil' B

Thanks for bringing some much needed science to these proceedings, my man. Too many people mistaking computer science for a therapy session where their feelings matter. Computer science has much in common with the honey badger. Think upon this and be enlightened.

Yours in perpetual discovery, - Lil' B

They really are that different, and I hear 10gen is hiring. Increase the peace.

- Lil' B

If a slave can continue serving reads whilst partitioned from a master that continues to accept writes then you cannot guarantee consistency. If a slave cannot serve reads when partitioned then you aren't available. If a master cannot accept writes when partitioned then you aren't available. See this excellent post from Coda Hale on why it is meaningless to claim a system is partition tolerant http://codahale.com/you-cant-sacrifice-partition-tolerance/.

One love.

- Lil' B

To some commenters: the C in CAP and the C in ACID are not the same thing. If that is not clear to you, it is unlikely the database you develop will include correct implementations of core concepts. Knowledge is power.

Peace and love to the human family.

- Lil' B

Thanks for the comments, Jorge. What you describe as a fundamental flaw is perhaps better described as a careful engineering trade-off. AtomicMap is intended for specific use cases. If you are not dealing with an extremely high throughput, high concurrency write system, then AtomicMap may not be the right choice for you. If you are dealing with complicated write semantics that are likely to raise exceptions, AtomicMap may not be the right choice for you. In our application, we have a lot of threads writing at once. Exceptions in that path would indicate a pretty significant problem, far worse than how to handle them gracefully.

We have chosen to trade some flexibility in how the data structure can be used in exchange for an enormous increase in throughput. Your needs may differ, resulting in different trade offs.

Oddly similar to my article in GigaOm last year. http://gigaom.com/cloud/nosql-is-for-the-birds/

As explained in the post, the minority side of the partition is not writable.

(Reposting my blog comment here)

"I mean primarily the ability to face a network partition and continue providing write service to all clients transitively connected to a majority of servers. Secondarily, I mean the ability to continue providing read-only service to all clients connected to any server."

A truly available system, in the sense of CAP, allows writes, not just reads, even under partition, even for clients not connected to the "majority" nodes. This leads inevitably to the need for conflict detection and resolution, and that whole "eventually consistent" thing. What you are describing is very useful, hence the existence of things like Chubby and ZK, but is most definitely not "available", per CAP.

Folks might also be interested in the classic paper on constructing locks from low level primitives like CAS, Herlihy's 'Wait-free Synchronization" http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A01...

+1

"does he thinks that at least object oriented programming is more naturally understandable by developers? The question is about how they might use, say, OO DBs with more understanding. may we say that OO approach in programming is much less alien that map-reduce things? because if we say 'people don't understand', then they might even don't understand some other part of their programming job."

OO is not natural, in my opinion, it is simply popular for a variety of reasons way outside the scope of this interview. There is no free lunch: regardless of paradigm, the best developers have a deep understanding of what is going on inside and under their applications, where that includes things like the databases on which they depend, the networks on which they depend, etc.

Was this comment produced by a Markov generator? No part of it makes any sense.

This article is mostly marketing phrases from the websites of the various projects. Sadly, much of it is inaccurate, extremely skewed, or otherwise not useful for the stated purpose of comparing the listed databases.

For example, CouchDB having a "Main Point" of "DB consistency" might be the case, as it is for Redis, when there is no replication. In replicated configurations, it is definitely not true. Further, the MVCC is weaker in many ways than in a Dynamo system like Riak as you have no way to influence or discover consistency between replicas.

I'm sure folks expert in other systems can identify similar errors in the rest of the post. Can someone explain to me who the target audience is for all these NoSQL comparison articles? They are universally poor, yet universally popular.

Google, like almost any other company of sufficient size, has a problem retaining great engineers who prefer smaller companies. Those preferences are not about the false dichotomy between "engineers" and "entrepreneurs". Mr. Ts'o enjoys a job in an established company where he can be paid well, work only on specific technical problems, work reasonable hours, etc. That's a fine choice, and the right one for many. It is, however, still exactly that: a job. People who start companies are not often looking for another job. Mr. Ts'o should be thankful that is so. Had Larry and Sergey taken his advice the company for which he works would not exist.

So many useful links in this discussion, I consolidated them (and a few extras) here http://post.b3k.us/modern-parsing-bibliography

Minor correction: the current draft is http://tools.ietf.org/html/draft-ietf-tcpm-initcwnd-00

I enjoyed it when I first read it a couple of years ago and the recent blog post from tsuna on context switching reminded me of it (http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...). Glad to see some other folks like it, as well.

CouchApp really is excellent marketing, folks, and I congratulate you. As I'm sure you know, any database with an HTTP interface will do exactly the same thing. Riak, for example. I leave you to your normal round of thoughtful, reasoned NoSQL vs RDBMS debate.

I think I see your confusion. The headline is not the message thread. It's a link you need to click. Then you can read the actual message thread. Hope this helps!

Show us on the doll where NoSQL touched you.

"A good friend deep in the security community once told me, off hand, that EC2 was "owned." I didn't take this too seriously until another good friend, who has been working at Amazon for the past several years, told me that engineers at Amazon were generally forbidden from using AWS due to security concerns."

"EDIT: To clarify, I'm not suggesting that Amazon knows AWS is "owned" and offers it to others anyway. I'm only noting that, for certain critical services, they themselves do not appear willing to take the risk."

I may not be the smartest guy, but it seems to me that's exactly what you are saying.

That certain services can't yet be moved to AWS is not an an indicator AWS is compromised. Several services, for example the payments infrastructure, are subject to regulations that make it challenging to implement _at all_, much less in a shared environment like AWS. Again, this is not an argument that AWS is compromised, and teams at Amazon are absolutely using AWS.

Both you and your friend are misinformed.

"...told me that engineers at Amazon were generally forbidden from using AWS due to security concerns."

The opposite is the case: there has been a huge push for some time to move (significant) parts of Amazon retail to AWS. It's extremely complex and service quality is paramount, so it takes a while to make it all happen.

It seems unlikely most users on the Internet could even parse your suggestion, much less execute it. That doesn't make them stupid, just not experts in the subject. Instead they rely on experts, like you, to make the right choices for them in these esoteric matters. While there are any number of ways you might solve this problem, HTTPS is the best available option since clients and servers already support it. As ericflo is pointing out, a small number of sites deploying HTTPS would go a long way to achieving the goal of a more secure Internet for all.

I'm very excited to see where this sort of pattern goes. Swiss-army knife middleware projects are much less interesting to me than the more minimalist approach possible directly using 0MQ.

From the VoltDB FAQ (http://community.voltdb.com/faq#id545596):

Key-Value stores are a mechanism for storing arbitrary data (i.e. values) based on individual keys. Distributing Key-Value stores is simple, since there is only one key. However, there is no structure within the data store and no transactional reliability provided by the system.