1632
правки
Изменения
м
Можно, например, с помощью меток времени или векторных часов.<br>
rollbackEdits.php mass rollback
** Программы могут работать на любом узле (данные действительно хранятся распределенно в отличие от репликации);<br>
** Удаленный доступ к данным (должны уметь сделать любой запрос на любом узле);<br>
Распределенная БД должна логически себя вести как одна большая БД, хотя временные задержки скрыть не удастся.<br>
=== Независимость от фрагментации ===
* Программы не знают на каком узле находятся данные.<br>
* Унифицированный доступ к данным, неважно, на локальном ли они узле или удаленном.<br>* Географическое секционирование, некоторые узлы могут быть географически удаленных и это надо учитывать.<br>
=== Независимость от репликации ===
* Автоматическая поддержка репликации.<br>
* Выбор узла для обновления.<br>
Могут как реплицироваться отдельные узлы, либо так и целиком вся БД.<br>
=== Распределенные транзакции ===
Участвует несколько узлов. Транзакция должна быть либо зафиксирована на всех узлах, либо на всех откачена. Бывают сбои как самих участников, так и каналов коммуникаций между ними.<br>
Можем удовлетворить только двум из следующих трем свойств одновременно:
* Consistency {{---}} информация на разных узлах согласована;<br>
* Availability {{---}} система отвечает на запросыв любой момент времени;<br>
* Partition tolerance {{---}} связи между узлами могут обрываться.<br>
* 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>
=== Управление каталогом ===
Для каталога (мета-описания наших данных) невозможна Soft-state синхронизация, потому что могут прийти данные, не описанные в каталоге, поэтому с ними действия должны быть синхронны.
==== Цели ====
* Независимость от расположения(независимо от узла запрос должен вернуть одни и те же данные);<br>
* Независимость от фрагментации;<br>
* Возможность переноса данных.<br>
* Локальное секционирование;<br>
* Секционирование и репликация.<br>
Вынуждены хранить реплики каталога во всех местах, но его объем небольшой, поэтому это не проблема. Для изменения делаем одну большую синхронную операцию.<br>
БД секционирована по конкретным узлам, на которых хранятся данные, и в каталоге явно указано где какие данные хранятся.<br>
Можем добавлять, удалять узлы
Обычно запрещается менять каталог БД, если не все узлы доступны, так как объединить изменение каталогов на практике обычно является нерешаемой задачей.<br>
=== Независимость от окружения ===
* Конвертация данных, запросов, каталога;<br>
* Поддержка распределенных транзакций, блокировок.<br>
Одна СУБД является координатором запроса, через шлюз достает данные другой СУБД.
При запросе шлюз притворяется, что является удаленной копией инициировавшей запрос БД, но получив запрос, транслирует его синтаксис или конвертирует один бинарный протокол в другой, после чего шлюз исполняет запрос на реальной БД другого типа,
конвертирует ответ в вид, понятный первой БД и отдает.<br>
На практике таких решений очень мало.
