масштабирование

ERDDAP™Тяжелые нагрузки, сети, кластеры, федерации и облачные вычисления

 

ERDDAP:

ERDDAP™Это веб-приложение и веб-сервис, который объединяет научные данные из различных местных и удаленных источников и предлагает простой, последовательный способ загрузки подмножеств данных в общих форматах файлов и создания графиков и карт. На этой странице обсуждаются вопросы, связанные с тяжелымиERDDAP™Использование загружает и исследует возможности для борьбы с чрезвычайно тяжелыми нагрузками через сети, кластеры, федерации и облачные вычисления.

Оригинальный вариант был написан в июне 2009 года. Существенных изменений не произошло. Последний раз обновлялся 2019-04-15.

Дисклеймер

Содержание этой веб-страницы является личным мнением Боба Саймонса и не обязательно отражает какую-либо позицию правительства или правительства.National Oceanic and Atmospheric Administration. Расчеты упрощены, но я думаю, что выводы верны. Я использовал неверную логику или ошибся в расчетах? Если это так, то виноват только я. Пожалуйста, отправьте электронное письмо с исправлениемerd dot data at noaa dot gov.  

Тяжелые грузы / ограничения

При интенсивном использовании, отдельноERDDAP™будет ограничен (от большинства до наименее вероятного) посредством:

Дистанционный источник Bandwidth

1. Удаленная пропускная способность источника данных — даже при эффективном соединении (Например, черезOPeNDAP) Если удаленный источник данных не имеет очень высокой пропускной способности интернет-соединения,ERDDAPОтветы будут ограничены тем, насколько быстроERDDAP™Можно получить данные из источника данных. Решение состоит в том, чтобы скопировать набор данных наERDDAPЖесткий диск, возможно, сEDDGridКопияилиEDDTableCopy.  

ERDDAPСервер Bandwidth

2. Разве чтоERDDAPСервер имеет очень высокую пропускную способность интернет-соединения,ERDDAPОтветы будут ограничены тем, насколько быстроERDDAP™Как получить данные из источников и как быстроERDDAP™Они могут возвращать данные клиентам. Единственным решением является получение более быстрого интернет-соединения.  

Память

3. Если одновременно поступает много запросов,ERDDAP™Может иссякнуть память и временно отказаться от новых запросов. (ERDDAP™Есть несколько механизмов, чтобы избежать этого и минимизировать последствия, если это произойдет.) Чем больше памяти на сервере, тем лучше. На 32-битном сервере 4+ ГБ действительно хороши, 2 ГБ в порядке, меньше не рекомендуется. На 64-разрядном сервере вы можете почти полностью избежать проблемы, получив много памяти. Видишь?\-Xmx и -Xms настройкидляERDDAPТомкэт. АнERDDAP™Получение интенсивного использования на компьютере с 64-разрядным сервером с 8 ГБ памяти и -Xmx, установленным на 4000M, редко, если вообще когда-либо, ограничивается памятью.  

Управлял Bandwidth

4. Доступ к данным, хранящимся на жестком диске сервера, значительно быстрее, чем доступ к удаленным данным. Тем не менее, еслиERDDAP™Сервер имеет очень высокую пропускную способность интернет-соединения, возможно, что доступ к данным на жестком диске будет узким местом. Частичное решение — использовать быстрее. (Например, 10000 RPM) Магнитные жесткие диски или SSD диски (Если это имеет смысл с точки зрения затрат) . Другим решением является хранение различных наборов данных на разных дисках, так что совокупная пропускная способность жесткого диска намного выше.  

Слишком много кэшированных файлов

5. Слишком много файлов вкэшкаталог -ERDDAP™Кэширует все изображения, но только кэширует данные для определенных типов запросов данных. Возможно, что каталог кэша для набора данных временно имеет большое количество файлов. Это замедлит запросы, чтобы увидеть, находится ли файл в кэше. (Правда!) .<кэш Minutes> вНастройка.xmlПозволяет установить, как долго файл может находиться в кэше, прежде чем он будет удален. Установка меньшего числа минимизирует эту проблему.  

процессор

6. Только две вещи занимают много времени процессора:
   • NetCDF4 иHDF5 теперь поддерживает внутреннее сжатие данных. Декомпрессия большого сжатогоNetCDF4/HDF5 файлов данных могут занять 10 и более секунд. (Это не ошибка реализации. Это природа сжатия.) Таким образом, несколько одновременных запросов к наборам данных с данными, хранящимися в сжатых файлах, могут создать серьезную нагрузку на любой сервер. Если это проблема, решение состоит в том, чтобы хранить популярные наборы данных в несжатых файлах или получить сервер с процессором с большим количеством ядер.
   • Изготовление графов (включая карты) : примерно 0,2 - 1 секунда на график. Так что если было много одновременных уникальных запросов на графы (WMSКлиенты часто делают 6 одновременных запросов!) Может быть ограничение CPU. Когда несколько пользователей работаютWMSКлиенты, это становится проблемой.  

Несколько идентичныхERDDAPс балансировкой нагрузки?

Часто возникает вопрос: "Чтобы справиться с тяжелыми нагрузками, могу ли я установить несколько идентичныхERDDAPс балансировкой нагрузки? Это интересный вопрос, потому что он быстро доходит до сути.ERDDAPДизайн. Быстрый ответ — «нет». Я знаю, что это неутешительный ответ, но есть несколько прямых причин и несколько более крупных фундаментальных причин, по которым я разработал эту идею.ERDDAP™использовать другой подход (федерациейERDDAPs, описанные в основной части настоящего документа) Я считаю, что это лучшее решение.

Некоторые прямые причины, почему вы не можете / не должны настраивать несколько идентичныхERDDAPs являются:

• данностьERDDAP™считывает каждый файл данных, когда он впервые становится доступным, чтобы найти диапазоны данных в файле. Затем он хранит эту информацию в индексном файле. Когда пользователь запрашивает данные,ERDDAP™использует этот индекс, чтобы выяснить, какие файлы искать запрашиваемые данные. Если бы было несколько одинаковыхERDDAPs, каждый из них будет делать эту индексацию, что является потраченным впустую усилием. С федеративной системой, описанной ниже, индексация выполняется только один раз.ERDDAPС.
• Для некоторых типов запросов пользователей (Например, для.nc.png, .pdf файлы) ERDDAP™Вы должны сделать весь файл, прежде чем ответ будет отправлен. ТакERDDAP™Храните эти файлы в течение короткого времени. Если идентичный запрос (Как это часто бывает, особенно для изображений, где URL встроен в веб-страницу.) ,ERDDAP™Можно повторно использовать кэшированный файл. В системе множественных идентичныхERDDAPs, эти кэшированные файлы не являются общими, поэтому каждыйERDDAP™без необходимости и расточительного воссоздания.nc.png или .pdf файлы. С федеративной системой, описанной ниже, файлы создаются только один раз.ERDDAPs и повторно используется.
• ERDDAPСистема подписки не настроена для совместного использования несколькимиERDDAPС. Например, если балансировщик нагрузки отправляет пользователя наERDDAP™и пользователь подписывается на набор данных, затем другойERDDAPВы не будете знать об этой подписке. Позже, если балансировщик нагрузки отправляет пользователя на другойERDDAP™и просит список его подписок, другойERDDAP™Скажет, что их нет (заставить его / ее сделать дубликат подписки на другой EREDDAP) . С федеративной системой, описанной ниже, система подписки просто обрабатывается основным, общедоступным, составным.ERDDAP.

Для каждой из этих проблем я мог бы (с большим усилием) Инженерное решение (Для обмена информацией междуERDDAPs) Но я думаю, чтофедерацияERDDAPподход (описанных в основной части настоящего документа) Это гораздо лучшее общее решение, отчасти потому, что оно имеет дело с другими проблемами.ERDDAPПодход «s-with-a-load-balancer» даже не начинает рассматриваться, особенно децентрализованный характер источников данных в мире.

Лучше всего принять тот простой факт, что я не проектировал.ERDDAP™развертывается как множественное идентичноеERDDAPs с балансировщиком нагрузки. Я сознательно разработалERDDAP™Хорошо работать в федерацииERDDAPs, которые, по моему мнению, имеют много преимуществ. В частности, федерацияERDDAPs идеально согласуется с децентрализованной распределенной системой центров обработки данных, которую мы имеем в реальном мире. (Подумайте о разных регионах IOOS, или о разных регионах CoastWatch, или о разных частях NCEI, или о 100 других центрах обработки данных в разных регионах.NOAANASA DAAC или 1000 центров обработки данных по всему миру) . Вместо того, чтобы говорить всем дата-центрам мира, что им нужно отказаться от своих усилий и поместить все свои данные в централизованное «озеро данных». (Даже если бы это было возможно, это ужасная идея по многим причинам - см. различные анализы, показывающие многочисленные преимуществадецентрализованные системы) ,ERDDAPДизайн работает с миром таким, какой он есть. Каждый центр обработки данных, который производит данные, может продолжать поддерживать, курировать и обслуживать свои данные. (Как они должны) И все же, сERDDAP™Данные также могут быть мгновенно доступны из централизованного источника.ERDDAPбез необходимости передачи данных централизованномуERDDAP™или хранение дублированных копий данных. Действительно, данный набор данных может быть одновременно доступен. из одногоERDDAP™в организации, которая производит и фактически хранит данные (Например, GoMOOS) , из одногоERDDAP™в родительской организации (Например, IOOS Central) , от все-NOAA ERDDAP™, Всеамериканское федеральное правительствоERDDAP™, от глобальногоERDDAP™ (ГУС) , и из специализированныхERDDAPs (Например,ERDDAP™Институт, посвященный исследованиям HAB) , по существу мгновенно и эффективно, поскольку только метаданные передаются междуERDDAPs, а не данные. В лучшем случае после первоначальногоERDDAP™В первоначальной организации все остальныеERDDAPможно быстро настроить (Несколько часов работы) с минимальными ресурсами (один сервер, который не нуждается в каких-либо RAID для хранения данных, поскольку он не хранит данные локально) Таким образом, при действительно минимальных затратах. Сравните это со стоимостью создания и обслуживания централизованного центра обработки данных с озером данных и потребностью в действительно массовом, действительно дорогостоящем подключении к Интернету, а также сопутствующей проблемой централизованного центра обработки данных. Для меня,ERDDAPДецентрализованный, федеративный подход намного выше.

В ситуациях, когда дата-центру требуется несколькоERDDAPдля удовлетворения высокого спроса,ERDDAPКонструкция полностью способна соответствовать или превышать производительность многоидентичной системы.ERDDAPs-with-a-load-balancer подход. У вас всегда есть возможность настроитьмногокомпонентныйERDDAPs (как обсуждалось ниже) Каждый из них получает свои данные от других.ERDDAPs, без балансировки нагрузки. В этом случае я рекомендую вам уделить внимание каждому из композитов.ERDDAPs другое имя/идентификацию и, если возможно, размещение их в разных частях мира; (Например, различные регионы AWS.) Например,ERD\US\East,ERDСША, Запад,ERD\IE,ERD\_FR,ERDIT, чтобы пользователи сознательно, неоднократно, работали с конкретнымиERDDAPС дополнительным преимуществом, что вы удалили риск из одной точки отказа.  

Сети, кластеры и федерации

При очень интенсивном использовании один отдельныйERDDAP™Войдет в один или несколькоограниченияперечисленных выше, и даже предлагаемых решений будет недостаточно. Для таких ситуаций,ERDDAP™имеет функции, которые позволяют легко создавать масштабируемые сетки (Также называется кластерами или федерациями.) изERDDAPs, которые позволяют системе справляться с очень тяжелым использованием; (Например, для большого центра обработки данных) .

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

Основная идея разработки масштабируемой системы состоит в том, чтобы определить потенциальные узкие места, а затем спроектировать систему так, чтобы части системы могли быть воспроизведены по мере необходимости, чтобы облегчить узкие места. В идеале каждая реплицированная часть линейно увеличивает емкость этой части системы. (Эффективность масштабирования) . Система не масштабируема, если нет масштабируемого решения для каждого узкого места.масштабируемостьотличается от эффективности (Как быстро можно выполнить задачу — эффективность деталей) . Масштабируемость позволяет системе расти и справляться с любым уровнем спроса. Эффективность (Скриншоты Scaling and Of The Parts) определяет, сколько серверов и т.д. потребуется для удовлетворения заданного уровня спроса. Эффективность очень важна, но всегда имеет свои пределы. Масштабируемость является единственным практическим решением для создания системы, которая может работать. очень интенсивное использование. В идеале система будет масштабируемой и эффективной.

Цели

Целями этого дизайна являются:

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

Рекомендации

Наши рекомендации являются

• По сути, я предлагаю создать композицию.ERDDAP™ ( D на диаграмме) которая является регулярнойERDDAP™Кроме того, он служит только для данных из других источников.ERDDAPС. Архитектура сетки призвана сместить как можно больше работы. (Использование CPU, использование памяти, использование полосы пропускания) Из композитаERDDAP™к другомуERDDAPС.
• ERDDAP™имеет два специальных типа данных,EDDGridИз ЭрддапаиEDDTable FromErddapкоторый ссылается на наборы данных на другихERDDAPС.
• Когда композитныйERDDAP™получает запрос на данные или изображения из этих наборов данных,ERDDAP™ перенаправлятьЗапрос данных к другомуERDDAP™Сервер. Результатом является:
  • Это очень эффективно (CPU, память и пропускная способность) Потому что иначе
    1. КомпозитныйERDDAP™должен отправить запрос данных другомуERDDAP.
    2. ДругойERDDAP™должен получить данные, переформатировать их и передать данные в композитныйERDDAP.
    3. КомпозитныйERDDAP™должен получать данные (Использование дополнительной полосы пропускания) Переформатировать его (Использование дополнительного времени процессора и памяти) и передавать данные пользователю (Использование дополнительной полосы пропускания) . Перенаправляя запрос данных и позволяя другомуERDDAP™Чтобы отправить ответ непосредственно пользователю, композитныйERDDAP™По сути, не тратит время процессора, память или пропускную способность на запросы данных.
  • Перенаправление является прозрачным для пользователя независимо от клиентского программного обеспечения. (браузер или любое другое программное обеспечение или инструмент командной строки) .

Сетчатые части

Частью сетки являются:

А. : Для каждого удаленного источника данных с высокой пропускной способностьюOPeNDAPВы можете подключиться непосредственно к удаленному серверу. Если удаленный сервер являетсяERDDAP™использоватьEDDGridEDDTable FromErddap или EDDTable FromERDDAPОбслуживание данных в КомпозитеERDDAP. Если удаленный сервер имеет другой типDAPсервер, например, THREDDS,Hyraxили GrADS, использоватьEDDGridОт Депа.

B Для каждогоERDDAPисточник данных (источник данных, из которогоERDDAPМожет читать данные) Если у вас есть сервер с высокой пропускной способностью, установите другойERDDAP™в сети, которая отвечает за обслуживание данных из этого источника данных.

• Если несколько такихERDDAPs не получает много запросов на данные, вы можете объединить их в одинERDDAP.
• ЕслиERDDAP™Для получения данных из одного удаленного источника требуется слишком много запросов, есть соблазн добавить дополнительные.ERDDAPs для доступа к удаленному источнику данных. В особых случаях это может иметь смысл, но более вероятно, что это перегрузит удаленный источник данных. (Что саморазрушительно) Предотвращение доступа других пользователей к удаленному источнику данных (Что не очень приятно) . В таком случае рассмотрите возможность создания другогоERDDAP™для обслуживания этого одного набора данных и копирования набора данных на этотERDDAPжесткий диск (смотреть C ) Возможно, сEDDGridКопияи/илиEDDTableCopy.
• B Серверы должны быть общедоступными.

C Для каждогоERDDAP-мобильный источник данных, имеющий сервер с низкой пропускной способностью (медленная работа по другим причинам) Подумайте о создании другогоERDDAP™и хранить копию набора данных об этомERDDAPЖесткие диски, возможно, сEDDGridКопияи/илиEDDTableCopy. Если несколько такихERDDAPs не получает много запросов на данные, вы можете объединить их в одинERDDAP. C Серверы должны быть общедоступными.

композитныйERDDAP

D : КомпозитныйERDDAP™является регулярнойERDDAP™Кроме того, он служит только для данных из других источников.ERDDAPС.

• Потому что композитныйERDDAP™имеет информацию в памяти обо всех наборах данных, может быстро реагировать на запросы о списках наборов данных; (Полный текстовый поиск, поиск по категориям, список всех наборов данных) , а также запросы на индивидуальную форму доступа к данным, сделать графическую форму илиWMSСтраница информации. Все это небольшие, динамически генерируемые HTML-страницы на основе информации, хранящейся в памяти. Поэтому ответы очень быстрые.
• Поскольку запросы на фактические данные быстро перенаправляются на другие.ERDDAPs, составнойERDDAP™Он может быстро реагировать на запросы на фактические данные без использования какого-либо времени процессора, памяти или пропускной способности.
• Перекладывая как можно больше работы (ЦП, память, пропускная способность) Из композитаERDDAP™к другомуERDDAPs, составнойERDDAP™Может показаться, что он обслуживает данные из всех наборов данных и все же не отстает от очень большого количества запросов данных от большого числа пользователей.
• Предварительные испытания показали, что составERDDAP™Он может отвечать на большинство запросов в ~ 1 мс процессорного времени или 1000 запросов в секунду. 8-ядерный процессор должен отвечать на 8000 запросов в секунду. Хотя можно представить всплески более высокой активности, которые вызовут замедление, это большая пропускная способность. Вполне вероятно, что пропускная способность центра обработки данных будет узким местом задолго до композита.ERDDAP™становится узким местом.

Современный max (время) ?

TheEDDGrid/TableFromErddap в составеERDDAP™только изменяет сохраненную информацию о каждом наборе исходных данных, когда набор исходных данных"перезагрузить"и некоторые изменения метаданных (Например, переменная времениactual\_range) , тем самым генерируя уведомление о подписке. Если исходный набор данных содержит данные, которые часто меняются (Новые данные каждую секунду) и использует"обновить"системы, чтобы замечать частые изменения базовых данных,EDDGrid/TableFromErddap не будет уведомлен об этих частых изменениях до следующей «перезагрузки» набора данных.EDDGridТаблица FromErddap не будет полностью обновлена. Вы можете минимизировать эту проблему, изменив исходный набор данных.<ПерезагрузкаEveryNMinutes> в меньшую величину (60? 15?) Чтобы было больше уведомлений о подписке, чтобы сообщитьEDDGrid/TableFromErddap обновляет свою информацию об исходном наборе данных.

Или, если ваша система управления данными знает, когда исходный набор данных имеет новые данные. (Например, через скрипт, который копирует файл данных на место) Если это не очень частое (каждые 5 минут или реже) Есть лучшее решение:

1. Не используйте<ОбновлениеEveryNMillis> для обновления набора исходных данных.
2. Установите исходный набор данных<ПерезагрузкаEveryNMinutes> в большее число (1440?) .
3. Пусть сценарий свяжется с исходным набором данныхфлаг URLСразу после этого он копирует новый файл данных на место. Это приведет к тому, что исходный набор данных будет полностью обновлен и заставит его генерировать уведомление о подписке, которое будет отправлено на веб-сайт.EDDGrid/TableFromErddap набор данных. Это приведет кEDDGrid/TableFromErddap Dataset будет полностью обновлен (В течение 5 секунд будут добавлены новые данные) . И все это будет сделано эффективно (Без ненужных перезагрузок набора данных) .

МногокомпонентныйERDDAPs

• В крайних случаях или при отказоустойчивости вы можете установить более одного композитного устройства.ERDDAP. Вполне вероятно, что другие части системы (В частности, пропускная способность центра обработки данных) Это станет проблемой задолго до появления композитного материала.ERDDAP™становится узким местом. Таким образом, решение, вероятно, заключается в создании дополнительных, географически разнообразных центров обработки данных. (зеркала) Каждый из них с одним составнымERDDAP™и серверов сERDDAPs и (по крайней мере) зеркальные копии наборов данных, которые пользуются большим спросом. Такая установка также обеспечивает отказоустойчивость и резервное копирование данных (С помощью копирования) . В этом случае лучше всего, если композитныйERDDAPУ них разные URL.

Если вы действительно хотите все композитыERDDAPs, чтобы иметь тот же URL, используйте систему переднего конца, которая присваивает данному пользователю только один из составных элементов.ERDDAPs (на основе IP-адреса) , так что все запросы пользователя идут только на один из составныхERDDAPС. Есть две причины:

• При перезагрузке базового набора данных и изменении метаданных (Например, новый файл данных в сетчатом наборе данных вызывает временную переменнуюactual\_rangeменяться) Композитный составERDDAPs будет временно немного не синхронизирован, но сПоследующая согласованность. Обычно они будут синхронизироваться в течение 5 секунд, но иногда это будет дольше. Если пользователь создает автоматизированную систему, которая опирается наERDDAP™подпискаЭто приводит к тому, что краткосрочные проблемы синхронности становятся значительными.
• Композит 2+ERDDAPКаждый имеет свой собственный набор подписок. (из-за описанной выше проблемы синхронизации) .

Таким образом, данный пользователь должен быть направлен только на один из составных элементов.ERDDAPчтобы избежать этих проблем. Если один из составныхERDDAPs идет вниз, система переднего конца может перенаправитьERDDAPПользователи для другогоERDDAP™Вот так. Однако, если это проблема емкости, которая вызывает первый состав.ERDDAP™провалиться (Чрезмерный пользователь? аатака типа "отказ в обслуживании"?) Это делает очень вероятным, что перенаправляет своих пользователей на другие составные устройства.ERDDAPЭто приведет ккаскадный отказ. Таким образом, наиболее надежной установкой является композитнаяERDDAPС разными URL.

Или, возможно, лучше создать несколько композитов.ERDDAPs без балансировки нагрузки. В этом случае вы должны указать на то, что каждый изERDDAPs другое имя/идентификацию и, если возможно, размещение их в разных частях мира; (Например, различные регионы AWS.) Например,ERD\US\East,ERDСША, Запад,ERD\IE,ERD\_FR,ERDIT, чтобы пользователи осознанно, неоднократно работали с конкретнымиERDDAP.

• \[Для увлекательного дизайна высокопроизводительной системы, работающей на одном сервере, см.Подробное описание Mailinator.\]

Наборы данных в очень высоком спросе

В очень необычном случае один из А. , B или C ERDDAPs не может идти в ногу с запросами из-за ограничений пропускной способности или жесткого диска, имеет смысл копировать данные (снова) На другом сервере + Hard Drive+ERDDAPВозможно, сEDDGridКопияи/илиEDDTableCopy. Хотя может показаться идеальным иметь исходный набор данных, а скопированный набор данных отображается как один набор данных в составе.ERDDAP™Это сложно, потому что два набора данных будут в разных состояниях в разное время. (В частности, после того, как оригинал получает новые данные, но до того, как скопированный набор данных получает свою копию.) . Поэтому я рекомендую, чтобы наборам данных давали несколько разные названия. (Например, "... (Копия #1) "и"... (Копия #2) "или, возможно," (Зеркало # n ) "или" (Сервер # n ) ") и отображаются как отдельные наборы данных в составеERDDAP. Пользователи привыкли видеть спискизеркальные сайтына популярных сайтах загрузки файлов, поэтому это не должно удивлять или разочаровывать их. Из-за ограничений пропускной способности на данном сайте может иметь смысл разместить зеркало на другом сайте. Если зеркальная копия находится в другом центре обработки данных, доступ только к композитной копии этого центра обработки данныхERDDAP™Различные названия (Например, "зеркало #1) В этом нет необходимости.

Рейды против обычных жестких дисков

Если большой набор данных или группа наборов данных не используются в значительной степени, может иметь смысл хранить данные на RAID, поскольку он обеспечивает отказоустойчивость и вам не нужна вычислительная мощность или пропускная способность другого сервера. Но если набор данных широко используется, может иметь смысл копировать данные на другом сервере.ERDDAP™+ жесткий диск (аналогичныйЧто делает Google) Вместо того, чтобы использовать один сервер и RAID для хранения нескольких наборов данных, вы можете использовать оба сервера + жесткий диск +ERDDAPs в сетке до тех пор, пока один из них не выйдет из строя.

неудачи

Что произойдет, если...

• Существует множество запросов на один набор данных (Например, все учащиеся одновременно запрашивают аналогичные данные.) ? ТолькоERDDAP™Обслуживание этого набора данных будет перегружено и замедлять или отклонять запросы. КомпозитныйERDDAP™и другиеERDDAPЭто не повлияет. Поскольку ограничивающим фактором для данного набора данных в системе является жесткий диск с данными. (неERDDAP) Единственное решение (Немедленно) сделать копию набора данных на другом сервере+hardDrive+ERDDAP.
• Ан А. , B или C ERDDAP™провал (Например, отказ жесткого диска) ? Только набор данных (s) обслуживаемых этимERDDAP™затронуты. Если набор данных (s) Отражается на другом сервере +hardDrive +ERDDAPЭффект минимальный. Если проблема заключается в отказе жесткого диска на уровне 5 или 6 RAID, вы просто замените диск и попросите RAID восстановить данные на диске.
• КомпозитныйERDDAP™провал? Если вы хотите создать систему с оченьвысокая доступностьВы можете установитьмногокомпонентныйERDDAPs (Как обсуждалось выше) Используя что-то вродеNGINXилиТраефикДля балансировки нагрузки. Обратите внимание, что данный составERDDAP™Они могут обрабатывать большое количество запросов от большого количества пользователей. запросы на метаданные малы и обрабатываются информацией, которая находится в памяти; Запросы данных (который может быть большим) перенаправляется ребенкуERDDAPС.

Простой, масштабируемый

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

Пропускная способность

Обратите внимание на примерную пропускную способность часто используемых компонентов системы:

компонент	Приблизительная пропускная способность (GBytes/s)
Память DDR	2,5
Диск SSD	1 1
Жесткий диск SATA	0,3
Гигабитный Ethernet	0,1
ОК-12	0,06
ОК-3	0,015
T1	0,0002

Один жесткий диск SATA (0,3 ГБ/с) На одном сервере с однимERDDAP™Может насытить Gigabit Ethernet LAN (0,1 ГБ/с) . Один Gigabit Ethernet LAN (0,1 ГБ/с) Вероятно, может насытить подключение к Интернету OC-12. (0,06 ГБ/с) . И по крайней мере один источник перечисляет линии OC-12 стоимостью около 100 000 долларов в месяц. (Да, эти расчеты основаны на том, чтобы довести систему до предела, что нехорошо, потому что приводит к очень вялым реакциям. Но эти расчеты полезны для планирования и балансировки частей системы.) Очевидно, что подходящее быстрое подключение к Интернету для вашего центра обработки данных является самой дорогой частью системы. Вы можете легко и относительно дешево построить сеть с десятком серверов, работающих на десятке.ERDDAPs, который способен быстро выкачивать много данных, но достаточно быстрое подключение к Интернету будет очень и очень дорогим. Частичные решения:

• Поощряйте клиентов запрашивать подмножества данных, если это все, что необходимо. Если клиенту нужны данные только для небольшого региона или с меньшим разрешением, то он должен запросить их. Поднастройка является центральным направлением протоколовERDDAP™Поддержка для запроса данных.
• Поощрять передачу сжатых данных.ERDDAP™ компресспередача данных, если она находит «принятое кодирование» вHTTP GETЗапросить заголовок. Все веб-браузеры используют «принять-кодирование» и автоматически декомпрессируют ответ. Другие клиенты (Например, компьютерные программы) должны использовать его явно.
• Сосредоточьте свои серверы на интернет-провайдере или другом сайте, который предлагает относительно менее дорогие расходы на пропускную способность.
• Рассредоточьте серверы вместе сERDDAPs различным учреждениям, с тем чтобы расходы распределялись. Вы можете связать свой композитERDDAP™к ихERDDAPС.

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

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

Как Legos

Разработчики программного обеспечения часто стараются использоватьшаблоны проектирования программного обеспечениядля решения проблем. Хорошие модели хороши, потому что они инкапсулируют хорошие, простые в создании и работе решения общего назначения, которые приводят к системам с хорошими свойствами. Имена шаблонов не стандартизированы, поэтому я назову шаблон, которыйERDDAP™Используется модель Lego. Каждый Lego (каждыйERDDAP) простой, маленький, стандартный, автономный, кирпич (сервер данных) с определенным интерфейсом, который позволяет связать его с другими LEGO (ERDDAPs) . части которыхERDDAP™В состав этой системы входят: системы подписки и flagURL. (что позволяет осуществлять связь междуERDDAPs) В ЭДД... Система перенаправления FromErddap и системаRESTfulзапросы на данные, которые могут генерироваться пользователями или другимиERDDAPС. Таким образом, дается два или более лего (ERDDAPs) Вы можете создать огромное количество различных форм. (Топологии сетиERDDAPs) . Конечно, дизайн и особенностиERDDAP™Это можно было сделать по-другому, а не по-лего, возможно, просто для того, чтобы включить и оптимизировать одну конкретную топологию. Но мы чувствуем, чтоERDDAPLego-подобный дизайн предлагает хорошее универсальное решение, которое позволяетERDDAP™администратор (или группы администраторов) Создание различных топологий федерации. Например, одна организация может создать три (или более) ERDDAPкак показано вERDDAP™Сетка/кластер выше. Распределенная группа (ИУОС? Береговая охрана? НЦЭИ? НВС?NOAA? USGS? Датаон? Днём? LTER? OOI? BODC? ONC? JRC? ВМО?) Можно установить одинERDDAP™В каждом маленьком форпосте (Данные могут находиться рядом с источником) После чего установить составERDDAP™Центральный офис с виртуальными наборами данных (которые всегда идеально актуальны) от каждого небольшого форпостаERDDAPС. Воистину, всеERDDAPs, установленные в различных учреждениях по всему миру, которые получают данные из другихERDDAPs и/или предоставлять данные другимERDDAPСформировать гигантскую сетьERDDAPС. Насколько это круто?! Так что, как и в случае с Lego, возможности бесконечны. Вот почему это хорошая модель. Вот почему это хороший дизайн дляERDDAP.

Различные типы запросов

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

• Многие запросы просты. Например: Каковы метаданные для этого набора данных? Или: Каковы значения временного измерения для этого сетчатого набора данных?ERDDAP™Они предназначены для того, чтобы работать с ними как можно быстрее (как правило, в любой точке мира).<=2 мс), сохраняя эту информацию в памяти.  
• Некоторые запросы умеренно жесткие. Например: Дайте мне это подмножество набора данных (который находится в одном файле данных) . Эти запросы можно обрабатывать относительно быстро, потому что они не так сложны.  
• Некоторые запросы являются сложными и, следовательно, требуют много времени. Например: Дайте мне это подмножество набора данных (который может быть в любом из 10 000+ файлов данных или может быть из сжатых файлов данных, каждый из которых занимает 10 секунд для декомпрессии) .ERDDAP™v2.0 представил несколько новых, более быстрых способов обработки этих запросов, в частности, позволив потоку обработки запросов породить несколько рабочих потоков, которые решают различные подмножества запроса. Но есть и другой подход к этой проблеме, которыйERDDAP™Подмножества файлов данных для данного набора данных могут храниться и анализироваться на отдельных компьютерах, а затем результаты объединяются на исходном сервере. Такой подход называетсяMapReduceи иллюстрируетсяHadoop, первый (?) Программа MapReduce с открытым исходным кодом, которая была основана на идеях из статьи Google. (Если вам нужен MapReduceERDDAPПожалуйста, отправьте электронный запрос наerd.data at noaa.gov.) GoogleBigQueryИнтересно, потому что это, кажется, реализация MapReduce применяется к поднастройке табличных наборов данных, который является одним изERDDAPОсновные цели. Вполне вероятно, что вы можете создатьERDDAP™Набор данных от BigQuery черезEDDTable FromDatabaseBigQuery можно получить через интерфейс JDBC.

Это мое мнение.

Да, расчеты упрощены. (Теперь немного датирован) Но я думаю, что выводы правильные. Я использовал неверную логику или ошибся в расчетах? Если это так, то виноват только я. Пожалуйста, отправьте электронное письмо с исправлениемerd dot data at noaa dot gov.

Облачные вычисления

Несколько компаний предлагают услуги облачных вычислений (например,Amazon Web ServicesиGoogle Cloud Platform) .Веб-хостинговые компанииНачиная с середины 1990-х годов, «облачные» сервисы значительно расширили гибкость систем и спектр предлагаемых услуг. С тех порERDDAP™Сетка состоит только изERDDAPС и с тех порERDDAPs являютсяJavaВеб-приложения, которые могут работать в Tomcat (Самый распространенный сервер приложений) или других серверов приложений, относительно легко настроитьERDDAP™сеть на облачном сервисе или веб-хостинге. Преимуществами этих услуг являются:

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

Недостатками этих услуг являются:

• Они платят за свои услуги, иногда много. (в абсолютном выражении; не то, что это не является хорошей ценностью) . Цены, указанные здесь, дляAmazon EC2. Эти цены (По состоянию на июнь 2015) Он спустится. В прошлом цены были выше, но файлы данных и количество запросов были меньше. В будущем цены будут ниже, но файлы данных и количество запросов будет больше. Детали меняются, но ситуация остается относительно постоянной. И дело не в том, что сервис завышен, а в том, что мы используем и покупаем большую часть сервиса.
  • Передача данных — передача данных в систему теперь бесплатна (Да!) . Передача данных из системы составляет $0,09/GB. Один жесткий диск SATA (0,3 ГБ/с) На одном сервере с однимERDDAP™Может насытить Gigabit Ethernet LAN (0,1 ГБ/с) . Одна гигабитная Ethernet LAN (0,1 ГБ/с) Вероятно, может насытить подключение к Интернету OC-12. (0,06 ГБ/с) . Если одно соединение OC-12 может передавать ~ 150 000 ГБ / месяц, затраты на передачу данных могут составлять до 150 000 ГБ @ 0,09 / ГБ = 13 500 долларов / месяц, что является значительной стоимостью. Ясно, если у вас дюжина трудолюбивыхERDDAPЕсли вы используете облачный сервис, ваши ежемесячные сборы за передачу данных могут быть значительными. (до $162 000 в месяц) . (Опять же, дело не в том, что услуга завышена, а в том, что мы используем и покупаем много услуг.)
  • Хранение данных — Amazon взимает 50 долларов в месяц за ТБ. (Сравните это с покупкой корпоративного диска объемом 4 ТБ за 50 долларов США / ТБ, хотя RAID добавляет административные расходы к общей стоимости.) Поэтому, если вам нужно хранить много данных в облаке, это может быть довольно дорого. (Например, 100 ТБ будет стоить 5000 долларов в месяц.) . Но если у вас нет действительно большого количества данных, это меньше, чем затраты на передачу данных. (Опять же, дело не в том, что услуга завышена, а в том, что мы используем и покупаем много услуг.)
     

Подстановка

• Проблема подмножества: Единственный способ эффективно распространять данные из файлов данных - это иметь программу, которая распределяет данные. (например,ERDDAP) работает на сервере, который имеет данные, хранящиеся на локальном жестком диске (быстрый доступ к SAN или локальному рейду;) . Локальные файловые системы позволяютERDDAP™ (и базовые библиотеки, такие как netcdf-java) Запрашивать конкретные байты из файлов и получать ответы очень быстро. Многие типы запросов данныхERDDAP™к файлу (Особенно сетчатые запросы данных, где значение шага > 1 1) не может быть выполнена эффективно, если программа должна запросить весь файл или большие куски файла из нелокального (Следовательно, медленнее) Система хранения данных, а затем извлечение подмножества. Если облако не выдаетERDDAP™быстрый доступ к байтовым диапазонам файлов (Как и в случае с локальными файлами) ,ERDDAPДоступ к данным будет серьезным узким местом и сведет на нет другие преимущества использования облачного сервиса.

Хостинг данных

Альтернатива вышеуказанному анализу затрат (который основан на данных владельца (например,NOAA) платить за хранение своих данных в облаке) Это произошло в 2012 году, когда Amazon (В меньшей степени это касается других облачных провайдеров.) начал размещать некоторые наборы данных в своем облаке (AWS S3) бесплатно (Вероятно, с надеждой, что они смогут возместить свои расходы, если пользователи будут арендовать экземпляры вычислений AWS EC2 для работы с этими данными.) . Очевидно, что это делает облачные вычисления гораздо более экономически эффективными, потому что время и стоимость загрузки данных и их размещения теперь равны нулю. сERDDAP™v2.0, есть новые функции для облегчения работыERDDAPВ облаке:

• А теперьEDDGridНабор данных FromFiles или EDDTableFromFiles может быть создан из файлов данных, которые удалены и доступны через Интернет. (Например, ведра AWS S3) используя<CashFromUrl> и<кэшировать GB> варианты.ERDDAP™Поддерживает локальный кэш из недавно использованных файлов данных.
• Теперь, если какие-либо исходные файлы EDDTableFromFiles сжаты (например,.tgz) ,ERDDAP™Они автоматически декомпрессируются при их прочтении.
• Теперь,ERDDAP™поток, отвечающий на данный запрос, будет порождать рабочие потоки для работы над подразделами запроса, если вы используете<nThreads> опции. Такая параллелизация должна позволить быстрее реагировать на сложные запросы.

Эти изменения решают проблему AWS S3, не предлагающего локальное хранилище файлов на уровне блоков. (старый) Проблема доступа к данным S3, имеющим значительное отставание. (Много лет назад (2014) Это отставание было значительным, но теперь оно намного короче и не столь существенно.) В целом, это означает, что созданиеERDDAP™Сейчас в облаке работает намного лучше.

Спасибо. — Большое спасибо Мэтью Арротту и его группе за их работу по созданиюERDDAP™В облаке и последующее обсуждение.  

Удаленная репликация наборов данных

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

• Быстрые обновления Трудно поддерживать локальный набор данных в актуальном состоянии немедленно (Например, в течение 3 секунд) после каждого изменения источника, а не, например, в течение нескольких часов.  
• Частые изменения С частыми изменениями сложнее справиться, чем с редкими. Например, с однодневными изменениями гораздо легче справиться, чем с изменениями каждые 0,1 секунды.  
• Небольшие изменения С небольшими изменениями в исходном файле сложнее справиться, чем с совершенно новым. Это особенно актуально, если небольшие изменения могут быть в любом месте файла. Небольшие изменения сложнее обнаружить и затруднить изоляцию данных, которые необходимо реплицировать. Новые файлы легко обнаружить и эффективно передавать.  
• Весь набор данных Сохранение всего набора данных в актуальном состоянии сложнее, чем сохранение только последних данных. Некоторым пользователям нужны свежие данные (Например, стоимость последних 8 дней) .  
• Несколько копий Сохранение нескольких удаленных копий на разных сайтах сложнее, чем сохранение одной удаленной копии. Это проблема масштабирования.  

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

относящийсяERDDAP™Инструменты

ERDDAP™предлагает несколько инструментов, которые могут быть использованы как часть системы, которая стремится поддерживать удаленную копию набора данных:

• ERDDAP?RSS (Резюме сайта Rich?) обслуживание
  предлагает быстрый способ проверить, есть ли набор данных на удаленном устройствеERDDAP™Изменился.  
• ERDDAP?подписной сервис
  является более эффективным (чемRSS) Подход: он немедленно отправит электронное письмо или свяжется с URL-адресом каждому подписчику, когда набор данных будет обновлен, и обновление приведет к изменению. Это эффективно в том, что это происходит как можно скорее, и нет никаких потраченных усилий. (Как и в случае с опросомRSSобслуживание) . Пользователи могут использовать другие инструменты (какIFTTT) реагировать на уведомления электронной почты от системы подписки. Например, пользователь может подписаться на набор данных на удаленном устройстве.ERDDAP™и использовать IFTTT для реагирования на уведомления о подписке по электронной почте и запуска обновления локального набора данных.  
• ERDDAP?флаговая система
  Предоставляет способ дляERDDAP™администратор, чтобы сообщить набор данных о своемERDDAPПерезагрузить как можно скорее. Форму URL флага можно легко использовать в скриптах. Форма URL флага также может использоваться в качестве действия для подписки.  
• ERDDAP?"files"система
  может предлагать доступ к исходным файлам для заданного набора данных, включая каталог в стиле Apache. («Веб-доступная папка») который имеет URL загрузки каждого файла, последнее измененное время и размер. Одним из недостатков использования"files"Система заключается в том, что исходные файлы могут иметь разные имена переменных и разные метаданные, чем набор данных, как он появляется вERDDAP. Если удаленныйERDDAP™Набор данных предлагает доступ к исходным файлам, что открывает возможность rsync-версии бедного человека: локальной системе становится легко увидеть, какие удаленные файлы изменились и их нужно загрузить. (Видишь?Опция FromUrlНиже вы можете использовать это.)
   

Решения

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

Системные требования Brute Force Solutions

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

• Пользовательские решения – это большая работа.
• Пользовательские решения, как правило, настолько настроены на данный набор данных и систему пользователя, что их нелегко использовать повторно.
• Пользовательские решения должны быть построены и поддерживаться вами. (Это никогда не бывает хорошей идеей. Всегда полезно избегать работы и заставлять кого-то делать работу!)

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

рысь

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

1. какое-то событие (Например,ERDDAP™Событие системы подписки) триггеры, запускающие rsync, (или, работа cron работает в определенное время каждый день на компьютере пользователя)

2. который контактирует с rsync на исходном компьютере,

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

4. который сравнивает эту информацию с аналогичной информацией для копии файлов пользователя,

5. который затем запрашивает куски файлов, которые изменились.

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

Основными недостатками rsync являются: требуется некоторое усилие для настройки. (Вопросы безопасности) ; есть некоторые проблемы масштабирования; и это не хорошо для поддержания наборов данных NRT в актуальном состоянии (Например, неудобно использовать rsync более чем каждые 5 минут.) . Если вы можете справиться с недостатками или если они не влияют на вашу ситуацию, rsync - отличное решение общего назначения, которое любой может использовать прямо сейчас для решения многих сценариев, связанных с удаленной репликацией наборов данных.

Есть пункт наERDDAP™Чтобы сделать список, чтобы попытаться добавить поддержку услуг rsyncERDDAP (Вероятно, довольно сложная задача) Для того, чтобы любой клиент мог использовать (или вариант) поддерживать актуальную копию набора данных. Если кто-то хочет работать над этим, пожалуйста, по электронной почтеerd.data at noaa.gov.

Есть и другие программы, которые делают больше или меньше того, что делает rsync, иногда ориентированные на репликацию набора данных. (Хотя часто на уровне копирования файлов) Например,Unidata?IDD.

Кэш из Url

Кэш FromUrlНастройка доступна (Начиная сERDDAP™v2.0) Для всехERDDAPТипы наборов данных, которые делают наборы данных из файлов (В основном, все подклассыEDDGridИз материаловиEDDTable Из материалов) . кэш FromUrl позволяет автоматически загружать и поддерживать локальные файлы данных, копируя их из удаленного источника через кэш. Из Урла. Удаленные файлы могут быть в папке Web Accessible Folder или каталог-подобном списке файлов, предлагаемом THREDDS.Hyrax, ведро S3 илиERDDAP?"files"система.

Если источник удаленных файлов удаленERDDAP™набор данных, который предлагает исходные файлы черезERDDAP™ "files"Система, тогда вы можетеподписыватьдля удаленного набора данных и использоватьфлаг URLдля вашего локального набора данных в качестве действия для подписки. Затем, когда удаленный набор данных изменится, он свяжется с URL-адресом флага для вашего набора данных, который сообщит ему перезагрузить ASAP, который будет обнаруживать и загружать измененные удаленные файлы данных. Все это происходит очень быстро (обычно ~5 секунд плюс время, необходимое для загрузки измененных файлов;) . Этот подход отлично работает, если изменения набора исходных данных представляют собой периодические добавления новых файлов и когда существующие файлы никогда не меняются. Этот подход не работает хорошо, если данные часто прилагаются ко всем. (или большинство) существующих исходных файлов данных, потому что тогда ваш локальный набор данных часто загружает весь удаленный набор данных. (Именно здесь необходим подход, похожий на ритм.)

Архив данных

ERDDAP™?Архив данныхЭто хорошее решение, когда данные часто добавляются в набор данных, но старые данные никогда не меняются. В основном, анERDDAP™Администратор может запускать ArchiveADataset (Возможно, в сценарии, возможно, под управлением Крона.) и указать подмножество набора данных, которые они хотят извлечь (Возможно, в нескольких файлах) и упаковывается в.zipили.tgzфайл, чтобы вы могли отправить файл заинтересованным людям или группам; (Например, NCEI для архивирования) или сделать его доступным для скачивания. Например, вы можете запускать ArchiveADataset каждый день в 12:10 утра..zipиз всех данных с 12:00 утра предыдущего дня до 12:00 утра сегодня. (Делайте это еженедельно, ежемесячно или ежегодно, по мере необходимости.) Поскольку упакованный файл генерируется в автономном режиме, нет опасности тайм-аута или слишком большого количества данных, как это было бы для стандарта.ERDDAP™просьба.  

ERDDAP™Стандартная система запросов

ERDDAP™Стандартная система запросов является альтернативным хорошим решением, когда данные часто добавляются в набор данных, но старые данные никогда не меняются. По сути, любой может использовать стандартные запросы для получения данных в течение определенного периода времени. Например, в 12:10 вы можете сделать запрос на все данные из удаленного набора данных с 12:00 предыдущего дня до 12:00 сегодня. Ограничение (По сравнению с подходом ArchiveADataset) Это риск тайм-аута или слишком много данных для одного файла. Вы можете избежать ограничений, делая более частые запросы на меньшие периоды времени.  

EDDTable FromHttpGet

\[Такой вариант пока не существует, но, кажется, его можно построить в ближайшее время.\]
НовыйEDDTable FromHttpGetтип набора данных вERDDAP™v2.0 позволяет представить другое решение. Базовые файлы, поддерживаемые этим типом набора данных, по существу являются файлами журнала, которые записывают изменения в набор данных. Должна быть возможность создания системы, которая поддерживает локальный набор данных периодически. (или на основе триггера) запросить все изменения, внесенные в удаленный набор данных с момента последнего запроса. Это должно быть столь же эффективным (или более) Он будет работать только в том случае, если удаленные и локальные наборы данных являются EDDTableFromHttpGet.

Если кто-то хочет работать над этим, пожалуйста, свяжитесь с намиerd.data at noaa.gov.

Распределенные данные

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

Есть отличное решение: даже не пытайтесь воспроизвести данные. Используйте авторитетный источник (Один набор данных на одинERDDAP) поддерживается поставщиком данных (Например, региональный офис) . Все пользователи, которым нужны данные из этого набора данных, всегда получают их из источника. Например, браузерные приложения получают данные из запроса на основе URL, поэтому не имеет значения, что запрос исходный на удаленном сервере. (Не тот же сервер, который размещает ESM) . Многие люди уже давно поддерживают этот подход к распределенным данным. (Рой Мендельсон в течение последних 20+ лет) .ERDDAPМодель сетки/федерации (80% этого документа) основывается на таком подходе. Это решение похоже на меч для Гордианского узла — вся проблема уходит.

• Это решение потрясающе простое.
• Это решение потрясающе эффективно, так как не делается никакой работы для сохранения реплицированного набора данных. (s) современный.
• Пользователи могут получить последние данные в любое время. (Например, с задержкой всего ~ 0,5 секунды) .
• Он довольно хорошо масштабируется, и есть способы улучшить масштабирование. (Смотрите обсуждение в верхней части 80% этого документа.)
   

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

Заключение

Пока нет единого, простого решения, которое идеально решает все проблемы во всех сценариях. (как rsync и распределенные данные) Мы надеемся, что есть достаточно инструментов и вариантов, чтобы вы могли найти приемлемое решение для вашей конкретной ситуации.