Jump to content

Сетка данных

Это простое высокоуровневое представление сетки данных, изображающей распределенное хранилище.

Сетка данных — это архитектура или набор сервисов, которые позволяют пользователям получать доступ, изменять и передавать чрезвычайно большие объемы географически распределенных данных в исследовательских целях. [1] Гриды данных делают это возможным благодаря множеству промежуточных приложений и сервисов , которые собирают данные и ресурсы из нескольких административных доменов , а затем предоставляют их пользователям по запросу.

Данные в сетке данных могут располагаться на одном или нескольких сайтах, где каждый сайт может быть собственным административным доменом, регулируемым набором ограничений безопасности относительно того, кто может получить доступ к данным. [2] Аналогичным образом, несколько копий данных могут быть распределены по всей сети за пределами их исходного административного домена, и ограничения безопасности, налагаемые на исходные данные для тех, кто может получить к ним доступ, должны в равной степени применяться к репликам. [3] Специально разработанное промежуточное программное обеспечение сетки данных обеспечивает интеграцию между пользователями и запрашиваемыми ими данными, контролируя доступ и делая их максимально эффективными.

Промежуточное ПО

[ редактировать ]

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

Универсальное пространство имен

[ редактировать ]

Поскольку источники данных в сетке данных будут состоять из данных из множества отдельных систем и сетей, использующих разные соглашения об именах файлов , пользователю будет сложно найти данные в сетке данных и узнать, что он получил то, что ему нужно, основываясь исключительно на существующих физических данных. имена файлов (PFN). Универсальное или унифицированное пространство имен позволяет создавать логические имена файлов (LFN), на которые можно ссылаться в сетке данных, которая отображается в PFN. [5] Когда LFN запрашивается или запрашивается, возвращаются все соответствующие PFN, включая возможные копии запрошенных данных. Конечный пользователь может затем выбрать из полученных результатов наиболее подходящую реплику для использования. Эта услуга обычно предоставляется как часть системы управления, известной как брокер ресурсов хранения (SRB). [6] Информация о местонахождении файлов и сопоставлениях между LFN и PFN может храниться в каталоге метаданных или реплик. [7] Каталог реплик будет содержать информацию о LFN, которые сопоставляются с несколькими репликами PFN.

Служба транспортировки данных

[ редактировать ]

Другая услуга промежуточного программного обеспечения — это услуга, обеспечивающая транспортировку или передачу данных. Транспортировка данных будет включать в себя множество функций, которые не ограничиваются только передачей битов, а также включают такие элементы, как отказоустойчивость и доступ к данным. [8] Отказоустойчивость в сетке данных может быть достигнута путем предоставления механизмов, которые гарантируют возобновление передачи данных после каждого прерывания до тех пор, пока не будут получены все запрошенные данные. [9] Существует несколько возможных методов, которые можно использовать, включая начало всей передачи с начала данных и возобновление с того места, где передача была прервана. Например, GridFTP обеспечивает отказоустойчивость, отправляя данные из последнего подтвержденного байта, не начиная всю передачу с начала.

Служба транспортировки данных также обеспечивает низкоуровневый доступ и соединения между хостами для передачи файлов. [10] Служба транспортировки данных может использовать любое количество режимов для реализации передачи, включая параллельную передачу данных, когда два или более потоков данных используются по одному и тому же каналу , или чередующуюся передачу данных, когда два или более потоков получают доступ к различным блокам файла для одновременной передачи в также использование базовых встроенных возможностей сетевого оборудования или специально разработанных протоколов для поддержки более высоких скоростей передачи. [11] Служба транспортировки данных может дополнительно включать функцию сетевого наложения для облегчения маршрутизации и передачи данных, а также функции файлового ввода-вывода , которые позволяют пользователям видеть удаленные файлы, как если бы они были локальными для их системы. Служба транспортировки данных скрывает от пользователя сложность доступа и передачи между различными системами, поэтому она выглядит как один унифицированный источник данных.

Служба доступа к данным

[ редактировать ]

Службы доступа к данным работают рука об руку со службой передачи данных, обеспечивая безопасность, контроль доступа и управление любой передачей данных в сети данных. [12] Службы безопасности предоставляют механизмы аутентификации пользователей, обеспечивающие их правильную идентификацию. Общие формы безопасности аутентификации могут включать использование паролей или протокола Kerberos . Службы авторизации — это механизмы, которые контролируют, к чему пользователь может получить доступ после идентификации посредством аутентификации. Общие формы механизмов авторизации могут быть такими же простыми, как права доступа к файлам. Однако потребность в более строгом контролируемом доступе к данным реализуется с помощью списков управления доступом (ACL), управления доступом на основе ролей (RBAC) и управления авторизацией на основе задач (TBAC). [13] Эти типы элементов управления можно использовать для обеспечения детального доступа к файлам, включая ограничения на время доступа и продолжительность доступа к детальным элементам управления, которые определяют, какие файлы можно читать или записывать. Последней услугой доступа к данным, которая может присутствовать для защиты конфиденциальности передачи данных, является шифрование. [14] Наиболее распространенной формой шифрования для этой задачи было использование SSL во время транспортировки. Хотя все эти службы доступа работают в пределах сетки данных, службы доступа в различных административных доменах, в которых размещаются наборы данных, по-прежнему будут действовать для обеспечения соблюдения правил доступа. Чтобы это работало, службы доступа к сетке данных должны соответствовать службам доступа к административным доменам.

Служба репликации данных

[ редактировать ]

Чтобы удовлетворить потребности в масштабируемости, быстром доступе и совместной работе пользователей, большинство гридов данных поддерживают репликацию наборов данных в точки в архитектуре распределенного хранилища. [15] Использование реплик позволяет нескольким пользователям быстрее получать доступ к наборам данных и сохранять пропускную способность, поскольку реплики часто можно размещать стратегически близко к сайтам или внутри них, где они нужны пользователям. Однако репликация наборов данных и создание реплик ограничены доступностью хранилища внутри сайтов и пропускной способностью между сайтами. Репликация и создание наборов данных реплик контролируется системой управления репликами. Система управления репликами определяет потребности пользователей в репликах на основе входных запросов и создает их на основе доступности хранилища и пропускной способности. [16] Затем все реплики каталогизируются или добавляются в каталог на основе сетки данных относительно их местоположения для запросов пользователей. Для выполнения задач, выполняемых системой управления репликами, она должна иметь возможность управлять базовой инфраструктурой хранения. Система управления данными также обеспечит своевременное распространение изменений в репликах на все узлы.

Стратегия обновления репликации

[ редактировать ]

Существует несколько способов, которыми система управления репликацией может обрабатывать обновления реплик. Обновления могут быть разработаны на основе централизованной модели, в которой одна главная реплика обновляет все остальные, или децентрализованной модели, в которой все одноранговые узлы обновляют друг друга. [16] Топология размещения узлов также может влиять на обновления реплик. Если используется иерархическая топология, обновления будут проходить в древовидной структуре по определенным путям. В плоской топологии порядок выполнения обновлений полностью зависит от одноранговых отношений между узлами. В гибридной топологии, состоящей как из плоской, так и из иерархической топологии, обновления могут происходить по определенным путям и между узлами.

Стратегия размещения репликации

[ редактировать ]

Существует несколько способов, которыми система управления репликацией может управлять созданием и размещением реплик, чтобы наилучшим образом обслуживать сообщество пользователей. Если архитектура хранения поддерживает размещение реплик при достаточном объеме памяти сайта, тогда это становится вопросом потребностей пользователей, имеющих доступ к наборам данных, и стратегии размещения реплик. [17] Было предложено и протестировано множество стратегий, позволяющих наилучшим образом управлять размещением реплик наборов данных в сетке данных для удовлетворения требований пользователей. Не существует одной универсальной стратегии, которая лучше всего отвечала бы всем требованиям. Выбор наилучшей стратегии зависит от типа сетки данных и требований сообщества пользователей к доступу. Можно даже создавать копии, в которых файлы зашифрованы для обеспечения конфиденциальности, что может быть полезно в исследовательском проекте, связанном с медицинскими файлами. [18] В следующем разделе представлены несколько стратегий размещения реплик.

Динамическая репликация
[ редактировать ]

Динамическая репликация — это подход к размещению реплик, основанный на популярности данных. [19] Метод был разработан на основе иерархической модели репликации. Система управления данными отслеживает доступное хранилище на всех узлах. Он также отслеживает запросы (обращения), которые запрашивают клиенты данных (пользователи) на сайте. Когда количество попаданий для определенного набора данных превышает порог репликации, это инициирует создание реплики на сервере, который напрямую обслуживает клиент пользователя. Если серверу прямого обслуживания, известному как родительский сервер, не хватает места, то отец отца в иерархии становится целью получения реплики и так далее по цепочке, пока она не будет исчерпана. Алгоритм системы управления данными также допускает динамическое удаление реплик, имеющих нулевое значение доступа или значение ниже частоты хранения данных, для освобождения места. Это повышает производительность системы с точки зрения времени отклика, количества реплик и помогает распределять нагрузку по сетке данных. Этот метод также может использовать динамические алгоритмы, которые определяют, действительно ли стоимость создания реплики соответствует ожидаемой прибыли с учетом ее местоположения. [16]

Адаптивная репликация
[ редактировать ]

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

Справедливая репликация
[ редактировать ]

Как и предыдущие методы адаптивной и динамической репликации, репликация справедливого распределения основана на иерархической модели репликации. Кроме того, как и в предыдущих двух случаях, популярность файлов играет ключевую роль в определении того, какие файлы будут реплицироваться. Отличие этого метода заключается в том, что размещение реплик зависит от нагрузки доступа и нагрузки на хранилище серверов-кандидатов. [ нужна ссылка ] Сервер-кандидат может иметь достаточно места для хранения, но обслуживать множество клиентов для доступа к хранимым файлам. Размещение реплики на этом кандидате может снизить производительность всех клиентов, обращающихся к этому серверу-кандидату. Поэтому размещение реплик этим методом осуществляется путем оценки каждого узла-кандидата на доступную нагрузку, чтобы найти подходящий узел для размещения реплики. Если все узлы-кандидаты имеют одинаковую нагрузку доступа, ни к одному из них или меньше доступа, чем к другому, то для размещения реплик будет выбран узел-кандидат с наименьшей нагрузкой на хранилище. Методы, аналогичные другим описанным методам репликации, используются для удаления неиспользуемых или уменьшения количества запрошенных реплик, если это необходимо. Удаленные реплики могут быть перемещены на родительский узел для последующего повторного использования, если они снова станут популярными.

Другая репликация
[ редактировать ]

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

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

Планирование задач и распределение ресурсов

[ редактировать ]

Такие характеристики грид-систем данных, как большой масштаб и неоднородность, требуют специфических методов планирования задач и распределения ресурсов. Для решения этой проблемы большинство систем используют расширенные классические методы планирования. [22] Другие предлагают принципиально иные методы, основанные на стимулах для автономных узлов, таких как виртуальные деньги или репутация узла. Другая специфика дата-гридов — динамика — заключается в непрерывном процессе подключения и отключения узлов и локальном дисбалансе нагрузки при выполнении задач. Это может привести к тому, что результаты первоначального выделения ресурсов для задачи станут устаревшими или неоптимальными. В результате большая часть гридов данных использует методы адаптации во время выполнения, которые позволяют системам реагировать на динамические изменения: балансировать нагрузку, заменять отключаемые узлы, использовать прибыль от вновь подключенных узлов, восстанавливать выполнение задачи после сбоев.

Система управления ресурсами (RMS)

[ редактировать ]

Система управления ресурсами представляет собой основную функциональность сетки данных. Это сердце системы, которое управляет всеми действиями, связанными с ресурсами хранения. В некоторых сетках данных может оказаться необходимым создать объединенную архитектуру RMS из-за различных административных политик и разнообразия возможностей, имеющихся в сетке данных, вместо использования одной RMS. В таком случае RMS в федерации будут использовать архитектуру, обеспечивающую совместимость на основе согласованного набора протоколов для действий, связанных с ресурсами хранения. [23]

Функциональные возможности RMS

[ редактировать ]
  • Выполнение запросов пользователей и приложений на ресурсы данных в зависимости от типа запроса и политик; RMS сможет одновременно поддерживать несколько политик и несколько запросов.
  • Планирование, сроки и создание реплик
  • Обеспечение соблюдения политики и безопасности в ресурсах сетки данных, включая аутентификацию, авторизацию и доступ.
  • Поддержка систем с различными административными политиками для взаимодействия при сохранении автономии сайта.
  • Поддержка качества обслуживания (QoS) по запросу, если функция доступна.
  • Обеспечьте соблюдение требований к отказоустойчивости и стабильности системы.
  • Управляйте ресурсами, например дисковым хранилищем, пропускной способностью сети и любыми другими ресурсами, которые взаимодействуют напрямую или как часть сетки данных.
  • Управляйте доверием к ресурсам в административных доменах. Некоторые домены могут налагать дополнительные ограничения на их участие, требующие адаптации RMS или федерации.
  • Поддерживает адаптивность, расширяемость и масштабируемость по отношению к сетке данных.

Топология

[ редактировать ]
Возможные топологии сетки данных
Possible Data Grid Topologies

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

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

Монадическая топология имеет центральный репозиторий, в который передаются все собранные данные. Затем центральный репозиторий отвечает на все запросы данных. В этой топологии нет реплик по сравнению с другими. Доступ к данным осуществляется только из центрального хранилища, которое может осуществляться через веб-портал. Одним из проектов, использующих эту топологию сетки данных, является Сеть инженерного моделирования землетрясений (NEES) в США. [25] Это хорошо работает, когда весь доступ к данным осуществляется локально или в пределах одного региона с высокоскоростным подключением.

Иерархическая топология подходит для совместной работы, когда имеется один источник данных, и их необходимо распределить по нескольким местам по всему миру. Одним из таких проектов, который выиграет от этой топологии, станет ЦЕРН , в котором работает Большой адронный коллайдер , генерирующий огромные объемы данных. Эти данные находятся в одном источнике и должны быть распространены по всему миру среди организаций, участвующих в проекте.

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

Потребность в сетках данных впервые была признана научным сообществом в области моделирования климата , где в терабайты и петабайты размером наборы данных становились нормой для транспортировки между объектами. [10] Более поздние исследовательские потребности в сетках данных были обусловлены Большим адронным коллайдером (LHC) в ЦЕРН , Лазерной интерферометрической гравитационно-волновой обсерваторией (LIGO) и Слоанским цифровым обзором неба (SDSS) . Эти примеры научных инструментов производят большие объемы данных, которые должны быть доступны большим группам географически разбросанных исследователей. [26] [27] Другие варианты использования сеток данных включают правительства, больницы, школы и предприятия, где предпринимаются усилия по улучшению услуг и сокращению затрат путем предоставления доступа к рассредоточенным и отдельным системам данных посредством использования сеток данных. [28]

С самого начала концепция сетки данных для поддержки научного сообщества рассматривалась как специализированное расширение «сетки», которая сама по себе изначально задумывалась как способ объединения суперкомпьютеров в метакомпьютеры. [29] Однако это просуществовало недолго, и сеть превратилась в возможность подключать компьютеры в любом месте в сети, чтобы получить доступ к любым желаемым файлам и ресурсам, подобно тому, как электричество доставляется по сети путем простого подключения устройства. Устройство получает электроэнергию через свое подключение, причем подключение не ограничивается конкретной розеткой. Исходя из этого, сетка данных была предложена как интегрирующая архитектура, способная предоставлять ресурсы для распределенных вычислений. Он также сможет обслуживать от нескольких до тысяч запросов одновременно, доставляя от гигабайт до терабайтов данных для каждого запроса. Сеть данных будет включать в себя собственную инфраструктуру управления, способную управлять всеми аспектами производительности и работы сеток данных в нескольких глобальных сетях, работая при этом в рамках существующей структуры, известной как Интернет. [30]

Сетка данных также была недавно определена с точки зрения удобства использования; что должна уметь сетка данных, чтобы она была полезна научному сообществу. Сторонники этой теории пришли к нескольким критериям. [31] Во-первых, пользователи должны иметь возможность искать и находить подходящие ресурсы в сетке данных среди множества ее наборов данных. Во-вторых, пользователи должны иметь возможность находить в сетке данных наборы данных, наиболее подходящие для их требований, среди многочисленных реплик. В-третьих, пользователи должны иметь возможность передавать и перемещать большие наборы данных между точками за короткий промежуток времени. В-четвертых, сетка данных должна предоставлять средства для управления несколькими копиями наборов данных внутри сетки данных. И, наконец, сетка данных должна обеспечивать безопасность с помощью контроля доступа пользователей внутри сетки данных, т. е. каким пользователям разрешен доступ к каким данным.

Сетка данных — это развивающаяся технология, которая продолжает меняться и расти, чтобы удовлетворить потребности растущего сообщества. Одна из первых программ, которые начали воплощать сетки данных в реальность, была профинансирована Агентством перспективных исследовательских проектов Министерства обороны (DARPA) в 1997 году в Чикагском университете . [32] Это исследование, инициированное DARPA, продолжило путь к созданию инструментов с открытым исходным кодом, которые делают возможным создание сеток данных. По мере появления новых требований к сеткам данных будут появляться или расширяться такие проекты, как Globus Toolkit, чтобы восполнить этот пробел. Сетки данных вместе с «Сеткой» будут продолжать развиваться.

Примечания

[ редактировать ]
  1. ^ Олкок, Билл; Червенак, Энн; Фостер, Ян; и др. Инструменты Data Grid: возможность использовать научные данные в больших распределенных данных
  2. ^ Венугопал, Шрикумар; Буйя, князь; Рамамоханарао, Котагири. Таксономия сеток данных для распределенного обмена данными стр. 37
  3. ^ Шорфузаман, Мохаммед; Грэм, Питер; Эскичиоглу, Расит. Адаптивное размещение реплик в иерархических сетках данных. стр.15
  4. ^ Падала, Прадип. Обзор промежуточного программного обеспечения данных для Grid-систем стр. 1
  5. ^ Падала, Прадип. Обзор промежуточного программного обеспечения данных для Grid-систем
  6. ^ Аркот, Раджасекар; Ван, Майкл; Мур, Рейган; Шредер, Уэйн; Кременек. Брокер ресурсов хранения – управление распределенными данными в сетке.
  7. ^ Венугопал, Шрикумар; Буйя, князь; Рамамоханарао, Котагири. Таксономия сеток данных для распределенного обмена данными – управление и обработка стр. 11
  8. ^ Кутзи, Серена. Эталонная модель для подхода к использованию сетки данных для адресации данных в динамическом SDI стр. 16
  9. ^ Венугопал, Шрикумар; Буйя, князь; Рамамоханарао, Котагири. Таксономия сеток данных для распределенного обмена данными стр. 21
  10. ^ Перейти обратно: а б Олкок, Билл; Фостер, Ян; Нефедова Вероника; Червенак, Энн; Дилман, Ева ; Кессельман, Карл. Высокопроизводительный удаленный доступ к данным моделирования климата: сложная проблема для технологий сетки данных.
  11. ^ Измайлов, Рауф; Гангули, Самрат; Ту, Нэн. Быстрая параллельная репликация файлов в сетке данных стр. 2
  12. ^ Раман, Виджайшанкар; Наранг, Индерпал; Кроун, Крис; Хасс, Лаура; Малайка, Сьюзен. Сервисы доступа к данным и обработки данных на гридах
  13. ^ Томас, РК и Сандху Р.С. Контроль авторизации на основе задач (tbac): семейство моделей для активного и корпоративно-ориентированного управления авторизацией.
  14. ^ Шрилатха, Малемпати. Грид-подход для обеспечения конфиденциальности данных. стр.1
  15. ^ Червенак, Энн; Шулер, Роберт; Кессельман, Карл; Коранда, Скотт; Мо, Брайан. Репликация данных на обширной территории для научного сотрудничества
  16. ^ Перейти обратно: а б с Ламехамеди, Хауда; Шиманский, Болеслав; Шенту, Зуджун; Дилман, Ева . Стратегии репликации данных в грид-средах
  17. ^ Падала, Прадип. Обзор промежуточного программного обеспечения данных для Grid-систем
  18. ^ Кранти, Г. и Рекха, Д. Шаши. Репликация защищенных объектов данных в сетке данных стр. 40
  19. ^ Белалем, Галем и Меруфель, Бахта. Управление и размещение реплик в иерархической сетке данных
  20. ^ Шорфузаман, Мохаммед; Грэм, Питер; Эскичиоглу, Расит. Адаптивное размещение реплик в иерархических сетках данных
  21. ^ Ранганатан, Кавита и Фостер, Ян. Определение стратегий динамической репликации для высокопроизводительной сети данных.
  22. ^ Епимахов, Игорь; Хамерлен, Абделькадер ; Диллон, Тарам; Морван, Франк. Методы планирования ресурсов для оптимизации запросов в системах обработки данных
  23. ^ Краутер, Клаус; Буйя, Раджкумар; Махешваран, Мутукумару. Таксономия и обзор систем управления грид-ресурсами для распределенных вычислений.
  24. ^ Чжу, Личунь. Управление метаданными в объединении баз данных Grid
  25. ^ Венугопал, Шрикумар; Буйя, князь; Рамамоханарао, Котагири. Таксономия сеток данных для распределенного обмена данными стр. 16
  26. ^ Олкок, Билл; Червенак, Энн; Фостер, Ян; и др. стр.571
  27. ^ Тирни, Брайан Л. Сетки данных и проблемы с производительностью сеток данных. стр.7
  28. ^ Тибодо, П. Правительства планируют проекты сетки данных.
  29. ^ Хейнгартнер, Дуглас. Сетка: Интернет нового поколения
  30. ^ Хейнгартнер, Дуглас. Сетка: Интернет нового поколения
  31. ^ Венугопал, Шрикумар; Буйя, князь; Рамамоханарао, Котагири. Таксономия сеток данных для распределенного обмена данными – управление и обработка стр. 1
  32. ^ Глобус. О наборе инструментов Globus
  • Олкок, Билл; Червенак, Энн; Фостер, Ян; Кессельман, Карл; Ливный, Мирон (2005). «Инструменты Data Grid: возможности науки о больших распределенных данных». Физический журнал: серия конференций . 16 (1): 571–575. Бибкод : 2005JPhCS..16..571A . CiteSeerX   10.1.1.379.4325 . дои : 10.1088/1742-6596/16/1/079 . S2CID   250673712 .
  • Олкок, Билл; Фостер, Ян; Нефедова Вероника л; Червенак, Энн; Дилман, Ева ; Кессельман, Карл; Ли, Джейсон; Сим, Алекс; Шошани, Арье; Драк, Боб; Уильямс, Дин (2001). «Высокопроизводительный удаленный доступ к данным моделирования климата: сложная проблема для технологий сетки данных». АКМ Пресс . CiteSeerX   10.1.1.64.6603 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  • Епимахов Игорь; Хамерлен, Абделькадер; Диллон, Тарам; Морван, Франк (2011). «Методы планирования ресурсов для оптимизации запросов в системах обработки данных». Достижения в области баз данных и информационных систем. 15-я Международная конференция ADBIS 2011 . Вена, Австрия: Springer Berlin Heidelberg. стр. 185–199. дои : 10.1007/978-3-642-23737-9_14 .
  • Краутер, Клаус; Буйя, Раджкумар; Махешваран, Мутукумару (2002). «Таксономия и обзор систем управления грид-ресурсами для распределенных вычислений». Программное обеспечение: практика и опыт . 32 (2): 135–164. CiteSeerX   10.1.1.38.2122 . дои : 10.1002/спе.432 . S2CID   816774 .


  • Ламехамеди, Хауда; Шиманский, Болеслав; Шенту, Зуджун; Дилман, Ева (2002). «Стратегии репликации данных в сетевых средах». Пятая международная конференция по алгоритмам и архитектурам параллельной обработки (ICA3PP'02) . Нажимать. стр. 378–383. CiteSeerX   10.1.1.11.5473 .
  • Падала, Прадип. «Обзор промежуточного программного обеспечения данных для Grid-систем». CiteSeerX   10.1.1.114.1901 . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  • Ранганатан, Кавита; Фостер, Ян (2001). «Определение стратегий динамической репликации для высокопроизводительной сети данных». В Proc. Международного семинара по грид-вычислениям . стр. 75–86. CiteSeerX   10.1.1.20.6836 . дои : 10.1007/3-540-45644-9_8 .

Дальнейшее чтение

[ редактировать ]
  • Хэнкок, Б. (2009). «Простая сетка данных с использованием операционной системы Inferno». Библиотека высоких технологий . 27 (3): 382–392. дои : 10.1108/07378830910988513 .
  • Раджкумар, Кеттимуту; Олкок, Уильям; Известняк, Ли; Наварро, Джон-Пол; Фостер, Ян (30 марта 2007 г.). «GridCopy быстро перемещает данные по сетке» (PDF) . Международный симпозиум по параллельной и распределенной обработке (IPDPS 2007) . Лонг-Бич: Международный IEEE. стр. 1–6 . Проверено 29 апреля 2012 г.
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: efc58762c935488b0fd4673f247dcf69__1717138800
URL1:https://arc.ask3.ru/arc/aa/ef/69/efc58762c935488b0fd4673f247dcf69.html
Заголовок, (Title) документа по адресу, URL1:
Data grid - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)