From ccb8233dc6501e2813641c27aa18b520e03c1d09 Mon Sep 17 00:00:00 2001 From: voitau Date: Sun, 26 Apr 2020 14:59:17 -0700 Subject: [PATCH] Translate RU: database - start --- README-ru.md | 108 +++++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 91 insertions(+), 17 deletions(-) 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)