Распределенные базы данных. Цели и проблемы — различия между версиями

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

Версия 02:24, 20 декабря 2021

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CAP теорема

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

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

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

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

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

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

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

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

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

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

Принцип BASE

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

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

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

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

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

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

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

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

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

Цели

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

Средства

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

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

Цели

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

Средства

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

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

Цели

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

Методы

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

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

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

Пример шлюза.png

Задачи шлюза

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