Architectural
Patterns
What solutions can you implement with Tarantool? And more importantly, how can they help you digitize the business? Check the basic Tarantool patterns here or request a demonstration to solve your problems right away.
Reliable NoSQL DBMS
Check Patternin Repository
- Read and write performance up to 1 million RPS per core
- Minimum response time of 50 nanoseconds
- Synchronous and asynchronous replication
You can use Tarantool as complete storage and source of data. Our DBMS is fast, fault-tolerant, and ACID compliant. With Tarantool, you can build solutions for the whole project, e.g. when starting a business, or use it as a separate component in a microservice architecture. In any case, you wouldn’t need any additional DBMS.
Disk Writing, Synchronous Replication, and Backup Recovery tools allow you to store mission-critical system data, like user profiles or authorization data, in Tarantool.
Tarantool performance is ensured by a built-in application server. The application server is embedded into the in-memory storage engine, so you can customize the database behavior for any business task. Tarantool provides two storage engines. You can store data in RAM only, or write it onto disk when the amount of data exceeds the RAM capacity.
Database Cache Consistency
Check Patternin Repository
- Fault tolerance powered by replication
- Persistence: no cache warm-up
- Ready-to-use connectors for popular databases, buses, queues: Oracle, Kafka, MySQL, PostgreSQL, MQTT, and others
This pattern is the most typical one. Over a half of all Tarantool solutions are designed to speed up legacy systems. When users access the same dataset at the same time, the number of reads increases significantly. The load increases, responses get delayed, and the customers become anxious. Consider a simple example. Every employee checks the balance on a payday.
Tarantool is persistence database, it does not need warming up. This means that you don’t have to wait hours that a traditional cache warm-up would take. Tarantool immediately restores the last state on restart by backing up the write-ahead logs and snapshots.
In this case, Tarantool acts as an intermediate data storage. It is by orders of magnitude faster than the main database: it can manage a workload of over 100 thousand RPS, compared with a thousand RPS for a traditional DBMS. This solution is easy to scale using replication and sharding.
Data Replication from Oracle or MySQL
Check Patternin Repository
- Automatic migration and application of the data schema
- Read and write performance up to 1 million RPS per core
- Ready-to-use connectors for popular databases, buses, queues: Oracle, Kafka, MySQL, PostgreSQL, MQTT, and others
Replication is used in projects that require improved performance and fault tolerance. Replication is a way to scale the database when information from one server is constantly replicated to another one, i.e. to a replica. In this case, Tarantool acts as a replica, which allows you to save on hardware.
Since Tarantool stores the data in RAM, you can improve the speed of your solution. To do this, implement the write-through approach, that is, perform all writes through Tarantool.
You can locate Tarantool replicas on different servers, or locate multiple Tarantool instances on the same server. We provide ACID guarantees for cluster transactions in distributed databases.
Persistent Queues
Check Patternin Repository
- PUT/GET speed in a queue up to 100 thousand RPS per instance
- Sharding: storing data on standalone servers
- Connectors for popular databases, buses, queues: Oracle, Kafka, MySQL, PostgreSQL, MQTT, and others
A queue is used in nearly all projects to separate complex data processing tasks and to smoothen the peak load. The simplest example of queue operation is mass mailing.
Tarantool is Russian open-source project that supports queues, and it is perfect for them! When a server restarts, data in the queue is saved due to persistence, so Tarantool immediately restores the latest state from the backup files. With Tarantool, you can also create distributed queues.
The built-in application server allows you to implement complex queue logic. It supports various processing guarantees in case of a failure: the at-least-once guarantee means that a message will be definitely delivered, but can arrive several times.
