Blind Write in DBMS

Blind writing, as the name suggests, means writing data into a database without checking or verifying the existing data. It’s a feature that allows write operations to happen directly, without any confirmation. This approach is commonly used in systems where write operations need to happen very frequently, such as in high-load applications. However, because there’s no verification or checks before writing, blind writing can sometimes cause issues like data inconsistencies or problems with managing concurrent operations.

In this article, we’ll explore how blind writing works, along with its benefits and drawbacks, to better understand when it’s useful and what challenges it might bring.

What is a Blind Write in DBMS?

A blind write is when data is written to a database without first locking the data being changed. Normally, databases lock data before writing to ensure that no other transactions can read or modify it at the same time, keeping the data consistent. In blind writing, this locking step is skipped, which can lead to situations where other transactions might try to read or write the same data simultaneously. To handle this, systems using blind writes need ways to manage these conflicts. Skipping locks can significantly speed up the writing process, especially in systems that handle a lot of write operations.

Why Use Blind Writes?

There are two main reasons why developers might choose to use blind writes:

Better Performance
Blind writes help speed up operations by skipping the step of reading data before writing it. This reduces delays and makes write operations faster, especially when dealing with raw data that doesn’t need to be read before being updated.

Avoiding Memory Issues
In situations where multiple systems or threads are accessing the same data, reading it before writing can sometimes lead to problems like lost updates or incorrect results. Blind writes can help avoid these issues by directly performing the write operation without worrying about the current data state.

For example, in a multithreaded process using counters, you can increment the counter for each client without first reading its current value. This ensures that no increments are lost, even if multiple clients are updating the counter at the same time.

Why Do Blind Writes Occur?

Developers might use blind writes for a few common reasons:

Skipping Error Handling
Sometimes developers skip checking for errors to save time. This could be due to laziness or the belief that error handling isn’t necessary. They might also copy code from elsewhere without verifying it, assuming it will work as is.

Making Assumptions
A developer might assume that the write operation will succeed and skip verifying conditions beforehand. However, if their assumption turns out to be wrong or the situation changes unexpectedly, the blind write can fail.

Race Conditions
In concurrent applications, race conditions are a common issue. A developer might check if it’s safe to write and find no conflicts, but between the check and the actual write, another operation could change the data, causing the write to fail. These unexpected changes can lead to problems like lost updates or inconsistent data.

How Does Blind Writing Work in DBMS?

No Locking on Write Operations

In most databases, operations like updating, inserting, or deleting data involve locking rows to prevent conflicts. Blind writes skip this locking step, allowing updates to happen faster. For example, if a customer’s address needs to be updated, the change happens directly without locking the data.

Multi-Version Concurrency Control (MVCC)

To make blind writing work, databases use a system called MVCC. This keeps old versions of the data even after updates, so transactions reading data can see a consistent version based on when they started. For instance, if a payment is being processed while a customer’s address is updated, the payment transaction still sees the old address until it finishes.

Asynchronous Lock Checks

After the write operation is done, the database checks for conflicts in the background. It tries to acquire a lock, verify no conflicts occurred, and ensure the write didn’t overwrite something it shouldn’t have. If a conflict is found, the write is undone, and the operation has to be retried. For example, if an order is added but another transaction deletes it at the same time, the add operation might fail and need to try again.

Eventual Consistency Model

Since conflict checks happen after the data is written, there’s a chance other transaction could read the new data before it’s confirmed as correct. This means the database may not always show the latest, accurate data immediately, but it will eventually. For instance, a report might show orders that were placed in the last minute but haven’t yet been fully processed.

Retry and Resolution Logic

Applications using blind writes need to handle retries when conflicts happen. If a write fails due to a conflict, the system retries it up to a certain number of times before giving up. For example, a payment process might allow up to five retries if a conflict occurs, and if it still fails, it stops to avoid an infinite loop.

Advantages and Disadvantages of Blind Writes

Advantages of Blind Writes

Blind writes come with two main benefits:

Faster Writes with Less Delay

By skipping the step of acquiring locks, blind writes allow data to be written much faster. This reduces the waiting time for transactions and increases the speed of write operations, making it possible to handle a higher volume of writes efficiently.

Reads and Writes Can Happen at the Same Time

In traditional systems, read and write operations on the same data often block each other, causing delays. With blind writes, reads can continue using older versions of the data, even while updates are happening. This allows both reading and writing to happen at the same time, improving the system’s overall performance.

These advantages make blind writes ideal for systems with heavy write loads, like MongoDB or Elasticsearch, which use similar techniques to achieve high performance. The ability to handle more writes in less time is the biggest strength of blind writes.

Disadvantages of Blind Writes

Blind writes also have some drawbacks that need to be managed carefully:

Conflict Resolution is More Complex

Since multiple transactions can try to access the same data at the same time, the application needs extra logic to detect errors, retry failed writes, and resolve conflicts. This adds complexity for developers.

Risk of Data Inconsistencies

Other transactions might see partially updated or incorrect data before changes are finalized. This can result in “dirty reads,” where the data isn’t yet consistent.

More Storage is Needed

Blind writes rely on storing multiple versions of data (old and new) to handle concurrency, which uses up more disk space and memory compared to traditional systems.

Index Performance Can Degrade

Frequent updates with blind writes can lead to fragmented indexes, which might slow down read performance over time.

Blind writes trade off some of the guarantees of traditional database systems, like strict consistency and isolation, to improve speed and scalability. While they are great for performance in write-heavy systems, they require careful handling to manage concurrency issues and maintain reliable data.

Conclusion

Blind writes offer a way to significantly boost write speed and handle more data in less time compared to traditional database transactions that prioritize strict consistency and isolation. This makes them a great fit for scenarios where performance matters more than perfect consistency, like logging, collecting metrics, or managing rapidly growing datasets such as time series data.

However, this performance boost comes with trade-offs. Blind writes reduce consistency guarantees and shift some of the responsibility for handling conflicts and errors from the database to the application. This adds complexity to the application code, so it’s important to fully understand these challenges before choosing this approach.

When used wisely and with careful programming, blind writes can be a powerful tool for scaling database systems in write-heavy applications, offering flexibility and performance beyond what traditional relational databases typically provide.

FAQs: –

• Why Use Blind Writes?

Blind writes are great for speeding up database performance. By skipping the step of locking data before making changes, they reduce the time it takes to complete write operations. This allows the database to handle many more writes per second, making blind writes ideal for applications that require fast and frequent data updates.

• When Should Blind Writes Be Avoided?

Blind writes come with a trade-off: they don’t guarantee immediate data consistency. This means they’re not suitable for situations where accuracy and consistency are critical, like financial transactions or other high-stakes applications. If your database needs to show the most up-to-date data at all times, blind writes aren’t a good choice.

• How Are Conflicts Handled with Blind Writes?

Using blind writes means your application must be ready to deal with conflicts. When two transactions try to change the same data at the same time, conflicts can happen. Developers need to write code that detects these issues, retries failed writes, and ensures updates are applied correctly. Handling this requires more effort compared to traditional databases, which handle these scenarios automatically.

• Can Blind Writes Lead to Data Loss?

Yes, blind writes can sometimes cause data loss. Since they skip locking, a more recent update can overwrite an earlier one without considering its changes. This is called a “lost update.” To avoid this, applications need to carefully manage and resolve conflicts.

• Do Blind Writes Affect Data Durability?

They can. If a system crash happens between a blind write and the database’s conflict check, incomplete or incorrect changes might get saved. To ensure data durability in such cases, databases may need special techniques, like journaling, to keep a reliable record of changes.