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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CAP теорема

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

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

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

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

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

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

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

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

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

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

Принцип BASE

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

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

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

Последние два свойства нужны для того, чтоб при восстановлении связи система постепенно (не мгновенно) приходила в согласованное состояние.

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

Можно, например, с помощью меток времени или векторных часов.

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

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

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

Цели

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

Средства

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

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

Цели

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

Средства

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

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

Цели

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

Методы

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

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

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

Задачи шлюза

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