In each of the two examples he defines a way of tracking both who you're following and who is following you by implementing two tables in SQL or two "column stores" in Cassandra.
Why would you need to (or want to) store these separately? A table indicating User X is following User Y would give you enough to fullfill queries for both followers and followees.
In a database, yes, a single table with two indexes would efficiently look up followings/followers.
But in Cassandra there is no support for secondary indexes, so the follower/following data needs to be in separate column families. Then, they each have an index and can be looked up efficiently. (At least as far as I understand things in the NoSQL world)
So what happens when you create the follower but not followed index then realize you need it. Is there a way to create that new ColumnFamily without writing a object-by-object program that must traverse all the data? I suppose the concept of data locality doesn't apply, but what is the best way to do that sort of operation?
I thought this was going to be about engineers trying to warn managers about impending massive failure and no one listening. the most famous (engineering) example being Challenger's O-rings.
5 comments
[ 4.8 ms ] story [ 27.4 ms ] threadWhy would you need to (or want to) store these separately? A table indicating User X is following User Y would give you enough to fullfill queries for both followers and followees.
But in Cassandra there is no support for secondary indexes, so the follower/following data needs to be in separate column families. Then, they each have an index and can be looked up efficiently. (At least as far as I understand things in the NoSQL world)
see Cassandra Complex: http://en.wikipedia.org/wiki/Cassandra_(metaphor)