22 lines
1.7 KiB
ReStructuredText
22 lines
1.7 KiB
ReStructuredText
######################
|
|
Transaction Processing
|
|
######################
|
|
|
|
We often get asked how FoundationDB can achieve high performance for transaction processing over a scalable, distributed cluster. Here is a brief overview.
|
|
|
|
The transactional authority
|
|
===========================
|
|
|
|
Because FoundationDB supports concurrent operations by clients, it uses a distributed set of nodes working together as a *transactional authority* to detect conflicting updates. Transactions execute using optimistic concurrency control, so they don't need to lock a key before updating it and unlock it afterward. Instead, when a transaction is submitted to the transactional authority, it will be rejected if there has been a conflicting transaction, requiring the client to retry the rejected transaction.
|
|
|
|
Transaction servers
|
|
===================
|
|
|
|
To maintain high performance, the transactional authority is implemented by a number of individual *transaction servers*, each of which manages a portion of the incoming stream of transactions. FoundationDB's design decomposes transaction processing into its individual functions and scales them independently. The separate functions are:
|
|
|
|
* batching incoming transactions;
|
|
* checking transaction conflicts;
|
|
* logging transactions;
|
|
* durably storing the data.
|
|
|
|
Of these functions, many people intuitively focus on transaction conflict checking stage as a potential bottleneck. Fortunately, it turns out that this function *is* scalable. FoundationDB uses a sophisticated data-parallel and multithreaded algorithm to optimize conflict-checking so that it requires only a small percentage of the system's total work. This optimization allows a few transaction servers to keep up with a large cluster of storage servers. |