MySQL Blob 与磁盘的“视频帧”比较
我有一个 C++ 应用程序，每秒生成 6 个相对较小的类似图像的整数数组。数据是64x48x2维int（即64x48二维向量的网格，每个向量由两个浮点数组成）。每张图像大约为 26kb。该应用程序还生成时间戳和一些描述数据的功能。我想将每帧的时间戳和特征存储在 MySQL 数据库列中。我还需要将原始数组存储为二进制数据，可以存储在光盘上的文件中，也可以存储为数据库中的 blob 字段。假设应用程序将或多或少地不间断运行，并且我将想出一种方法来归档超过特定年龄的数据，这样存储就不会成为问题。
对于 blob、光盘上的文件或我可能没有想到的其他方法，这里的权衡是什么？我不需要查询二进制数据，但我需要查询表中的其他元数据/功能（我肯定会根据时间戳构建索引），并检索二进制数据。如果我将多个帧存储在磁盘上的单个文件中（而不是每个文件一帧），方程会发生变化吗？
是的，我已阅读 使用 BLOB 的 MySQL 二进制存储与操作系统文件系统：大文件、大数量、大问题 和 要做或不做：将图像存储在数据库中，但我认为我的问题有所不同，因为在这种情况下，将有数百万个相同尺寸的图像二进制文件。我不确定在文件系统中维护这么多小文件与在 db blob 列中存储这么多文件相比，对性能的影响如何。任何观点将不胜感激。
I have a c++ app that generates 6x relatively small image-like integer arrays per second. The data is 64x48x2-dimensional int (ie, a grid of 64x48 two-dimensional vectors, with each vector consisting of two floats). That works out to ~26kb per image. The app also generates a timestamp and some features describing the data. I want to store the timestamp and the features in a MySQL db column, per frame. I also need to store the original array as binary data, either in a file on disc or as a blob field in the database. Assume that the app will be running more or less nonstop, and that I'll come up with a way to archive data older than a certain age, so that storage does not become a problem.
What are the tradeoffs here for blobs, files-on-disc, or other methods I may not even be thinking of? I don't need to query against the binary data, but I need to query against the other metadata/features in the table (I'll definitely have an index built against timestamp), and retrieve the binary data. Does the equation change if I store multiple frames in a single file on disk, vs. one frame per file?
Yes, I've read MySQL Binary Storage using BLOB VS OS File System: large files, large quantities, large problems and To Do or Not to Do: Store Images in a Database, but I think my question differs because in this case there are going to be millions of identically-dimensioned binary files. I'm not sure how the performance hit to maintaining that many small files in a filesystem compares to storing that many files in db blob columns. Any perspective would be appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在某个时刻，查询许多 blob 会变得慢得难以忍受。我怀疑即使您的二进制文件尺寸相同，情况也会如此。此外，您仍然需要一些代码来访问和处理 blob。而且这并没有利用文件缓存，而文件缓存可能会加速直接从文件系统进行图像查询的速度。
但！您提供的链接没有提到基于对象的数据库，它可以以一种您可以非常快速地访问它的方式存储您所描述的数据，并且可能以本机格式返回它。有关讨论，请参阅链接或仅搜索 google，有很多讨论：
在 NoSQL 存储中存储图像< /a>
我也会研究一下 HBase。
我想既然你不确定首先要使用什么（并且没有答案），那么替代解决方案可能是合适的。
At a certain point, querying for many blobs becomes unbearably slow. I suspect that even if your identically dimensioned binary files this will be the case. Moreover you will still need some code to access and process the blobs. And this doesn't take advantage of file caching that might speed up image queries straight from the file system.
But! The link you provided did not mention object based databases, which can store the data you described in a way that you can access it extremely quickly, and possibly return it in native format. For a discussion see the link or just search google, there are many discussions:
Storing images in NoSQL stores
I would also look into HBase.
I figured since you were not sure about what to use in the first place(and there were no answers), an alternative solution might be appropriate.