1632
правки
Изменения
м
rollbackEdits.php mass rollback
** Программы могут работать на любом узле (данные действительно хранятся распределенно в отличие от репликации);<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>
На практике таких решений очень мало.
