Discover how we transform IT and strengthen the security of the top companies in the market.
Integrated security to detect, prevent, and respond to threats.
Continuity and recovery to keep your business always running.
Compliance and security culture to elevate your company’s cyber maturity.
Take control of your company’s IT with integrated and secure management tools.
Hybrid and integrated infrastructure to support the evolution of your business.
Use hybrid cloud with the security of having the support of one of the most important players in the market.
Specialized services to operate and evolve your IT efficiently.
Provide your company with Private Network solutions that only an end-to-end integrator can offer.
Outsource efficiently, maintaining control over everything your company needs.
Handle payment and invoice issuance with credibility, efficiency, and data security.
Articles, events, and information to go beyond and dive deep into each technology. Be inspired to transform your company.
Learn about technological innovations and how they can benefit your company.
When relational databases were first conceived, one of the concepts adopted was the “ACID” concept, which is an acronym for four characteristics that databases are believed to require:
Together, these properties make a relational database secure and reliable for most systems:
The principle of atomicity guarantees that a transaction is treated as something indivisible (A “not” and TOMO “division”). The term atom emerged about 500 years BC, when the Greek philosopher Democritus conjectured about the division of matter into increasingly smaller portions until it could no longer be divided.
When applied to database transactions, this concept was incorporated so that a transaction composed of multiple instructions cannot be divided. Imagine transferring $20 from João’s account to Maria’s account. If this transaction were executed partially, we would lose João’s money or create money in Maria’s account, causing a problem. Therefore, the database must guarantee that both operations succeed, or that neither occurs.
By the principle of consistency, if a database is considered consistent before a transaction, it must remain consistent after the transaction. Using the previous example where João pays Maria $20, the sum of João’s and Maria’s balances combined cannot change after a transaction, since we are taking from one and giving to the other.
The principle of isolation must guarantee that, in a situation with multiple transactions occurring simultaneously, one does not interfere with the other, so that the result of all transactions — regardless of whether they are executed in parallel or sequentially — is the same.
The principle of durability indicates that as soon as a transaction is closed (commit), its effect is not lost, even in cases of software or hardware failure.
These principles are the soul of the database and, thanks to them, databases are highly reliable for data manipulation. However, for them to function properly, we need to impose rules and limits, such as lock concepts and PK and FK constraints. Because of these limits, depending on the modeling used, some applications may experience performance issues that make certain systems unfeasible.
With this in mind and trying to solve these performance problems, a relaxation of these rules was created, which were “creatively” named BASE, making an analogy to the pH principle (acid vs. base) in chemistry:
In this model, created with the primary objective of increasing performance and availability, data distribution and multiple servers are used as a strategy, allowing for horizontal scalability. However, this brings problems.
The first concept to be understood in the BASE model is “Eventual Consistency.” To understand how this works, let’s imagine that a database has 2 nodes and that every piece of data recorded in one of the nodes is replicated to the other. With this configuration, we have two options for reading the information, doubling the read performance.
However, to avoid hindering write performance, the application makes changes to only one of the nodes and, through an independent process, these changes are replicated to the other node. Since this replication does not occur instantaneously (non-atomic), there is a possibility that an application reading the same information from both nodes will obtain different values, being considered inconsistent. Nevertheless, if an information is not changed for some time, we can expect that at the end of the replication, the data will become identical, becoming consistent again.
The second concept involved in the BASE model is “Soft State.” If we imagine the states a transaction passes through, we can have periods where it is active, in the process of finishing, being aborted, or completed. Following the same principle, a distributed transaction can only be considered “completed” when the change has actually been replicated to all nodes.
Before this occurs, reading the information from all nodes may return inconsistent data, and we have no way of knowing if: 1 – the change failed on the second node or 2 – due to high latency, the data has not yet been replicated. Since we cannot state exactly what state the transaction is in, we have the “Soft State.”
The concept of “Basically Available” has to do with the durability and availability of a change. In a database with distributed data, all nodes are considered available, and it is possible for two applications to change a certain piece of information simultaneously, each in a different node. Upon executing the replication, the database perceives an inconsistency and needs to resolve the problem.
Imagine a piece of information with content ‘A’ being changed from ‘A’ to ‘B’ on node 1 by application 1 and, simultaneously, being changed from ‘A’ to ‘C’ on node 2 by application 2. What should be the final result after the data “convergence”? ‘B’ or ‘C’? One of the pieces of information must be discarded, causing the data to not remain available. Additionally, data recently inserted into one of the nodes and not yet replicated also cannot be read through the other node, making it temporarily unavailable.
Given these problems of the BASE model, under what circumstances could this model be used safely? Examples of this are content search systems like Google and YouTube. When searching for information, we may eventually receive an incomplete response. However, this does not affect the general functioning of the system and does not affect all information in the database in a generalized way. We can create an unlimited number of replicas, greatly increasing processing capacity, and an eventual inconsistency or loss of data does not significantly impact the result.
Although the ACID and BASE concepts are not exclusive indicators of RELATIONAL or NoSQL databases, respectively, it is common to find relational databases implementing ACID principles and NoSQL databases implementing BASE principles. An example of an exception to this is the Oracle NoSQL database, which can work with both models. It functions with BASE principles most of the time due to distributed transactions but can perform transactions with multiple operations on a single node using the ACID model.
Our team of experts is ready to support your company with solutions that enhance performance and security.
