В этом посте представлен обзор текущих проблем, возникающих при создании систем удовлетворяющих требованиям ACID и возможности их преодоления без перехода к NoSQL системам. | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translation complete.
If you do not want to register an account, you can sign in with OpenID.
The problems with ACID, and how to fix them without going NoSQL | В этом посте представлен обзор текущих проблем, возникающих при создании систем удовлетворяющих требованиям ACID и возможности их преодоления без перехода к NoSQL системам. | |
It is a poorly kept secret that NoSQL is not really about eliminating SQL from database systems (e.g., see these links). Rather, systems such as Bigtable, HBase, Hypertable, Cassandra, Dynamo, SimpleDB (and a host of other key-value stores), PNUTS/Sherpa, etc. are mostly concerned with system scalability. It turns out to be quite difficult to scale traditional, ACID-compliant relational database systems on cheap, shared-nothing scale-out architectures, and thus these systems drop some of the ACID guarantees in order to achieve shared-nothing scalability (letting the application developer handle the increased complexity that programming over a non-ACID compliant system entails). In other words, NoSQL really means NoACID. | Широко известно, что набирающее последнее время популярность NoSQL движение направлено отнюдь не на исключение SQL из СУБД. Скорее основной целью систем, подобных Bigtable, HBase, Hypertable, Cassandra, Dynamo, SimpleDB (и множеству других хранилищ "ключ-значение"), PNUTS/Sherpa и прочих является масштабируемость системы. Масштабирование традиционных ACID реляционных СУБД на дешевых серверах и архитектуре "shared-nothing", оказывается очень сложной задачей. Поэтому вышеуказанные системы отбрасывают некоторые из ACID требований, чтобы достичь масштабируемости. Однако масштабируемость в данном случае достигается за счет усложнения разработки приложений, т.к. необходимые примитивы синхронизации запросов и транзакций нужно создавать самостоятельно. Таким образом, NoSQL скорее означает NoACID. | |
Our objective in this post is to explain why ACID is hard to scale. At the same time, we argue that NoSQL/NoACID is the lazy way around these difficulties---it would be better if the particular problems that make ACID hard to scale could be overcome. This is obviously a hard problem, but we have a few new ideas about where to begin. | В этой заметке нам хотелось бы прежде всего объяснить, почему так тяжело масштабируется ACID-система. В то же время хочется подчеркнуть, что NoSQL\NoACID слишком "простой" путь на наш взгляд. Вместо того, чтобы обходить проблемы, мешающие масштабированию ACID систем, было бы лучше попытаться их решить. Несомненно, это сложная задача, но у нас есть пара новых идей. | |
ACID, scalability and replication | ||
For large transactional applications, it is well known that scaling out on commodity hardware is far cheaper than scaling up on high-end servers. Most of the largest transactional applications therefore use a shared-nothing architecture where data is divided across many machines and each transaction is executed at the appropriate one(s). | Известно, что масштабировать большие транзакционные системы, увеличивая количество "обычных" серверов, намного дешевле, чем увеличивать мощность сервера, покупая все более мощные сервера верхнего ценового сегмента. Поэтому значительное количество больших транзакционных приложений используют shared-nothing архитектуру, когда данные распределяются по множеству машин и каждая транзакция выполняется на необходимых машинах. | |
The problem is that if a transaction accesses data that is split across multiple physical machines, guaranteeing the traditional ACID properties becomes increasingly complex: ACID's atomicity guarantee requires a distributed commit protocol (such as two-phase commit) across the multiple machines involved in the transaction, and its isolation guarantee insists that the transaction hold all of its locks for the full duration of that protocol. Since many of today's OLTP workloads are composed of fairly lightweight transactions (each involving less than 10 microseconds of actual work), tacking a couple of network round trips onto every distributed transaction can easily mean that locks are held for orders of magnitude longer than the time each transaction really spends updating its locked data items. This can result in skyrocketing lock contention between transactions, which can severely limit transactional throughput. | В ситуации когда транзакция затрагивает данные, расположенные на нескольких физических машинах, поддержка ACID свойств становится все сложнее. Требование атомарности транзакций приводит к тому, что необходим распределенный протокол фиксации транзакций (как, например, двухфазная фиксация) на всех машинах, участвующих в транзакции. Для изолированности транзакций необходимо блокирование требуемых ресурсов на все время выполнения транзакции. |
