Hi, The difference from traditional clustering is there is no single mysql database so failover and replication don't need to be managed manually. Cassandra is the system where writes "take some time" to propagate but the time we're talking about is almost always less than a second. The exception is when a node becomes unreachable so changes simply cannot be propagated to that node (as was shown in the video). This matter of eventual consistency is not a bug but a very important design feature of highly scalable systems. In a traditional SQL system there is also a span of time for an update to be logged to disk, when this is happening, a lock prevents other threads from accessing that data so requests back up. With a swarm of nodes handling a flood of queries and updates, this design simply doesn't scale. For the financial industry, the row locking is an absolute necessity since a stale read could cause an account to go out of balance. For serving web pages, as long as care is taken in the storage and caching infrastructure, cutting this corner is relatively safe and highly advantageous. Thanks, Caleb On 07/04/2012 02:44 AM, Paul Libbrecht wrote:

Yes, this is exactly what I was thinking about when I designed it. I envisioned the next generation as being more powerful than the current generation in a Turing sense so that it can emulate it to provide backward compatibility. I had imagined a UI where the user selects properties in a class editor and template code is generated below which they can edit. As far as the UI goes, the sky really is the limit here. Thanks, Caleb On 07/04/2012 04:26 AM, Jerome Velociter wrote: