跳转到主内容

缩放

ERDDAP™- 重载、网格、集群、联合会和云计算​

 

ERDDAP数字 :

ERDDAP™是一种网络应用程序和网络服务,它集聚了来自不同本地和远程来源的科学数据,提供了一种简单、一致的方式,以共同的文件格式下载数据子集,并制作图表和地图。 本网页讨论与重型ERDDAP™通过电网、集群、联合会和云计算处理极其沉重的负荷的可能性。

原版于2009年6月写成. 没有重大变化。 这是最后一次更新 2019-04-15.

分会​

这个网页的内容是鲍勃·西蒙斯的个人观点,并不一定反映政府或政府的任何立场。National Oceanic and Atmospheric Administration。 。 。 计算是简单的,但我认为结论是正确的。 我用错逻辑还是计算错误? 如果是这样,那是我的错。 请发送带有更正的电子邮件至erd dot data at noaa dot gov。 。 。 。  

    • 说吧

重载/限制​

大量使用,一个独立ERDDAP™将会受到限制 (从最有可能到最小可能) 通过:

远程源带宽​

  1. 远程数据源的带宽——即使是高效连接 (例如,通过OPeNDAP) 除非远程数据源有很高的带宽 互联网连接,ERDDAP反应会受到速度的限制ERDDAP™可以从数据源获取数据。 一个解决方案是将数据集复制到ERDDAP硬盘,也许与EDDGrid复制或EDD 表格复制。 。 。 。  

ERDDAP服务器宽度​

  1. 除非我们...ERDDAP其服务器有非常高的带宽 互联网连接,ERDDAP反应会受到速度的限制ERDDAP™能够从数据源获取数据,并有多快ERDDAP™可返回数据给客户端。 唯一的解决方案是获得更快的互联网连接.  

内存​

  1. 如果同时有许多请求ERDDAP™可以耗尽内存并暂时拒绝新的请求. (ERDDAP™有一些机制可以避免这种情况,并尽可能减少发生这种情况的后果。) 所以服务器内存越多越好. 在32位服务器上,4+GB真的很好,2GB是好的,更少的不推荐. 在64位服务器上,通过获得大量的内存,几乎可以完全避免这个问题. 见\- Xmx 和 - Xms 设置(单位:千美元)ERDDAP汤姆猫 一个ERDDAP™在计算机上获得大量使用,拥有一个64位服务器,内存为8GB和-Xmx设定为4000M,即使有,也很少受到内存的限制.  

驱动带宽​

  1. 访问存储在服务器硬盘上的数据比访问远程数据要快得多. 虽然如此,如果ERDDAP™服务器具有非常高的带宽互联网连接,在硬盘上访问数据有可能是一个瓶颈. 部分解决方案是更快使用 (例如,10,000卢比) 磁硬盘或 SSD 驱动器 (如果成本合理的话) 。 。 。 另一种解决办法是在不同的驱动器上存储不同的数据集,这样累积的硬盘带宽就会高得多.  

太多文件缓存​

  1. 一个文件太多缓存目录 -ERDDAP™缓存所有图像,但只缓存某些类型数据请求的数据。 一个数据集的缓存目录有可能暂时拥有大量文件. 这将拖慢查看文件是否在缓存中的请求 (痷!) 。 。 。 。<缓存 分钟( G) :设置. xml允许您在删除文件前设定文件在缓存中的时间。 如果确定数量较少,这一问题就会最小化。  

CPU 软件​

  1. 只有两件事需要大量CPU时间:
    • NetCDF经常预算:HDF5现在支持内部压缩数据. 解压缩大型压缩器NetCDF4个HDF5个数据文件需要10秒或更多秒. (这不是一个执行错误。 压缩的性质.) 因此,对存储在压缩文件中的数据的数据集的多次同时请求会给任何服务器造成严重压力. 如果这是一个问题,解决方案是将流行的数据集存储在未压缩文件中,或者获得一个拥有更多核心的CPU的服务器.
    • 绘制图表 (包括地图) :每个图约0.2 - 1秒. 因此,如果有许多同时 独特的图请求 (WMS客户经常同时提出6项请求!) ,可能存在CPU限制. 当多个用户运行时WMS客户,这是个问题。  
    • 说吧

多个相同的ERDDAP负载平衡?​

这个问题经常出现:"为了应付沉重的负载,我可以设置多个相同的ERDDAP与负载平衡?" 这是一个有趣的问题,因为它迅速到达核心ERDDAP设计 快速回答是"不". 我知道这是一个令人失望的答案,但有一些直接原因和一些更大的根本原因,我设计ERDDAP™采用不同的办法 (联邦ERDDAPs,本文件大部分部分所述。) 我认为这是一个更好的解决方案。

一些直接原因,你无法/不应该设置多个相同的ERDDAP标准是:

  • 给定ERDDAP™读取每个数据文件,当它首次可用时,以便查找文件中的数据范围。 然后在索引文件中存储这些信息。 后来,当用户请求获得数据时,ERDDAP™使用该索引来查找需要的数据。 如果有多个相同的ERDDAPs,他们各自会做这个索引,这是浪费的努力。 根据下文所述的联邦制,索引编制工作只有一次,由其中一人完成。ERDDAP编号
  • 某些类型的用户请求 (例如,用于.nc, png, .pdf 文件) ERDDAP™在回复发送前,必须制作全部文件。 这么说ERDDAP™短时间缓存这些文件 。 如果收到同样的请求 (正如它经常做的那样,特别是对于嵌入网页的 URL 图像) , (中文).ERDDAP™可以重用缓存文件。 在多个相同的系统中ERDDAPs,这些缓存文件不共享,所以每个ERDDAP™将不必要和浪费地重建.nc, .png, 或.pdf文件. 根据下文所述的联邦制度,档案只由其中一人制作一次。ERDDAPs,并重新使用。
  • ERDDAP订阅系统不是由多个共享的ERDDAP编号 例如,如果负载平衡器将用户发送到一个ERDDAP™并用户订阅一个数据集,然后是另一个ERDDAPS不会知道 订阅。 后来,如果负载平衡器将用户发送到不同的ERDDAP™并索取订阅单,其他ERDDAP™将说没有 (导致他/她重复订阅另一个EREDDAP) 。 。 。 采用下文所述的联邦制,订阅系统仅由主要、公共、综合部门处理。ERDDAP。 。 。 。

是的,对于这些问题,我可以 (以极大的努力,) 设计解决方案 (以在ERDDAP编号) 但我认为联合会ERDDAPS 方针 (本文件主要部分叙述) 这是一个更好的总体解决办法,部分原因是它处理其他问题,即多种同种-ERDDAPs-加载-平衡方法甚至没有开始解决,特别是世界上数据来源的分散性质。

最好接受一个简单的事实 即我不是设计的ERDDAP™以多种相同方式部署ERDDAPs带有负载平衡器. 我自觉设计ERDDAP™在联邦范围内开展良好工作ERDDAPs,我认为这有很多优点。 特别是,一个联合会ERDDAPs与我们现实世界中分散分布的数据中心系统完全一致 (考虑不同的IOOS区域,或者不同的海岸观察区域,或者NCEI的不同部分,或者100个其他数据中心.NOAA或全球1000个数据中心) 。 。 。 而不是告诉世界所有数据中心 他们需要放弃努力 把他们的所有数据放进集中的"数据湖" (即使有可能,但出于许多原因,这是一个可怕的想法 -- -- 见各种分析,这些分析显示:权力下放的系统) , (中文).ERDDAP其设计与世同效. 产生数据的每一个数据中心可以继续维护、整理和服务其数据。 (他们应该) ,然而,与ERDDAP™数据也可以通过集中式的ERDDAP,不需要将数据传送给中央ERDDAP™或存储重复的数据副本。 事实上,一个数据集可以同时提供 从 aERDDAP™在制作和实际存储数据的组织 (例如,GOMOS) , (中文). 从 aERDDAP™在上级组织 (例如,IOOS中心) , (中文). 从所有...NOAA ERDDAP™, (中文). 从全美联邦政府ERDDAP™, (中文). 从全球范围ERDDAP™ (海鸥) , (中文). 专业人员ERDDAP编号 (例如,aERDDAP™专门从事HAB研究的机构) , (中文). 基本上都是瞬间有效的,因为只有元数据在ERDDAPs,不是数据. 最好在开始之后ERDDAP™在原组织,所有其他ERDDAPs可以快速设置 (几个小时的工作) ,但资源极少 (一个不需要任何RAID来存储数据的服务器,因为它没有在本地存储数据) ,因此成本确实很低。 与此相比,建立和维护一个带有数据湖的集中数据中心的成本,以及真正大规模,真正昂贵的互联网连接的必要性,再加上集中数据中心是一个单一故障点的问题. 对我来说ERDDAP分权的、联合的办法是远远的,远远优越的。

在某一数据中心需要多个数据的情况下ERDDAP满足高需求,ERDDAP其设计完全能够匹配或超过多同-的性能.ERDDAPS -A -A -平衡器方法。 你总是有选择设置多种复合ERDDAP编号 (如下所述) ,每个数据都来自其他ERDDAPs,没有负载平衡. 在这种情况下,我建议你提出一点 给每个复合体ERDDAP不同名称/身份,如果可能的话,在世界不同地区建立 (例如,不同AWS区域) 例如,ERD东部,ERD韦斯特,ERD\_,ERD法语,ERDQQIT,使用户有意识地,反复地,与特定的ERDDAP,加上您已经从一个失败点上消除了风险的额外好处。  

    • 说吧

网格、集群和联合会 ​

在非常重的使用下,一个单独的ERDDAP™将遇到一个或多个制约以上所列,甚至所建议的解决办法都是不够的。 在这种情况下,ERDDAP™具有便于构建可伸缩网格的特性 (也称为集群或联合会) 页:1ERDDAPs 允许系统处理非常重的使用 (例如,一个大型数据中心) 。 。 。 。

我用着网格作为一般术语,以表示一类计算机集群所有部件可能或可能不实际位于一个设施,可能或可能不集中管理。 合用同一地点、集中拥有和管理电网的优势 (分组) 他们从规模经济中获益 (特别是人的工作量) 并简化系统各部分的运作。 非共用电网、非中央所有和管理的优势 (联合会) 即它们分配人的工作量和费用,并可能提供额外的容错能力。 下面我提出的解决方案对于所有网格,群集,和联邦地形都非常有效.

设计可缩放系统的基本思想是找出潜在的瓶颈,然后设计系统,以便系统的某些部分可以按需要复制来缓解瓶颈. 理想的情况是,每个复制部分都线性地提高系统这一部分的能力。 (缩放效率) 。 。 。 除非每个瓶颈都有可扩展的解决方案,否则系统是无法伸缩的.可缩放性与效率不同 (如何迅速完成任务——各部分的效率) 。 。 。 可伸缩性使系统能够成长,处理任何水平的需求. 效率 (缩放量和) 确定需要多少服务器等来满足特定水平的需求。 效率非常重要,但总是有限度。 可扩展性是建立能够处理问题的系统的唯一实际解决办法。 非常喜欢 严重使用。 理想的情况是,该系统将可扩展和高效。

目标​

这一设计的目标是:

  • 做一个可伸缩的建筑 (通过复制任何负担过重的部分容易扩展的) 。 。 。 建立一个高效率的系统,在可获得的计算资源条件下,最大限度地增加数据的可用性和吞吐量。 (费用几乎总是一个问题。)
  • 为了平衡系统各部分的能力,使系统的一个部分不会压倒另一个部分.
  • 使建筑结构简单,使系统易于设置和管理.
  • 使一个建筑与所有格子地形都很好使用.
  • 如果某一部分变得负担过重,则使这种制度以优雅和有限的方式失败。 (复制一个大数据集所需的时间将永远限制系统应付对特定数据集的需求突然增加的能力.)
  • (如果可能的话) 做一个与任何特定建筑无关的建筑云计算服务或其他外部服务 (因为它不需要它们) 。 。 。 。

建议​

我们的建议是 网格/组图

  • 基本上,我建议建立一个综合ERDDAP™ ( D级 在图表中) ,这是常规ERDDAP™但是它只服务于其他数据ERDDAP编号 电网的建筑设计 尽可能转移工作 (CPU的使用、内存使用、带宽使用) 从复合ERDDAP™给对方的ERDDAP编号
  • ERDDAP™有两个特殊的数据集类型,EDDGrid从埃尔达普和来自Erddap的EDD表,指 其他数据集ERDDAP编号
  • 当组合ERDDAP™请求从这些数据集获取数据或图像ERDDAP™ 重定向对对方的数据请求ERDDAP™服务器。 结果是:
    • 这很有效率 (CPU、内存和带宽) 因为不然
      1. 综合说明ERDDAP™必须将数据请求发送给对方ERDDAP。 。 。 。
      2. 另一个ERDDAP™必须获取数据,重塑数据,并将数据传送到复合数据ERDDAP。 。 。 。
      3. 综合说明ERDDAP™必须收到数据 (使用额外的带宽) ,重塑它 (使用额外的 CPU 时间和内存) ,并将数据传送给用户 (使用额外的带宽) 。 。 。 通过重定向数据请求并允许对方ERDDAP™将响应直接发送给用户,复合ERDDAP™基本上不花费CPU的时间、内存或带宽处理数据请求。
    • 重定向对用户透明, 不管客户端软件如何 (浏览器或任何其他软件或命令行工具) 。 。 。 。

网格部件​

电网部分为:

页:1 数字 : 对于每个具有高波段宽度的远程数据源OPeNDAP服务器,您可以直接连接到远程服务器。 如果远程服务器是ERDDAP™编辑EDDGrid从 Erddap 或 EDD 表格ERDDAP为复合数据服务ERDDAP。 。 。 如果远程服务器是其它类型DAP服务器,例如THREDDS,Hyrax,或GrADS,使用EDDGrid从达普.

页:1 : 每张ERDDAP- 可读数据源 (数据来源,ERDDAP可以读取数据) 它有一个高频宽服务器, 设置另一个ERDDAP™用于提供来自此数据源的数据的网格。

  • 如果有几项ERDDAP数据请求不多 你可以把它们合并成一个ERDDAP。 。 。 。
  • 如果ERDDAP™专门从一个远程来源获取数据的请求太多,因此增加额外数据的诱惑力很大。ERDDAPs 访问远程数据源。 在特殊情况下,这可能有意义,但更有可能使远程数据源被覆盖 (这是自欺欺人) 并阻止其他用户访问远程数据源 (这可不好) 。 。 。 在这种情况下,考虑设立另一个ERDDAP™以服务于该数据集并复制该数据集ERDDAP硬盘 (见 C级 ) ,也许与EDDGrid复制和(或)EDD 表格复制。 。 。 。
  • 页:1 服务器必须向公众开放。

C级 : 每张ERDDAP- 具有低带宽服务器的可读数据源 (或由于其他原因服务缓慢) ,考虑设立另一个ERDDAP™并存储其中的数据集副本ERDDAP硬盘,也许有EDDGrid复制和(或)EDD 表格复制。 。 。 。 如果有几项ERDDAP数据请求不多 你可以把它们合并成一个ERDDAP。 。 。 。 C级 服务器必须向公众开放。

复合ERDDAP​

D级 数字 : 综合说明ERDDAP™是一个常规ERDDAP™但是它只服务于其他数据ERDDAP编号

  • 因为综合ERDDAP™拥有关于所有数据集的内存信息,它可以快速响应对数据集列表的请求 (全文搜索、分类搜索、所有数据集列表) ,以及请求单个数据集的数据访问表,制作图表表,或WMS信息页面。 这些都是基于内存中保存的信息的小型、动态生成的 HTML 页面。 所以反应非常迅速。
  • 因为对实际数据的要求很快被重定向到另一个ERDDAPs, 综合数ERDDAP™可以在不使用任何CPU时间,内存,或带宽的情况下迅速响应对实际数据的请求.
  • 尽可能多地转移工作 (CPU、内存、带宽) 从复合ERDDAP™给对方的ERDDAPs, 综合数ERDDAP™似乎可以服务于所有数据集的数据,但仍能跟上大量用户提出的大量数据要求。
  • 初步试验显示,复合材料ERDDAP™可以在 CPU 时间 ~ 1ms 中响应大多数请求,或 1000 个请求/秒. 因此,一个8个核心处理器应该能够响应大约8000个请求/秒. 虽然可以预见到活动会增加,从而造成减速,但这是大量的吞吐量。 数据中心带宽很可能在复合材料之前就成为瓶颈ERDDAP™成为瓶颈。
最新最多数 (时间) ? 。 。 。​

那个EDDGrid组合图中的Erddap表格ERDDAP™仅在源数据集为时更改其存储的关于每个源数据集的信息"重装"和一些元数据变化 (例如,时间变量的actual\_range) ,从而生成订阅通知。 如果源数据集的数据经常变化 (例如,每秒有新数据) 并使用"更新"系统注意到基础数据经常变化,EDDGrid/Table FromErddap不会被通知这些频繁的更改,直到下一个数据集"重装",所以EDDGrid/表 从Erddap不会完全更新。 您可以通过更改源数据集的<将 EveryNiminutes & gt; 重新装入到一个较小的值 (60岁?) 以便有更多的订阅通知告知EDDGrid/Table FromErddap来更新关于源数据集的信息.

或者,如果您的数据管理系统知道源数据集是否有新数据 (例如,通过复制数据文件的脚本) 如果这不是超频繁的 (例如,每5分钟,或频率较低) ,有一个更好的解决方案:

  1. 别用<更新EveryNMILIS>以保持源数据集的更新.
  2. 设置源数据集<将 EveryNiminutes & gt; 重装到更大的数 (1440号?) 。 。 。 。
  3. 让脚本联系源数据集旗帜 URL复制到新数据文件后立即生效。 这将导致源数据集完全更新,并导致其生成订阅通知。EDDGrid/表从Erddap数据集. 这将会导致EDDGrid/ Table from Erddap 数据集要完美更新 (5秒内,新的数据被添加) 。 。 。 和所有将会高效完成的工作 (无需重新装入数据集) 。 。 。 。

多重复合ERDDAP编号​

  • 在非常极端的情况下,或者为了容错,你可能想要设置一个以上的复合体.ERDDAP。 。 。 该系统的其他部分很可能 (特别是,数据中心的带宽) 将会成为一个问题 早在综合ERDDAP™成为一个瓶颈。 因此,解决方案可能是建立更多,地域多样,数据中心 (镜像) ,每个组合ERDDAP™和服务器ERDDAPs 和 (起码) 镜像数据集副本,这些数据集的需求很高。 这种设置还提供故障容错度和数据备份 (通过复制) 。 。 。 在这种情况下,最好是综合ERDDAPs有不同的 URL 。

如果你真的想要所有的复合材料ERDDAPs 要拥有相同的 URL,请使用前端系统,将给定的用户分配到一个复合件ERDDAP编号 (基于 IP 地址) ,这样用户的所有请求都只到其中的一个复合ERDDAP编号 有两个原因:

  • 当一个基础数据集重新装入和元数据变化时 (例如,网格数据集中的新数据文件导致时间变量的actual\_range更改) 组合ERDDAPs会暂时略微脱离同步,但与最终一致性。 。 。 通常情况下,它们会在5秒内重排,但有时会更长. 如果用户创建了依赖于ERDDAP™订阅短暂的同步性问题将变得严重。
  • 2+ 组合ERDDAPs 各自维持自己的一套订阅 (由于上述同步问题) 。 。 。 。

因此,给定的用户应该被引导到一个复合体ERDDAP避免这些问题。 如果其中一种复合ERDDAPs下降,前端系统可以重定向ERDDAP用户到另一个ERDDAP™就是这样 但是,如果能力问题造成第一个综合问题ERDDAP™失败 (一个过于热闹的用户? (单位:千美元)拒绝服务攻击? 。 。 。) ,这很可能使其用户转向其他复合体ERDDAPs 将导致串联失败。 。 。 因此,最强壮的设置是综合ERDDAPs 具有不同的URL.

或者,也许更好,设置多种复合ERDDAPs 没有负载平衡。 在这种情况下,你应该提出一点 给每一个ERDDAP不同名称/身份,如果可能的话,在世界不同地区建立 (例如,不同AWS区域) 例如,ERD东部,ERD韦斯特,ERD\_,ERD法语,ERDQQIT , 以便用户有意识地, 重复使用特定ERDDAP。 。 。 。

高需求数据集​

在非常不寻常的情况下, 其中一个 页:1 , (中文). 页:1 ,或 C级 ERDDAPs由于带宽或硬盘限制,无法跟上请求,复制数据是有道理的 (再来一次) 打开另一个服务器+硬 驱动器+ERDDAP,也许与EDDGrid复制和(或)EDD 表格复制。 。 。 虽然将原始数据集和复制数据集作为复合材料中的一个数据集无缝地显示似乎很理想ERDDAP™,这很困难,因为两个数据集在不同时间会处于略微不同的状态. (特别是,在原始数据获得新数据后,但在复制的数据集获得副本之前) 。 。 。 因此,我建议数据集的标题略有不同。 (例如, " ... (复制 # 1) 和","还有. (复制 # 2) " 或也许 " (镜子 无 ) " 或 " (服务器 # 无 ) " , ") 并将其作为单独的数据集出现在复合材料中ERDDAP。 。 。 用户习惯于查看镜像站点在流行的文件下载网站, 所以这不应该出乎意料或让他们失望。 由于某一站点的带宽限制,将镜像放置在另一个站点可能是合理的. 如果镜像复制件位于不同的数据中心, 只需该数据中心的复合件即可访问ERDDAP™,不同的标题 (例如,"Mirror #1") 没必要

RAIDs 相对常规硬盘​

如果一个大型数据集或一组数据集没有大量使用,那么将数据存储在RAID上可能会有道理,因为它提供了断层耐受性,并且由于你不需要另一个服务器的处理功率或带宽. 但如果一个数据集被大量使用,将数据复制到另一个服务器+可能更合理.ERDDAP™+ 硬盘 (类似谷歌会做什么) 而不是使用一个服务器和一个RAID来存储多个数据集,因为您可以使用两个服务器+hardDrive+ERDDAPs在网格,直到其中之一失败。

失败​

如果... 会怎么样?

  • 一个数据集的请求激增 (例如,一个班级的所有学生同时要求类似的数据) ? 。 。 。 只有ERDDAP™服务于该数据集将超载、减速或拒绝请求。 综合说明ERDDAP™其他项目ERDDAPs不会受到影响。 由于系统中某一数据集的限制因素是带有数据的硬盘 (没有ERDDAP) ,唯一的解决方案 (非即时) 是在不同的服务器上复制一个数据集+hardDrive+ERDDAP。 。 。 。
  • 一个 页:1 , (中文). 页:1 ,或 C级 ERDDAP™失败 (例如,硬盘故障) ? 。 。 。 只有数据集 (编号) 服务于此ERDDAP™受影响。 如果数据集 (编号) 在另一个服务器上镜像+hardDrive+ERDDAP,效果微乎其微。 如果问题在于5或6级RAID中的硬盘故障,那么你只需要更换驱动器,让RAID重建驱动器上的数据.
  • 综合说明ERDDAP™失败? 如果你想建立一个系统 与非常高可用性,你可以设置多种复合ERDDAP编号 (上文讨论过的) 使用类似的东西纳吉林克斯或特拉菲克语Name处理负载平衡。 注意某一复合材料ERDDAP™能够处理大量用户提出的大量请求,因为 元数据请求小,由内存中的信息处理, 请求提供数据 (可能是大块的) 重定向给孩子ERDDAP编号

简单, 可缩放​

这一系统很容易建立和管理,在其中任何部分负担过重时也很容易扩展。 特定数据中心唯一的实际限制是数据中心的带宽和系统的成本.

带宽​

注意系统常用部件的大致带宽:

|构成部分|近似带宽 (GBytes/s 数字) | |- - - 说吧|- - - 说吧| |DDR 内存|2.5 对| |SSD 驱动器|页:1| |SATA 硬盘|0.3 (韩语)| |盖加比特以太网|0.1 (中文(简体) ).| |OC-12 (中文(简体) ).|0.06 (英语).| |OC-3号|0.015 (简体中文).| |T1 电话|0.0002 亿|

所以,一个SATA硬盘 (0.3GB/s (单位:千美元)) 一个服务器上ERDDAP™可能饱和 Gigabit 以太网局域网 (0.1GB/s (单位:千兆赫)) 。 。 。 和一个Gigabit以太网局域网 (0.1GB/s (单位:千兆赫)) 可能饱和 OC- 12 互联网连接 (0.06GB/s (英语).) 。 。 。 而至少有一个来源列出OC-12线路每月耗资约10万美元. (是的,这些计算是基于将系统推向极限,这不好,因为它导致反应非常迟缓。 但是,这些计算对于规划和平衡系统的某些部分是有用的.) 显然,你数据中心的互联网连接速度非常快 是系统最昂贵的部分 你可以轻而易举地搭建一个网格 有十几台服务器在运行ERDDAPs能够迅速抽出大量数据,但适当快速的互联网连接将非常非常昂贵。 部分解决办法是:

  • 鼓励客户要求提供数据子集,如果这是所需要的。 如果客户端只需要一个小区域或更低的分辨率的数据,那就是他们应该要求的数据. 子设定是协议的中心焦点ERDDAP™支持请求数据。
  • 鼓励传输压缩数据.ERDDAP™ 压缩如果发现“接受编码”在HTTP GET请求标题。 所有网页浏览器都使用"accept-encoding",并自动解压响应. 其他客户 (例如,计算机程序) 必须明确使用它。
  • 在ISP或其他能提供相对较低成本带宽成本的网站凝结您的服务器.
  • 以ERDDAPs) 向不同机构支付费用。 然后可以链接您的复合材料ERDDAP™成员名单ERDDAP编号

请注意:云计算和网络托管服务提供所有你需要的互联网带宽,但不要解决价格问题.

关于设计可伸缩、容量大、容错系统的一般信息,见Michael T. Nygard的书释放它。 。 。 。

像乐高​

软件设计师经常尝试用好软件设计模式用来解决问题。 良好的模式是好的,因为它们封装好的,容易创造和工作,通用的解决方案导致具有良好属性的系统. 模式名称没有标准化,所以我会称之为模式ERDDAP™使用乐高模式。 每个乐高 (每个ERDDAP) 是一个简单、小、标准、独立、砖块 (数据服务器) 带有定义的界面,允许它与其他 legos 连接 (ERDDAP编号) 。 。 。 。 内容ERDDAP™这个系统包括: 订阅和旗下URL系统 (能够相互沟通ERDDAP编号) 电磁脉冲 从Erddap重定向系统和RESTful用户或其他用户可生成的数据请求ERDDAP编号 因此,给予两个或两个以上的legos (ERDDAP编号) ,可以创建大量不同的形状 (网络地形ERDDAP编号) 。 。 。 当然,设计和特征ERDDAP™本来可以做不同的, 而不是乐高式的, 也许只是为了让一个特定的地形学能够和优化。 但我们觉得ERDDAP类似乐高的设计提供了良好的通用解决方案,使任何一种ERDDAP™管理员 (或一组管理员) 创造各种不同的联邦地形。 例如,一个组织可以设立三个组织。 (或超过) ERDDAPs 如ERDDAP™上方网格/组合图。 。 。 。 或分布的团体 (iOOS(英语:IOOS)? 海岸观察? NEEI(国家教育局)? 无武器?NOAA? 。 。 。 国务院? 数据ONE? 近地点? LTER吗? 呜? BODC吗? ONC ONC? ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC ONC. JRC吗? 气象组织?) 可以设置一个ERDDAP™每个小前哨站 (这样数据就可以靠近源头) 然后建立一个复合体ERDDAP™使用虚拟数据集的中央办公室 (总是完美更新的) 从每个小前哨站ERDDAP编号 事实上,所有ERDDAPs,安装于世界各地的各种机构,这些机构从其他机构获取数据。ERDDAP和/或向其他机构提供数据ERDDAPs,形成一个巨大的网络ERDDAP编号 这有多酷? 所以,和乐高一样,可能性是无限的. 这就是为什么这是一个很好的模式。 这就是为什么这是一个很好的设计ERDDAP。 。 。 。

不同类型的请求​

这种数据服务器地形学讨论的现实生活中的复杂问题之一是,对不同类型的请求有不同的类型和不同的优化方式. 这主要是个单独的问题 (这么快就能ERDDAP™数据响应数据要求?) 从地形学讨论 (处理数据服务器之间的关系, 而哪个服务器拥有实际数据) 。 。 。 。ERDDAP™当然,试图有效地处理所有类型的请求,但处理一些比其他更好的请求。

  • 许多请求很简单。 例如: 此数据集的元数据是什么 ? 或者:这个网格化数据集的时间维度值是什么?ERDDAP™目的是尽快处理这些(通常在<=2 ms)通过将这些信息保存在内存中.  
  • 有些请求有些困难。 例如: 给我这个数据集的子集 (它在一个数据文件中) 。 。 。 这些请求可以相对迅速地处理,因为它们并不困难.  
  • 有些请求很困难,因此耗费时间。 例如: 给我这个数据集的子集 (可能包含在10,000+数据文件中,或者可能来自压缩数据文件中,每个压缩数据文件需要10秒解压缩) 。 。 。 。ERDDAP™v2.0引入了一些新的、更快的方法来处理这些请求,特别是允许请求处理线程生成若干工人线程,处理请求的不同子集。 但有另一种办法解决这一问题,即ERDDAP™尚不支持:可以将某一数据集的数据文件子集存储和分析到单独的计算机上,然后将结果合并到原始服务器上。 这种方法叫做地图并表现为:哈多普语Name,第一个 (? 。 。 。) 开源的MapReduce程序,它基于谷歌的一篇论文中的想法. (如果您需要地图ERDDAP请发送电子邮件请求到erd.data at noaa.gov。 。 。 。) 谷歌的音乐大查询有趣的是,它似乎是用于子设置表格数据集的MapReduce的实现,而该数据集是其中之一。ERDDAP主要目标。 很可能你可以创建一个ERDDAP™从大查询数据集通过数据库中的 EDD 表格因为大查询可以通过JDBC接口访问.

这就是我的看法。​

是的,计算是简单的 (现在稍稍过时) 但我认为结论是正确的 我用错逻辑还是计算错误? 如果是这样,那是我的错。 请发送带有更正的电子邮件至erd dot data at noaa dot gov。 。 。 。

    • 说吧

云计算 ​

若干公司提供云计算服务 (例如,亚马逊网络服务和谷歌云平台) 。 。 。 。网络托管公司自1990年代中期以来就提供了更简单的服务,但“云”服务大大扩大了系统的灵活性和所提供的服务范围。 自从ERDDAP™网格仅包含ERDDAPs 及自此以来ERDDAP这是Java可在Tomcat运行的网络应用程序 (最常用的应用程序服务器) 或其他应用服务器,应相对容易设置ERDDAP™网格在云服务或网站托管网站上。 这些服务的好处是:

  • 它们提供非常高的带宽互联网连接。 仅此即可证明使用这些服务是合理的。
  • 他们只收你的服务费 例如,您可以访问非常高的带宽互联网连接,但您只支付实际传输的数据。 让你建立一个很少被压抑的系统 (即使在高峰期的需求) ,无需支付很少使用的能力。
  • 它们很容易扩展。 您可以在不到一分钟的时间里更改服务器类型,或添加尽可能多的服务器或存储量。 仅此即可证明使用这些服务是合理的。
  • 他们免除了你管理服务器和网络的许多行政职责。 仅此即可证明使用这些服务是合理的。

这些服务的缺点是:

  • 他们的服务费,有时很多 (绝对值,不是说不是好值) 。 。 。 。 这里列出的价格是用来亚马逊EC2。 。 。 。 这些价格 (截止2015年6月) 会下来的 过去,价格较高,但数据文件和请求数量较少。 未来价格会更低,但数据文件和请求数量会更大. 因此细节变化,但情况保持相对稳定. 并不是服务价格过高,而是我们正在使用和购买许多服务。
    • 数据传输——数据传输进入系统现已免费. (没错!) 。 。 。 。 系统外数据传输为0.09/GB. 一个SATA硬盘 (0.3GB/s (单位:千美元)) 一个服务器上ERDDAP™可能饱和 Gigabit 以太网局域网 (0.1GB/s (单位:千兆赫)) 。 。 。 。 一个Gigabit 以太网局域网 (0.1GB/s (单位:千兆赫)) 可能饱和 OC- 12 互联网连接 (0.06GB/s (英语).) 。 。 。 。 如果一个OC-12连接可以传输~15万GB/月,数据传输成本可能高达15万GB@0.09/GB=13,500美元/月,这是一个巨大的成本. 很明显,如果你有一打辛苦工作ERDDAPs在云服务上, 您的月数据传输费可能很大 (每月最多162 000美元) 。 。 。 。 (也不是服务价格过高 而是我们使用和购买了很多服务)
    • 数据存储——亚马逊每TB收费50美元/月. (与购买一家4TB企业相比,直接开销为~50/TB,尽管RAID将其投入其中,行政费用增加了总成本。) 所以,如果你需要 存储大量的数据在云, 它可能相当昂贵 (例如,100TB将花费5 000美元/月) 。 。 。 但是除非你拥有大量的数据, 这比带宽/数据传输成本要小。 (也不是服务价格过高 而是我们使用和购买了很多服务)
       

分区​

  • 子设定问题 : 有效分发数据文件数据的唯一方法是拥有分发数据的程序 (例如,ERDDAP) 在存储本地硬盘数据的服务器上运行 (或类似的快速访问 SAN 或 当地RAID) 。 。 。 。 允许本地文件系统ERDDAP™ (以及基础图书馆,例如netcdf-java) 请求特定字节从文件中选择范围,并很快得到回复。 许多类型的数据请求来自ERDDAP™转到文件 (特别是网格数据请求,其中斜率值 > 页:1) 如果程序需要从非本地文件请求整个文件或一个文件的大块,则无法有效完成 (因此慢一点) 数据存储系统,然后提取子集。 如果云层布置不给ERDDAP™快速访问文件的字节范围 (和本地文件一样快) , (中文).ERDDAP获取数据将是一个严重的瓶颈,否定使用云服务的其他好处。

主机数据​

上述成本效益分析的替代办法 (它基于数据所有者 (例如,NOAA) 支付数据存储在云中) 2012年左右抵达亚马逊 (在较小的程度上,一些其他云提供者) 开始在其云中托管一些数据集 (AWS S3 导弹) 免费 (如果用户租用AWS EC2计算实例与这些数据合作,他们可能希望能够收回费用) 。 。 。 显然,这使得云计算成本效益大大提高,因为上传数据和托管数据的时间和成本现在是零。 与ERDDAP™v2.0, 有促进运行的新功能ERDDAP云何时.

  • 现在,一个EDDGrid从Files或EDDTable FromFiles数据集可以从远程数据文件中创建,可通过互联网访问 (例如,AWS S3桶) 通过使用<从 Url> 缓存<缓存大小 GB> 选项.ERDDAP™将维护最近使用的数据文件的本地缓存。
  • 现在, 如果从 Files 源文件压缩到 EDD Table (例如,.tgz) , (中文).ERDDAP™当他们诵读《古兰经》的时候,《古兰经》将自动地毁灭他们。
  • 现在,ERDDAP™响应给定请求的线程将生成工人线程,以便在请求的分节上工作,如果您使用<nThreads> 选项 。 这种平行性应能够对困难的请求作出更快的反应。

这些修改解决了 AWS S3 不提供本地,块级文件存储和 (旧) 获取S3数据存在严重滞后的问题。 (数年前 (~2014 (中文(简体) ).) ,但现在要短得多,所以没有那么严重。) 总之,这意味着设置ERDDAP™在云中工作现在更好。

谢谢 ——多亏了马修·阿罗特和他的团队在OOI最初的努力中,他们将工作放在:ERDDAP™在云中和由此而来的讨论。  

    • 说吧

数据集的远程复制​

还有一个共同的问题与上述关于电网和联合会的讨论有关。ERDDAPs:数据集的远程复制。 基本问题是:一个数据提供者维护一个偶尔会变化的数据集,而一个用户想要维护一个最新的本地副本这个数据集 (由于各种原因) 。 。 。 显然,这种情况有许多不同之处。 有些变化比其他变化更难处理。

  • 快速更新 更新本地数据集比较困难 马上 (例如,在3秒内) 每次改变源头之后, 而不是,比如在几个小时内。  
  • 频繁变化 频繁的变化比很少的变化更难处理。 例如,每天一次的改变比每0.1秒的改变容易处理得多.  
  • 小变化 对源文件的小改动比全新的文件更难处理. 如果小改动可能在文件中的任何地方,则情况尤其如此。 微小的变化更难发现,也更难孤立需要复制的数据. 新的文件易于发现并高效传输.  
  • 完整数据集 保持整个数据集的更新比保持最近的数据更困难。 有些用户只需要最近的数据 (例如,过去8天的价值) 。 。 。 。  
  • 多个副本 在不同网站保存多个远程副本比保存一个远程副本更难。 这就是缩放问题  

源数据集可能发生的几类变化以及用户的需求和期望显然存在大量的变异. 许多变体很难解决. 一个局势的最好解决办法往往不是另一个局势的最好解决办法——还没有一个普遍的伟大解决办法.

相关ERDDAP™工具 ​

ERDDAP™提供几种工具,作为维护数据集远程副本的系统的一部分:

  • ERDDAP因为RSS (丰富网站摘要?) 服务
    提供了快速检查远程上数据集的方法ERDDAP™已经改变。  
  • ERDDAP因为订阅服务
    更为高效 (超过RSS) 方法:当数据集更新并导致更新时,它将立即向每个用户发送电子邮件或联系URL。 这样做很有效率,因为它是尽快发生的,没有浪费的努力 (投票结果RSS服务) 。 。 。 。 用户可以使用其他工具 (喜欢爱滋) 对订阅系统的电子邮件通知作出反应。 例如,用户可以订阅远程计算机上的数据集ERDDAP™并使用 IFTTT 对订阅邮件通知作出反应,并触发本地数据集的更新。  
  • ERDDAP因为旗帜系统
    提供一种途径,ERDDAP™管理员告诉他/她的数据集ERDDAP尽快重新装入。 旗帜的URL形式在脚本中很容易使用. 旗的URL形式也可以作为订阅的动作.  
  • ERDDAP因为"files"系统
    可以为给定数据集提供对源文件的访问,包括文件的Apache式目录列表 (a "网易文件夹") 它有每个文件的下载 URL,上次修改的时间和大小。 一个缺点是使用"files"系统是源文件可能具有不同的可变名称和不同的元数据,而不是它出现在其中的数据集ERDDAP。 。 。 。 如果一个遥控器ERDDAP™数据集提供了对其源文件的访问,这打开了穷人版本的rsync的可能性:一个本地系统很容易看到哪些远程文件已经改变,需要下载. (见从Url 选项缓存下方可以使用这个。)
     

解决方案​

虽然这一问题存在许多不同之处,而且可能的解决办法也为数不胜枚举,但只有少数基本的解决办法:

自定义、 残酷的强制解决方案​

一个明显的解决方案是手动自定义解决方案,因此对特定情况进行了优化:制作一个检测/识别哪些数据已经改变的系统,并将这些信息发送给用户,以便用户可以请求更改的数据. 你可以做到这一点,但有缺点:

  • 自定义解决方案是很多工作。
  • 自定义解决方案通常被定制到给定的数据集和给定的用户系统,以至于无法轻易被重新使用.
  • 自定义解决方案必须由您建立和维护 。 (这不是一个好主意。 避免工作,找别人做工作,这总是个好主意!)

我劝阻采取这种做法,因为寻找由他人建立和维持的一般解决办法几乎总是更好的,这种解决办法可以很容易地在不同情况下再利用。  

红外线​

红外线是现有的,令人惊叹的好,通用的解决方案,在用户的远程计算机上保持源计算机上的文件集同步. 其运作方式是:

  1. 一些事件 (例如,aERDDAP™订阅系统活动) 触发运行 rsync, (或者,一个 cron 工作每天在特定时间运行 rsync 在用户的计算机上)
  2. 在源计算机上联系rsync,
  3. 用于计算每个文件块的一系列散列,并将这些散列传递给用户的rsync,
  4. 将这些信息与用户文件副本的类似信息进行比较,
  5. 然后请求更改的文件块。

考虑到它所做的一切, rsync运行非常快 (例如,10秒加数据传输时间) 和非常高效。 有一个rsync 的变量对不同情况进行优化 (例如,通过预先计算和缓冲每个源文件块的散列) 。 。 。 。

rsync的主要弱点是: 需要一些努力来建立 (安全问题) ; 有一些缩放问题; 而且它不利于使 NRT 数据集真正更新 (比如说,每5分钟使用一次以上的rsync就太尴尬了) 。 。 。 如果你能应对这些弱点,或者说它们不会影响你的情况,rsync是一个极好的,通用的解决方案,任何人都可以立刻用来解决许多涉及远程复制数据集的情景.

上面有个东西ERDDAP™要尝试为 rsync 服务添加支持到ERDDAP (可能是一个相当困难的任务) ,使任何客户端能够使用 rsync (或变体) 以保持数据集的最新副本。 如果有人想做这个,请发电子邮件erd.data at noaa.gov。 。 。 。

其他程序多或少做rsync的工作,有时面向数据集复制 (虽然通常在文件复制一级) 例如,Unidata因为缺碘症。 。 。 。

从 Url 缓存​

来自Url的缓存设置可用 (开始ERDDAP™页:1) 为所有人提供ERDDAP从文件生成数据集的数据集类型 (基本上,所有子类EDDGrid从文件和来自文件的 EDD 表格) 。 。 。 缓存 FromUrl 通过缓存将本地数据文件从远程源复制到自动下载和维护使其变得微不足道 从Url设定。 远程文件可以在Web Accessable文件夹或THREDDS提供的类似目录的文件列表中,Hyrax,一个S3桶,或ERDDAP因为"files"系统。

如果远程文件的来源是远程ERDDAP™数据集,通过ERDDAP™ "files"系统,然后你可以订阅,并使用旗帜 URL作为订阅动作的本地数据集。 然后,每当远程数据集更改时,它会联系您的数据集的旗子URL,它会告诉它重新装入ASAP,它会检测和下载已更改的远程数据文件. 这一切发生得很快 (通常~5秒加上下载已修改文件所需的时间) 。 。 。 如果源数据集的更改是定期添加的新文件,当现有文件永远不变时,这种方法就大有效果. 如果数据经常附在所有人身上,这种做法就不会奏效。 (或大多数) ,因为您的本地数据集经常下载整个远程数据集。 (这就是需要一种类似红外线的方法的地方。)

存档 ADataset​

ERDDAP™因为存档 ADataset当数据经常被添加到数据集时,这是一个很好的解决方案,但旧的数据从未被更改。 基本上,一个ERDDAP™管理员可以运行 ArchiveADataset (也许在剧本,也许运行 由cron) 并指定要提取的数据集的子集 (可能在多个文件中) 和软件包.zip或.tgz文件,以便您将文件发送给感兴趣的人或团体 (例如,用于归档的NCEI) 或可供下载。 例如,您可以每天12: 10运行 ArchiveADataset,并让它成为.zip从前一天中午12:00到今天中午12:00的所有数据。 (或者,做这个每周,每月,或每年,根据需要。) 由于被包装的文件是离线生成的,因此不存在超时或数据过多的危险,因为将有一个标准ERDDAP™请求。  

ERDDAP™标准请求系统​

ERDDAP™标准请求系统是数据经常被添加到数据集时的替代好解决方案,但老的数据从未被更改. 基本上,任何人都可以使用标准请求来获取特定时间范围的数据. 例如,每天中午12点10分,你可以从前一天中午12点到今天中午12点从一个远程数据集索取所有数据。 限制 (与 ArchiveADataset 方法相对应) 是一个超时或一个文件的数据过多的风险。 可以通过更频繁地请求缩短时间来避免限制.  

来自 HttpGet 的 EDD 表格​

\[这个选项尚不存在,但似乎可以在不远的将来建造.\]
新的来自 HttpGet 的 EDD 表格数据集类型ERDDAP™v2.0使设想另一种解决办法成为可能。 这类数据集维护的基本文件基本上是记录数据集变化的日志文件. 应该能够建立一个定期维持本地数据集的系统。 (或基于触发) 请求自上次请求以来对远程数据集所做的所有修改。 这同样有效 (或超过) 和 rsync 相比,它会处理许多困难的情景,但只有在远程和本地数据集是 EDDTable FromHttpGet 数据集时才会奏效。

如果有人想做这个 请联系我erd.data at noaa.gov。 。 。 。

分布的数据​

以上所有解决方案都无法解决问题的硬性差异,因为复制几乎实时 (NRT (新唐语)) 数据集非常困难,部分原因是所有可能的情况。

有一个伟大的解决方案: 不要试图复制数据。 相反,使用一个权威来源 (1个数据集ERDDAP) ,由数据提供者维护 (例如,区域办事处) 。 。 。 所有想从该数据集获得数据的用户,总是从源头获得. 例如,基于浏览器的应用程序从基于 URL 的请求中获取数据,所以,请求是到远程服务器上的原始源上并不重要 (并非托管无害环境管理的服务器) 。 。 。 许多人长期主张这种分布式数据方法 (例如,Roy Mendelssohn,过去20年) 。 。 。 。ERDDAP网格/成型模型 (此文档的前80%) 以这种方法为基础。 这个解决方案就像一把剑对着一个Gordian Knot——整个问题消失了.

  • 这种解决办法非常简单。
  • 这一解决方案效率惊人,因为没有为保留一个复制数据集开展工作 (编号) 最新新闻.
  • 用户可以随时获取最新数据 (例如,延迟只有~0.5秒) 。 。 。 。
  • 规模相当大,而且有办法改进规模。 (参见本文前80%的讨论.)
     

不,这不是解决所有可能情况的办法,但对于绝大多数人来说,这是一个伟大的解决办法. 如果在某些情况下这种解决办法有问题/有弱点,往往值得努力解决这些问题或克服这些弱点,因为这种解决办法的惊人优势。 如果/当这个解决方案对于某个特定的情况来说确实不可接受时,例如,当您真的必须有一个本地的数据副本时,那么考虑上面讨论的其他解决方案.  

结论​

虽然没有单一而简单的解决方案能完美地解决所有情景中的所有问题 (数据几乎是) 希望有充足的工具和选择 这样你就可以为自己的特殊情况找到一个可以接受的解决方案