Bolt is a global mobility company headquartered in Estonia that mainly offers vehicle hiring, micromobility, car-sharing, and food delivery services. Bolt has over 100 million customers in more than 500 cities across 45 countries and regions, has partnerships with over 3 million vendors globally, and employs more than 3,000 people.
Major pain points with the previous MySQL solution
Previously, Bolt used MySQL as its main database. This solution worked well for quite a while. But as Bolt’s business grew, MySQL was not able to keep up with the ever increasing workload.
The database was difficult to scale, operate, and maintain
Bolt has many product teams that develop and manage thousands of microservices. These microservices process hundreds of terabytes in more than 300 schemas, and the data volume is ever growing. MySQL could hardly scale to handle so much data. To try and remedy the situation, Bolt manually sharded tables and added columns. But this was time-consuming, the process takes a week or longer on a loaded one terabyte table. In addition, there were operational issues when they ran commands like ALTER (DDL) or ran a backup.
Fragile storage reliability and availability
In order to support its millions of customers, Bolt has incredibly high expectations of system uptime and disaster recovery. But their old MySQL-based storage solution was too fragile to survive disasters. They would occasionally lose data, even though they deployed a multi-master cluster like Galera to MySQL to enhance the system’s availability.
Bolt spent quite a bit of time exploring new solutions before they chose TiDB. For example, they once considered Vitess. But it turned out that Vitess required too many changes to Bolt’s applications—and it had similar operational issues to MySQL. Moreover, Vitess had poor MySQL compatibility. Bolt finally chose TiDB, an open source, distributed NewSQL database, for good reasons.
TiDB has been an open source database since day one. Every line of code is transparent, so Bolt can change, hack, modify, and customize the code according to their needs, and TiDB will still work.
TiDB has almost infinite horizontal scalability. By automatically adding or removing storage nodes, it can easily handle up to hundreds of terabytes of sudden data spikes or plunges. In addition, TiDB’s architecture separates computing and storage, so Bolt can scale in or out the compute and storage resources separately according to their changing business needs. This also helps Bolt control their database and operation costs.
TiDB uses the Raft consensus algorithm to ensure that data is highly available and safely replicated throughout storage in Raft Groups. TiKV is TiDB’s storage server, and data is redundantly copied between TiKV nodes and placed in different Availability Zones to protect against machine or data center failure. TiDB provides automatic failover, which ensures system uptime. In addition, TiDB offers a choice of multiple disaster recovery solutions, each of which applies to different scenarios with flexible costs.
MySQL compatible and integrated with main tech stacks
TiDB is highly compatible with MySQL, so it was easy for Bolt’s engineering team to migrate data to TiDB. They saved both time and money. In addition, TiDB is well-integrated with main tech stacks such as Kafka and Kurbenetes, and can be run on AWS as well.
TiDB is designed to work in the cloud, on-premises, or in hybrid environments. It is cloud native in that it takes full advantage of the scalability and elasticity of the cloud. Running a distributed SQL environment provides many advantages, with added resiliency and the ability to scale up, down, in, or out as needed to meet business requirements. TiDB’s cloud-native capabilities allow users to scale as needed to meet changing business needs, with costs always kept in check.
Further, when you combine TiDB with Kubernetes, users can:
- Ensure consistent environments for development and deployment.
- Instantiate a new node as needed, whether to accommodate growth or to replace a lost node.
TiDB is a cost effective solution as a whole.
- It has strong compression capability, which reduces storage costs. For example, a four terabyte MySQL table can be compressed to less than two terabytes after being migrated to TiDB. According to Bolt’s production experience, TiDB’s average compression rate is around 3. But the rate might change slightly—sometimes more and sometimes less—depending on the data type.
- It has a simplified architecture and can handle transactional and analytical workloads at the same time.
- It can horizontally and separately scale in or out computing and storage resources according to business requirements.
- It is easy to operate and maintain, which also decreases maintenance costs.
- It has good MySQL compatibility, so the migration process is smooth and easy.
- It supports flexible deployment on Amazon Elastic Kubernetes Service (EKS) with Graviton2 (Arm64), which enables better price to performance.
During the deployment, migration, and usage process, Bolt got prompt support from TiDB engineers, and received special and customized improvements to TiDB.
TiDB in production
As of October 2022, Bolt has deployed seven TiDB clusters storing dozens of terabytes of data and hundreds of schemas.
- Four TiDB clusters are running for the production business, including the balance, billing, ordering, and internet of things (IoT) services.
- Two TiDB clusters are alpha and beta clusters for development or pre-production.
- One TiDB cluster is a downstream cluster deployed in Stockholm for disaster recovery.
Speak with an Expert
Book a Demo from one of our experts and let us know how we can help.
In the future, Bolt plans to rely on TiDB even more, including migrating more clusters from MySQL to TiDB, using TiDB’s change data capture tool, TiCDC , to set up multi-region clusters on AWS for failover, and trying TiFlash, TiDB’s columnar store, for instant analytical queries.
This article is created based on a talk given by Boris Savelev at the Virtual HTAP Summit.