我可能正在研究一个从视觉系统收集图像的系统，并将它们与状态信息一起存储在dB中。 由于系统连接到高速运行的连续生产过程，因此将需要高数据吞吐率。 从SF我想知道的是如何指定一个能够满足我的要求的系统。
物理上这个系统的布局是：
就数据速率而言，系统每秒至less需要接收40-80MB的图像（每张图像大约2MB）。
可能的增强包括将db / webserver分成两个系统。 只存储在dB中的文件path，让计算机做BMP到JPG或PNG压缩。
那么为了实现这个目标，我需要指定哪些基本统计数据呢？
感谢您的build议
编辑更正的大小以读取MB
编辑忘记我提到了“相机”一词，并将其replace为“magic-box-that-drops-2MB-files-into-computer-by-ftp”
编辑2月24日对不起，谁回答，似乎我一直在忽略你。 当他们意识到并非系统中的所有组件实际上都具有以太网时，项目就被搁置了一会儿（是的，我应该在TDWTF上发布）
第一点的消息。 当被告知所有的数据需求时，规格被退回。 现在，我只需要每秒存档6或7个单行文本文件，并且只有在存在被视为问题的情况下才能存档完整的2MB图像。 由于生产过程中运行所有这些应该是生产好产品，那么这应该是一个罕见的事情。 如果连续出现多个故障，它们也会closures。因此，平均数据吞吐量仍然很低，我可以将插入缓冲在磁盘上，直到我赶上（如果需要的话）
现在的恐怖故事。 虽然我非常欣赏如何build立一个强大的系统的build议，但是我今天发现这个项目已经购买了“（是的 – 只有一台）”计算机（而且我根本没有说明它的规格）。 我确定它是一台不错的电脑，但是当我想知道戴尔Optiplex 760将会如何工作时，我的桌子正在开始变形。
我会select最好的答案，并作为我的select奖
其实他们都是很好的答案。 可惜我不能分裂我的投票。
我不得不想一想这个，所以很抱歉拖延回到你身边。
如果我正在build造这个，我会做以下的事情;
顺便说一句，你将不得不拥有相当强大的防火墙，路由器，负载平衡器和交换机。
这将使您能够在单个磁盘控制器出现故障，大量磁盘故障以及一个或多个采集服务器出现故障的情况下继续工作。 如果负载变得太大，您可以非常容易地将前端和后端文件pipe理器分割到不同的机器上，您也可以将整个文件pipe理器用于备份目的。
然后，您可以构build后端function来查询数据库，并根据需要检索图像，而不影响入口性能。
如果你想让我更详细地介绍一下，请告诉我。
为此，您需要围绕中央数据库服务器群集Web服务器。 另外，这里最大的（也是最丑的）大部分工作不在存储或服务中，而是在高速采集。
在你接受这个之前，你绝对必须做一轮性能testing。 这可能意味着从硬件供应商获得演示单元。 打电话给一个人聊天，销售人员有权安排硬件演示，你可以使用一两个星期。 IBM和惠普都非常好。
我非常关心笨重的文件传输方法（BMP和FTP）与高性能的期望相结合。 你将遇到这个问题，尤其是FTP的连接速度有多快。 对于最终花在服务器上的额外现金，您可能会为更灵活的相机单元而努力。 这些相机如何能够在第一时间到达FTP服务器？ 他们是ip-camera？
球场架构：2个“通讯”服务器处理文件获取，数据input到数据库，然后转移到networking服务器或存储在SAN上。 每个双千兆位nics处理图像的双四核，最小的本地存储。 1个数据库服务器。 这个规范只需要是平均的，取决于你要处理的地方，你要存储多less元数据和统计数据，以及你要服务多less个并发的用户连接。 1或2个Web服务器。 同样，规格完全取决于您需要支持的用户数量，无论是公共还是私人网站，以及您select处理image processing的位置。
你试图达到的目标听起来可能是某种车间生产监控系统。 如果是这样的话，这就是应该留给该领域的专家（SCADA等）的那种工作。 这些系统是昂贵的，安全的关键和soforth，有一个专门的团队，只是与IT松散关联，是一件非常好的事情（tm）
为了回应您关于您所捕获的数据量的说明，这类数量是一个严峻的挑战。 你指出这与某种制造业有关，所以我假定这将是一个24×365的要求。 我只想在这里讨论存储容量 – 其他人已经对处理架构进行了评论，但是我认为了解整体解决scheme的规模是非常重要的。
在40MBytes / sec的情况下，如果这是一个持续的过程，那么您一年的数据量是半个PB，而您需要将所有文件保留在合理的存储空间中。 如果您确实需要这样做，那么无论您的存储解决scheme如何，您都可以为您提供远超过您所需的即时IO性能。 至less如果我从供应商处购买半字节的存储空间，我希望能够提供一些不错的快速磁盘存储选项以及音量。 无论您如何构build，基于磁盘的半字节存储容量都将非常昂贵，并占用大量的机架空间。 6×48驱动器带有2TB SATA驱动器的磁盘arrays将吃掉半个42U机架，为了保持旋转，会吸收几千瓦的功率。
实际上，不需要浪费太多的磁盘空间 – 在将这些文件提交到中长期存储之前，您想放弃BMP格式。 如果你想保持无损PNG应该节省60％至90％的BMP，如果有损压缩不是一个问题，那么JPEG一定会节省80-95％，所以build立一个处理堆栈，从BMP转换之前你把它保存到永久存储是至关重要的。 即使如此，你仍然希望拥有大约50TB的存储空间，这样一年的数据价格便宜，但是你可以find一个普通汽车的价格，而不是费尔里特型的费用。背部。 如果您要购买这么多的空间，那么它也应该能够轻松地为您提供初始相机卸载和数据库所需的高IO分段容量。
你的数据库也不会是微不足道的 – 如果这些捕获率保持不变（我假设它是如果这是一个制造过程），那么你将有每天近200万logging – 每年十亿四分之三十亿。 如果每个logging只有1k左右，那么你的数据库将是600GB。 有很多的解决scheme可以处理，但它不是一个小型的数据库。
如果我假设这是一个全天候的24×7数据传输过程，那么当然，所有这些都是过度的，但即使这只是8×5而不是24×365，你也需要一个相当大的，强大的（昂贵的）SAN和然后尝试将所有支持服务（Web前端\数据库\image processing）塞进一个盒子里是没有意义的。