Re: Which way to Cassandraville?
Correction, I mean vendor specific. Proprietary is OK so long as there aren't any lock-in tricks or they can be dodged easy. Jim C. On 07/22/2014 12:12 PM, jcllings wrote: Does it have an annotation scheme or arrangement so I don't have to put proprietary stuff in my Java? Jim C. On 07/20/2014 06:24 PM, Kevin Burton wrote: I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Very very out of date… Having said that, what Java clients should I be looking at? I'd recommend the Datastax Java Driver. Works really well for us and if you're familiar with JDBC it will be easy to get up and running fast. They are supporting it pretty aggressively too… the custom data type stuff is already supported in 2.1. Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? One was just posted to the list… I would say there are 2-3 … I posted on the same question and there's a thread around my email address if you want to search for it. I personally ended up writing my own that just used a velocity code generator so I could control the byte code output easily. I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. It's very close to an abbreviated SQL92 with a few less features. You won't have a problem. -- Founder/CEO Spinn3r.com http://Spinn3r.com Location: *San Francisco, CA* blog:* *http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com signature.asc Description: OpenPGP digital signature
Re: Which way to Cassandraville?
So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C. signature.asc Description: OpenPGP digital signature
Re: Which way to Cassandraville?
What kinds of things would it be good to know for an interview? The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient. On Tue, Jul 22, 2014 at 9:20 PM, jcllings jclli...@gmail.com wrote: So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C.
Re: Which way to Cassandraville?
You can also try http://caffinitas.org - Open Source Java object mapper for C* using Datastax's Java Driver licensed using APL2. It is intended to be a bit close to what JPA does. Although, it cannot support JPA features 1:1 since there are fundamental differences between RDBMS and NoSQL/C*. But it has other features that traditional RDBMS do not have. CQL in general is relatively close to SQL (CQL is SQL minus joins and subqueries, plus collections) - with C* 2.1 you can add plus user types Regarding an interview: 1. knowledge of query-driven data model 2. knowledge of C* cluster organization / how data is distributed 3. knowledge of consistency (levels) 4. knowledge of C* read and write path Robert Am 22.07.2014 um 21:20 schrieb jcllings jclli...@gmail.com: So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Which way to Cassandraville?
OK to clarify, I don't mean as an Administrator but an application developer. If you use an ORM how important is CQL3? The object being to eliminate any *QL from Java code. Perhaps this technology isn't as mature as I thought. Jim C. On 07/22/2014 12:42 PM, DuyHai Doan wrote: What kinds of things would it be good to know for an interview? The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient. On Tue, Jul 22, 2014 at 9:20 PM, jcllings jclli...@gmail.com mailto:jclli...@gmail.com wrote: So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C. signature.asc Description: OpenPGP digital signature
Re: Which way to Cassandraville?
Having an ORM says nothing about the maturity of a database, it says more about the community and their willingness to create one. The database itself has nothing to do with the creation of the ORM. Atop everything else, as was stated, knowing how to model your queries is the most important thing, more than knowing how to use the driver. Cassandra has a very specific way that it stores data, if you attempt to store data the way you do in any other RDBMS there is a good chance you will have a very hard time. Also, this: http://my.safaribooksonline.com/book/databases/9780133440195 We wrote it for 1.2 but most all of the information still applies. The performance gains you get from Cassandra come at a cost, that cost being that you need to know what you are doing. On July 22, 2014 at 4:01:21 PM, jcllings (jclli...@gmail.com) wrote: OK to clarify, I don't mean as an Administrator but an application developer. If you use an ORM how important is CQL3? The object being to eliminate any *QL from Java code. Perhaps this technology isn't as mature as I thought. Jim C. On 07/22/2014 12:42 PM, DuyHai Doan wrote: What kinds of things would it be good to know for an interview? The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient. On Tue, Jul 22, 2014 at 9:20 PM, jcllings jclli...@gmail.com wrote: So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C.
Re: Which way to Cassandraville?
Let me respond with another question: How important is SQL for a JPA developer? Mappers eliminate the boring and error-prone stuff like execute SELECT, read fields, call setters etc. They can automatically perform conversions, apply optimizations, etc etc etc. Mappers do not remove the need of a developer to think about that what (s)he's coding. IMO mappers help and make life easier. Period. Means: you should always know what the thing does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known. If you don't you will get into trouble - sooner or later. Robert PS: I avoid the abbreviation ORM - it includes the term relational ;) Am 22.07.2014 um 22:00 schrieb jcllings jclli...@gmail.com: OK to clarify, I don't mean as an Administrator but an application developer. If you use an ORM how important is CQL3? The object being to eliminate any *QL from Java code. Perhaps this technology isn't as mature as I thought. Jim C. On 07/22/2014 12:42 PM, DuyHai Doan wrote: What kinds of things would it be good to know for an interview? The underlying storage engine and how CQL3 maps to it. It's more than important, it's crucial. Knowing what you do and what you can't with CQL3 is not sufficient. On Tue, Jul 22, 2014 at 9:20 PM, jcllings jclli...@gmail.com wrote: So It seems that: 1. There are indeed a few (3-4) mapping schemes. 2. CQL isn't very hard and represents a subset of (ANSI?) SQ92. Both of these are validated based on further research and list guidance. It appears that learning Cassandra from an application developers perspective essentially means learning what you can't do at all and learning what you can't do directly that you could do with an RDMBS. This and keys and maybe a thing or two about replication strategies and you should be good to go. Does this seem accurate? What kinds of things would it be good to know for an interview? Jim C. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Which way to Cassandraville?
On 07/22/2014 01:11 PM, Robert Stupp wrote: Let me respond with another question: How important is SQL for a JPA developer? ... IMO mappers help and make life easier. Period. Means: you should always know what the thing does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known. If you don't you will get into trouble - sooner or later. Robert PS: I avoid the abbreviation ORM - it includes the term relational ;) Agreed. That is why in previous posts I've been calling it PoJo Mapping. When someone suggests I try on yet another hat, though, I get a little excited. ;-) In this case I've been wearing the ORM / RDBMS hat for long enough that I actually don't think about it much. So your point is made. I've already been wearing the hat in question. I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL. This may make the transition easier, because as you say, it eliminates the cruft. Jim C. signature.asc Description: OpenPGP digital signature
Re: Which way to Cassandraville?
I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL It would be too easy. You should also know how the CQL3 maps to underlying data storage. On Tue, Jul 22, 2014 at 10:33 PM, jcllings jclli...@gmail.com wrote: On 07/22/2014 01:11 PM, Robert Stupp wrote: Let me respond with another question: How important is SQL for a JPA developer? ... IMO mappers help and make life easier. Period. Means: you should always know what the thing does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known. If you don't you will get into trouble - sooner or later. Robert PS: I avoid the abbreviation ORM - it includes the term relational ;) Agreed. That is why in previous posts I've been calling it PoJo Mapping. When someone suggests I try on yet another hat, though, I get a little excited. ;-) In this case I've been wearing the ORM / RDBMS hat for long enough that I actually don't think about it much. So your point is made. I've already been wearing the hat in question. I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL. This may make the transition easier, because as you say, it eliminates the cruft. Jim C.
Re: Which way to Cassandraville?
Yep - too easy. It does not matter what you use (CQL3, Pojo Mapper ;) or whatever). And I guess it's easier for a pure Java coder knowing nothing about C* to start with a mapper. But in the end you should know what's going on - since you will be in the position to fix bugs and performance issues. And I think there's no opposition when I say that it's better to prevent bugs ;) The easiest way to learn things is just to start using it - play with it - make tests - dig around - build a prototype - benchmarks - performance tests - again and again. But throw away your prototype - start from scratch - with the lessons learned in mind :) Am 22.07.2014 um 22:37 schrieb DuyHai Doan doanduy...@gmail.com: I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL It would be too easy. You should also know how the CQL3 maps to underlying data storage. On Tue, Jul 22, 2014 at 10:33 PM, jcllings jclli...@gmail.com wrote: On 07/22/2014 01:11 PM, Robert Stupp wrote: Let me respond with another question: How important is SQL for a JPA developer? ... IMO mappers help and make life easier. Period. Means: you should always know what the thing does to read/write your data. Practically not down to the details - but the concepts and pitfalls should be known. If you don't you will get into trouble - sooner or later. Robert PS: I avoid the abbreviation ORM - it includes the term relational ;) Agreed. That is why in previous posts I've been calling it PoJo Mapping. When someone suggests I try on yet another hat, though, I get a little excited. ;-) In this case I've been wearing the ORM / RDBMS hat for long enough that I actually don't think about it much. So your point is made. I've already been wearing the hat in question. I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL. This may make the transition easier, because as you say, it eliminates the cruft. Jim C. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Which way to Cassandraville?
On 07/22/2014 01:37 PM, DuyHai Doan wrote: I surmise if you are using a mapper, it should be more a matter of knowing how the annotations map to the back-end rather than the CQL It would be too easy. You should also know how the CQL3 maps to underlying data storage. It would be if I intended to stop there. I was just picking a familiar starting point. The best employee at any interview, of course, is both omniscient and omnipotent. Ah...but then we would be merely leasing in in HIS universe. ;-) Jim C. signature.asc Description: OpenPGP digital signature
Re: Which way to Cassandraville?
Checkout datastax devcenter which is a GUI datamodelling tool for cql3 http://www.datastax.com/what-we-offer/products-services/devcenter On Sun, Jul 20, 2014 at 7:17 PM, jcllings jclli...@gmail.com wrote: So I'm a Java application developer and I'm trying to find entry points for learning to work with Cassandra. I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Having said that, what Java clients should I be looking at? Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. What, if any, GUI tools are available for working with Cassandra, for data modelling? Jim C. -- http://twitter.com/tjake
Re: Which way to Cassandraville?
Removing *QL from application code is not really an indicator of the maturity of a technology. ORMs and automatic type mapping in general tend to be very easy things for a developer to work with allowing for rapid prototypes, but those applications are often ill-suited to being deployed is high-volume environments. I have used a wide variety of ORMs over the last 15 years, hibernate being a favourite at which I am held to have some expertise, but when I am creating an app for the real world in situations where I can expect several million requests/day, I do not touch them. On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani jak...@gmail.com wrote: Checkout datastax devcenter which is a GUI datamodelling tool for cql3 http://www.datastax.com/what-we-offer/products-services/devcenter On Sun, Jul 20, 2014 at 7:17 PM, jcllings jclli...@gmail.com wrote: So I'm a Java application developer and I'm trying to find entry points for learning to work with Cassandra. I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Having said that, what Java clients should I be looking at? Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. What, if any, GUI tools are available for working with Cassandra, for data modelling? Jim C. -- http://twitter.com/tjake -- - michael dykman - mdyk...@gmail.com May the Source be with you.
Re: Which way to Cassandraville?
True - Hibernate, Eclipselink and others add plenty of synchronization overhead owed the fact that an entity instance does not need to be explicitly persisted to get persisted (just change the loaded instance and flush the session). That's very expensive (CPU and heap). Even though transaction synchronization adds another cost. Pure mapping as itself is not really expensive compared to what one would do to return a Pojo or persist a Pojo. Take a look at https://bitbucket.org/snazy/caffinitas/ - PersistenceSessionImpl.loadOne()/insert() add not much overhead during runtime - but you get the object ready to use. PS We are doing several million requests per day with Hibernate - but I spent a lot of work to optimize framework between business logic and JPA. It would not work out of the box. Am 22.07.2014 um 23:32 schrieb Michael Dykman mdyk...@gmail.com: Removing *QL from application code is not really an indicator of the maturity of a technology. ORMs and automatic type mapping in general tend to be very easy things for a developer to work with allowing for rapid prototypes, but those applications are often ill-suited to being deployed is high-volume environments. I have used a wide variety of ORMs over the last 15 years, hibernate being a favourite at which I am held to have some expertise, but when I am creating an app for the real world in situations where I can expect several million requests/day, I do not touch them. On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani jak...@gmail.com wrote: Checkout datastax devcenter which is a GUI datamodelling tool for cql3 http://www.datastax.com/what-we-offer/products-services/devcenter On Sun, Jul 20, 2014 at 7:17 PM, jcllings jclli...@gmail.com wrote: So I'm a Java application developer and I'm trying to find entry points for learning to work with Cassandra. I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Having said that, what Java clients should I be looking at? Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. What, if any, GUI tools are available for working with Cassandra, for data modelling? Jim C. -- http://twitter.com/tjake -- - michael dykman - mdyk...@gmail.com May the Source be with you. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Which way to Cassandraville?
The problem with Hibernate and the kind is that they try to do many thing at once. And support for JOINS bring a damned lots of complexity. You need to manage object graphs and circular references - statefull session - not thread-safe - not good fit for async multi threaded envs On Tue, Jul 22, 2014 at 11:56 PM, Robert Stupp sn...@snazy.de wrote: True - Hibernate, Eclipselink and others add plenty of synchronization overhead owed the fact that an entity instance does not need to be explicitly persisted to get persisted (just change the loaded instance and flush the session). That's very expensive (CPU and heap). Even though transaction synchronization adds another cost. Pure mapping as itself is not really expensive compared to what one would do to return a Pojo or persist a Pojo. Take a look at https://bitbucket.org/snazy/caffinitas/ - PersistenceSessionImpl.loadOne()/insert() add not much overhead during runtime - but you get the object ready to use. PS We are doing several million requests per day with Hibernate - but I spent a lot of work to optimize framework between business logic and JPA. It would not work out of the box. Am 22.07.2014 um 23:32 schrieb Michael Dykman mdyk...@gmail.com: Removing *QL from application code is not really an indicator of the maturity of a technology. ORMs and automatic type mapping in general tend to be very easy things for a developer to work with allowing for rapid prototypes, but those applications are often ill-suited to being deployed is high-volume environments. I have used a wide variety of ORMs over the last 15 years, hibernate being a favourite at which I am held to have some expertise, but when I am creating an app for the real world in situations where I can expect several million requests/day, I do not touch them. On Tue, Jul 22, 2014 at 5:10 PM, Jake Luciani jak...@gmail.com wrote: Checkout datastax devcenter which is a GUI datamodelling tool for cql3 http://www.datastax.com/what-we-offer/products-services/devcenter On Sun, Jul 20, 2014 at 7:17 PM, jcllings jclli...@gmail.com wrote: So I'm a Java application developer and I'm trying to find entry points for learning to work with Cassandra. I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Having said that, what Java clients should I be looking at? Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. What, if any, GUI tools are available for working with Cassandra, for data modelling? Jim C. -- http://twitter.com/tjake -- - michael dykman - mdyk...@gmail.com May the Source be with you.
Re: Which way to Cassandraville?
On Tue, Jul 22, 2014 at 1:10 PM, Russell Bradberry rbradbe...@gmail.com wrote: Having an ORM says nothing about the maturity of a database, it says more about the community and their willingness to create one. The database itself has nothing to do with the creation of the ORM. Except, as in this case, when one has baked what looks an awful lot like an ORM into the Database... ;D =Rob
Re: Which way to Cassandraville?
Having said that, what Java clients should I be looking at? Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? The Java Driver offers a basic object mapper in the mapper module. If you look for something more evolved, have a look at http://doanduyhai.github.io/Achilles/
Re: Which way to Cassandraville?
I just finished reading Cassandra: The Definitive Guide which seems pretty out of date and while very informative as to the technology that Cassandra uses, was not very helpful from the perspective of an application developer. Very very out of date… Having said that, what Java clients should I be looking at? I'd recommend the Datastax Java Driver. Works really well for us and if you're familiar with JDBC it will be easy to get up and running fast. They are supporting it pretty aggressively too… the custom data type stuff is already supported in 2.1. Are there any reasonably mature PoJo mapping techs for Cassandra analogous to Hibernate? One was just posted to the list… I would say there are 2-3 … I posted on the same question and there's a thread around my email address if you want to search for it. I personally ended up writing my own that just used a velocity code generator so I could control the byte code output easily. I can't say that I'm looking forward to yet another *QL variant but I guess CQL is going to be a necessity. It's very close to an abbreviated SQL92 with a few less features. You won't have a problem. -- Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile https://plus.google.com/102718274791889610666/posts http://spinn3r.com
