В связи с двумя предыдущими пунктами сразу приходит на ум мысль - как в условии функциональной декомпозиции и горизонтального разбиения будет обеспечиваться поодержка транзакций, ведь практически любая операция влечет за собой изменение более чем одной сущности. Стандартный ответ подразумевает создание распределенной транзакции, которая включает в себя все модифицируемые ресурсы и использование two-phase commit для того, чтобы быть уверенным в том, что транзакция прошла успешно, либо же была отменена для всех вовлеченных в нее сущностей. Однако, у всего есть своя цена, и подобный подход резко ухудшает масштабируемость, производительность и увеличивает время ожидания. Также ограничивается и доступность системы - ведь при создании распределенной транзакции все вовлеченные в нее ресурсы должны быть свободны. Это может привести к тому, что при увеличении нагрузки на систему и росте ресурсов, вовлеченных в распределенные транзакции, система перестанет справляться с обслуживанием клиентов.
Архитекторы, имеющие большой опыт в проектировании подобного рода распределенных систем, утверждают, что требование обеспечить мгновенную согласованность вносимых изменений среди распределенных частей системы достаточно редко требуется на практике, и к тому же редко бывает возможным.
Около 10 лет назад профессор Eric Brewer сформулировал CAP-теорему, согласно которой, среди трех требуемых характеристик распределенной системы: consistency(C), availability(A) и performance(P) одновременно можно выбрать только 2 варианта. Для 24x7 доступной веб-системы, работающей под большой пользовательской нагрузкой придетсся выбрать 2 последние, иначе система не сможет выполнять свое предназначение. Следовательно, consistency придется пожертвовать.
Однако если операция работы с данными производится в рамках одного сервера БД, то тогда вполне можно объединять несколько операций в рамках транзакции или разрешить auto-commit для определенных запросов. Конечно, подобное нарушение принципов ACID не гарантирует немедленную consistency среди всех распределенных частей системы, но взамен этого ситема будет доступна большинство рабочего времени.
Естесственно, подобное построение системы влечет за собой определенные нетривиальные технические решения, призванные обеспечить корректность работы в каждом конкретном случае и ни в коем случае не является тривиальным. Однако в распределенных системах это необходимо и consistency уже нельзя рассматривать с позиции "все-или-ничего".
Комментариев нет:
Отправить комментарий