What is Vitess?

What Is Vitess and What Does It Solve?

Anyone dealing with MySQL is fed-up with the tedious horizontal scaling. Vitess is an easy way to fix this, as this modern database solution is capable of managing end-to-end deployment, sizing, and management of swelled database instance collection. Keep note of the fact that only open-source database instances are supported.

Along with MySQL, it’s compatible with MariaDB and Percona as well. Because of its flexible architecture, Vitess users experience the same ease and effectiveness in the public cloud, private cloud, and hardware-based ecosystem.

By default, Vitess amplifies various basic SQL features and aligns them with NoSQL database scalability. With the right and need-based implementation, it can assist on various fronts, such as -

• Need-based SQL database scaling so that data is shared without causing much surge in the application
• Easy bare-metal migration to any public or private cloud
• Error-free management of a wide range of SQL database instances
• It eases down the MySQL implementation as it supports server protocol and is compatible with leading languages.
• Vitess Kubernetes allows one to install MySQL in Kubernetes using kubectl. 
• Other than k8s, Slack Vitess is also a leading use case of this tool.

‍

Vitess Features

Vitess is popular because of some of its features that other MySQL implementation solutions lack. Have a look at the key ones.

1. Protection

Vitess is committed to keeping the MySQL implementation process seamless and well-protected. To make it happen, it uses query rewriting & sanitization. The process enables developers to add query limits and prevent non-determines updates from taking place.

Then we have query blacklisting, which is important to keep troublesome queries away from your databases. It achieves the goal by customizing the rules.

Query killer is a notable Vitess capability that protects the implementation by eliminating the queries consuming more than usual time while returning data. Lastly, Vitess uses the table ACL feature, which is of great help in determining the access control for the tables.

2. Performance

There are multiple ways using which Vitess ensures that there is hardly any operational failure during the MySQL implementation. For instance, it offers connection pooling that ensures various front-end application queries are coupled in a single MySQL connection. This way, it ensures that queries are always present, which results in optimal performance.

Next, it offers a query deduping feature. It refers to reusing the in-flight queries for the same requests to ensure that a query is always in the execution phase.

Lastly, Vitess manages to control the timeout by using the transaction manager. The tool limits the transaction and prevents overstuffing.

3. Monitoring

Vitess features a wide range of performance analysis tools that one can use to watch over the database's performance. Any performance delays can be quickly spotted and fixed this way.

4. Topology Management Tools

Vitess comes with cluster management tools and a highly optimized GUI that one will seek during topology management. As Vitess-based topologies are meant to work perfectly in cross-regions, management becomes easier than ever.  

5. Sharding

With Vitess, sharing is of premium grade, and its management is seamless. It comes with an in-built re-sharding facility that works dynamically. The native horizontal and vertical support makes things way too easy.

Lastly, Vitess offers a wide range of sharding schemes that can easily integrate.

Vitess Architecture

As mentioned earlier, Vitess is used as a cluster management tool. Perfection and effortlessness are attained because of its crisp architecture that we will explain next.

The key forming aspects of Vitess are VTTablet and VTGate. Let’s understand these two first.  

• VTGate

The first component, VTGate, is basically a cluster of stateless nodes. These nodes mainly work as a front-end resource. Every user-generated query is bound to pass through the VTGate host that later closely inspects the query.

From detailed inspection, VTGate tries to figure out which all shards are part of the query and then forwards only the compatible ones. Structure-wise, every shard features N tablets. Out of all the N tablets, one will be a leader.  

A tablet is further made up of two components, VTTablet and MySQL – Each of them runs on an identical host.

• VTTablet

The second component, VTTablet, bears the responsibility of monitoring local MySQL and ensuring its optimal health. To attain this goal, VTTablet eliminates faulty queries, enforces limitations, and performs periodic health checks. Keep note of the fact that VTTablet will always exist with MySQL.

Metadata is often a part of Vitess architecture. The role of metadata is to explain the keyspace sharded process, define the shard leader, and explain the shard tablets.

• Topology service

All these pieces of data are restocked in the topology service. At the very basic level, topology service has to be a continually performing store capable of housing metadata in a small amount.  

For Vitess, it’s a plug-in-based feature capable of being fully integrated with Consul, Zookeeper, and etcd. The topology service implementation is also possible with the help of a watches-supportive metadata store. VTGate helps in information pulling and writing as topology service implementation takes place.  

When topology services are deployed in Vitess architecture, make sure that they are never deployed in the query hot path. It modifies with every metadata change and is often accessible using node startup.

You can’t access the topology service for every query, and if it demands shard routing, VTGate is used for query caching.  

Now, topology services are further categorized into two sections. The first kind is a global topology service that will have no association with any cell. Often, stagnant data is stored by this variety.

The second kind, The local topology service, is cell-specific and features everything that is the part of global topology service. In addition, it also features information related to a specific cell.  

For instance, the host address of a current cell tablet is stored in a local topology service. Whenever the global topology service receives an update, it’s forwarded to the local counterparts.

• Cells

The next in-discussing Vitess architecture component is a cell that mostly exists in plural form. A cell is nothing but a host collection. The participating hosts will have a distinct failure boundary. This way, it keeps failure impact under control. Cells are often required when Vitess’s cross-region deployment is the goal.

• Vtclclient and vtctld server 

Lastly, we have these two components to explain.  

These two co-exist to create HTTP-based clients and servers that make reading and understanding topology services easier than ever. The key purpose of vtctlclient is to make calls that the vtctld server uses. The viability of this pair decides the extent to which a user can cause cluster changes. 

Mostly, vtctldclient is used to trigger a reparenting scenario, read the tablet metadata, hunt down the shard leader node, and trigger a resharding workflow.

Vitess vs. Vanilla MySQL 

As Vanilla MySQL is also a very famous MySQL implementation method, it’s evident that it will be closely compared with Vitess. Here is a crisp overview of Vitess v/s Vanilla MySQL.

Vitess vs NoSQL 

NoSQL is a traditional resource used for MySQL implementation. But, Vitess is a modern approach as it fixes many loopholes that NoSQL is not fixed.

‍

Conclusion

When MySQL implementation is the concern, Vitess is a consider-worthy option. It is very powerful and will tend to bring commendable outcomes when used right. Once used only by hyperscalers, Vitess is now widely available and is loved by all.  

It’s packed with capabilities that improve performance, protection, and scale.  As compared to traditional approaches like NoSQL, Vitess is far better and result-driven. Try it today and experience lucrative benefits.