Распределенные базы данных. Цели и проблемы

Набор требований к распределенным базам данных, которых хотят достигнуть

Требования по децентрализации

• Локальная независимость - узел должен функционировать даже в изоляции

(имеется в виду отвечать как на запросы на чтение, так и на изменение).

• Отсутствие центрального узла, так как при его наличии и отключении не выполнится локальная независимость.
  
• Непрерывное функционирование;
  
  • Надежность, то есть все наши изменения будут применены и никогда не потеряются;
    
  • Доступность, даже при отсутствии связности.
    

Вынуждены использовать стратегию равноправности узлов, но могут выбираться локальные временные координаторы, которые будут координировать запросы, затрагивающие несколько узлов.

Требования по прозрачности

• Независимость от расположения;
  
  • Программы могут работать на любом узле (данные действительно хранятся распределенно в отличие от репликации);
    
  • Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле);
    

Распределенная БД должна логически себя вести как одна большая БД.

Независимость от фрагментации

• Программы не знают на каком узле находятся данные.
  
• Унифицированный доступ к данным.
  
• Географическое секционирование.
  

Независимость от репликации

• Автоматическая поддержка репликации.
  
• Выбор узла для обновления.
  

Могут как реплицироваться отдельные узлы, так и целиком вся БД.

Распределенные транзакции

Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.

• Поддержка распределенных запросов.
  
  • Один запрос получает данные с разных узлов;
    
  • Несколько узлов могут участвовать в одной транзакции;
    
  • Должна быть согласованность фиксаций и отката.
    

Независимость от окружения

• От аппаратуры, то есть должны быть унифицированное представление данных;
  
• От ОС, то есть должна быть конвертация данных и поддержка разных ОС;
  
• От сети, например, в дата центрах будет быстрая локальная связь;
  
• От типа СУБД, хотелось бы уметь делать распределенную БД, которая обслуживается разными системами управления БД (Oracle, Postgres, etc). Но в реальности все очень печально.
  

Проблемы распределенных баз данных

CAP теорема

Можем удовлетворить только двум из следующих трем свойств одновременно:

• Consistency — информация на разных узлах согласована;
  
• Availability — система отвечает на запросы в любой момент времени;
  
• Partition tolerance — связи между узлами могут обрываться.
  

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

Чаще всего компромиссы рассматривают с точки зрения partition tolerance. В случае разрыва связи можем:

• Частично отказаться от доступности, поэтому функционировать

будет только одна часть системы (например, самая большая);

• Частично отказаться от согласованности, поэтому не все узлы будут в согласованном состоянии,

но при объединении системы будут протоколы, приводящие всю систему в согласование.

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

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

Принцип BASE

• Basically Available - сбой узла приводит к отказу только для части пользователей

(тех, которые присоединены были в данному узлу);

• Soft-state - изменение состояния без внешнего вмешательства, данные могут поменяться без изменений со стороны пользователя;
  
• Eventual consistency - временная несогласованность.
  

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

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

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

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

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

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

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

Оптимизация вопросов

В распределенном случае еще сложнее, поскольку нужны новые механизмы агрегации, которые будет учитывать планировщик запросов.

Цели

• Минимизация время выполнения;
  
• Минимизация количества затронутых данных (в том числе удаленных), коммуникаций.
  

Средства

• Выбор узлов получения и обработки данных;
  
• Полусоединения;
  
• Применение репликации.
  

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

Цели

• Распараллеливание запроса;
  
• Изоляция транзакций;
  
• Детектирование распределенных взаимных блокировок.
  

Средства

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

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

Цели

• Независимость от расположения;
  
• Независимость от фрагментации;
  
• Возможность переноса данных.
  

Методы

• Централизованное хранилище;
  
• Полная репликация;
  
• Локальное секционирование;
  
• Секционирование и репликация.
  

Независимость от окружения

Используется механизм шлюзов — разные СУБД могут общаться друг с другом за данными несмотря на разные форматы хранения данных, запросов.

Задачи шлюза

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