I'm having difficulty establishing how cql is implemented at the lowest level. Is it still making calls to the thrift interface or is it something completely different
It is possible to use CQL from either Thrift or the new native binary protocol. However the native drivers provide much better support for the more sophisticated Cassandra functions. Thrift is essentially deprecated.
In addition to the other answer, I'd like to add that CQL (and its drivers) interact with Cassandra via a new, binary protocol, and not via Thrift. The original row/column structure of Cassandra is still intact, but it is largely abstracted away by CQL.
There was a great blog post done on this subject out on Planet Cassandra: Understanding How CQL3 Maps To Cassandra’s Internal Data Structure. It makes for quick read, and has some simple examples that explain how the abstraction provided by CQL3 functions. I highly recommend running through the examples yourself on your own, local Cassandra instance.
Related
I need an embedded cassandra for my project and I was wondering if I can use Stubbed Cassandra for data storage. Because I need a system to simulate CQL requests and responses.
Thanks everyone.
You cant use it as a real datastore. Use real cassandra as a real cassandra datastore. check out ccm which is probably more what your looking for.
There are wrappers for it in dtests (python) and the java driver uses it for testing and has a java wrapper.
I don't really have any experience at all with SCassandra but I worked on several projects using Apache Cassandra and there are some use cases like multidatacenter infrastructure to experiment and I don't think SCassandra can do it. So if you plan to do simple tests, that's fine, But advanced use cases really need to be tested in a real cassandra distribution.
As others have mentioned, you will need the real Cassandra for data storage. However, if you want to test CQL requests/responses then you can use this library:
Cassandra-Spy
It runs an actual embedded Cassandra and also can simulate failures for inserts/selects. This helps you test your app's behaviour in failure cases. I wrote the library to address this specific use case.
I'm finally getting the hang of Cassandra, part of the issue was learning / respecting the differences between Thrift and CQL3.
Many of the tutorials I am finding online are for CQL3. My question: Is CQL3 truly the preferred method, and is Thrift being discouraged? Reason I ask is I spent a couple of days trying to get what I needed through Pycassa which does not support Cassandra 1.2 and that is based on the Thrift model.
Is CQL3 truly the preferred method, and is Thrift being discouraged?
Short answer is yes.
Longer answer is:
CQL3 should be preferred for many reasons:
platform-agnostic language: CQL3 looks like SQL and is easier to handle that pure Thrift API code.
Higher level of abstraction: for end-users, it's easier to deal with CQL3 to query data rather than juggling with low-level Thrift API, although some good higher abstraction frameworks exist (Hector for Java, Pycassa for Python ...=
Easier to administer for operational teams: when creating a new table or adding new referential data, it is easier to write CQL3 scripts that ops teams can understand, check and execute rather than cryptic cassandra-cli scripts (set cf[rowKey][columnName] = ...). I'm migrating all our cassandra-cli scripts to CQL3 because it's a pain in the ass to maintain them
Last but not least, CQL3 make life easier for third-party framework developers. I've developed Achilles, an open-source persistence manager for Cassandra. The Thrift version was painfull to implement, the CQL3 version was a piece of cake escpecially because it uses the Java Driver from Datastax
That being said, CQL3 is no bed of roses either. Before leveraging the full power of the query language, you need to understand how Cassandra storage engine works. The language gives you the illusion that everything is easy and will work as SQL but the plain truth is no. There are some important semantics differences, especially when using the WHERE clause.
Yes, CQL is the preferred API. It is much easier to use and not all operations are supported through the Thrift API.
You can use cassandra-dbapi2 for CQL3 in Python: https://code.google.com/a/apache-extras.org/p/cassandra-dbapi2/.
Short answer: Yes
However given how new it is compared to thrift based clients it is safe to assume there is vastly more thrift clients in production.
Given Datastax now produce their own Java driver that supports exclusively CQL3 it is probably a good idea to follow suite: https://github.com/datastax/java-driver
Recently I noticed the Cassandra and DataStax are pushing CQL3 more. A new java driver even released, this one does not use Thrift at all.
And if your are not going to use "compact storage" you will not able to use Thrift with your application. Thus, I believe that Thrift is fading out from Cassandra.
My question is, for a new application should I go head and use CQL3? However, I still prefer thrift because I want to know what's going on underneath and on the other hand I do not want to be using something that is fading out and becoming a legacy. What do you recommend?
My company recently went through the same thought process and ended up using CQL3 over thrift.
Although there is a slight lack of transparency with the additional layer of abstraction going on with CQL3, the ease and familiarity of writing SQL style statements makes the code much more readable and intuitive in my opinion. Plus we found the cqlsh interface far more user friendly than cassandra-cli for debugging and general db maintenance (the auto-complete is fab in cqlsh!).
Once you understand the underlying data structure and how CQL3 represents that data, the extra layer of abstraction pales into insignificance, really.
Datastax are encouraging developers to use cql3 for newer applications. From the Thrift to CQL3 Guide:
…we believe that CQL3 is a simpler and overall better API for Cassandra than the thrift API is. Therefore, new projects/applications are encouraged to use CQL3 (though remember that CQL3 is not final yet, and so this statement will only be fully valid with Cassandra 1.2). But the thrift API is not going anywhere.
Thrift won't be getting newer features (unless they are requested a lot) so it's safe to say that CQL3 is the better choice for new apps (of course there are exceptions… if you need low-level you need thrift). My only pain is that datastax's driver does not yet support SSL but that is in the pipeline and will hopefully be a committed feature soon.
I'm using Cassandra as the database and want to use Devise
Does Devise support Cassandra as the database? I looked around but did not find any information related to Devise-Cassandra on the wiki or anywhere else.
Is there third party plugins supporting it or other gem for authentication as devise?
Thank you
No, I have never heard of such thing.
Actually I suggest you keep your users in a more traditional database and use cassandra only for the most intensive I/O data.
Cassandra wasn't made to substitute other databases nor to be user with ORM (that's actually written in its official webpage)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am trying to develop application using Hive as the Database, and then I also find noSQL solutions as an alternative to it.
Now decided to develop using Cassandra, my next problem is about what client should I use? which one is better, Hector -- a pure java solutions, or Kundera with JPA like development?
I prefer Hector, but I am curious about Kundera. Is there anyone using Kundera? Which is better?
I'm curious about CQL (Cassandra Query Language). Can it integrate with Hector?
Hector is slowly moving towards CQL integration. The first steps have been made, but because of the experience of an unstable API, the developers seem to have postponed a new release. The CQL API is rather new, as it should be nearly equivalent to a SQL syntax. I made some basic steps with CRUD operations to verify that data could be written and read via CQL.
Nevertheless, the CQL JAR is not usable out of the box like a standard JDBC driver as of now, and misses some important feature aspects. Having a look at the more or less difficult to understand thrift API and the not really much simpler hector API, I am convinced that CQL will be established as the state-of-the-art access API for Cassandra in version 0.8.1 and 1.0, where thrift will remain the native, raw access for some time.
The competition between both APIs has nothing to do with the decision of Hector. Hector itself provides additional services like failure and connection handling in the cluster. These are features being addressed by neither thrift nor CQL.
I don't really believe in all other O/R mappers, or even those claiming to provide a full-fledged JPA. I cannot imagine how this should work.
Answering your question about clients - Hector essentially provides access to the Cassandra native API (columns, column families, rows etc) whereas Kundera aims to hide these details and provide object-database mapping.
Kundera therefore probably makes it easier to quickly persist a range of Java objects into Cassandra - but may not provide an efficient mapping, perhaps losing some of the performance that noSQL approaches provide.
Hector expects you to adapt to the Cassandra data model - this will be harder work, but is likely to deliver more performance.
There is now a new client, Astyanax, released by Netflix in January 2012.
"Astyanax is a Java Cassandra client. It borrows many concepts from
Hector but diverges in the connection pool implementation as well as
the client API. One of the main design considerations was to provide a
clean abstraction between the connection pool and Cassandra API so
that each may be customized and improved separately. Astyanax provides
a fluent style API which guides the caller to narrow the query from
key to column as well as providing queries for more complex use cases
that we have encountered. The operational benefits of Astyanax over
Hector include lower latency, reduced latency variance, and better
error handling."
The source code for Astyanax is hosted at Github: https://github.com/Netflix/astyanax
For details about using CQL with Cassandra and Hector, see:
https://github.com/rantav/hector/wiki/Using-CQL
The following mail list thread is a good discussion on where we will be going with CQL as an API:
http://groups.google.com/group/hector-users/browse_thread/thread/540dc9c3908fbb44/f5ee488f2178e2f4
For the sake of completeness I think the Pelops library should be mentioned too. Hector seems to be the most used, but Pelops has a simpler API. Pelops does not support CQL.
Coming from Ruby I find both to be extremely verbose and imperative, though.
Kundera no more relies on Solandra for indexing approach. It enables you now to use secondary indexing support provided by Cassandra and as well as it gives you a way to run jpa queries over OPP (like range queries etc). We are working to enable native CQL support.
Take a look at:
http://mevivs.wordpress.com/2012/02/13/how-to-crud-and-jpa-association-handling-using-kundera/
for more details.
-Vivek
There is no java client in the same level with hector, hector is the best and there is work in progress in hector side to support cql. I saw cql commits for hector in github this month, but doesn't know it's final state. You can ask it to hector users group http://groups.google.com/group/hector-users
Also there is a very simple object mapper in hector
https://github.com/rantav/hector/wiki/Hector-Object-Mapper-%28HOM%29
My Best,
Serdar Irmak
Kundera 2.0.4 released:
Major Changes in this release:
Cross-datastore persistence( Easy to migerate existing mysql app over nosql)
support for relational databases (e.g Mysql etc)
replace solandra with lucene based indexing.
Support added for bi-directinal associations.
Performance improvement fixes.
We tested and 1 million inserts with proper indexing happened in 6 minutes.
Vivek
I am yet to try Hector, but am involved in latest Kundera 2.0.1 release. I suggest you give it a try. It has gone a major change since its inception and you can see a lot of new features getting added and bugs being fixed. Currently it supports JPA 1.0 and Cassandra 0.7.6 but we are planning to add support for Cassandra 0.8 and JPA 2.0 very soon. There is a pretty good example here: https://github.com/impetus-opensource/Kundera/wiki/Getting-started that may help you get started.
Astyanax api produces human-readable code and does include connection pooling.
CQL support over cassandra has been integrated in kundera 2.0.6(yet to be released). It allows to execute CQL as nativequery now.
-Vivek