Translate RU: database - start
voitau
parent
a94dbf4c70
commit
ccb8233dc6
108
README-ru.md
108
README-ru.md
|
|
@ -1790,7 +1790,11 @@ l10n:p -->
|
|||
|
||||
## Database
|
||||
|
||||
TBD
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/Xkm5CXz.png"/>
|
||||
<br/>
|
||||
<i><a href=https://www.youtube.com/watch?v=w95murBkYmU>Источник: Scaling up to your first 10 million users</a></i>
|
||||
</p>
|
||||
|
||||
<!-- l10n:p
|
||||
### Relational database management system (RDBMS)
|
||||
|
|
@ -1809,7 +1813,23 @@ l10n:p -->
|
|||
|
||||
### Relational database management system (RDBMS)
|
||||
|
||||
TBD
|
||||
Реляционная база данных (SQL) - это набор данных, организованных в виде таблиц.
|
||||
|
||||
**ACID** - описывает набор свойст [транзакций для реляционных баз данных](https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D1%8F_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0)).
|
||||
|
||||
* **Атомарность (Atomicity)** - каждая транзакция выполняется либо целиком, либо не выполняется совсем (откатывается)
|
||||
* **Согласованность (Consistency)** - любая транзакция переводит базу данных из одного правильного состояния в другое правильное состояние, сохраняя согласованность данных
|
||||
* **Изолированность (Isolation)** - параллельное выполнение транзакцией должно иметь такие же результаты, как и их последовательное выполнение
|
||||
* **Стойкость (Durability)** - после завершение транзакции, данные должны остаться сохранёнными
|
||||
|
||||
Существует ряд подходов для масштабирования реляционных баз данных:
|
||||
|
||||
* репликация "ведущий-ведомый"
|
||||
* репликация "ведущий-ведущий"
|
||||
* федерализация
|
||||
* шардирование
|
||||
* денормализация
|
||||
* SQL тюнинг
|
||||
|
||||
<!-- l10n:p
|
||||
#### Master-slave replication
|
||||
|
|
@ -1825,7 +1845,14 @@ l10n:p -->
|
|||
|
||||
#### Master-slave replication
|
||||
|
||||
TBD
|
||||
Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могу реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
|
||||
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/C9ioGtn.png"/>
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): master-slave replication
|
||||
|
|
@ -1836,7 +1863,8 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): master-slave replication
|
||||
|
||||
TBD
|
||||
* Для переключения ведомого сервера в ведущий необходима дополнительная логика
|
||||
* См. [Disadvantage(s): replication](#disadvantages-replication) для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".
|
||||
|
||||
<!-- l10n:p
|
||||
#### Master-master replication
|
||||
|
|
@ -1852,7 +1880,13 @@ l10n:p -->
|
|||
|
||||
#### Master-master replication
|
||||
|
||||
TBD
|
||||
Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестают работать, система может продолжать работать на чтение и запись.
|
||||
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/krAHLGg.png"/>
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): master-master replication
|
||||
|
|
@ -1865,7 +1899,10 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): master-master replication
|
||||
|
||||
TBD
|
||||
* Необходим балансировщик нагрузки или понадобиться изменить логику приложение для опеределения куда будет идти запись.
|
||||
* Большинство систем "ведущий-ведущий" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
|
||||
* При возрастании количества серверов на запись (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
|
||||
* См. [Disadvantage(s): replication](#disadvantages-replication) для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): replication
|
||||
|
|
@ -1879,7 +1916,11 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): replication
|
||||
|
||||
TBD
|
||||
* Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
|
||||
* Операции записи реплицируются на ведомый сервера. Если совершается много операций на запись, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций на чтение.
|
||||
* С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
|
||||
* На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
|
||||
* Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Source(s) and further reading: replication
|
||||
|
|
@ -1890,7 +1931,8 @@ l10n:p -->
|
|||
|
||||
##### Source(s) and further reading: replication
|
||||
|
||||
TBD
|
||||
* [Scalability, availability, stability, patterns](http://www.slideshare.net/jboner/scalability-availability-stability-patterns/)
|
||||
* [Multi-master replication](https://en.wikipedia.org/wiki/Multi-master_replication)
|
||||
|
||||
<!-- l10n:p
|
||||
#### Federation
|
||||
|
|
@ -1906,7 +1948,14 @@ l10n:p -->
|
|||
|
||||
#### Federation
|
||||
|
||||
TBD
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/U3qV33e.png"/>
|
||||
<br/>
|
||||
<i><a href=https://www.youtube.com/watch?v=w95murBkYmU>Source: Scaling up to your first 10 million users</a></i>
|
||||
</p>
|
||||
|
||||
Федерализация (или функциальное разделение) разбивает базы данных по функциям. Например, вместо одной монолитной базы данных, можно создать три отдельных базы данных:
|
||||
**форум**, **пользоватили** и **товары**, что приведет к меньшему количествую операций чтения и записи в каждую базу данных и, как следствие, сократить задержку репликации. Меньшие базы данных позволяют хранить больше данных в памяти, что приводит к более оптимальному использованию кэширования. Из-за отстуствие единого ведущего сервера, операции записи можно делать параллельно, увеличавая пропускную способность.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): federation
|
||||
|
|
@ -1919,7 +1968,10 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): federation
|
||||
|
||||
TBD
|
||||
* Федерализация неэффективна, если схема базы данных требует больших функций или таблиц.
|
||||
* Неободимо изменить логику приложения, чтобы определить, с какими базами данных работать.
|
||||
* Операция соединения данных (JOIN) становится сложнее [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
|
||||
* Федерализация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Source(s) and further reading: federation
|
||||
|
|
@ -1929,7 +1981,7 @@ l10n:p -->
|
|||
|
||||
##### Source(s) and further reading: federation
|
||||
|
||||
TBD
|
||||
* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)
|
||||
|
||||
<!-- l10n:p
|
||||
#### Sharding
|
||||
|
|
@ -1949,7 +2001,17 @@ l10n:p -->
|
|||
|
||||
#### Sharding
|
||||
|
||||
TBD
|
||||
<p align="center">
|
||||
<img src="http://i.imgur.com/wU8x5Id.png"/>
|
||||
<br/>
|
||||
<i><a href=http://www.slideshare.net/jboner/scalability-availability-stability-patterns/>Источник: Scalability, availability, stability, patterns</a></i>
|
||||
</p>
|
||||
|
||||
Шардирование распределяет данны между разными базами данных так, что каждя база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые сервера (шарды).
|
||||
|
||||
Аналогично [federation](#federation), шардинг уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшение производительность и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увиличая пропускную способность.
|
||||
|
||||
Расптространненый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): sharding
|
||||
|
|
@ -1963,7 +2025,11 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): sharding
|
||||
|
||||
TBD
|
||||
* Логика приложения должна быть адаптирована к работе с шардами, что может привести к более сложным SQL запросам.
|
||||
* Данные могут неравномерно распределяться среди шардов. Например, использование данных активных пользователей, находящихся на одном шарде, увеличивают нагрузку на него.
|
||||
* Балансировка усложняет систему. Функция шардирования, основанная на [consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) может уменьшить общий объем передаваемых данных.
|
||||
* Соединение данных (JOIN) из нескольких шардов сложнее
|
||||
* Шардирование требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Source(s) and further reading: sharding
|
||||
|
|
@ -1975,7 +2041,9 @@ l10n:p -->
|
|||
|
||||
##### Source(s) and further reading: sharding
|
||||
|
||||
TBD
|
||||
* [The coming of the shard](http://highscalability.com/blog/2009/8/6/an-unorthodox-approach-to-database-design-the-coming-of-the.html)
|
||||
* [Shard database architecture](https://en.wikipedia.org/wiki/Shard_(database_architecture))
|
||||
* [Consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html)
|
||||
|
||||
<!-- l10n:p
|
||||
#### Denormalization
|
||||
|
|
@ -1989,7 +2057,11 @@ l10n:p -->
|
|||
|
||||
#### Denormalization
|
||||
|
||||
TBD
|
||||
Денормализация - это попытка улучшить скорость чтения за счет производительности записи. Избыточные копии данных записываюся в несколько таблиц для избежания сложных операций соединения данных. Некоторый СУБД, например [PostgreSQL](https://ru.wikipedia.org/wiki/PostgreSQL) и Oracle поддерживают [материализованное представление](https://ru.wikipedia.org/wiki/%D0%9C%D0%B0%D1%82%D0%B5%D1%80%D0%B8%D0%B0%D0%BB%D0%B8%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5), которые выполнюят задачу хранения избыточных данных и поддержку их согласованности.
|
||||
|
||||
При использовании [federation](#federation) и [sharding](#sharding), данные становятся распределенными. В результате выполнение операций соединения данных усложняется. Денормализация может позволить избавиться от необходимости в сложных JOIN запросах.
|
||||
|
||||
В большинстве систем, количество операций на чтение значительно больше операций на запись (100:1, или даже 1000:1). Операция на чтение в результате сложного соединения данных может быть очень ресурсоемкой и требованть значительного времени, потраченного на операции c жестким диском.
|
||||
|
||||
<!-- l10n:p
|
||||
##### Disadvantage(s): denormalization
|
||||
|
|
@ -2001,7 +2073,9 @@ l10n:p -->
|
|||
|
||||
##### Disadvantage(s): denormalization
|
||||
|
||||
TBD
|
||||
* Данные дублируются.
|
||||
* Ограничения могу помочь поддерживать избыточные копии данных в актуальном состоянии, но увиличивают сложность архитектуры базы данных
|
||||
* Денормализованная база данных под большой нагрузкой может работать медленее, чем её нормализованный аналог.
|
||||
|
||||
<!-- l10n:p
|
||||
###### Source(s) and further reading: denormalization
|
||||
|
|
@ -2011,7 +2085,7 @@ l10n:p -->
|
|||
|
||||
###### Source(s) and further reading: denormalization
|
||||
|
||||
TBD
|
||||
* [Денормализация](https://ru.wikipedia.org/wiki/%D0%94%D0%B5%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F)
|
||||
|
||||
<!-- l10n:p
|
||||
#### SQL tuning
|
||||
|
|
|
|||
Loading…
Reference in New Issue