We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
目前 dp2kernel 是利用 SQL 数据库记录的 image 类型字段或者本地对象文件存储对象。希望设计一种接口机制,允许 dp2kernel 利用外部对象存储来存储这些对象。
目前可以想到的外部对象存储方式有如下这些:
接口应该设计成一种标准的 API,然后根据不同的存储方式实现这些 API 的功能。
为了节省存储空间,存储系统可以建立一种内容 hash 和物理文件的对照关系,凡是相同的内容只在存储系统中存储一份。每一个引用事项删除的时候,自动检查它是不是引用这个物理文件的最后一个引用事项,如果是,则一并删除物理文件;否则还将保留物理文件。不过,这种存储策略是可选的,从 API 角度并没有规定必须采用这种存储策略。当然,API 角度要做一些配合,比如可能需要传递内容 hash。
存储系统应当实现独立的备份和恢复机制,当存储系统被损坏后,可以用备份进行恢复。建议采用大备份和日备份结合的方式。大备份可以考虑采用某种增量 delta 备份的方式(即不再备份以前备份过的内容),节省备份存储空间。
最后剩下一个问题,dp2kernel 内置的对象管理机制,还需要用这套 API 改写么?或者说取消以前的内置机制,默认使用一套文件型的 API 实现代替。
The text was updated successfully, but these errors were encountered:
No branches or pull requests
目前 dp2kernel 是利用 SQL 数据库记录的 image 类型字段或者本地对象文件存储对象。希望设计一种接口机制,允许 dp2kernel 利用外部对象存储来存储这些对象。
目前可以想到的外部对象存储方式有如下这些:
接口应该设计成一种标准的 API,然后根据不同的存储方式实现这些 API 的功能。
为了节省存储空间,存储系统可以建立一种内容 hash 和物理文件的对照关系,凡是相同的内容只在存储系统中存储一份。每一个引用事项删除的时候,自动检查它是不是引用这个物理文件的最后一个引用事项,如果是,则一并删除物理文件;否则还将保留物理文件。不过,这种存储策略是可选的,从 API 角度并没有规定必须采用这种存储策略。当然,API 角度要做一些配合,比如可能需要传递内容 hash。
存储系统应当实现独立的备份和恢复机制,当存储系统被损坏后,可以用备份进行恢复。建议采用大备份和日备份结合的方式。大备份可以考虑采用某种增量 delta 备份的方式(即不再备份以前备份过的内容),节省备份存储空间。
最后剩下一个问题,dp2kernel 内置的对象管理机制,还需要用这套 API 改写么?或者说取消以前的内置机制,默认使用一套文件型的 API 实现代替。
The text was updated successfully, but these errors were encountered: