[openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step)

Radomir Dopieralski openstack at sheep.art.pl
Fri Mar 14 10:18:25 UTC 2014


On 14/03/14 11:08, Alexei Kornienko wrote:
> On 03/14/2014 09:37 AM, Radomir Dopieralski wrote:

[snip]

>> OpenStack is a big, distributed system of multiple databases that
>> sometimes rely on each other and cross-reference their records. It's not
>> uncommon to have some long-running operation started, that uses some
>> data, and then, in the middle of its execution, have that data deleted.
>> With soft delete, that's not a problem -- the operation can continue
>> safely and proceed as scheduled, with the data it was started with in
>> the first place -- it still has access to the deleted records as if
>> nothing happened. You simply won't be able to schedule another operation
>> like that with the same data, because it has been soft-deleted and won't
>> pass the validation at the beginning (or even won't appear in the UI or
>> CLI). This solves a lot of race conditions, error handling, additional
>> checks to make sure the record still exists, etc.
>
> 1) Operation in SQL are working in transactions so deleted records will
> be visible for other clients until transaction commit.
>
> 2) If someone inside the same transaction will try to use record that is
> already deleted it's definitely an error in our code and should be fixed.
> I don't think that such use case can be used as an argument to keep soft
> deleted records.

Yes, that's why it works just fine when you have a single database in
one place. You can have locks, transactions, cascading operations and
all this stuff, and you have a guarantee that you are always in a
consistent state, unless there is a horrible bug.

OpenStack, however, is not a single database. There is no system-wide
solution for locks, transactions or rollbacks. Every time you reference
anything across databases, you are going to run into this problem.

-- 
Radomir Dopieralski



More information about the OpenStack-dev mailing list