What are ACID characteristics? ACID is an acronym that contains the four attributes required to guarantee the reliability of a transaction processing in a database. “Transaction” here means a processing unit which summarizes a series of tasks performing a specific operation in the database and which cannot be broken down any further. ACID stands for Atomicity, Consistency, Isolation and Durability, which are briefly explained as follows:
Atomicity: A property that guarantees that all the tasks in a transaction are executed, if it’s not possible, then none are executed at all Consistency: A property that guarantees to meet the predetermined consistency at the start and end of a transaction Isolation: To hide the process of operations during a transaction from other operations Durability: To keep the operation permanent and the result not lost at the time the user receives the completion notification of the transaction A good example to explain ACID characteristics in actual processing is a remittance between accounts at a bank. In order to securely transmit remittance from one bank account (A) to another (B), the two processes of “withdrawing from A” and “depositing into B” should satisfy ACID characteristics. If ACID characteristics are not guaranteed, something can go drastically wrong, like say for example, only the amount from A decreases while B shows no change, or the balance of B differs every time it is inquired. The banking system is one of the most fundamental aspects of society and its reliance on ACID characteristics truly showcase these characteristics’ importance. It is apparent that the transaction function is necessary for databases where even a slight deviation of data values can be a serious problem, such as with e-commerce sites and banks. More explanation about the four characteristics using this example of bank accounts can be found in various websites like Wikipedia, so you may refer to the link for more details.
Transaction on NoSQL databases Most traditional relational databases have transactional features, and as long as you describe the transaction with appropriate SQL, the return value will not be different depending on the timing. On the other hand, on the distributed NoSQL database, processing performance and scale-out performance are greatly improved by relaxing processing strictness. But as a trade-off, many NoSQL databases don’t support the ACID-guaranteed transaction or have some restrictions. GridDB is a NoSQL database which pursues high-speed and high-scalability and does not have a transaction function for the entire database like a relational database. However, transactions are supported in “container” units. The figure below is a conceptual diagram of GridDB’s key container type. For more details about the key container type, please refer to
![](https://griddb-pro.azureedge.net/en/wp-content/uploads/2017/07/Key-container.png")
We believe that transactions of this container basis are necessary and sufficient when using IoT applications. For example, let’s ponder how to best calculate the power consumption of many smart meters as introduced in
this blog. First, to determine the particle size of the container, create a container for each sensor (each smart meter for this example). This makes it possible to use the “time-series container type” which allows it to handle time series data. Next, make a container to manage geographical information. You may also need to add a container for management purposes. I mentioned earlier that GridDB supports transactions on a container basis. That means that you can process ACID-guaranteed transactions for smart meter containers, administrative containers, containers managing geographic information, and SQL statements. Then, what about calculations across the database? In GridDB, Atomicity is not guaranteed for transactions that refer to multiple containers. Therefore, when updating values ‹‹to multiple containers, it is necessary to describe error handling on the application side. In this case, however, it will not be a big problem as you do not need to update values but just refer to them when you calculate something across the entire database– calculating sum of the power consumption of a certain time using the data of all the smart meters, or analyzing the time change of the electric power consumption and predicting the demand. As we wrote in a previous blog , GridDB is a CP type database, so unlike AP type databases that emphasize availability, values ‹‹do not change every time you query. Thus, in this example, the lack of Atomicity should be no problem and the application side does not need any special error handling. GridDB is an optimal database for applications that focus on data aggregation and analysis and uses the results to make a quick, real-time decisions.
GridDB will satisfy relational database users who have issues with performance as it supports transactions on a per-container basis while also focusing on the consistency of the entire database. If you would like to try GridDB now, the Community Edition has its source code released under the AGPL license, and is available for free here.
If you have any questions about the blog, please create a Stack Overflow post here https://stackoverflow.com/questions/ask?tags=griddb .
Make sure that you use the “griddb” tag so our engineers can quickly reply to your questions.