Planet Cassandra is the first place many people go to learn about Cassandra. For many, the Try Cassandra page is their first real interaction with Cassandra. In the past, the Try Cassandra page has included video tutorials as well as downloads that you could have used to install Cassandra on your own machine (virtually or physically). After downloading and setting up the Cassandra node(s), only then would you be able to actually issue commands and begin learning about Cassandra’s capabilities.
Wouldn’t it be great if you could jump to the end of that process, and start typing/learning the commands directly from the Try Cassandra page?
We thought so too! At DataScale have taken the Cassandra setup part, and done that for you. All you have to do is use the web-based interactive CQL Shell that we’ve integrated directly into the Try Cassandra page. That’s it.
The rest of the spirit of the Try Cassandra page hasn’t changed. You will still issue mostly the same commands that you would have before, and learn the same things as before. We’ve just simplified it.
What is CQL Shell?
The CQL Shell is a python-based command line client that is included in the Cassandra installation. To simplify the interaction with Cassandra, we made that command line experience available via a web browser. You can issue all the same CQL commands that you would from a command line. The only difference is that you don’t have to worry about where to do that from as it’s all in-browser.
How does CQL Shell work?
The Try Cassandra page is divided into two sections. First is the left menu, which is separated into walkthrough instructions for Developer and Administrator. Second is the main body of the page, which has the CQL Shell that resembles a command line interface.
The user should click the desired walkthrough and try out the commands as shown.
This is done by either copying commands from the walkthrough and pasting them into the CQL Shell or by typing the commands directly into the CQL Shell.
The Developer walkthrough has basic Cassandra concepts with the corresponding CQL commands. The user will be able to create tables as well as insert, update, select, and delete records.
The Administrator walkthrough is a little bit tougher to do in a web browser, as some of it involves interacting with system level command lines. However, we’ve done our best to show the system commands as well as the CQL commands to run and what the expected output would be. It walks the user through the config files & utility tools, and some typical administrative tasks.
What is DataScale doing in the background?
DataScale is in the the business of managing Cassandra as a Service. We have developed an entire platform for managing, monitoring, and providing secure access for application developers to use with their data and/or applications. Part of that platform includes the same web-based CQL shell that is being exposed on Planet Cassandra’s Try Cassandra page, and how we are managing all of the Cassandra infrastructure behind it.
The Cassandra cluster behind the Try Cassandra page is hosted in Amazon’s cloud. It uses a single data center of four EC2 nodes of instance type m3.xlarge. These are quad-core Intel Xeon machines with a pair of 40 GB SSDs and 15 GB of RAM. These four nodes are each running Cassandra version 2.1.3 (at the time of this blog) and are span across three Amazon availability zones. In addition to the Cassandra nodes, we also have a couple smaller machines used for various cluster monitoring/logging and our back-end web server code.
What are some challenges with hosting Try Cassandra?
The Try Cassandra environment is a multi-tenant architecture; meaning that a single cluster of Cassandra serves all the sessions generated from Try Cassandra. Because of this, we’ve had to set a few small rulesets around what can and cannot be done in the environment.
Since many users will be connecting to Try Cassandra at the same time, we have to be able to segregate users from each other. It would be a bad user experience for one user to be able to affect the environment of another user (i.e. User A could potentially delete User B’s data/table structure). So to ensure that could not happen, we have enforced a couple rules. Each user/session gets it’s own dynamically generated user and keyspace created specifically for it. That user is then granted access to only that keyspace and has access to all other keyspaces revoked. At the end of the session (or 3 hours, whichever comes first) the user and keyspace will be removed. This will keep capacity and disk usage to a minimum.
We’ve also disabled a couple of the intrinsic cqlsh commands (COPY & SOURCE) that allow you to load data from files. Since those specific commands are not part of the Try Cassandra walkthroughs, we don’t allow the user to do it. Doing so would also open up the browser to the file system, which is never a good idea.
Is there a limit to the number of users that can connect to CQL Shell at one time?
No. Theoretically, we are only limited by our hardware. The monitoring we have in place will allow us to scale up automatically if any of our capacity metrics reach our thresholds.
Can I spin up my own Cassandra cluster, and code against it in-browser?
Absolutely. Head on over to DataScale.io and sign up to experience our service yourself. We will contact you to set up time to discuss your current implementation and how we can help. Make sure you let us know you found us via PlanetCassandra.org, we’ve set up special pricing for qualifying startups.