指定硬件的最低传输速率

指定硬件的最低传输速率

我可能会开发一个系统,该系统从视觉系统收集图像并将它们与状态信息一起存储在 dB 中。由于该系统与高速运行的连续生产过程相关,因此需要高数据吞吐率。我想从 SF 那里了解的是,您将如何指定一个满足我要求的系统。

从物理上讲,该系统的布局如下:

  • 相机通过 FTP 将 BMP 图像和包含状态信息的小文件发送到计算机上的目录(请注意,相机只能发送 BMP。任何图像压缩都必须在接收计算机上完成)
  • 计算机扫描目录以查找新图像。
  • 计算机收到图像后,将其插入到 dB(或将图像移动到新目录并将引用插入到 dB)。此时也会插入状态信息。
  • dB 用于为允许浏览图像、显示不同时间段的图像质量统计数据等的网站提供信息。该网站也可以托管在同一台计算机上。

在数据速率方面,该系统需要持续每秒接收至少大约 40-80MB 的图像(每张图像约 2 MB)。

可能的改进包括将数据库/网络服务器拆分为两个系统。只在数据库中存储文件路径,并让计算机执行 BMP 到 JPG 或 PNG 的压缩。

那么为了实现这一目标我需要指定哪些基本统计数据?

  • 网络速度?相机和计算机之间有专用以太网吗?
  • CPU 类型和速度?
  • 系统总线速度?
  • 内存速度?
  • 磁盘驱动器类型和速度?

谢谢你的建议

编辑 更正尺寸为 MB

编辑 忘记我提到的“相机”这个词,用“通过 FTP 将 2MB 文件放入计算机的神奇盒子”代替

编辑 2 月 24 日 抱歉,回答这个问题的人,我好像一直在忽略你们。当他们意识到系统中的所有组件实际上都没有以太网时,该项目被搁置了一段时间(是的,我应该在 TDWTF 上发帖)

第一条消息。当得知总数据需求时,规格被撤回。现在我每秒只需存档 6 或 7 个单行文本文件,并且只有当出现问题时才存档完整的 2MB 图像。由于运行所有这些的生产过程应该能够生产出优质产品,因此这种情况应该很少发生。此外,如果连续发生几次故障,他们就会关闭生产线……因此平均数据吞吐量仍然很低,我可以将插入内容缓冲到磁盘上,直到我赶上进度(如果需要)

现在来看看恐怖故事。虽然我真的很感激关于如何构建一个强大系统的建议,但我今天发现“那台”(是的 - 唯一的一台)电脑是为这个项目购买的(而我对它的规格完全没有发言权)。我确信这是一台不错的电脑,但当我好奇这台电脑如何与戴尔 Optiplex 760 配合使用时,我的办公桌开始出现头部形状的凹痕。

  • E8400 酷睿 2 双核 CPU
  • 2GB 内存
  • 160 GB 高清
  • SQL Server Express(只能使用 1GB 内存、1 个核心和 4GB 最大数据库大小)

我会选出最好的答案,并将其作为我的选择

其实这些都是很好的答案。可惜我不能分票。

答案1

我不得不对这个问题进行一些思考,所以很抱歉这么晚才回复您。

如果我正在构建这个,我会执行以下操作;

  • 您最喜欢的任何风格的专用数据库服务器(或集群)。
  • 购买一个大小合适的双控制器 NetApp 盒,比如带有 4 个 10Gbps 端口的 3140。在其上设置一个 1TB-2TB 的基于 SAS 的 vFiler 作为 FTP 获取门户,文件放入此共享中,也可以通过 SMB 或 NFS 访问。然后设置第二个更大的 SATA(或 SAS,取决于预算)vFiler,通过 SMB 或 NFS 共享。
  • 服务器通过双 1Gbps 或 10Gbps 链路连接到 NetApp,这些服务器查看 FTP“监视文件夹”,通过一个小型标志文件分配自己来管理一个文件集,将图像复制到更大的文件管理器并创建一个引用文件最终位置的 DB 条目,一旦完成,清除原始文件(包括管理标志文件)。然后寻找另一项工作,重复,冲洗。

顺便说一句,您必须拥有相当强大的防火墙、路由器、负载平衡器和交换机。

这样,您就可以应对单个磁盘控制器发生故障、大量磁盘发生故障以及一台或多台采集服务器发生故障的情况。如果负载过大,您可以非常轻松地将前端和后端文件服务器拆分到不同的机器上,也可以将整个文件服务器快照以进行备份。

然后,您可以构建后端功能来查询数据库并根据需要检索图像,而不会影响入口性能。

如果您希望我更详细地讲解这一点,请告诉我。

答案2

为此,您需要围绕中央数据库服务器集群化 Web 服务器。此外,这里最大的(也是最难处理的)工作不是存储或服务,而是高速获取。

你绝对必须在承诺之前进行一轮性能测试。这可能意味着从硬件供应商那里获得演示单元。打电话给一家并聊一聊,销售人员有权安排硬件演示,您可以使用一两周。IBM 和 HP 在这方面都做得很好。

我非常担心笨重的文件传输方法(BMP 和 FTP)与高性能的期望相结合。您将遇到问题,尤其是 FTP 处理连接的速度。对于您最终在服务器上花费的额外现金,您可能能够负担得起更灵活的摄像机单元。这些摄像机首先如何能够到达 FTP 服务器?它们是 ip 摄像机吗?

大致架构:2 个“通信”服务器处理文件采集、将数据输入数据库,然后传输到 Web 服务器或 SAN 上的存储。每个服务器都有双千兆网卡、双四核用于处理图像、最小本地存储。1 个数据库服务器。其规格只需达到平均水平,具体取决于您要在哪里进行处理、要存储多少元数据和统计数据以及要为多少个并发用户连接提供服务。1 或 2 个 Web 服务器。同样,规格完全取决于您需要支持的用户数量、是公共网站还是私人网站以及您选择在哪里处理图像。

您想要实现的目标听起来像是某种车间生产监控系统。如果是这样的话,这种工作应该留给该领域的专家(SCADA 等)。这些系统非常昂贵,安全至关重要等等,拥有一支与 IT 关系不大的专业团队是一件非常好的事情(tm)

答案3

针对您关于捕获的数据量的澄清,这种数量是一个严峻的挑战。您表示这与某种制造设置有关,因此我假设这将是 24x365 的要求。我在这里只讨论存储量 - 其他人对处理架构发表了评论,但我认为让您了解整体解决方案的规模很重要。

如果这是一个持续的过程并且您需要将所有文件保留在合理的存储空间中,那么以 40MBytes/sec 的速度,您每年需要处理半 PB 的数据。如果您确实需要这样做,那么无论使用哪种存储解决方案,都可以为您提供远超您需要的即时 IO 性能。如果我从供应商那里购买半 PB 的存储空间,我至少希望它能够提供一些不错的快速磁盘存储选项以及卷。无论您如何构建它,半 PB 的磁盘存储都将非常昂贵并且会占用大量的机架空间。带有 2TB SATA 驱动器的 6x48 驱动器磁盘阵列将占用半个 42U 机架并消耗几千瓦的电力才能保持旋转。

但实际上没必要浪费那么多磁盘空间 - 您需要在将它们提交到中期/长期存储之前放弃 BMP 格式。如果您想保持无损,PNG 应该比 BMP 节省 60% 到 90%,如果有损压缩不是什么大问题,那么 JPEG 绝对可以为您节省 80-95%,因此在将其保存到永久存储之前构建一个从 BMP 转换的处理堆栈至关重要。即便如此,您也希望有大约 50TB 的存储空间来存储一年的数据,这并不便宜,但您可以以普通汽车的价格找到/构建它,而不是像 PB 级的东西那样花费您购买法拉利类型的费用。如果您购买那么多空间,那么它还应该能够轻松为您提供初始相机卸载和数据库所需的高 IO 暂存容量。

您的数据库也不会小到可以忽略不计 - 如果这些捕获率能够维持(如果这是针对制造过程的话,我假设它们能够维持),那么您每天将添加近 200 万条记录 - 每年 3/4 亿条。如果每条记录只有 1k 左右,那么您的数据库将达到 600GB。有很多解决方案可以处理这个问题,但无论如何它都不是一个小数据库。

如果我对这是一个具有稳定数据速率的 24x7 过程的要求的假设不正确,那么当然所有这些都是多余的,但即使它只运行 8x5 而不是 24x365,您也需要一个非常大且强大(昂贵)的 SAN,并且尝试将所有支持服务(Web 前端 \DB \图像处理)塞进一个盒子里是没有意义的。

相关内容