diff --git a/README-ru.md b/README-ru.md
index fa622c6a..ad0f954f 100644
--- a/README-ru.md
+++ b/README-ru.md
@@ -1790,7 +1790,11 @@ l10n:p -->
## Database
-TBD
+
+ 
+
+ Источник: Scaling up to your first 10 million users
+
### 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 тюнинг
#### Master-slave replication
-TBD
+Ведущий сервер работает на чтение и запись, реплицируя записи на один или более ведомых серверов. Ведомый сервер работает только на чтение. Ведомые сервера могу реплицировать на дополнительные ведомые сервера (как в древовидной структуре). Если ведущий сервер перестает работать, система продолжает работать в режиме только на чтение до тех пор, пока один из ведомых серверов не станет ведущим, или пока новый ведущий сервер не будет создан.
+
+
+ 
+
+ Источник: Scalability, availability, stability, patterns
+
+
##### Disadvantage(s): master-slave replication
-TBD
+* Для переключения ведомого сервера в ведущий необходима дополнительная логика
+* См. [Disadvantage(s): replication](#disadvantages-replication) для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".
#### Master-master replication
-TBD
+Оба ведущих сервера работают на чтение и запись и координирует операции записи между собою. Если один из ведущих серверов перестают работать, система может продолжать работать на чтение и запись.
+
+
+ 
+
+ Источник: Scalability, availability, stability, patterns
+
##### Disadvantage(s): master-master replication
-TBD
+* Необходим балансировщик нагрузки или понадобиться изменить логику приложение для опеределения куда будет идти запись.
+* Большинство систем "ведущий-ведущий" либо слабо согласованы (нарушая ACID) либо имеют большую задержку из-за необходимости синхронизации.
+* При возрастании количества серверов на запись (ведущих) возрастает задержка и возникает необходимость разрешения конфликтов.
+* См. [Disadvantage(s): replication](#disadvantages-replication) для пунктом, характерных для подходов "ведущий-ведомый" и "ведущий-ведущий".
##### Disadvantage(s): replication
-TBD
+* Существует риск потери данных, если ведущий сервер перестает работать до того, как новые данные будут реплицированы на другие сервера.
+* Операции записи реплицируются на ведомый сервера. Если совершается много операций на запись, ведомые сервера могут быть перегружены реплицированием этих операций, влияя на производительность операций на чтение.
+* С ростом количества ведомых серверов увеличивается объем репликации, что приводит к задержке репликации.
+* На некоторых системах, запись на ведущем сервере может делаться в несколько потоков, выполняемых параллельно. Запись на ведомых серверах происходит последовательно в один поток.
+* Репликация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
##### 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)
#### Federation
-TBD
+
+ 
+
+ Source: Scaling up to your first 10 million users
+
+
+Федерализация (или функциальное разделение) разбивает базы данных по функциям. Например, вместо одной монолитной базы данных, можно создать три отдельных базы данных:
+**форум**, **пользоватили** и **товары**, что приведет к меньшему количествую операций чтения и записи в каждую базу данных и, как следствие, сократить задержку репликации. Меньшие базы данных позволяют хранить больше данных в памяти, что приводит к более оптимальному использованию кэширования. Из-за отстуствие единого ведущего сервера, операции записи можно делать параллельно, увеличавая пропускную способность.
##### Disadvantage(s): federation
-TBD
+* Федерализация неэффективна, если схема базы данных требует больших функций или таблиц.
+* Неободимо изменить логику приложения, чтобы определить, с какими базами данных работать.
+* Операция соединения данных (JOIN) становится сложнее [server link](http://stackoverflow.com/questions/5145637/querying-data-by-joining-two-tables-in-two-database-on-different-servers).
+* Федерализация требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
##### Source(s) and further reading: federation
-TBD
+* [Scaling up to your first 10 million users](https://www.youtube.com/watch?v=w95murBkYmU)
#### Sharding
-TBD
+
+ 
+
+ Источник: Scalability, availability, stability, patterns
+
+
+Шардирование распределяет данны между разными базами данных так, что каждя база данных управляет только частью данных. Например, с увеличением количества пользователей в базу данных пользователей добавляются новые сервера (шарды).
+
+Аналогично [federation](#federation), шардинг уменьшает количество операций записи и чтения на каждый сервер, уменьшая репликацию и улучшая кэширование. Размер индексов также уменьшается, что приводит к улучшение производительность и более быстрым запросам. Если один из шардов выходит из строя, другие шарды продолжают работать. Во избежание потери данных можно ввести дополнительную репликацию данных. Так же как и с федерализацией, нету централизованного сервера на запись, что позволяет делать запись параллельно, увиличая пропускную способность.
+
+Расптространненый подход шардирования таблицы пользователей основан на разделении по имени или местоположению.
##### Disadvantage(s): sharding
-TBD
+* Логика приложения должна быть адаптирована к работе с шардами, что может привести к более сложным SQL запросам.
+* Данные могут неравномерно распределяться среди шардов. Например, использование данных активных пользователей, находящихся на одном шарде, увеличивают нагрузку на него.
+ * Балансировка усложняет систему. Функция шардирования, основанная на [consistent hashing](http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html) может уменьшить общий объем передаваемых данных.
+* Соединение данных (JOIN) из нескольких шардов сложнее
+* Шардирование требует большего количества аппаратного обеспечения и увеличивает общую сложность системы.
##### 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)
#### 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 жестким диском.
##### Disadvantage(s): denormalization
-TBD
+* Данные дублируются.
+* Ограничения могу помочь поддерживать избыточные копии данных в актуальном состоянии, но увиличивают сложность архитектуры базы данных
+* Денормализованная база данных под большой нагрузкой может работать медленее, чем её нормализованный аналог.
###### 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)