Since a Zookeeper cluster is a quorum based system similar to Cassandra,
it only goes down when n/2 nodes go down. And the same way you have to
stop writing to Cassandra if N/2 nodes are down (if using QUoRUM), your
App will have to wait for the Zookeeper cluster to come online again
before it can proceed.
On 01/06/2012 12:03 PM, Drew Kutcharian wrote:
Hi Everyone,
What's the best way to reliably have unique constraints like functionality with
Cassandra? I have the following (which I think should be very common) use case.
User CF
Row Key: user email
Columns: userId: UUID, etc...
UserAttribute1 CF:
Row Key: userId (which is the uuid that's mapped to user email)
Columns: ...
UserAttribute2 CF:
Row Key: userId (which is the uuid that's mapped to user email)
Columns: ...
The issue is we need to guarantee that no two people register with the same email
address. In addition, without locking, potentially a malicious user can
"hijack" another user's account by registering using the user's email address.
I know that this can be done using a lock manager such as ZooKeeper or
HazelCast, but the issue with using either of them is that if ZooKeeper or
HazelCast is down, then you can't be sure about the reliability of the lock. So
this potentially, in the very rare instance where the lock manager is down and
two users are registering with the same email, can cause major issues.
In addition, I know this can be done with other tools such as Redis (use Redis
for this use case, and Cassandra for everything else), but I'm interested in
hearing if anyone has solved this issue using Cassandra only.
Thanks,
Drew
