Классика баз данных - статьи
Такая трехзвенная конфигурация проиллюстрирована на
Такая трехзвенная конфигурация проиллюстрирована на рис. 7.
Рис. 7. Трехзвенная архитектура обработки потоковых данных
К сожалению, такая архитектура, в которой требуемая функциональность распределяется по трем тяжеловесным компонентам системного программного обеспечения, не будет хорошо функционировать. Например, для каждого сообщения, для которого требуется поиск состояния и применение прикладных сервисов, понадобится несколько переключений контекстов процессов между разными службами.
Чтобы проиллюстрировать накладные расходы, требуемые для обработки одного сообщения, проследим шаги обработки сообщения. Приходящее сообщение сначала доставляется по шине, а затем перенаправляется в собственный код приложения (шаг 1), в котором это сообщение очищается, а потом обрабатывается. Если требуется сопоставить данное сообщение с историческими данными, для чего нужен доступ к персистентным данным, то посылается запрос серверу баз данных (шаги 2-3), и этот сервер обращается к базе данных. Ответные данные посылаются в код приложения по обратному маршруту (шаги 4-5). Наконец, результат обработки сообщения направляется в GUI задачи клиента. В общем и целом, для обработки одного сообщения потребовалось шесть раз «пересечь границу». Вдобавок к очевидному переключению контекстов требуется еще и «на лету» преобразовывать сообщения соответствующими адаптерами к собственным форматам используемых систем и обратно. Результатом является крайне низкое соотношение объема полезной работы и накладных расходов. Эти накладные расходы останутся высокими и ограничивающими достижение требуемой производительности, даже если использовать какое-либо пакетирование сообщений.
Чтобы избежать такой потери производительности, в системе обработки потоковых данных все эти три службы должны обеспечиваться в одном компоненте системного программного обеспечения, выполняемом как один многопотоковый процесс на каждой машине, где функционирует эта система. Следовательно, в SPE должны иметься элементы СУБД, сервера приложений и системы передачи сообщений.По сути, SPE должна обеспечивать специализированные возможности всех трех видов программного обеспечения «под одной крышей».
Это наблюдение приводит к вопросу о том, действительно ли является оптимальным используемое в настоящее время разбиение системного программного обеспечения на компоненты (например, серверы приложений, СУБД, системы Extract-Transform-Load, файловые системы, шины передачи сообщений, файловые системы, Web-серверы и т.д.)? В конце концов, эта декомпозиция возникла частично по историческим причинам, а частично по маркетинговой случайности. Кажутся вполне приемлемыми другие способы разбиения системных служб по продуктам, и не следует удивляться, если в будущем произойдут существенные изменения в определениях компонентов и их разбиении по продуктам.
