101
правка
Изменения
Нет описания правки
** От сети, например, в дата центрах будет быстрая локальная связь;<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>
Последние два свойства нужны для того, чтоб при восстановлении связи система постепенно (не мгновенно) приходила в согласованное состояние.<br>
=== Разрешение несогласованности ===
Можно, например, с помощью меток времени или векторных часов.<br>
Если разрешать при чтении, то замедляется чтение.<br>
При записи - замедляется запись.<br>
Может быть отдельный асинхронный процесс, приводящий систему к согласованию, но это тоже ресурсы.<br>
=== Оптимизация вопросов ===
В распределенном случае еще сложнее, поскольку нужны новые механизмы агрегации, которые будет учитывать планировщик запросов.<br>
==== Цели ====
* Минимизация время выполнения;<br>
* Минимизация количества затронутых данных (в том числе удаленных), коммуникаций.<br>
==== Средства ====
* Выбор узлов получения и обработки данных;<br>
* Полусоединения;<br>
* Применение репликации.<br>
=== Управление параллельностью ===
==== Цели ====
* Распараллеливание запроса;<br>
* Изоляция транзакций;<br>
* Детектирование распределенных взаимных блокировок.<br>
==== Средства ====
* Распределенные транзакции;<br>
* Распределенные блокировки;<br>
* Стратегия основной копии.<br>
=== Управление каталогом ===
==== Цели ====
* Независимость от расположения;<br>
* Независимость от фрагментации;<br>
* Возможность переноса данных.<br>
==== Методы ====
* Централизованное хранилище;<br>
* Полная репликация;<br>
* Локальное секционирование;<br>
* Секционирование и репликация.<br>
=== Независимость от окружения ===
Используется механизм шлюзов {{---}} разные СУБД могут общаться друг с другом за данными несмотря на разные форматы хранения данных, запросов.<br>
==== Задачи шлюза ====
* Реализация протоколов с помощью семантического взаимодействия;<br>
* Конвертация данных, запросов, каталога;<br>
* Поддержка распределенных транзакций, блокировок.<br>
