See all blog posts

Chris Bannister Discusses GoCQL at ScyllaDB Summit 2017

GoCQL provides an efficient way to interact with ScyllaDB with Golang applications. For example, GoCQL automatically discovers all data centers, racks and hosts in your cluster, manages a pool of connections to them, and distributes queries in a reasonable and efficient way. Since Chris Bannister, the GoCQL package maintainer, is giving a talk about GoCQL at ScyllaDB Summit 2017, I  was able to interview him to learn more about his talk. Let’s begin the interview.

Please tell us about yourself and what you do for GoCQL?

I maintain GoCQL, a Golang driver for Apache Cassandra & ScyllaDB and know too much about the Apache Cassandra binary protocol.

How did you get started with GoCQL and Go?

The driver was actually started by tux21b, I started contributing by fixing some bugs and joined the maintainer team a year later. Since then I’ve become the last of the active maintainers and still contribute.

I have been programming in Go for just over four years now. I like the simplicity of doing concurrency, compared to Java spawning a goroutine to do some processing in the background is trivial. While many people complain about error handling being verbose, I find that it forces you to think more clearly about what happens when you encounter errors. Go also comes with some great tooling for testing and profiling, and it compiles really fast.

What will you be talking about at ScyllaDB Summit 2017?

How to use GoCQL to execute queries and what the driver does that you can’t see.

What type of audience will be interested in your talk?

Anyone looking to or does use GoCQL or if they are curious about how Cassandra drivers work.

Can you please tell me more about your talk?

I will be going over how to use GoCQL to connect and execute queries against Apache Cassandra and ScyllaDB. Whilst doing so, I will explain best practices and some things to watch out for and will go over what the driver is doing behind the scenes when it is executing queries. Unlike traditional database drivers, GoCQL does more than just converting the query into wire format and sending it to a server. For example, it maintains a full view of the cluster to enable it to send queries to the node which owns the data and dynamically discover nodes joining and leaving the cluster.

Have you ever compared the performance of a Go client vs Java client?

Not directly. While the performance of the driver is very important, I focused instead on the code to make sure that it is easy to maintain and correct. I have not seen many issues complaining that the driver is slowing users applications down so I assume it’s good enough. If someone finds a performance issue then I’ll happily work to resolve it.

Are all of the Java driver’s API and CQL features supported in Go?

Probably not. I’ve not paid that close of attention to the java driver. It has enough of the core driver support for people to use and tailor to their environment. GoCQL aims to be a pretty low-level driver whilst still being usable for the majority of situations, if a user wants more features such as object mapping, there are libraries which build on top of GoCQL to offer this kind of functionality. While the Java driver offers both synchronous and asynchronous clients, GoCQL only provides a synchronous interface. Go makes it trivial for users to do the calls asynchronously if they desire.

What’s the roadmap for the GoCQL client?

One of the last things I want to improve is retry policies. I think it’s one of the oldest parts of the driver left over. While today they work, they are very basic but I’ve yet to come up with an interface which I’m happy with. I’m currently working on the v5 binary protocol.

What do you think about moving parts of GoCQLx to GoCQL such as the use of named query parameters or binding parameters from map?

Gocql natively supports named parameters but using them with positional ones is not super intuitive. I’m not hugely keen on adding dynamic query binding via structs or maps as it adds more complexity to the driver which has to be maintained. Given that tools like GoCQLx can be written and support these things, I think it is generally a better idea to have these features exist outside of the driver core.

How do you test GoCQL?

I have spent a lot of time setting up our CI system to be as reliable as possible as it is today. This is massively important to not discourage people from contributing if they cause an unrelated failure and also for maintainers to have confidence that changes won’t break from unforeseen things. The CI system exists to try and exercise as much of the codebase against different Apache Cassandra versions which test each binary protocol version, internal cluster metadata (which has a habit of changing between versions), and host discovery. The tests are made up of many integration and unit tests. Many are regression tests from fixed bugs and run against a cluster of 3 nodes in TravisCI which is great.

Where can we learn more information about your talk?

Please check out our GitHub page for the latest information.

How can the people get in touch with you?

The best way to get in touch with me is through Twitter and the GoCQL users group.

Thank you very much, Chris. We can not wait to see your talk in person and learn more.

ScyllaDB Summit is taking place in San Francisco, California on October 24-25. Check out the current agenda on our website to learn about the rest of the talks—including technical talks from the ScyllaDB team, the ScyllaDB roadmap, and a hands-on workshop where you’ll learn how to get the most out of your ScyllaDB cluster.