Rows are distributed around the cluster according to the ordering from the Partitioner used, and the Replication Strategy. All data for the same key will be stored together, and then replicated RF times.
To answer your questions...
1) Each node is responsible for the keys between the previous nodes token and it's own. So if your node tokens are set as "vertexid_" all keys with the same prefix will be in the same range. Note that the row data will be stored on RF replicas, and not just on the node with the appropriate token.
2) I *think* you want to look at o.a.c.s.StorageService.getNaturalEndpoints() , this is not exposed to the outside world though. However *every* read or write request is sent to all replicas, even those at CL ONE. There is no concept of one node been the only place that a row is stored.
FWIW it sounds like you want to disable some of the fine work cassandra does to ensure your data is replicated and available. By deciding that one machine will be responsible for a portion of the data you are introducing a single point of failure. Try writing your app against a cluster and let cassandra take care of things, then dive into the details. For example I cannot remember anyone on the list having serious issues with network overhead.
You may also want to consider flock db from twitter, it sits on top of a sharded MySQL db https://github.com/twitter/flockdb
Aaron
On 16 Nov, 2010,at 03:53 AM, Claudio Martella <claudio.marte...@tis.bz.it> wrote:
Hello list,
I'm in the process of writing an application which uses cassandra as a
"storage" backend. The application is a graph database and it's supposed
to be a baseline application for further development in the field.
The idea is to implement a property graph: a multigraph (multiple edges
connecting two vertices are possible) with properties in the form of
name/value for edges and vertices. The idea is to traverse the graph
with queries like "give me all the women that are liked by men i know",
something like:
Vertex[name=claudio]=>outgoingEdge[type=knows]=>Vertex[gender=male]=>outgoingEdge[type=likes]=>Vertex[gender=female].
This is basically a step by step expansion/filtering based on properties.
In my architecture my application-logic node is coupled with the
cassandra node storing its data. I'd like to have some kind of "atomic
set" of data that is "granted" to be stored on the same cassandra node
(in my case the vertex, its adj list, its properties, its edges and
their properties), so that i can issue the required filtering and
expansion to a particular node which will issue the logic behind it (and
i can route such request with the same logic cassandra routes its
requests).
This is in an effort to (a) minimize network i/o (i'd be able to send
the query token to the application node which would issue a local get to
its local cassandra) and (b) distribute computation (i'd be able to
distribute filtering between all the nodes storing for example the
node's neighborhood). This is still not optimal, but it would be a good
start.
For this reason i thought about a datamodel that has composite keys:
vertexid and edgeid are uuids while propertyname is a string.
CF vertices {
vertexid_propertyname {
propertyvalue: null
}
}
CF edges {
vertexid_[in|out]_propertyname_edgeid {
propertyvalue: othervertexid
}
}
With this datamodel i could easily and efficiently issue slices and
ranges to cassandra with the equality predicates on properties i need.
What i need now is to partition my data on the prefix "vertexid_". Such
a datamodel does have a concept of "ascending ordering", so i thought
about OPP, but to my understanding OPP does not grant that all the data
starting with the same prefix will end up in the same cassandra node,
but only some of it. My set of data about a vertex could still be split
between two cassandra nodes in case the token ends up being a key in the
middle of the set, right?
What i require exactly is:
(1) to have all the rows belonging to the same vertexid (which is a
uuid) on the same cassandra node. Can i achieve this?
(2) given this partitioning, know the IP of the cassandra node storing
that vertex data, from outside of cassandra. This is the logic cassandra
uses to route requests for keys and i have to access it from outside.
Can anybody comment about these?
Thanks
Claudio
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.marte...@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to priv...@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
