Translate RU: database - start

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