Vitess was created for “people who love MySQL for its functionality, but have chosen not to use it because it does not scale well,” said Sugu Sougoumarane, one of the creators of Vitess who is now co-founder and chief technology officer at PlanetScale Data, a still-stealth startup centered around Vitess, in an interview with The New Stack.
“There has been some hesitation about using MySQL because it doesn’t scale. But now with Vitess, that can be considered a solved problem,” he said.
Vitess users fall into two camps, Sougoumarane explained. One camp is heavy MySQL users who have already figured out how to shard a MySQL database across multiple servers to improve performance, but would rather use Vitess than maintain their own software. The second group tends to be smaller organizations that have outgrown their single instances of MySQL.
The adoption of Vitess shows the CNCF Technical Oversight Committee (TOC), which voted the new technology in this week, is taking a hard look at the challenges of persistent storage confronting cloud-native operations. Last week the TOC voted in the Rook cloud-native storage interface as well.
Vitess is a database clustering system for the horizontal scaling of MySQL, an open source relational SQL database management system overseen by Oracle. It shards a database across different servers, encapsulating the shard-routing logic internally. Instead of using the Oracle MySQL driver, apps deploy the Vitess API driver, in effect rendering MySQL a cloud-native database. Users can split and merge shards, according to their needs. Under the covers, the software relies on CNCF’s open source Kubernetes container orchestration engine to speed auto-scaling, through the use of container clusters.
Vitess also offers other cloud-native functionality such as support for automatic failover/recovery, replication and rolling upgrades. It supports multiple sharding schemes, and users can create their own. It also comes with master management and performance management tools.
Vitess brings the massive scalability of a NoSQL database, while maintaining the consistency model of the SQL-based MySQL. Over the past decade, many users had given up altogether on MySQL and other SQL-compliant databases that provide ACID guarantees of data consistency, opting for looser, more easily-scalable NoSQL data stores instead.
These users assumed they didn’t require transactional properties, but “you run into more and more use cases where you want better guarantees from the data,” said Sougoumarane. So many ended up implementing the required transactional properties in the applications themselves. As a result, “those applications end up being much more complex than they would be,” he said.
- 105 contributors
- 5,413 GitHub stars
- 15 releases
- 13,733 commits
- 707 forks
Not all users went with NoSQL, of course. Many organizations, such as Slack or Facebook, have preferred to use MySQL, though they needed more scalability than the database system can manage itself out-of-the-box. There are approaches to scale standard relational databases, however, they cause an increasing amount of work to maintain. Initially, a database can be scaled through making replicas, so that multiple copies are available from which the same data can be read. Eventually, write performance becomes a problem, and so the next step would be to split off different tables to their servers, and, ultimately, a single table must be split across multiple servers, which becomes a headache to manage, one that just gets worse over time.
Vitess was designed to hide all this complexity. Last year, Amazon Web Services engineered its own MySQL-like database service, Aurora, with multi-master capability for both database reads and writes, effectively giving the service virtually unlimited scale-out capability. A technology like Vitess can offer the same capabilities, but not tie the end-user to a particular cloud service.
Vitess began life in 2010 as an internal YouTube project to build a proxy server (that element is now called “VTGate”), designed to pool connections (A slow point in MySQL) and to buffer against toxic queries that can bring down an MySQL instance.
Originally, Vitess was meant to run on bare-metal. But when YouTube migrated to the Google Cloud in 2013-14, the YouTube developers needed to equip the software for running in a containerized environment, one managed by container orchestration software very much like Kubernetes. So the devs built the abstraction and APIs into Vitess so it could work in such an environment.
As a result, “We were almost ready for Kubernetes when it was released,” Sougoumarane said. Kubernetes helps manage up to tens of thousands of nodes that Vitess can spawn. “Without Kubernetes, you would have to write a lot of custom launch scripts to deploy. ” If a server goes down, Kubernetes can bring back a node somewhere else, and rebalance the application across the new configuration.
The backend components are written in the Go programming language. The software supports MySQL back to version 5.6, as well as MySQL-knockoff MariaDB back to version 10. Backups can be done to either a Network File Server, or to a blob store.
Vitess is the 16th project to be taken on by CNCF, alongside Kubernetes, Prometheus, OpenTracing, Fluentd, Linkerd, gRPC, CoreDNS, containerd, rkt, CNI, Envoy, Jaeger, Notary, TUF and Rook. Vitess has been accepted as an incubation-level project, under the CNCF Graduation Criteria v1.0.
One of the requirements for any CNCF incubation project is that it is used successfully in production by at least three independent end users. Here, Vitess is well covered: BetterCloud, Flipkart, Quiz of Kings, Slack, Square Cash, and Stitch Labs all use the software, in addition to YouTube itself. The use can range across mobile apps, gaming companies, financial institutions, retail and other businesses.
Stitch Labs, for instance, has about hundred shards running on Kubernetes, managing well over hundred thousand queries per second (QPS), Sougoumarane said. Slack is another organization that deploys Vitess. The company wanted to continue to use MySQL, though its rapidly-growing service would require billions of MySQL transactions to be processed per day. “We needed a solution that would offer a familiar full-featured SQL interface, and wanted to continue to use MySQL as the backing store to maintain our operations knowledge and comfort level,” said Michael Demmer, Slack senior staff engineer, in a statement. “Vitess is a natural choice for this purpose and has served us well so far.”
Booking.com, GitHub, HubSpot, Slack, and Square all actively contribute to the project.
The Cloud Native Computing Foundation is a sponsor of The New Stack.