Моделирование задержки сети и параллельной обработки информации в распределенных баз данных, Дизайн

РЕЗЮМЕ

Дизайн реагировать распределенных систем баз данных является одной из основных проблем для информационных систем менеджеров. В высокой латентностью пропускной способности сети и местные обработки самых значительных факторов, запросы и обновления времени отклика. Параллельная обработка может быть использована для сведения к минимуму их последствия, особенно если учесть на этапе проектирования. Это разумное репликации и размещения данных в сети, что позволит параллелизма быть эффективно использованы. Тем не менее, задержки и параллельной обработки в значительной степени игнорировались в предыдущих подходов распределенных баз данных. Мы представляем комплексный подход к распределенной базе данных, дизайн, разрабатывает эффективные комбинации данных, распределения и обработки запросов стратегий, которые в полной мере использовать параллелизм. Мы используем генетический алгоритм для того, чтобы одновременной оптимизации распределения данных и обработки запросов стратегий. Покажем, что игнорирование последствий задержки и параллелизм на этапе проектирования может привести к выбору реагирующий распределенных дизайна баз данных.

Предметные области: Компьютер-коммуникационных сетей, распределенных баз данных, генетические алгоритмы, задержки сети, параллельной обработки, Оптимизация запросов и времени отклика моделирование.

ВВЕДЕНИЕ

Распределенная база данных (DDB) системы стали обыденным явлением, как организации участвовать в электронной коммерции, поставщик партнерства, виртуальных организаций, а также слияний и поглощений. Все они требуют интеграции географически распределенных операций и управления ими. Проектирование распределенных баз данных, которые эффективно поддерживать высокие объемы приложений обработки транзакций является критическим фактором успеха для этих организаций (март, Хевнер,

Проектирование распределенных баз данных, которая эффективно использовать параллелизм, чтобы свести к минимуму время реакции сложной и трудной задачей, особенно в высокоскоростных сетях, где коммуникация задержки, вызванные задержкой в очередь может быть существенным компонентов времени отклика, даже доминирующих передачи данных и их переработке время. Данные разделы или фрагменты должны быть определены и выделены узлов в сети, возможно, с избыточностью, с учетом ожидаемых моделей использования. Тем не менее, ожидаемые от интенсивности использования, определяются стратегии обработки запросов, которые разработаны, чтобы воспользоваться распределения и репликации данных дизайна. Таким образом, сочетание дизайна распределения данных и распределенного запроса оптимизации конструкции, в том числе параллелизма, должны быть произведены одновременно.

В этой статье мы представляем всеобъемлющий подход распределенных баз данных, что решает эту задачу. Она расширяет подход, разработанный в марте и Rho (1995) и Rho и марте (1995, 2000), на основе затрат подход, ориентированный на относительно малой емкости сети, что не считает, задержки или параллелизма. Вклад этого исследования являются: демонстрируя значение задержки и параллелизма в моделировании времени отклика для мощных сетей, разработка комплексной модели своевременно реагировать на замену ненадлежащего стоимости основе модели, используемой в предыдущих исследований, обеспечивая комплексный инструмент для эффективного производства Время ответа распределенных баз данных, образцов и анализ последствий игнорирования задержки и параллелизм на распространение данных и обработки запросов конструкций выбраны таким инструментом.

Учитывая описание сетевой среды, логические базы данных (т. е. отношения), и характеристика соответствующего обновления и поиска запросов наш подход выделяет фрагменты данных в узлы и конструкции обработки стратегии для каждого запроса, так что среднее время отклика системы сводится к минимуму . Фрагмент может быть выделено более 1 узла, в результате чего репликация дизайна. Такая репликация снижает время поиска ответа, избавляя от необходимости получать доступ к удаленным данным, однако, это увеличивает время отклика обновление после обновления должен быть применен к каждой реплики. Запрос стратегии обработки (или выполнение плана) определяет, какие фрагменты (реплики) используются, где присоединиться к операции выполняются, порядок, в котором присоединиться к операции выполняются, и какой метод используется для каждого соединения. Эффективность распределения данных зависит от данных, использование шаблонов и параметров нагрузки в системе, которая, в свою очередь, зависят от планов выполнения запросов. Тем не менее, эффективность плана выполнения запроса зависит от распределения данных и нагрузки в системе, порожденная всеми другими планов выполнения запроса. Различные распределения данных проектов и альтернативных планов выполнения запроса дают различные возможности для выполнения операций параллельно.

Такая взаимозависимость делает эту проблему неразрешимой для аналитических методов решения. Мы используем вложенные генетического алгоритма аналогична разработаны и проанализированы в марте и Rho (1995) и Rho и марте (1997, 2000). Генетический алгоритм генерирует начальный пул полную базу данных проектов в том числе данные распределения и обработки запросов стратегий. Таким образом, вышеупомянутые взаимозависимости может быть должным образом учтены и возможности для параллелизма определены. Наше время отклика модели оценки минимального времени реакции на каждый запрос в каждой конструкции. Генетический алгоритм, то объединяет ранее сгенерированный конструкции для создания новых проектов, которые аналогичным образом оценены. Новые конструкции, обладающего более среднее время отклика, чем существующие конструкции добавлены в пул и конструкций с худшее среднее время отклика удаляются. Генетический алгоритм может быть остановлен в любое время, уступая пул "хороший" дизайн. Больше бассейн имеет право развиваться, тем более вероятно, генетический алгоритм, чтобы найти очень эффективные конструкции. Дополнительные преимущества генетических алгоритмов подхода включают возможность добавить время реакции или загрузить ограничения на конкретные вопросы или узлами сети. Такие ограничения являются чрезвычайно трудно определить в аналитических подходов.

Мы применили этот подход к набору задач, основанных на обработке транзакций Совет TPC-C тест (обработка транзакций Совета, 2002), стандартной базы данных и запросов проблемы дизайна. На основании этих опытов можно заключить, что рассмотрение задержки и параллелизм на этапе проектирования может дать значительно отличается распределение данных конструкций и обработки запросов стратегии, чем подходы, которые их игнорируют. Последствия задержки увеличиваются в очень высокой скоростью сетей и модерируются эффективного использования параллелизма. Рассмотрение задержки без параллелизма имеет тенденцию к уменьшению объема данных, репликации при рассмотрении параллелизм без задержки приводит к увеличению его. Это связано с тем, что эффективное использование параллелизма может значительно уменьшить время отклика обновления, основным сдерживающим фактором для репликации. Кроме того, эффективное использование параллелизма может уменьшить необходимость для выполнения сложных запросов данных планов, предусматривающих сокращение таких стратегий, как полу-соединений, часто используемых в запросе алгоритмов оптимизации.

В оставшейся части этого статья организована следующим образом. В следующем разделе мы кратко опишем компоненты запроса время отклика в распределенных системах. После этого мы развиваем наши Время отклика модели, описывающей как возможности для параллелизма, были выявлены и оценены. Затем с помощью этой модели время отклика в наш генетический алгоритм и представить наши экспериментальные результаты. В последнем разделе кратко наши выводы и предложения направления для дальнейших исследований.

ОСНОВЫ ВРЕМЯ РЕАГИРОВАНИЯ

До распределенных баз данных подходов в первую очередь на основе затрат (см., например, Бланкиншип и др.., 1997; Корнелл

Новая модель время отклика должны быть разработаны, что включает в себя взаимозависимыми эффекты связи задержек и параллелизма на время отклика. В настоящем документе представлены такие модели. Как будет показано ниже, и показал в наших экспериментальных анализа, неспособность всесторонне рассматривать как сообщение задержек и параллелизма может привести к распределенной базе данных конструкций с плохой работы время отклика.

Время отклика в распределенной базы данных состоит из двух компонентов, местного времени обработки и ответа сети (коммуникации) времени. Местное время обработки количество времени, необходимое для поиска и анализа данных, необходимых для запроса на узел, из которого он был вызван. Она включает в себя очереди задержек из-за процессоров и дисковых операций ввода / вывода грузов, конкуренции за доступ к сети средних и фактического извлечения данных и времени обработки.

Время отклика сети состоит из трех компонентов: передавать время в очереди и промежуточных задержек при обработке и задержки. Передача время находится в обратной зависимости пропускной способности сети и пропускной способности. На его долю приходится времени уйдет на данные "по проводам". Очереди и задержки промежуточной обработки берет на себя какой-либо обработки, что происходит в сети между передающим и принимающим узлами. Эти задержки зависят от характера сети, протоколов к ней, и нагрузок. Однако, они не зависящим от какого-либо одного сетевого приложения и моделируются только как сеть постоянная. Задержка это время она принимает сигнал распространяется от отправляющего узла к узлу получать, как только оно было передано и без учета какой-либо обработки. Это в зависимости от расстояния между отправителем и получателем и скорость сигнала.

Влияние задержки зависит от пропускной способности сети, размер сообщения, и расстояния. Как показано в таблице 1 латентность наиболее значимых для широкополосных сетей, малых сообщений, а также на большие расстояния. Рассмотреть вопрос о направлении 140-байт сообщения (представитель запросом или обновить сообщение) на расстоянии 600 миль (представитель внешние сети). На 56 Кбит / с (низкой пропускной способностью сети) направляет время составляет 20 миллисекунд, то есть, она занимает 20 миллисекунд, чтобы поместить сообщение в сеть (140 байт * 8 bits/byte/56 Кбит / с). Предполагая, сигнал скорости 2 * 10 ^ 8 м / сек (около 120 тысяч километров в секунду) (Сталлингс

Если это расстояние сократилось до 0,2 миль (представитель внутренней организационной сети), то задержки сводится к 0,0017 мс и составляет лишь 0,01% от времени отклика в сети 56 кбит / с, 0,23% в сети T1 и 6,24 % в T3 сети. Если размер сообщения увеличивается до 14000 байт (представитель ответов на запросы) последствия задержки пренебрежимо малы в локальной сети или в сети 56 Кбит / с, даже за 600 миль. Хотя сокращения, эффект задержки по-прежнему важное значение в T1 и T3 глобальных сетей (6,45% и 66,63% от времени отклика, соответственно). Игнорирование латентность, как и в предыдущие дизайн DDB подходов, подходит, когда большие сообщения отправляются на небольших, низкой пропускной способности сети. Это недопустимо, когда небольшие сообщения дуги направлены на больших, высокоскоростной сети. Последние характерны для современного большого объема системы обработки транзакций, таких как те, которые используются в банках, пакет услуг доставки электронных цепей поставок, распределенных производственных и обслуживающих организаций, а также успешные розничные Интернет и поставщиков финансовых услуг.

Координации требует обновления операций в распределенной базе данных с помощью репликации производит много небольших сообщений. Тем не менее, параллелизм может быть использован для смягчения последствий задержки. Рассмотрим, например, запрос на обновление, где цель данных реплицируются. Запрос узел происхождения должны отправить обновление сообщений и блокировка запросов и подтверждений к каждому узлу, на котором копии хранятся данные. Количество и типы сообщений зависит от механизма управления параллелизмом используется (Рам

Поиска запрос время отклика также зависит от задержки и параллелизма. Если данные разумно воспроизведены и распространены, может быть можно разложить поиска запросов в подзапросы, некоторые из которых могут быть запущены на разных узлах, параллельно, в результате чего общее сокращение времени реагирования. Рассмотрим распределенных баз данных с узлами в Нью-Йорке, Бостоне и Далласе, где для клиентов и транзакций данных для Восточного побережья клиентов реплицируются в Нью-Йорке и Бостоне. Рассмотрим, то запрос выдается в Далласе в Восточном побережье клиенты определенного типа и их операции в течение указанного периода времени, таких как:

Этот запрос может быть обработан в нескольких вариантах. Один из них, чтобы отправить сообщение в Нью-Йорк просить запроса осуществляется там, и результат возвращается в Даллас. Второе это отправить сообщение в Бостон просить запроса осуществляется там и результат послал в Даллас. Наконец, третий способ отправить одно сообщение в Нью-Йорк просить выбранных клиентов и одна в Бостон просить выбранной операции и выполнять вступить на промежуточных итоговых таблиц в Далласе. Это третья стратегия позволяет отбор работ на клиентов и сделки таблиц, которые будут одновременно, параллельно, и задержки для каждого сообщения перекрываются во времени. Хотя эта стратегия может привести к увеличению данных, передаваемых в Даллас (более "стоимость"), общее время отклика может быть значительно уменьшена, в зависимости от сети и узла мощностей и нагрузок.

Запросы с участием более чем двух таблиц позволить себе дополнительные возможности для сокращения времени отклика путем параллелизма и использование данных стратегий сокращения, такие как полу-соединения. Следовательно, как мы покажем ниже, важно точно моделировать последствия задержки и параллелизма для поиска и обновления запросов для того, чтобы производство реагировать распределенных дизайна баз данных.

Распределенная модель проектирования баз данных

С учетом логической базы данных (таблицы), набор запросов представляющих обновления и поиска требованиям множества пользователей базы данных, и сетевое окружение, в котором система должна быть реализована, цель подход к проектированию DDB заключается в следующем: (1 ) выделять фрагменты данных в узлах сети и (2) разработка стратегии обработки запросов для каждого запроса, которые наиболее эффективно удовлетворить определенные потребности. Первый гол, называют данные распределения, был решен целый ряд исследователей в различных сетевых настроек (см., например, Apers, 1988; Корнелл

Это исследование расширяет основной подход Rho и марте (1995, 2000), чтобы включить эффекты латентности сети и параллелизма. Покажем, что они имеют значительное влияние на выбор эффективного проектирования DDB ..

Каждый запрос имеет узел возникновения и, может быть различным, назначение узел, на котором результаты запроса не требуется. Данные могут быть доступны из и обрабатываются на различных узлах в сети в порядке, установленном в системе управления базами данных. Если запрос поиска можно разложить на независимые подзапросы, то разумное репликации и размещения данных может позволить запроса стратегии обработки, которые используют преимущества параллелизма (Wong

Представляющих потенциальный интерес для параллелизма в разработке DDB является оптимизация запросов в контексте многопроцессорных вычислительных архитектур (Srivastava

Оптимизация запросов поиска

Запрос деревья

Запрос деревьев себе абстрактное представление запросов, представляя каждая составляющая работы в качестве узлов в дереве. Чтобы облегчить путаницы с узлов в компьютерной сети, мы будем ссылаться на запрос узлов дерева, как операции и использовать термин узел только в контексте компьютерной сети. Например, рассмотрим следующий простой запрос присоединиться, обозначим запросов 1.

Запрос 1 является одним из запросов в транзакции TPC-C NEW порядка (обработка транзакций Совета, 2002). Он присоединяется к КЛИЕНТОВ и СКЛАД таблицы производства скидки клиента, фамилия, кредитного лимита, а ставка налога в течение определенного клиента, склад, и района. Она состоит из трех операций, 2 и 1 сканирует присоединиться. Сканирование 1 выбирает соответствующие клиентов и сканирование 2 выбирает соответствующие склады. Присоединиться к 1 сочетает в себе выбранных клиентов и на складах. График этих операций мы получим дерево запроса на рисунке 1.

Приоритет для дерева запроса указывается, что сканирование и сканирование 1 2 обе стороны должны быть завершены до 1 Присоединиться может начать выполнение. Если сканирование и сканирование 1 2 выполняются на одном узле, они должны быть выполнены последовательно. Однако, если они проводятся в различных узлов, они могут выполняться параллельно, может быть, уменьшая общее время отклика на запрос.

Таблица 2 показывает, операции, необходимые для обработки этой простой присоединиться запроса. Задержки, понесенные по каждой операции зависит от того, где находятся данные и где обработка не производится. Сеть время наступает, если исходный и целевой узлы различны. Например, если 1 Сканирование выполняется на запрос узел, то это не нужно отправить сообщение с просьбой, которая сканирует операции, то есть время для компонентов, 5, 6, 7 и 8 будет 0. Простейший сценарий, где все операции выполняются при запросе узел, в этом случае нет Есть задержки в сети, но сканирует бы все должны быть обработаны последовательно (и все данные должны быть выделены там).

Параллельная обработка запросов в поисковых

Для оценки минимального времени реакции на запрос, возможности параллелизма между все необходимые операции должны быть определены. Если все они выполняются последовательно, общее время реагирования просто сумма отдельных операций. Однако, если сделка способна контролировать распараллеливания операций, и, если операции выполняются на разных узлах, то это может быть возможным, чтобы выполнить несколько операций, в то же время (Хасан, Флореску,

Хонг и Стонбракер (1994) предположил, что оптимальный план параллельного выполнения является распараллеливание оптимального последовательного плана выполнения. Хотя использованы в последующей работе, это положение было опровергнуто в случае общего ничего систем (Ziane и др.., 1995), тип параллельной системы баз данных, похожую на распределенных баз данных. Кроме того, последовательные задачи оптимизации запросов сама NP-полной, что делает этот подход неуместным для проектирования DDB.

Для решения этой проблемы наш генетический алгоритм создает и развивает полную базу данных проектов в том числе данных ассигнований и исполнения планов для каждого запроса к эффективному решению. Для каждого запроса он определяет сканирование и присоединиться к узлам, типы соединений (нормальный или присоединиться к полу-), а также порядок соединения, устраняя тем самым необходимость последовательного оптимизации запросов. Он также дает возможность оценить планы параллельного доходы без учета того, они последовательно оптимального, тем самым позволяя выявления передового параллельных планов, которые не обязательно хорошие последовательных планов. Таким образом у нас остается задача распараллеливания данной планы, выявление операций, которые могут выполняться параллельно, и определения оптимального порядка, в котором до начала их исполнения.

В 1 Запрос все сканирует и ряд связи операций может быть параллельной, в зависимости от плана выполнения запроса. Например, предположим, что порядок проверки были указаны генетический алгоритм для сканирования 1 последующим сканированием 2, и каждый будет выполнена проверка на другой узел, S1 и S2, соответственно. Предположим далее, что запрос узел, дп, отличается от любой проверки узлов и с присоединиться к узлу, J1. Диаграммы Ганта на рисунке 2 показан план выполнения запроса, показывая параллельных операций. Для примера, предполагается, что каждая проверка продолжается 6 единиц IO времени и 4 единицы времени процессора, что присоединиться к занимает 4 единиц IO времени и 6 единиц процессорного времени, и другие операции по 1 единицу времени, которое каждый . Фактические значения для конкретной задачи проектирования рассчитываются от параметров сети и нагрузки, порожденная всеми другими вопросами для проектирования на стадии рассмотрения.

Как показано на рисунке 2, то запрос узел, дп, посылает сообщение на первой проверки узла, S1, которые несет процессор и время передачи (к югу SendCPU ^ ^ п, ^ и s1z TX ^ югу дп, S1 ^). Параллельно с задержкой и получения этого сообщения (задержка ^ югу дп, S1 и ^ ^ ReceiveCPU югу дп, S1 ^), а также последующего сканирования переработки на S1 (Сканио югу ^ ^ S1 и ScanCPU ^ ^ к югу S1), то запрос узел может отправить сообщение на второй узел сканирования, S2 (к югу SendCPU ^ ^ п, ^ и S2 TX ^ югу дп, S2 ^), а также присоединиться к узлу (к югу SendCPU ^ дп, J1 ^ ^ TX и к югу дп, J1 ^ ). В то же время, S1 и S2 может обрабатывать свои задачи и отправить результаты присоединиться узла. Тем не менее, сообщения обрабатываются последовательно в узле соединения. Присоединиться и передачи результата запроса узел также последовательно.

Время отклика этот запрос, с заданными параметрами и распространения данных, оценивается в 34 единиц времени, когда параллелизм в полной мере. Оценка последовательной обработки 54 единиц времени (сумма всех операций раз показано на рисунке 2). Если все необходимые данные хранятся на одном узле (удаленный из запроса узел) потребуется 38 единиц времени только одно сообщение запрос (4 единицы времени), и одно сообщение ответа (4 единицы времени) необходимы в дополнение к обработки липы (30 единиц времени). Таким образом, учитывая только этот запрос, распределенного подхода проектирования баз данных, что не считает параллелизма будут выбирать централизованной разработки, в то время как один, который рассматривает параллелизм бы выбрать распределенного проектирования. Этот простой пример показывает важность учета параллелизм на этапе проектирования.

В этой простой запрос один из трех компонентов определяет время, в которое присоединиться обработки может начаться в выбранных присоединиться узла. Они предназначены Scan1Time, Scan2Time и JoinRequestTime (табл. 3). Прежде чем присоединиться к обработке может происходить, как сканирование должен быть заполнен и присоединиться к просьбе должны быть получены присоединиться узел (максимум Scan1Time, Scan2Time и JoinRequestTime). Scan1Time входит время, необходимое на дп, чтобы отправить запрос и время, необходимое на S1 для выполнения первого сканирования. Scan2Time аналогичен, но включает в себя SendCPU и передачи шагов сканирования 1. Это отражает тот факт, что сканирование начинается 1 до 2 сканирования. Таким образом, дп не может отправить сообщение на S2, пока он направил запрос S1. Кроме того, включает в себя JoinRequestTime SendCPU и TX шаги как сканирование, так дп отправляет сообщения и проверки узлов перед отправкой в один узел соединения.

Список событий обработка

Событие списки используются в дискретных событий моделирования временно организовать мероприятия (закон

Мы построим список событий непосредственно из плана выполнения запроса производства генетического алгоритма (фрагмент отбора, присоединиться к порядку, присоединиться к узлу, а также данные о стратегии сокращения). Таким образом, единственный оставшийся решение для сканирования операций. Если два сканирует свой вклад в присоединиться, и они выполняются на одном узле, то порядок, в котором они выполняются несущественно-и должна быть завершена до присоединиться может начаться. Однако, если сканирование осуществляется на разных узлах, которая принимает один длинный для завершения должна быть запущена первой. Это дает больше сканирования больше времени для завершения, а просьбы о втором сканирования послал. Если два сканирует внести свой вклад в различные объединения, порядок соединения будет определять порядок проверки. Например, предположим, сканирования и сканирования 1 4 выполняются на одном узле. Сканирование 1 вносит вклад Присоединиться к 1; 4 сканирования обеспечивает ввод Присоединиться 3. Присоединиться к 1 выполняется перед Присоединиться к 3. В этом случае сканирование 1 будет иметь приоритет над Сканирование 4. Полный алгоритм разрешения конфликтов, представленным ниже.

Экспериментальная оценка воздействия параллелизма и латентность

В этом разделе мы приводим результаты серии экспериментов с целью продемонстрировать использование наших распределенного подхода проектирования баз данных. Мы первые настоящее время база данных, используемая в наших экспериментах, а затем обсудим опытно-конструкторских и результаты.

База данных и транзакций окружающей среды

Экспериментальных окружающей среды на основе обработки транзакций TPC Benchmark Council-C. Результатах теста TPC Benchmark (TM) С "OLTP (Online Transaction Processing) нагрузки. Она представляет собой смесь только для чтения и обновления интенсивные операции, которые имитируют деятельность нашли в сложных прикладных средах OLTP. Он делает это, проявляя широту системы компонентов, связанных с такой среде "(обработка транзакций Совета, 2002, p. 5). Он предназначен для оценки большого обработки транзакций системы, работающие предприятия аппаратных класса и систем управления базами данных.

TPC-C тест определяет 8-таблицы базы данных (табл. 4), в центре которой находится стол СКЛАД. Все другие таблицы, за исключением элемент таблицы, имеют размеры по отношению к нему. В Таблице 4, например, каждый склад имеет 10 районов, каждый из которых поддерживает 3000 клиентов. Каждый клиент имеет один выдающийся порядка, в среднем порядка 10 линий. Кроме того, система отслеживает новые заказы, по заказу клиента и истории платежей, а также биржевые-уровней, на каждом складе. Есть 100000 пунктов, каждый из которых наполняется на каждом складе. Логической модели данных (в том числе частичное атрибутов внешних ключей) приведен на рисунке 3.

TPC-C тест определяет пять операций, каждая из которых содержит от 2 до 11 запросов. К ним относятся: NEW-порядка (4 поиска и 5 запросов обновление), ОПЛАТЫ (6 поиска и 5 запросов обновление), ORDER-STATUS (7 запросов поиска), доставка (3 поиска и обновления 4 запросов) и STOCK УРОВНЯ (2 поиск запросов). Мы используем подмножество этих в наших экспериментах, а именно: NEW-заказа, оплаты и STOCK уровне.

Хотя эти операции являются относительно сложными, индивидуальные запросы в них простые, имея только два многотабличной запросов, каждый из которых только одна присоединиться. Таким образом, мы ввели запрос Информация для заказа (Query 2), что требует от данных таблицы 5: склад, район, покупатель и порядка, определенного порядка (обозначается как: O_ID). Такой сложный запрос характерно оперативной аналитической обработки данных (OLAP) система работает против транзакционные базы данных.

Мы используем конфигурацию сети с 5 узлов, 4 назначенных в качестве склада и 1 в штаб-квартире. Минимальная фрагментов определялись на основе критериев отбора каждого запроса в соответствии с предложением Apers (1988) и др. Navathe. (1984). Например, клиенты обслуживаются склад 1 сгруппированы в W1_CUSTOMER фрагмента клиентов обслуживаются в 2 склада W2_CUSTOMER фрагмент, и так далее, уступая четыре фрагмента клиента. Четыре фрагменты Аналогично определяется по РАЙОН, порядок ORDER-LINE, истории, Нью-го порядка, и STOCK. Потому что СКЛАД крайне мала это не фрагментарный характер. Поскольку все товарно-материальных ценностей хранятся на всех складах элемент таблицы не фрагментарный характер. Поэтому Есть 30 фрагментов, которые будут выделены, любой из которых может быть воспроизведена на любом узле. Частоты для каждой транзакции выполняется на каждом узле приведены в таблице 5. Эти результаты в 182 запросов (90 и 92 обновлений извлечений), около 36000 сделки казни, и более 350 000 запросов казни.

Эта проблема больше, чем те, которые использовались в предыдущих исследованиях. Например, Rho и марте (2000) использовали 54 запросов и 17 фрагментов, в то время как Рам и Нарасимхан (1994), используемые до 10 узлов и 10 фрагментов, уменьшая количество реплик за три фрагмента. Кроме того, поскольку она основана на TPC Benchmark это легитимность установленной нормы на практике.

Решение процедуры

Время отклика модели была выполнена в рамках вложенных генетического алгоритма с использованием Microsoft Visual C 6.0. Система имеет 23 объектов и в общей сложности 9000 строк кода. Пять объектов реализации генетического алгоритма. Их конструкция была адаптирована из Rho и марте (2000). Остальные 18 объектов внедрения модели время отклика. Они были разработаны и внедрены специально для этого исследования.

Хотя Есть целый ряд возможных подходов к решению, генетический подход, алгоритм был выбран по ряду причин (Rho

Генетические алгоритмы требуют параметры для управления размером решения бассейн, несколько поколений, и операторам использовать для эволюционного процесса (Гольдберг, 1989; Вос, 1999). Для этого исследования внешней генетический алгоритм создает пул 25 распределения данных конструкций и развивается их в течение максимум 750 поколений. Внутренний генетический алгоритм формирует пул 100 конструкций операции выделения и эволюции им в течение максимум 7500 поколений. Скрещивания и мутации операторов и последующих мутаций, которые используются Rho и марте (2000). Структура гена и эксплуатации вложенные генетического алгоритма, рассматриваются в Приложении.

Сетевая среда

Два разных возможностей сети (скорости) моделируются, 1,544 Мбит / с и 44,736 Мбит / с. 1,544 Мбит / с скорость выделенной линии T1, очень популярный вид услуг доступен только в Северной Америке. Скорость выделенной линии T3 является 44,736 Мбит / с или эффективная скорость передачи данных в ОС-1 цифровой связи, как это определено синхронной оптической сети (SONET) (Балларт

Мы решили каждой задачи, так и без задержки, по консервативным оценке скорости биты сети на две трети скорости света (2 * 10 ^ 8 м / сек). Это нижняя граница латентность (Сталлингс

Конфигурация сети приблизительно на большой площади континентального сети слоем 3 и 4 протокола характеристика Transmission Control Protocol (TCP) для сделки (T / TCP), работающие на основе Интернет-протокола (IP). T / TCP изменяет TCP, что полезная нагрузка сообщения может осуществляться в сообщении установки сессии (Stevens, 1996). В дополнение к 20 байта требуется IP, он накладные расходы 20 байт заголовка сообщения (если параметры не указаны). Дополнительные 100 байта предполагаются для данных, необходимых для сделки процессора (например, данные учетной записи пользователя). Таким образом, каждое сообщение, предполагается провести 140 байта. Восемь комбинаций скорости сети, задержка, и параллелизм были проанализированы (табл. 6). Результаты для каждой комбинации, обсуждаются ниже.

РЕЗУЛЬТАТЫ ИССЛЕДОВАНИЙ

Последствия задержки увеличиваются в очень высокой скоростью сетей и модерируются точного моделирования и эффективного использования параллелизма. Последовательная обработка без задержки является базовой. Это эквивалентно предположений, сделанных в предыдущие экономически распределенных подходов проектирования баз данных. В результате игнорирования задержку, ранее распределенная база данных, подходы к проектированию недооценивать время отклика для распределенных запросов и, как правило, выделить операции недостаточно узлов, чтобы избежать задержек и очередей для балансировки нагрузки на систему. Когда задержка входит в последовательном модели, однако, его влияние на время реакции составляет переоценить, однажды в сети сообщений путешествовать самостоятельно и одновременно, т.е. параллельно. Последовательные модели не учитывают этого. Следовательно, они не подходят для распределенных баз данных в высокоскоростных сетях.

Эти эффекты показали в наших экспериментах. В сети T1, учет задержки привели к времени отклика на лучший проект, увеличится на 755% в случае последовательной обработки. В случае параллельной обработки время отклика лучший дизайн увеличился лишь на 295%. В T3 сети, где задержки является основным компонентом времени отклика, это увеличение, значительно больше, 2569% и 455% соответственно.

В последнем столбце таблицы 7 показывает процентное сокращение среднего времени отклика на запрос в результате использования параллелизма. Эти цифры отражают процентное снижение средневзвешенной время отклика между лучшими sequentiallatency и лучшие параллельно задержки решения. В обоих T1 и T3 случаев улучшения были значительными, 97% и 96% соответственно. Очевидно, что дополнительные сложности параллельной обработки может дать значительное улучшение времени отклика. Тем не менее, это не просто параллелизм, что дает эти улучшения. Распределение данных должны быть разработаны с учетом потенциала параллелизма для достижения этих результатов.

Рассмотрение параллелизм приводит к фундаментальным изменениям в конструкции распределения данных. Как уже говорилось выше, извлечение преимуществ репликации должны быть взвешены против ее недостатки обновления. Репликация сокращает время поиска ответа, поскольку любая копия может быть использована, но увеличивает время отклика обновление, так как все реплики должны быть обновлены. Параллелизм может сократить время отклика для обновления реплик, и поэтому рассмотрение этого параллелизма, как ожидается, приведет к увеличению репликации. Это показано в таблице 8, который показывает лучшие данные ассигнования на 4 экспериментов, которые включают задержки. Конструкция представлена в бинарной матрице формата данных в виде строк и столбцов в качестве узлов. 1 в любой строке или столбце пересечения означает, что соответствующий фрагмент этой строки было выделено узла, соответствующего этому столбцу. 0 означает, что фрагмент не было выделено там. Таким образом, вступление 00001 в первом ряду последовательных столбца T1 задержка означает, что таблица ПУНКТ было выделено только 4 узла, соответствующего склада 4 (штаб-квартира узел 0). Реплицированные фрагменты подчеркнуты. 00111 вступления в первом ряду параллельных столбца T1 задержка означает, что элемент таблицы была воспроизведена в узлах 2, 3 и 4, соответствующие склады 2, 3 и 4 (опять же, штаб-квартира узел 0) ..

В таблице 9 приведены три меры объем репликации, в лучших дизайн генерируется в каждом из опытов. Первая мера, объем данных, является объем данных, выделенные решением. Максимальный объем данных (Max) является объем хранения данных, необходимых для репликации каждого фрагмента в каждом узле, в данном случае 1413 мегабайт (Мб). Минимальная сумма данных достигается путем выделения каждого фрагмента только один узел. Она требует 283 Мб общей памяти данных. Второй мерой репликации репликации фактор. Если только одна копия фрагмента выделяется, фрагмент 0% подражания. Если в двух экземплярах, распределяются, фрагмент 25% других местах, и так далее, вплоть до 100% фактора репликации, если он повторяет на всех 5 узлов. Последняя мера является общее количество фрагментов выделено в системе. Минимум 30, по одному экземпляру каждого фрагмента. Максимум 150, пять копий каждого фрагмента. Таблицы 8 и 9 показывают, что для рассмотрения этой проблемы параллелизма результаты значительно выше, чем репликация последовательной модели. Хотя этот результат зависит проблема становится ясно, что выбранный распределенных баз данных конструкций для последовательной и параллельной обработки существенно отличаются, укрепляем наше утверждение, что рассмотрение параллелизм имеет основополагающее значение для эффективного распределенного проектирования баз данных ..

В последовательных решений, T1 последовательного задержки и T3 последовательная задержка в таблице 9, 34 и 35 фрагментов, соответственно, были выделены. Дополнительные ассигнования в T3 результаты случае из-за стола ПУНКТ выделяется 4 узлов. Если это стол, который не влияют обновления, и поэтому не несет никакой репликации казни был снят с рассмотрения, Есть только два воспроизведены фрагменты T3 последовательного решения задержки, по сравнению с 4 в T1 последовательного решения Latency. Таким образом, наше утверждение, что в отсутствие параллелизма и при наличии обновлений, быстрее сети приводит к меньшей поддержкой репликации выгоды.

Оценка экспериментальных результатов

Ziane, Zait, а также Гонконг (1995) и оспаривается Hong (1994) утверждение о том, что Стонбракер оптимального параллельный план выполнения для запроса распараллеливания его оптимального последовательного плана выполнения. Они показали, что при определенных конфигурациях компьютер, известный как общие, ничего системы, утверждение, является недействительным и, следовательно, к выводу, что различные алгоритмы должны быть разработаны с целью определения оптимального параллельных планов выполнения в таких условиях. Так как распределенная система является одной из форм коллективного ничего системы мы и ожидали результатов в соответствие с Ziane, Zait и Гонконг (1995). Это, по сути, дела. В наших экспериментах лучшие параллельные планы выполнения запросов, как правило, отличается от лучших последовательных планов выполнения запросов, даже если данные ассигнования позволяют им быть одинаковыми.

Кроме того, лучшие распараллеливания последовательных дизайн, не обязательно дают эффективные параллельные конструкции. Чтобы продемонстрировать этот факт, мы использовали модель параллельного времени отклика оценить среднее время отклика лучших последовательных конструкций. Среднее время реагирования для T1-SL решение, когда планов выполнения запросов дуги параллельных является 0,03719 секунды по сравнению с 0,02558 секунды, когда параллелизм был рассмотрен во время разработки (например, T1-PL раствора), казнь время отклика около 45%. Таким образом, рассмотрение параллелизм на этапе проектирования в результате отбора данных и операции ассигнований больше подходит для параллельного исполнения модели. Такой же результат имеет место и в T3 случай, когда лучшее решение в соответствии с моделью SL имеет параллельный время отклика 0,02981 секунд, по сравнению с 0,02352 сек получается при параллелизм был рассмотрен во время разработки (например, T3-PL раствора), уступая Время ответа наказание в виде 27%.

Различия между последовательной и параллельной решения особенно очевидны обновления запросов. Запрос на обновление состоит из четырех исходящих сообщений и три входящих сообщений на реплики. Таким образом, общее время отклика для последовательного обновления по крайней мере, г * (4 * 3 * Отправить прием), где г-число копий. По распараллеливания этих сообщений, общее время реакции обновление приблизится к одним узлом обновление: (4 * 3 * Отправить прием). Это сокращение времени обновления ответ делает более привлекательным репликации в рамках параллельной модели исполнения.

Разница в количестве повторений от последовательных и параллельных решений подчеркивает это свойство параллелизма. По распараллеливания запросов и обновлений, значительный прирост производительности может быть достигнуто. По сути, метод, в котором хорошее решение репликации данных достигается с помощью последовательного исполнения отличается от используемого для достижения хорошего решения с параллельной обработки. Данные будут воспроизведены, если казнь время отклика обновления нескольких копий перевешивают сокращения времени реагирования на запросы поиска, что выиграет от этого репликации. В очередной случае, есть высокий штраф времени ответа на обновления в связи с задержкой (многие мелкие сообщений) и последовательного местной переработки. Однако, в случае параллельного, способность выполнять обновления в параллельной компенсации влияния задержки и местного времени обработки. Отсюда с более суровое наказание, время отклика для репликации, последовательный случае требует большей поиска ответа сокращение времени, чтобы оправдать репликации, чем аналогичного случая, в результате чего меньше репликации для последовательного дела. Кроме того, параллельное исполнение запроса зависит от способности присвоить потенциально параллельные операции, чтобы различные узлы.

Оптимальное количество и тип репликации также зависит от скорости сети, когда параллелизм используется. В T1-PL случае репликации коэффициент составляет 25%, 20 из 30 фрагментов, реплицируются по крайней мере один раз. В T3-PL случае, это 53%, 25 из 30 фрагментов, реплицируются по крайней мере один раз. Однако, несмотря на T3-PL конструкция имеет значительно более репликации она не просто добавить реплики T1-PL дизайна. Распределения и репликации данных конструкция отличается. Таким образом, приходим к выводу, что последствия скорость работы сети на данных, распределения и репликации конструкции должны быть оценены на основе проблем по-задачи. Проектный подход, представленные в настоящем документе представлена действенным инструментом для таких оценок.

Конечно, репликации данных увеличивает требования к памяти, увеличивая тем самым стоимость хранения проектной и, возможно, напряжение местного потенциала узла. Такие ограничения ресурсов могут быть легко включены в генетический алгоритм направляя ее устранить любое решение, которое нарушает какие-либо локальной обработки и хранения ограничений.

Лучшее распределение данных генерируются в соответствии с последовательной предположение весьма отличаются от тех, генерируется, когда параллелизм рассматривается (табл. 8). Это дает дополнительные свидетельства того, что это не достаточно, чтобы принять хороший дизайн генерируется при последовательном предположения и просто распараллелить его. Процесс проектирования должны параллелизма во внимание в целях обеспечения максимальной отдачи. Кроме того, как указывалось выше, эффективная распределенная база данных конструкций зависит также от скорости сети. Данные распределения и репликации конструкции значительно отличаются по T1 и T3 случаях, даже когда параллелизм включены на этапе проектирования. T3-PL решение не только более репликации, оно выделяет и репликацию данных отличается от T1-PL решения. Поэтому проекты распределенных баз данных должны быть пересмотрены, как сетевые конфигурации и возможности перемен.

Выводы и дальнейшие исследования

Проектирование распределенных баз данных, которые минимизируют общее время отклика системы в текущей высокой пропускной способности сети является сложной и трудной задачей. Затратный подход являются неприемлемыми, поскольку они игнорируют последствия задержки сети и параллелизма. До времени отклика подходы, которые считают параллелизма и задержки были направлены на оптимизацию запросов предполагая данного распределения и репликации данных дизайна. Это первый распределенный подход проектирования баз данных, которые всесторонне рассматриваются проблемы взаимозависимы распределения данных, репликации дизайна и обработки запросов стратегии в высокоскоростной сети, где задержки и параллелизма, оказывают значительное влияние на время отклика.

Учитывая описание сетевой среды, логические базы данных (например, отношения) и соответствующего обновления и поиска запросов наш подход выделяет фрагменты данных с узлами, возможно, при репликации, а также проекты планов выполнения для каждого запроса. планов выполнения запроса предусматривать выделение выбора и присоединиться к операции по узлов в сети, обработки данных полугосударственными присоединиться к стратегии, а также эффективно использовать параллелизм, чтобы свести к минимуму среднее время отклика. Оптимальное распределение данных зависит от ожидаемого использования данных моделей и нагрузки в системе, которая, в свою очередь, оцениваются планы выполнения запросов. Оптимальные планы выполнения запросов зависеть от структуры данных и распределения нагрузки в системе, порожденная всеми другими запросами. Различные распределения данных проектов и альтернативных планов выполнения запроса дают различные возможности для выполнения операций параллельно.

Такая взаимозависимость делает эту проблему неразрешимой для аналитических методов решения. Мы рассматриваем эту проблему с помощью вложенных генетического алгоритма. Генетический алгоритм создает первоначальное население полную базу данных проектов в том числе распределение данных, репликации и обработки запросов стратегий. Таким образом, вышеупомянутые взаимозависимости может быть должным образом учтены до начала их использования модели время отклика для оценки минимального времени реакции на каждый запрос. Генетический алгоритм использует стандартные и специально адаптирована кроссовера и мутации операторам развивать населения и выбрать оптимальную конструкцию вблизи. Дополнительные преимущества генетических алгоритмов подхода включают возможность добавить определенное время ответа или ограничения нагрузки на конкретные вопросы или узлами сети.

Мы продемонстрировать с помощью серии экспериментов, игнорируя последствия задержки и параллелизм на этапе проектирования может привести к выбору неэффективного распределения данных и обработки запросов стратегии, в частности для сетей с высокой пропускной способностью. Мы используем совета обработки транзакций TPC-C тест в качестве основы для этих экспериментов, чтобы обеспечить проблема, представитель корпоративных систем обработки транзакций. Решения этой проблемы при различных сетей и моделей время отклика были подготовлены и проанализированы.

Можно утверждать, как в параллельных баз данных литературы, что параллелизм строго во время выполнения явление. Эта литература основное внимание уделяется разработке планов выполнения запросов, которые используют параллелизм чтобы свести к минимуму время отклика для данного распределенных баз данных. Кроме того, что исследования, хотя и считают параллелизма для этой цели, упростили задачу, полагая условий, в которых общение времени можно пренебречь, например, многопроцессорных машин или локальных сетей. Таким образом, в то время как общие подходы, предложенные в этой области исследований, которые применимы к распределенной базы данных, конкретных алгоритмов нет. Кроме того, наши исследования показали, что если параллелизм не рассматривается на этапе проектирования, в результате проектных данных, доля не может позволить эффективно использовать параллелизм. Используя методы, предложенные в работе, мы можем рассмотреть параллелизма во время разработки, тем самым достижения проектирования баз данных гораздо лучше подходит для выполнения время распараллеливания.

Есть несколько областей для проведения дополнительных исследований. Во-первых, точность и эффективность моделей, представленных должны быть оценены. Это потребует реализации альтернативных проектов по данной проблеме, сравнение фактических время ответа на каждый запрос к предсказанным с помощью модели. Такая реализация также будет способствовать определению воздействия различных мониторов обработки транзакций и управления распределенной базой данных конвенций.

Во-вторых, дополнительные эксперименты и анализ чувствительности должно быть выполнено. Хотя TPC-C обеспечивает Benchmark насущной проблемой базе дополнительного анализа проблемы и экологические характеристики не требуется. Такой анализ должен включать компромисс между поиска и обновления частот, объемов данных, расстояния между узлами, потенциал узла сети и мощности и нагрузки, стохастическое моделирование выполнения запроса и оптических сетей. Такие эксперименты также будет способствовать выявлению критических параметров. Определение критических параметров позволит разработчикам сконцентрировать ресурсы на точного определения значения этих параметров для их конкретных условий. Например, если незначительные изменения в перерабатывающих мощностей и нагрузок на местных узлов приведет к существенным изменениям в конструкции данных распределения, то дизайнеры должны точно оценивать эти мощности и нагрузки до разработки дизайна данные распределения. Такой анализ должен включать как пиковой нагрузки и средней нагрузки.

В частности вопрос о дифференцированном расстояния между узлами требует дополнительных исследований. Последствия задержки зависят от расстояния. При прочих равных условиях дальше узел от других узлов более выражены последствия задержки. Тем не менее, задержки влияет как на восстановление и обновление времени отклика. Если воздействие на поиск время отклика перевешивают воздействие на обновление времени отклика, например, из-за объема переданных данных и количество сообщений, необходимых каждому, а затем более удаленный узел будет, как правило, имеют повышенные уровни репликации для сведения к минимуму последствия задержки. Точно так же присоединиться к операции по запросам, не доступа к данным из этого узла будет меньше шансов быть возложены на него, потому что сокращение задержек при обработке достигнутые уступки должны превышать дополнительные задержки, вызванных ею. Эта неспособность сделать общие выводы и правила проектирования-оф-пальца является еще одним свидетельством для значения такого инструмента, как, что поставленные в этом исследовании. Эффективность в распределенных баз данных является чрезвычайно проблемы зависимости. Так как сетевые характеристики, данные объемы, расстояния и запросы и обновления изменения требований, распределенные базы данных проектов необходимо изменить, чтобы вместить их всех.

В-третьих, алгоритмы для создания разделов с данными, чтобы быть тиражирован и выделил просто в зависимости от запроса критериям отбора. Вполне возможно, что новые алгоритмы фрагментации, принимая такие факторы, как задержки и параллелизма во внимание, будет создать более эффективные фрагменты, которые поддаются более высокую производительность в параллельных распределенных баз данных.

В-четвертых, этот подход ориентирован на системы обработки транзакций, где минимизации времени отклика имеет решающее значение. Необходимы дальнейшие исследования для решения разработке других распределенных сред баз данных, таких как хранилища данных и системы DSS. Такие условия обычно поддерживают специальной обработки запросов, использовать партию, а не операция обновления, чрезвычайно интенсивные процессора, и может привести к большой или малой результатов запроса. Кроме того, сведение к минимуму время реакции не может быть важнейшей целью дизайна. Тем не менее, учитывая большое число одновременно работающих пользователей и сложные аналитические потребности обработки данных и операции выделения и параллельной обработки данных, вероятно, играют важную роль в разработке таких систем. [В редакцию: май 2002. Принято редколлегией: июль 2003.]

Ссылки

Apers, П. М. Г. (1988). Данные распределения в распределенных системах баз данных. ACM Сделки на Database Systems, 13, 263-304.

Балларт Р.,

Бернштейн, П. А.,

Бланкиншип Р., Хевнер А.,

Корнелл, Д. В.,

Голдберг, Д. Е. (1989). Генетические алгоритмы поиска, оптимизации и машинного обучения. Чтение, М.: Addison-Wesley.

Хасан, В. (1996). Оптимизация запросов SQL для параллельных машин. Лекции по информатике 1182. Берлин: Springer-Verlag.

Хасан, W., Флореску Д.,

Хевнер,, У, О. В.,

Гонконг, W.,

Hua, К. А., Tavanapong, W.,

Йоханссон, J. M. (2000). О влиянии задержки сети на распределенной системы проектирования. Информационные технологии управления, 1, 183-194.

Йоханссон, J. М., март, С. Т.,

Kulkarni, U.,

Закон, А. М.,

Марта, С. Т., Хевнер А.,

Марта, С. Т.,

Navathe, S., Кери, S., Wiederhold Г.

Oracle. (1999). Oracle8i Параллельные установки сервера и конфигурации руководство релиз 8.1.5, корпорация Oracle Документ A67439. Доступно по адресу: (<a target="_blank" href="http://www.csee" <rel="nofollow"> http://www.csee / A>. Umbc.edu/help/oracle8/server.815 / a67439/toc.htm, по состоянию на 4 марта 2003).

Рам, S.,

Rho, S.,

Rho, S.,

Rho, S.,

Шэн, О. Р.,

Шривастава, J.,

Сталлингс, W.,

Стивенс, В. Р. (1996). TCP / IP Illustrated, Том 3: TCP по операциям, HTTP, NNTP, и UNIX протоколов домена. Том 3, Ридинг, Массачусетс: Addison-Wesley.

Sun Microsystems. (1998). Результатах теста TPC Benchmark (TM) полный отчет раскрытия использованием Sun Microsystems Ultra Enterprise 3500 и Sybase Adaptive Server Enterprise 11,5 ЕБФ 7940 реляционными базами данных, технический отчет, Sun Microsystems, Пало-Альто, Калифорния, апрель.

Обработки транзакций Совета. (2002). Результатах теста TPC Benchmark (TM) C стандартных пересмотра спецификации 5.1, обработки транзакций Совета декабря. Доступно по адресу: (<a target="_blank" href="http://www.tpc.org" rel="nofollow"> http://www.tpc.org </ A> доступ 4 марта 2003).

Вос, М. Д. (1999). Простой генетический алгоритм: Фонд и теории. Cambridge, MA: MIT Press.

Wong Е.,

Ю, H.,

Ю., К. Т.,

Ziane, М., Zait, М.,

Йеспер М. Йоханссон

Microsoft Corporation, One Microsoft Way, Redmond, WA 98052, адрес электронной почты: <a <href="mailto:jesperjo@microsoft.com"> jesperjo@microsoft.com />

Сальваторе Т. марта [кинжал]

Оуэн Высшая школа менеджмента, Университета Вандербильта, Nashville, TN 37203, адрес электронной почты: <a href="mailto:Sal.March@owen.vanderbilt.edu"> Sal.March @ owen.vanderbilt.edu </ A>

J. David Науманн

Информация и решение Департамента науки, Carlson школа управления, 321 19-я авеню Юг, Миннеаполис, MN55455, адрес электронной почты: <a href="mailto:dnaumann@umn.edu"> dnaumann@umn.edu </ A>

[Кинжал] корреспондент автора.

Йеспер М. Йоханссон является менеджером программы обеспечения безопасности в связи по вопросам безопасности и инженерной группы по вопросам безопасности бизнеса Microsoft в группы (СБУ). Его работа в Microsoft сделок с обеспечением более защищенной инфраструктуры вычислений и работы пользователей по всему спектру продуктов и услуг Microsoft продает. Он занимается всеми аспектами безопасности Microsoft в дизайн, по умолчанию, а также развертывания цели. До прихода в СБУ д-р Johansson был старшим технологом безопасности в группе Стратегии Безопасности, касающиеся вопросов безопасности в собственной инфраструктурой Microsoft. Д-р Johansson регулярно публикует в научных журналах по различным вопросам информационной безопасности. До прихода в Microsoft, д-р Johansson был ассистентом профессора информационных систем в Бостонском университете, где он проводил исследования в области информационной безопасности, компьютерных сетей и баз данных, а также преподавал в этих областях. Д-р Johansson имеет докторскую степень в области управления системами информации из Университета Миннесоты, MS в информационных системах, MBA в Университете штата Мэриленд, и степень бакалавра в области международного бизнеса, немецкий, с небольшим во французской литературе от California State University, Фуллертон.

Сальваторе Т. Марш Дэвид Уилсон профессор К. управления при Оуэн высшая школа менеджмента, Университета Вандербильта. Он получил степень бакалавра в области промышленного строительства и MS и доктора исследовательских работ в университете Корнелла. Его основные функции обучения и исследовательские интересы в области формализмов представления данных, распределенных баз данных, технологии электронной торговли и развития информационной системы инструментов и методологий. Его исследования появились в журналах, таких как ACM Surveys вычисления, ACM Сделки на Database Systems, коммуникаций ACM, IEEE Transactions на данных, информатики и управления, Decision Sciences, журнал MIS, информационных систем, информационных систем и исследований . Он работал в качестве редактора главный для ACM Surveys вычислительным (1986-1992) и в качестве ассоциированного редактор ежеквартального MIS (1993-1998 годы). В настоящее время старший редактор информационных систем научных исследований и помощник редактора для принятия наук, журнал управления базами данных и информационных систем границ.

J. David Науманн является доцентом информационных систем в Карлсон школа Ment возраст человека в университете штата Миннесота. Прежде чем стать академическим, д-р Науман был компьютерную карьеру, которая включала времени в качестве программиста, системного аналитика, компьютерные продавцом, консультантом и сервис-бюро менеджера. Его Б., MS, и доктора взяты из Университета Миннесоты. Автор исследований в области коммуникаций в ACM, Decision Sciences, MIS Quarterly, информации и управления, а также других научных журналах. С Гордон Дэвис, он стал автором личной продуктивности с информационным технологиям (McGraw-Hill, 1997). Он создал и эксплуатирует широко используется факультет Directory службы Интернета. Он учит, системный анализ и дизайн, программирование, телекоммуникации и Интернет, а также проводит исследования в этих областях.