postgresql使用bytea blob或文件位置来存储序列化对象？
我想将序列化对象存储在某处，环顾四周后，意识到有几种方法可以做到这一点。
我正在考虑将文件存储在文件系统中的某个位置，并将文件位置存储为表中的条目。
假设文件大小约为 100-500Kb，这是一种合适的方法吗？或者使用 bytea 或 blob 是更好的解决方案？
I want to store a serialized object somewhere and after looking around, realize there are a couple of ways to do this.
I'm looking at storing the file somewhere in the file system and storing the file location as entries in a table.
Assuming the files are around 100-500Kb, is this a suitable way of doing so? Or using bytea or blob a better solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
小对象（500Kb）可以像 bytea 一样正常工作。大小的主要限制是，您需要首先在服务器上具体化内存中的整个字段，然后在客户端上具体化（有一些方法可以解决它，但它们是有限的）。对于半兆字节来说，这应该不是问题，但如果您开始存储更大的对象，则可能需要一些考虑。
将其存储在文件系统中并存储位置（或存储由 SERIAL 序列中的代理主键命名的文件）是处理较大文件的好方法，当然您也可以在此处应用它。缺点是您失去了事务完整性（您无法确定文件系统和数据库都已更新，因此您需要实现某种验证工具来定期运行以比较它们），并且可能更重要的是您可以'无法获得一致的备份（如果备份的是文件而不是数据库记录怎么办？或者反过来）当然，也有一些方法可以处理这个问题，但它很快就会变得比将数据存储在桌子。
Small objects (which 500Kb) qualifies as will work fine as bytea. The main limitation on the size is that you will need to materialize the whole field in memory first at the server and then at the client (there are ways aorund it, but they are limited). For half a megabyte, that shouldn't be an issue, but if you start storing much larger objects it may need some consideration.
Storing it in the filesystem and storing the location (or storing it named by a surrogate primary key from a SERIAL sequence) is a good way to deal with larger files, and you can of course apply it here as well. The downsides are that you loose transactional integrity (you can't be sure that both the filesystem and the database was updated, so you need to implement some kind of verification tool to run regularly to compare these), and probably more importantly you can't get consistent backups (what if the file was backed up and not the db record? or the other way around) There are methods to deal with this as well, of course, but it rapidly becomes much more complex than keeping the data stored in the table.