So far we have seen various problems that arise with concurrent transactions and how different approaches try to tackle them(and sometimes fail). The major issue with…
Transactions: Write skew & why we need serialization?
Up until now we have seen various problems that can arise due to concurrent request for both read as well as write access of a…
Transactions: Tackling lost updates
As part of read committed isolation and snapshot isolation, we primarily focussed on tactics to ensure correctness of reads in a concurrent transactional system. But…
Transactions: Snapshot Isolation
In our previous post we covered read committed isolation level. Read committed isolation level ensures that: We cannot perform reads across transactions It prevents dirty…
Transactions: Read committed isolation
Ensuring that each resource is accessed and modified by a single user at a time is very complex on the application layer. This is why…
Transactions: Atomicity & Isolation
In last post, we saw the use case of why we need transactions to maintain a consistent state of our storage system. A database is…
Transactions: Why we need all or nothing?
In real life applications, things can go wrong for scenarios which you have never considered while designing the application. These failures can happen due to…
Partitioning: Handling secondary indexes in partitions
Up until now we have discussed partitioning in a system where we are able to store a record in a partition and retrieve from the…
Partitioning: Consistent Hashing
While ending our discussion on various approaches to partitioning, we saw how the typical hashing approaches fail when we encounter a node failure or when…
Partitioning: Approaches to partitioning
Before diving into approaches to partition a database, let us clear up one thing in aspect of partition and its relationship with replication. Partitioning &…