Blind Write in DBMS

Blind writing is like what its name suggests means writing data blindly in the database. This refers to a feature in the database in which the write operation of the database system can be performed without any confirmation or verification of existing data. This is highly suitable in work-heavy applications where write operations are performed very frequently. But because the data is not verified or checked before writing it can lead to complications such as data inconsistency and concurrency control.

In this article we will understand the workings of blind writing in the database and look at how it works, we will look at its advantages and disadvantages.

What is a Blind Write?

A blind write simply refers to a write operation on a database that does not first acquire locks on the data it is modifying. In a typical database system, before writing data, exclusive locks would be acquired to prevent other transactions from reading or writing the same data at the same time. This ensures the accuracy and consistency of the data. With a blind write, the data is written without taking those locks. This introduces a risk that another transaction may attempt to read or write the same data simultaneously. Software using blind writes must have mechanisms in place to deal with potential concurrency issues. However, avoiding locks can substantially speed up write performance in some high-volume use cases.

How Blind Writes Works?

No Locking on Write Operations

• When performing a write operation like UPDATE, INSERT, or DELETE, most databases acquire locks on the affected rows before making changes.
• A blind write skips this locking step to achieve faster write performance
• For example, updating a customer record to change their address would just execute the update SQL statement without any row-level locking.

Multi-Version Concurrency Control

• Blind writing requires databases to use multi-version concurrency control (MVCC).
• MVCC means keeping old versions of rows in storage even when updates occur.
• This allows transactions reading data to see a consistent snapshot based on when they started.
• For example, a payment transaction would continue to see the old customer address even after a concurrent update changes it.

Asynchronous Lock Check

• After executing write operations, the database does an Asynchronous lock check.
• It attempts to acquire a write lock, check for conflicts, and confirm no dirty writes occurred.
• If conflicts are found, the write is rolled back and must be retried.
• For example, adding an order row may fail the lock check if another transaction deleted the order already.

Eventual Consistency Model

• Because the check for conflicts happens after the write, the database cannot prevent dirty reads.
• Other concurrent transactions may read data updates before they are confirmed as committed.
• This means data has “eventual consistency” – reads reflect completed writes only eventually.
• Reports may include some uncommitted orders placed in the past minute for example.

Resolution Logic Required

• The application must have logic to retry failed writes due to asynch lock conflicts.
• Typically there are max retry counts before a fatal error to prevent infinite loops.
• Transactions that conflict with uncommitted writes may also fail and retry.
• For example, a payment processing retry loop allows up to 5 retry attempts before failing.

Advantages of Blind Writes

There are two major advantages to using blind write capabilities in a database:

• Improved write throughput and reduced latency for write transactions. By not waiting to acquire locks, writes can happen faster, with less time spent blocking. This allows much higher write volume and lower latency.
• Allowing reads and writes to happen in parallel. In typical systems, read transactions will conflict with writes to the same data, causing them to queue. With blind writes, reads can still proceed using earlier snapshots of data even if it is concurrently being updated. This improves overall utilization – reads and writes can happen in parallel.
• These factors allow blind-writing systems to scale very well for write-intensive use cases. Popular database systems like MongoDB and Elasticsearch use blind writes or similar lock-free concurrency control to achieve high throughput at scale. The improved performance blinds write provide is their biggest advantage.

Disadvantages and Challenges of Blind Writes

Blind writes also come with some substantial downsides:

• Complexity for conflict resolution: The application must have logic to detect write errors caused by concurrent access and retry/resolve them. This can add significant complexity to deal with these race conditions.
• Data inconsistencies visible to other transactions: Other transactions may “see” incomplete updates that are later rolled back. There is no way to fully prevent dirty reads of data.
• Additional storage overhead to preserve row versions: Multi-version storage requires more disk space and memory than single-version data storage.
• Index fragmentation from updates: Indexes may become fragmented more easily due to out-of-order writes. This can impact read performance over time.

In essence, blind writes mean giving up atomicity and isolation, two key properties that allow databases to ensure state consistency. This trade off improves performance, but requires extra work by developers to handle concurrency issues and adds eventual consistency complexities.

Conclusion

Blind writes allow database management systems to improve write throughput and reduce latency dramatically compared to typical atomic, fully isolated transactions. This performance comes at the cost of weakened consistency guarantees and additional complexity to handle that. There are good use cases where giving up some consistency for performance makes sense, such as logging, metrics collection, or rapidly growing datasets like time series data. But blind writing introduces challenges that all teams evaluating the technology should thoroughly understand beforehand – it shifts the complexity from the database into the application code itself. When applied judiciously and with careful programming though, blind write capabilities provide one method for scaling database write capacity higher than traditional relational approaches allow.

Frequently Asked Questions on Blind Write – FAQs

Why use blind writes?

Blind writes significantly speed up write performance and throughput for databases. By skipping upfront locking, they greatly reduce write latency and allow far more write operations per second. This performance boost makes blind writing very useful for write-intensive applications.

When should blind writes be avoided?

Blind writes introduce eventual consistency, where reads may not reflect the latest writes for a period of time. Thus, they are inappropriate for databases that require strong data consistency guarantees. Applications doing mission-critical transactions or dealing with financial data should typically avoid using blind write capabilities.

What conflict handling is required when using blind writes?

The application must have robust error handling and retry mechanisms for failed write operations. Detecting conflicts between concurrent write attempts and properly re-applying changes requires thoughtful coding. Developers must handle more concurrency scenarios compared to databases that prevent dirty writes and lost updates.

Can blind writes lose data?

Yes, since locking is skipped, some blind write scenarios can lead to lost updates where a more recent data change overrides an earlier change, leading to permanent data loss. Careful handling of conflicts is required to prevent this.

Do blind writes affect data durability?

Potentially. If crashes occur during the window between a blind write and subsequent lock check, uncommitted and invalid changes can persist after recovery. Special journaling techniques may be required to ensure durability guarantees.