35 lines
No EOL
2.2 KiB
Markdown
35 lines
No EOL
2.2 KiB
Markdown
---
|
||
title: "High Performance MySQL: Proven Strategies for Operating at Scale"
|
||
author: "Silvia Botros, Jeremy Tinley"
|
||
isbn: "978-1-492-08051-0"
|
||
---
|
||
|
||
|
||
Famously, people often used MySQL as a queue and then learned the hard way why it was bad. The most cited reasons were the overhead of polling for new queue actions, the management of locking records for process‐ ing, and the unwieldy size of queue tables as data grows over time.
|
||
|
||
Funny enough, this comes when I was wondering if I should it use to hold events instead of Kafka for bas just because the data will be small and I feel lazy about picking up Kafka. Guess I should listen to the experts and not use it for what it is not :)
|
||
|
||
|
||
## Locks
|
||
|
||
Read locks on a resource are shared, or mutually nonblocking: many cli‐ ents can read from a resource at the same time and not interfere with one another. Write locks, on the other hand, are exclusive—that is, they block both read locks and other write locks—because the only safe policy is to have a single client writing to the resource at a given time and to prevent all reads when a client is writing.
|
||
|
||
There can be table level locks and row level locks.
|
||
|
||
|
||
Table level locks:
|
||
- Lock the entire table: nobody can read or edit anything in the table when there is a write lock
|
||
Row level locks:
|
||
- Are implemented in the storage engine, not the server.
|
||
- Only lock certain rows of the table, allowing concurrent operations on the rest of the table.
|
||
|
||
## ACID test
|
||
|
||
The system is ACID complient if it satisfies:
|
||
|
||
1. Atomicity: transactions are all or nothing. There is no possibility of partial execution. If the whole transaction is not successful, everything is rolled back to the initial state.
|
||
2. Consistency: ???
|
||
3. Isolation: the results of a transaction are invisible to other transactions until the transaction is complete. In other words: transaction B is not affected in any way by transaction A when it has not started or is mid-way through execution. Only when transaction A is finished, this might impact transaction B.
|
||
4. Durability: a committed transaction makes permanent changes. The data is persisted and won't be lost, even in the case of an ungraceful shutdown.
|
||
|
||
Continue on page 30. |