Просмотр исходного текста страницы Распределенные базы данных. Цели и проблемы

== Набор требований к распределенным базам данных, которых хотят достигнуть ==
=== Требования по децентрализации ===
*Локальная независимость - узел должен функционировать даже в изоляции
(имеется в виду отвечать как на запросы на чтение, так и на изменение).<br>
* Отсутствие центрального узла, так как при его наличии и отключении не выполнится локальная независимость.<br>
* Непрерывное функционирование;<br>
** Надежность, то есть все наши изменения будут применены и никогда не потеряются;<br>
** Доступность, даже при отсутствии связности.<br>
Вынуждены использовать стратегию равноправности узлов, но могут выбираться локальные временные координаторы, которые будут координировать запросы, затрагивающие несколько узлов.
=== Требования по прозрачности ===
* Независимость от расположения;<br>
** Программы могут работать на любом узле (данные действительно хранятся распределенно в отличие от репликации);<br>
** Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле);<br>
Распределенная БД должна логически себя вести как одна большая БД, хотя временные задержки скрыть не удастся.<br>
=== Независимость от фрагментации ===
* Программы не знают на каком узле находятся данные.<br>
* Унифицированный доступ к данным, неважно, на локальном ли они узле или удаленном.<br>
* Географическое секционирование, некоторые узлы могут быть географически удаленных и это надо учитывать.<br>
=== Независимость от репликации ===
* Автоматическая поддержка репликации.<br>
* Выбор узла для обновления.<br>
Могут как реплицироваться отдельные узлы, так и целиком вся БД.<br>
=== Распределенные транзакции ===
Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.<br>
* Поддержка распределенных запросов.<br>
** Один запрос получает данные с разных узлов;<br>
** Несколько узлов могут участвовать в одной транзакции;<br>
** Должна быть согласованность фиксаций и отката.<br>
=== Независимость от окружения ===
* От аппаратуры, то есть должны быть унифицированное представление данных;<br>
* От ОС, то есть должна быть конвертация данных и поддержка разных ОС;<br>
* От сети, например, в дата центрах будет быстрая локальная связь;<br>
* От типа СУБД, хотелось бы уметь делать распределенную БД, которая обслуживается разными системами управления БД (Oracle, Postgres, etc). Но в реальности все очень печально.<br>

== Проблемы распределенных баз данных ==
=== CAP теорема ===
Можем удовлетворить только двум из следующих трем свойств одновременно:
* Consistency {{---}} информация на разных узлах согласована;<br>
* Availability {{---}} система отвечает на запросы в любой момент времени;<br>
* Partition tolerance {{---}} связи между узлами могут обрываться.<br>

Но свойства не бинарные, а доказательство верно только для бинарных свойств.<br>
То есть зачастую согласованность нужна не во всех случаях, не в всегда нельзя пережить без ответа системы и так далее, а значит, что не попадаем под условие CAP-теоремы.<br>

Чаще всего компромиссы рассматривают с точки зрения partition tolerance. В случае разрыва связи можем:<br>
* Частично отказаться от доступности, поэтому функционировать 
будет только одна часть системы (например, самая большая);<br>
* Частично отказаться от согласованности, поэтому не все узлы будут в согласованном состоянии, 
но при объединении системы будут протоколы, приводящие всю систему в согласование.<br>

Без обрыва связи система не разделена и будет полностью выполняться как доступность, так и согласованность.<br>

Есть подход BASE, ослабляющий CAP<br>

==== Принцип BASE ====
* Basically Available - сбой узла приводит к отказу только для части пользователей 
(тех, которые присоединены были в данному узлу);<br>
* Soft-state - изменение состояния без внешнего вмешательства, данные могут поменяться без изменений со стороны пользователя;<br>
* Eventual consistency - временная несогласованность.<br>

Soft-state происходит только в ситуации, когда клиенты отдельно изменяли данные при обрыве соединений, и при восстановлении связи у каждого из клиентов будут изменения произошедшие без его вмешательства.<br>
Eventual consistency нужен для того, чтобы была гарантия, что мы узнаем обо всех изменениях после применения протокола объединения при восстановлении оборванной связи.<br>
Последние два свойства нужны для того, чтоб при восстановлении связи система постепенно (не мгновенно) приходила в согласованное состояние.<br>

Этот подход возможно реализовать в реальном мире.<br>

=== Разрешение несогласованности ===

Если разрешать при чтении, то замедляется чтение.<br>
Можем узнавать, не появилось ли на каком-то удаленном узле изменение наших данных, о котором он еще не успел сообщить, что небыстро.<br> 

При записи - замедляется запись.<br>
Можем запрещать изменять удаленные данные в случае разрыва соединения, но локальные изменять свободно.<br>

Может быть отдельный асинхронный процесс, приводящий систему к согласованию, но это тоже ресурсы.<br>
Будет честно запрашивать изменения, объединять их и доносить новое состояние до всех узлов БД.<br>

Итого, у нас будет несколько изменений, которые нужно как-то объединить.<br>
Можно, например, с помощью меток времени или векторных часов.<br>

=== Оптимизация вопросов ===
В распределенном случае еще сложнее, поскольку нужны новые механизмы агрегации, которые будет учитывать планировщик запросов.<br>
К тому же мы не можем предсказать какой объем данных придет от удаленного узла, а предзапрос для выяснения этого требует дополнительных ресурсов.<br>

==== Цели ====

Хотим того же, что и при наличии всего одного узла:<br>
* Минимизация время выполнения;<br>
* Минимизация количества затронутых данных (в том числе удаленных), чтобы не загружать лишний раз каналы.<br>
* Минимизация количества коммуникаций, так как сходить лишний раз на удаленный узел - потеря производительности.<br>

==== Средства ====
* Выбор узлов получения и обработки данных;<br>
Обычно либо данные напрямую пересылаются к клиенту, либо выбирается один из узлов на которых данные исходно хранятся, но могут быть и более сложные схемы, на которых в теории некий промежуточный узел может агрегировать все данные и уже он их отошлет клиенту.<br>
* Полусоединения (половины будущего объединения) - один узел может от другого узла спросить id только те, которые ему нужны для построения соединения и делается это за одну коммуникацию;<br>
* Применение репликации, тогда зачастую клиентскому узлу нужно будет запросить у исходных узлов, нет ли у них изменений в запрашиваемых данных.<br>

=== Управление параллельностью ===

Большое количество узлов может дать как ускорение получение данных, но так и дает большие сложности по синхронизации, все проблемы распределенных систем находят свое место и в распределенных БД.

==== Цели ====
* Распараллеливание запроса (достижим гораздо более высокий параллелизм благодаря наличию кучи различных узлов из которых параллельно достаем данные, что быстро);<br>
* Изоляция транзакций или удаленные распределенные блокировки, что очень непросто;<br>
* Детектирование распределенных взаимных блокировок тоже усложняет задачу.<br>

==== Средства ====
* Распределенные транзакции;<br>
* Распределенные блокировки;<br>
* Стратегия основной копии.<br>

При связной системе можно обойти сложности засчет основной копии, но нужно все равно решать вышеуказанные сложности, так как есть потенциальный отказ коммуникации в системе.<br>

=== Управление каталогом ===

Для каталога (мета-описания наших данных) невозможна Soft-state синхронизация, потому что могут прийти данные, не описанные в каталоге, поэтому с ними действия должны быть синхронны.

==== Цели ====
* Независимость от расположения (независимо от узла запрос должен вернуть одни и те же данные);<br>
* Независимость от фрагментации;<br>
* Возможность переноса данных.<br>

==== Методы ====
* Централизованное хранилище;<br>
* Полная репликация;<br>
* Локальное секционирование;<br>
* Секционирование и репликация.<br>

Вынуждены хранить реплики каталога во всех местах, но его объем небольшой, поэтому это не проблема. Для изменения делаем одну большую синхронную операцию.<br>
БД секционирована по конкретным узлам, на которых хранятся данные, и в каталоге явно указано где какие данные хранятся.<br>
Можем добавлять, удалять узлы 
Обычно запрещается менять каталог БД, если не все узлы доступны, так как объединить изменение каталогов на практике обычно является нерешаемой задачей.<br>

=== Независимость от окружения ===
Используется механизм шлюзов {{---}} разные СУБД могут общаться друг с другом за данными несмотря на разные форматы хранения данных, запросов.<br>
[[Файл:Пример шлюза.png|right|300px]]

==== Задачи шлюза ====

* Реализация протоколов с помощью семантического взаимодействия;<br>
* Конвертация данных, запросов, каталога;<br>
* Поддержка распределенных транзакций, блокировок.<br>

Одна СУБД является координатором запроса, через шлюз достает данные другой СУБД.
При запросе шлюз притворяется, что является удаленной копией инициировавшей запрос БД, но получив запрос, транслирует его синтаксис или конвертирует один бинарный протокол в другой, после чего шлюз исполняет запрос на реальной БД другого типа, 
конвертирует ответ в вид, понятный первой БД и отдает.<br>

На практике таких решений очень мало.