mvcc: don't block on concurrent reads

[heyitsanthony]

Right now mvcc must acquire a heavily contended mutex to make Range requests. For better scalability, protect it without taking the mutex.

[vimalk78]

currently a Range request acquires

• a read lock in mvcc.kvindex
• a lock in mvcc.store
• a lock in mvcc.backend.batchTx

are you planning to remove all three locks?

can you pls share your idea ?

[heyitsanthony]

@vimalk78 mvcc.store and mvcc.backend.batchTx. There's already a RWMutex in mvcc.kvindex, so there's no read contention. There's going to be a separate transactional view for reads. This is related to getting the performance back for #6876.

[vimalk78]

the mvcc.store.mu should be change to RWMutex, cannot completely remove it from Range path.

for reading the boltdb, do you plan to hold a single ReadOnly transaction, or create a new ReadOnly transaction for every Range request, or use DB.View method. perhaps using DB.View will be better as we dont have to deal with transactions directly and create/close will be done by boltdb.

[xiang90]

@vimalk78

xiang90@1fcc012

This is an example for what we should start with. But note that the readTx needs to capture the changes happened in batchTx before it. So we need to have a shared in-mem map in front of these txs.

@heyitsanthony might provide more thoughts on that.