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

Пятизвенная архитектура

В такой архитектуре каждый уровень представляет собой отдельный сервис (рис. 1, б). Самый известный пример — это стек Google, состоящий из GFS (файловый уровень), BigTable (уровень менеджера записей) и Megastore (уровень баз данных). Наверху же находятся уровни приложений и презентационный. Такая сепарация обеспечивает высокую модульность, позволяющую разработчикам легко использовать отдельные элементы стека. Например, при аналитической обработке данных с помощью MapReduce можно пользоваться только файловым уровнем. BigTable, работая поверх файловой системы, предоставляет функциональность простого менеджера записей: доступ к ключам-значениям («строкам» в терминологии Google) с атомарными однострочными операциями, применяемыми для работы с веб-индексом Google. Уровень Megastore добавляет к этому поддержку транзакций и самоподдерживаемые индексы. Хотя у такого расслоения есть много преимуществ, оно создает дополнительный сетевой трафик между уровнями: например, операция соединения требует, чтобы данные доставлялись с файлового уровня через диспетчер записей на уровень базы данных. Возможно также снижение эффективности из-за дублирования функциональности на разных уровнях. В случае Google разные уровни выполняют протоколирование для нужд консистентности и отказоустойчивости, создавая дублирующиеся журналы.
Четырехзвенная разделенная архитектура с файловым уровнем

Один из способов уменьшить трафик между уровнями — объединить базу данных и диспетчер записей в один уровень (рис. 1, в). Внизу, в роли надежной сетевой системы хранения данных (Networked Attached Storage, NAS) действует файловый сервис. Подобно классической трехзвенной архитектуре, такое сочетание позволяет разработчикам пользоваться стандартными СУБД, такими как MySQL, однако за достижение высокой отказоустойчивости в этом случае отвечает файловый уровень, а не база данных. Примеры — Amazon Relational Database Service, Amazon Elastic Compute Cloud (EC2) в сочетании с Amazon Elastic Block Service (EBS), используемым как NAS. Последний позволяет разработчикам установить СУБД по выбору — можно достигнуть высокой устойчивости, просто сохраняя все журналы операций базы на томе EBS, который можно будет смонтировать на другом экземпляре EC2, если первоначальный даст сбой. К сожалению, такая архитектура наследует ограничения по масштабируемости от классической трехзвенной, так как обычно использует традиционную монолитную СУБД. Кроме того, трудно согласовать различные протоколы консистентности, применяемые внутри файлового уровня и объединенного уровня базы данных и диспетчера записи. В связи с этим, например, если Amazon RDS даст сбой, приложение может потерять изменения, внесенные за последние пять минут.