Gora Cassandra module design rationale

["Zirpins. Christian" <c....@seeburger.de>]

Hi all,



in the course of evaluating Gora, I'm looking for information on the design rationale behind the Gora Cassandra module.



In particular, I'm trying to find information on the following (debatable?) points:



- Gora keys are mapped to C* partition keys only

- Gora requires the C* ByteOrderedPartitioner

- Comparators are always BYTESTYPE

- Gora makes extensive use of super column families

- The implementation has a hard-coded replication factor of 1



- Gora doesn't  seem to take advantage of native column ordering in C*

- Gora doesn't seem to utilize C* compound primary keys

- Gora doesn't seem to allow the use of per-operation consistency levels



Any pointers or upcoming discussions are appreciated.



Cheers,

Christian






...




SEEBURGER AG            Vorstand/Seeburger Executive Board:
Sitz der Gesellschaft/Registered Office:                Bernd Seeburger, Axel Haas, Michael Kleeberg
Edisonstr. 1
D-75015 Bretten         Vorsitzender des Aufsichtsrats/Chairperson of the Seeburger Supervisory Board:
Tel.: 07252 / 96 - 0            Dr. Franz Scherer
Fax: 07252 / 96 - 2222
Internet: http://www.seeburger.de               Registergericht/Commercial Register:
e-mail: info@seeburger.de               HRB 240708 Mannheim


Dieses E-Mail ist nur f?r den Empf?nger bestimmt, an den es gerichtet ist und kann vertrauliches bzw. unter das Berufsgeheimnis fallendes Material enthalten. Jegliche darin enthaltene Ansicht oder Meinungs?u?erung ist die des Autors und stellt nicht notwendigerweise die Ansicht oder Meinung der SEEBURGER AG dar. Sind Sie nicht der Empf?nger, so haben Sie diese E-Mail irrt?mlich erhalten und jegliche Verwendung, Ver?ffentlichung, Weiterleitung, Abschrift oder jeglicher Druck dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG noch der Absender ( Zirpins. Christian ) ?bernehmen die Haftung f?r Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren Anh?nge auf Viren zu pr?fen.


The present email addresses only the addressee which it targets and may contain confidential material that may be protected by the professional secret. The opinions reflected herein are not necessarily the one of the SEEBURGER AG. If you are not the addressee, you have accidentally got this email and are not enabled to use, publish, forward, copy or print it in any way. Neither SEEBURGER AG , nor the sender (Zirpins. Christian) are liable for viruses, being your own responsibility to check this email and its attachments for this purpose.

Re: Gora Cassandra module design rationale

[Alfonso Nishikawa <al...@gmail.com>]

Hi Christian,

First of all I must say I am not a Cassandra user, but I will tell details
I found. I hope some of them would be useful.

> - Gora keys are mapped to C* partition keys only

I admit I don't have much knowledge about, so I have to look what is that
of the partition keys :(

> - Gora requires the C* ByteOrderedPartitioner

Same as last question :(

> - Comparators are always BYTESTYPE

I think I read about this somewhere hardcoded, yes.

> - Gora makes extensive use of super column families

True. If I am not wrong, It is discouraged since are deprecated. But at
this time we have to maintain compatibility at least until Gora 1.0.

> - The implementation has a hard-coded replication factor of 1

This could be improved in properties.I think I saw some ticket suggesting
that possibility of configuration, but my memory is not much reliable.

> - Gora doesn't  seem to take advantage of native column ordering in C*

I guess does not take advantage. (A)

> - Gora doesn't seem to utilize C* compound primary keys

No, does not use them. (B)

> - Gora doesn't seem to allow the use of per-operation consistency levels

I never heard about this. Interesting. I thought it was consistency
globally. (C)

> Any pointers or upcoming discussions are appreciated.

It seems you have been checking the code (it's a hard work). Thank you:)
For (A),(B) and (C) must understand that Gora at this moment is an
abstraction layer which allows changing backends. I personally will
appreciate ideas about features that will be in accordance with the
semantics involving the other datastores. At this moment what is completely
possible is adding configuration options.

Seems you have experience with Cassandra, so your comments will be much
useful. For example, why do you need compound keys. It could be possible to
add as feature and simulate in other datastores.

This is my opinion, of course.

I will be looking forward your comments.

Regards,

Alfonso Nishikawa