RCSB蛋白质数据库查询和分发系统的质量保证

摘要

介绍

RCSB蛋白质数据库（RCSB PDB）(1)是全球PDB（wwPDB）的成员(2)和它的一个数据分发站点。2009年，该网站(网址：www.pdb.org)平均每月有16.5万名独立访问者使用，他们浏览了1270万个网页，并通过HTTP下载了近1TB的数据。此外，通过FTP和rsync从RCSB PDB下载数据的速度在一年中平均每秒超过7个文件，在最繁忙的一天中平均每秒近87个文件。最近的一项分析表明，2000多个其他网站提供了到RCSB PDB网站的链接。鉴于RCSB PDB服务对结构生物学界和相关科学学科的重要性，我们需要确保服务质量。这篇文章是关于提供这样的服务质量。

与此同时，PDB的规模和复杂性不断增加。PDB中的结构数量在过去5年中大约翻了一番，RCSB PDB网站带宽（传输的数据量）在过去3年中几乎翻了一倍。内容的增长随着时间的推移而加速：2000年，每周大约有50个新结构发布，现在这个速度几乎翻了三倍，每周有近150个新结构。此外，数据增长不仅是定量的，而且数据也变得更加复杂。例如，核糖体等非常大的结构物现在正在更常规的基础上释放；有更多的确定结构的方法，甚至在单一结构确定期间使用混合方法的情况下。

用户期望值也在上升。网络速度的提高和浏览器技术的改进提高了“可接受”网站性能的标准。数据也可以通过越来越多的协议和服务访问：10年前，FTP和HTTP是唯一提供的在线服务（我们也有CD-ROM发行版）；现在，除此之外，还提供了rsync、使用SOAP或RESTful协议的web服务和RSS提要。用户越来越期待Web 2.0类型的功能，这意味着社交书签、视频和其他服务。同样，智能手机和其他移动设备构成了越来越多的客户。

为了满足日益增长的科学期望，将继续添加显著的功能增强(三)例如成对和全面对抗所有结构线形(4)以及开放存取文献的整合(5). 例如，在观察超大结构或蛋白质-配体相互作用方面，结构可视化变得越来越复杂。人们对与其他web资源的集成以及工作流解决方案的启用，而不是简单的数据下载，抱有更高的期望。总之，增长、复杂性和用户期望说明了保持质量保证的挑战。

尽管有这些具体的挑战，信息技术的质量保证通常是一个难题。为什么会这样？正如我们将要看到的，在维护网站时，质量保证有很多组成部分，但最容易发现的问题可能是软件测试。惠特克探讨了为什么软件测试很难的问题(6). 他提出的原因包括软件复杂性、使用场景的几乎无限变化、许多不同的用户界面和操作环境以及缺乏时间和资源来测试所有内容。当然，质量保证远不止是测试(7). 虽然测试可能被视为检测问题的质量控制措施，以便随后进行纠正，但质量保证也首先关注预防问题。此外，运行生物数据库和网站显然涉及硬件和软件，这两个方面将在本文中讨论。

PubMed搜索显示，有关生物数据库和相关网站质量保证的文献相对较少。许多出版物审查了生物数据的质量(8–12). 然而，很少有出版物描述允许访问和探索数据的服务质量。生物医学开源项目质量保证实践调查(13)主要关注软件测试和同行评审。当然，在计算机科学领域有大量关于软件质量保证的文献，其中包括专门针对该主题的整个期刊软件质量期刊(网址：www.springerlink.com/content/0963-9314). 然而，PubMed中并没有对这些文献进行索引，因此生物信息学社区也不太容易获得这些文献。

本文不是关于PDB数据的质量保证，因为其他地方已经对此进行了广泛的描述(14–16). 相反，我们在这里描述了用于确保与分发和查询这些数据相关的服务质量的实践。在本文后面的主要部分中，我们讨论了RCSB PDB的几个质量保证领域：（i）硬件冗余和故障转移；（ii）每周更新数据库；（iii）软件版本；（iv）监测和故障排除工具和实践。随着生物网络资源的数量持续快速增长，一些项目在相关性和突出性方面日趋成熟，我们希望RCSB PDB网站的质量保证案例研究将有助于其他生物数据库和网站开发或扩展自己的“最佳实践”集。

冗余和故障切换

在此，我们将重点放在托管和提供关键RCSB PDB服务的硬件和软件上，如数据库、网站和FTP站点。对于任何一个基础设施来说，问题不是它是否会失败，而是什么时候会失败，这只是常识。此类故障可能是物理设备故障（例如硬盘或主板）或硬件上运行的服务中断（例如服务于网站的挂起的Apache Tomcat进程）。如果此类故障导致关键生产服务中断，我们需要提供冗余解决方案，以及管理从故障硬件或软件到工作硬件或软件的故障切换的后勤。无论维护需要、计划内或计划外停电、数据库或软件更新、自然灾害等情况如何，我们都力争实现100%的正常运行时间，并且实际实现了99.9%以上的正常运行率。我们利用多层物理和后勤冗余来实现这一目标。

多级硬件冗余

现场网站(网址：www.pdb.org)和FTP站点(ftp.wwpdb.org网站)由多个负载平衡服务器同时提供服务。原因不仅包括上述冗余需求，还包括单个服务器可能无法承受峰值流量负载的事实。该网站通常由五台Dell PowerEdge 2950服务器提供服务，每台服务器具有两个四核2.66 GHz Intel Xeon处理器和32 GB RAM。FTP站点由三台Dell Power Edge 1950服务器提供服务。每台服务器都具有两个四核2.5 GHz Intel Xeon处理器，以及8 GB RAM。

上述八台服务器构成了实时生产集群，该集群位于圣地亚哥加州大学圣地亚哥分校（UCSD）圣地亚哥超级计算机中心（SDSC）的机房中。两个较小的集群维护在两个独立的物理位置（分别由两个web服务器和一个FTP服务器组成）。其中一个集群位于加州大学圣迭戈分校的斯卡格斯药学与药物科学学院（SSPPS），另一个集群位于新泽西州罗格斯大学校园。这些集群可以在SDSC的维护或停电期间，或者在可能影响一个或两个UCSD位置的灾难性灾难发生时提供故障转移服务(图1). 第二个SDSC集群在配置上与实时生产集群相同，主要用于每周更新的高级分段，并且仅在最合理的情况下用于故障转移。

在单独的窗口中打开

图1。

硬件冗余和DNS故障转移的示意图。在三个不同的地理位置有四个集群：圣地亚哥超级计算机中心（SDSC）和圣地亚哥加州大学（UCSD）的斯卡格斯药学和药物科学学院（SSPPS），以及新泽西州立大学的罗格斯。每个集群包含多个负载平衡的Web和FTP服务器。第三方DNS提供商用于管理网站的DNS条目(网址：www.pdb.org)和FTP站点(ftp.wwpdb.org网站)包括在主集群发生故障时进行故障转移。

此外，还有一个最基本形式的PDB数据服务冗余级别：根据wwPDB的章程协议，通过FTP分发PDB档案在欧洲PDB（PDBe）和日本PDB（PDBj）是重复的(2).

每周数据库更新

每周三00:00 UTC，每周都会在web和FTP站点上向公众发布新条目和修改条目的数据更新。及时准确地分发这些数据更新是我们最关键的任务之一。在过去10年中，RCSB团队在网站更新的截止日期之前保持了近乎完美的记录。唯一的例外是更新在内部完成的一周内，但在截止日期之后的几个小时内，更改公共DNS条目的错误未被检测到，导致公众无法及时看到更新。制定了额外的测试程序，以防止再次发生。在接下来的部分中，我们将描述为一致地确保这些每周数据库更新的及时执行和交付而遵循的过程。

数据档案的同步和测试

罗格斯大学（Rutgers University）的RCSB PDB工作人员每周更新新条目和修改条目。作为此过程的一部分，公共FTP存档和所谓的“沙盒”的内部主副本将被更新。沙盒是存档的另一个视图，仅用于内部更新，内容与公共FTP站点几乎相同，但组织方式不同。

更新FTP和沙盒主副本后，将其传播到公共站点的工作由UCSD的RCSB PDB员工负责。在一周内，共在四个集群中的26台服务器上执行任务，包括同步FTP和沙盒存档的各种副本，以及在数据库/web服务器上运行每周更新。为了减少单调和人为错误的可能性，所有这些进程都是从一个中央服务器启动的，然后中央服务器通过ssh连接将必要的命令发送到适当的服务器集。四个集群的FTP和数据库更新在一周内交错进行，以平衡高级升级的需要和匹配活动集群内容的故障转移集群的可用性(图2).

在单独的窗口中打开

图2。

Web和FTP服务器的交错每周更新计划。总体目标是在任何给定时间平衡对更新高级阶段（红色和橙色）的需求与对当前数据（绿色）的尽可能多的故障切换。更新周期从星期五开始，第二个SDSC集群（SDSC 2）。周一和周二更新了另外两个集群。星期三UTC 00:00，通过在两个SDSC集群（粗轮廓）之间切换DNS条目，更新被公开。DNS更改需要几个小时才能传播，直到最后一个现已过期的群集（蓝色）上的更新开始。带有粗轮廓的绿色显示了向公众提供数据的“实时”集群。其他绿色的簇具有相同的当前内容。正在更新红色的群集。橙色表示包含尚未公开发布的“暂存”数据的已完成更新的集群。蓝色表示与实时公共站点相比其数据已过时的集群。

首先，所有沙箱服务器（因为它们只在内部使用）和备份SDSC集群的FTP服务器都通过rsync同步到它们各自的主副本。Rsync首先以静默模式运行，将所有可能发生的更改记录到日志中，而不实际进行任何更改。然后，Python脚本会分析这个静默的rsync日志，以确保每周更新的完整性。通过引用新文件和修改文件的单独列表，这些完整性检查可以回答这样的问题：“rsync是否已传输新的和修改的PDB ID的所有预期文件？”和“不会修改任何意外文件吗？”如果所有测试都通过，则会在实时模式下重复rsync。然后，另一个验证脚本检查总持有量：“之前的条目计数减去过时条目，再加上新条目，是否与新计数相加？”内部沙盒和公共FTP站点的各种目录路径之间的此计数是否一致

硒测试套件

每周更新过程的下一步是在备份SDSC集群的每个web服务器上运行数据库更新（在接下来的几天内，在其他三个集群上重复此操作）。此数据库更新的详细信息超出了本文的范围。简单地说，mmCIF格式的结构文件(17)在所有新的和修改的条目中，解析并加载到数据库中，计算派生数据，并导入几十个外部数据库中的相关内容。50多个加载器类中的任何一个的问题都会记录在数据库中，并通过电子邮件发送给员工。

新的软件构建是从软件的稳定生产分支创建的，并部署到更新的web服务器上。虽然此更新有时可能包含关键的错误修复，但生产站点上站点功能的更改通常保留给精心编制的软件版本，如下一节所述。新闻项目和其他所谓的静态web内容现在保存在内部开发的独立内容管理系统（CMS）中。这进一步减少了已部署构建中的更改，从而有助于生产站点软件的稳定性。

每周数据更新的一个关键质量保证是一个广泛的Selenium测试套件。Selenium是一套用于测试web应用程序的工具（seleniumhq.org）。SeleniumIDE是Selenium项目之一，是一个在Firefox web浏览器中运行的插件。它记录并回放Firefox中任何网站的测试。我们为RCSB PDB网站开发了一套广泛的测试，包含1300多个步骤（“转到此URL”、“单击此链接”、“输入此搜索词”、“等待页面返回”等）。其中，350多个命令是断言或验证，例如“页面是否包含某些文本？”页面上的数字与测试期间存储的数字匹配吗？'，等(图3). 站点功能的测试覆盖率主要根据AWStats日志分析和Google Analytics流量分析显示的站点使用情况确定。

在单独的窗口中打开

图3。

Firefox浏览器中完全执行的SeleniumIDE测试套件的屏幕截图。我们开发了一套广泛的测试脚本，有几个目标，例如检查用户界面的关键元素，验证每周更新的完整性，以及比较多个服务器之间的结果。左上方的面板显示了测试脚本列表。顶部中间的面板显示了验证关键字搜索是否为最新的脚本示例。它从每周发布中选择第一个条目ID，从其标题中提取关键字，然后搜索该关键字，并断言搜索结果包括给定的条目ID。右上方的面板包含用于执行测试的控件并显示测试结果。底部面板是一个常规浏览器窗口，显示脚本加载的网页。

此测试套件在更新后在每个集群的每个web服务器上运行。该套件有几个总体目标。它测试用户界面的关键元素，例如关键字搜索和单个条目的结构摘要页面。它检查每周更新的完整性，例如，通过断言网站上返回的结构总数与FTP存档中的内容相匹配。此外，它通过将被测试服务器的结果与专用主服务器的结果进行比较，确保负载平衡集群中的每个服务器为许多查询返回相同的结果。一旦切换了公共DNS条目以激活更新，就会针对公共URL（而不是单个服务器）运行另一个更短的Selenium测试套件，以确保公共站点已成功更新。

软件版本

质量保证的另一个主要目标是为RCSB PDB网站提供动力的软件。它是用Java编写的，由2000多个类组成，大约有20万行源代码。UCSD维护现场的RCSB PDB员工目前由八名全职员工组成，其中一半是全职开发人员，另一半将时间分配给开发、项目管理和系统管理。带有主要新功能的新软件版本大约每年在生产现场发布四次。这是一个中等规模的软件项目，其复杂性足以使良好的软件实践成为一项相当重要的任务。本节简要介绍了用于监控代码质量和站点性能以及确保新软件版本稳定性的工具和实践。

监控和故障排除工具

即使是尽最大努力确保高性能网站具有最少的错误，也不能消除对硬件和软件的监控需求。已经描述了一些监控和通知实践，如负载平衡器和DNS故障转移警报。这里我们概述了用于监视和故障排除的其他工具。

监测工具

ServerStalker是一种内部开发的工具，用于监视所有生产服务器及其提供的服务的当前硬件状态。除了对所有服务器进行简单的ICMP ping测试外，对web服务器进行监控的项目还包括使用的CPU和硬盘空间的百分比、Java进程使用的RAM数量、PDB条目的数量以及MySQL数据库的状态。此外，还为每个服务器和集群提供了更新状态的摘要，以指示它们是否包含当前数据、当前是否正在更新或是否已完成升级以备将来公开发布。对于FTP服务器，将快速确认FTP和rsync服务的可用性。ServerStalker的总体目标是快速查看每个生产服务器的当前运行状况。我们打算在未来开源ServerStalker。

此外，我们使用仙人掌(网址：www.cacti.net)以图形方式显示随时间收集的状态信息(图4). 每隔几分钟收集一次内部和外部流量、CPU和内存使用量、线程计数和Tomcat会话计数等参数，并以图形形式显示每个服务器或集群。这对于追溯调查服务器崩溃或性能瓶颈特别有用。例如，如果用户报告一个复杂的查询返回速度太慢，Cacti可能有助于识别MySQL或Tomcat当时的瓶颈所在。

在单独的窗口中打开

图4。

Cacti监控工具截图(网址：www.cacti.net). 每隔几分钟收集一次内部和外部流量、CPU和内存使用量、线程计数和Tomcat会话计数等参数，并以图形形式显示每个服务器或集群。时间窗口在集群刚刚用新的季度软件版本重新安装后开始，并显示在每个服务器上连续的Selenium测试期间的服务器负载。出于安全原因，服务器名称被编辑。

当然，服务器日志需要仔细收集和归档。Web、FTP和rsync日志由AWStats（AWStats.sourceforge.net）分析，网站流量由Google Analytics进一步分析(www.google.com/analytics网站). 除了提供基本的使用统计数据外，这些分析还可以帮助识别使用模式，包括采用新功能。然而，对此类分析的全面讨论超出了本文的范围。

讨论和总结

RCSB PDB致力于提供优质资源和高度可靠的服务。这意味着无论维护需求、停电等情况如何，都可以在365年7月24日不间断访问。

在管理PDB十多年的时间里，RCSB PDB在网站的可靠性和性能方面普遍受到用户的好评。然而，我们得到的一个教训是，用户不一定告诉我们他们遇到的问题，但可能只是离开网站。在最近的一年里，该网站从大约100万个独特的IP地址访问，但只有大约1600名不同的用户写信给电子服务台，提出评论、问题或担忧。虽然这些数字为各种解释留下了空间，但与用户的个人互动，例如在会议上，有时也反映出不愿意说出感知到的问题。一些用户表示，他们只是认为自己做错了什么，没有考虑到网站上可能存在漏洞。当然，人们总是希望在外部用户体验问题之前发现内部问题，但刚刚描述的趋势增加了这样做的负担。

要测试多少以及如何测试的问题并不是一个简单的答案。时间和资源根本不允许我们测试一切，因此必须确定优先顺序。自动化测试与手动测试的问题也是一个有趣的问题。虽然完整的测试自动化可能天真地看起来像是一个明显的目标，但我们发现它不能完全取代手动测试，并且需要适当的平衡。另一个有趣的心理方面是过度测试的固有危险。测试脚本中包含的断言越多，其中一个断言失败的可能性越高。这不总是件好事吗？是的，只要失败确实反映了一个真正的问题。然而，增加测试也会增加错误报告的可能性，根据我们的经验，这会带来测试人员自满的危险（“我以前见过这种失败，我不会担心这种情况”）。所有测试的构思和实施都应确保失败确实反映了一个需要进一步调查的真实问题。

Selenium IDE作为测试环境有很多优点。开始使用GUI测试编辑器编写测试很容易，同时，HTML格式的测试源代码也很容易手动编辑。有多种方法可以寻址页面上的HTML元素，包括通过强大的XPath查询语言在文档对象模型（DOM）中的相对和绝对位置。可以在Selenium命令中嵌入任意JavaScript，从而允许计算数学构造，并添加在断言中包含逻辑的有限方法。然而，Selenium IDE的一个缺点（至少在没有使用第三方插件的情况下）是缺乏真正的流控制或循环，使得一些重复测试有点尴尬（例如“对于每个结构基因组中心，测试返回的结构数量”）。

我们认为，使用Selenium IDE的最大优点是，在真实浏览器中执行测试构成了一个测试环境，与最终用户与网站交互的真实体验最为相似。单元测试和回归测试是全面质量保证策略的重要组成部分。然而，最终的目标并不是让每个类都通过单元测试，而是让所有网站功能按设计和预期运行。web浏览器是大多数用户最常用的RCSB PDB接口，这使得Selenium IDE成为用户体验到的应用程序集成测试的合适选择。

几年来，我们制定了质量保证实践。虽然其中许多可以被视为相当标准的行业实践，但我们会根据需要不断修订和完善它们。特别是硬件冗余带来了必要的权衡，如数据同步开销、硬件利用率低、财务约束、可扩展性限制等。例如，相互独立更新的数据库的多个副本可能会由于某种原因而随着时间的推移在内容上出现分歧。我们打算通过未来的硬件重新设计对此进行改进。

我们可以改进的另一个领域是回归测试的使用。虽然回归测试套件涵盖了相当多的站点功能，但它并不全面。此外，一个理想的目标可能是，对于发现并修复的每个错误，都会在回归套件中添加一个测试，以避免将来出现任何未检测到的相同问题。显然，这必须与完整测试套件的运行时间相平衡。

在本文中，我们概述了用于软件维护的工具和实践。软件和数据库的原始设计在别处描述(18). PDB网站提供了足够的功能，因此在单个web应用程序中维护所有代码变得越来越困难。为了解决站点某一方面的代码更改对其他功能产生负面影响的风险，我们正在不断地对代码进行模块化。通过BioJava已经可以获得代码库的一些组件(19)项目。

总之，我们已经描述了RCSB PDB查询和分发系统的质量保证工作，特别是RCSB PDB网站的质量保证工作。通过多层冗余，我们努力争取100%的正常运行时间，并几乎实现了这一目标。每周的数据库更新和大约每季度的软件发布在公开之前都经过了仔细的阶段性测试。最后，我们概述了一些用于调查确实发生的问题的工具和实践，尽管我们首先尽力避免这些问题。

致谢

工具书类