数据库选型时遇到PostgreSQL的一个问题
首先说一下背景，这是一个传统的面向企业的产品型软件，每天会录入大量的日志型数据到数据库中(目前最高每天几百G)，由于是产品型软件，销售后数据库安装在企业内部，上门进行数据库维护是很困难的，所以要求尽可能轻运维(这与大部分的互联网应用方案很不一样)。
以前产品使用的数据库是SQL Server，针对数据进行了分表分库处理，其中有一个功能就是备份/加载，这个功能允许用户定期按天把历史日志数据从系统中备份出来另外存放，当需要使用时才加载回系统进行使用，这个功能对于这个场景应该是很重要的，历史数据如果一直在数据库中对磁盘空间要求要很大，如果能备份出来就可以单独找其他空间来存放了。这个功能由于是按天分库，只要使用SQLServer的Attach和Detach功能就能很好地进行分离和加载，速度是很快的，用户体验会非常好。
目前选型数据库时，发现Postgresql好像满足不了这个需求，考量了它的几种备份方案，都解决不了：
- pg_dump来备份，这是逻辑备份方案，在备份和恢复时都需要较长的时间及占用大量的CPU资源
- 物理备份只支持整个Postgresql的Data目录备份，显然也是不能满足的
- 使用WAL的PITR也是不行的
实际我想实现的是如何能把数据从数据库中快速分离出来，并且能快速加载回去，按这个想法我想到的只有物理备份才有可能做到的，从Postgresql的数据组织来看它不同表的数据也是存放到不同的文件中的。
在官网上也有过这个提问：
https://www.postgresql.org/message-id/CAA-aLv5cQf09zvFRCB1XXUQLSp-ouX0S_Hq6ryScd6CtamipFQ%40mail.gmail.com
简单搜了一下，Oracle和Mysql可以通过传输表空间实现类似的功能：
http://blog.itpub.net/17203031/viewspace-749513/
http://blog.itpub.net/29773961/viewspace-2134065/
想问问有什么方法能实现我的需求吗？
PS: 如果物理备份，不用考虑OS, 版本等差异，一些非常规方案也行(选型MySQL时类似问题就可以通过一些修复语句能做到)
写回答
-
一个笨办法，通过sql语句查到表对应的文件，将文件mv出来，用的时候再mv进去。mv出来时，表在数据库可见，但是访问会提示文件不存在；mv回去后可以正常访问。
mydb=# select relname, nspname, spcname, pg_relation_filepath(tc.relname::regclass), pg_size_pretty(pg_relation_size(tc.relname::regclass)) from pg_class tc, pg_namespace tn, pg_tablespace tt where tn.oid = tc.relnamespace and tt.oid = tc.reltablespace and relname = 'test1';
relname nspname spcname pg_relation_filepath pg_size_pretty test1 public test pg_tblspc/19846/PG_9.5_201510051/19697/20281 40 kB (1 row)
mydb=# db
List of tablespaces Name | Owner | Locationpg_default apple pg_global apple test postgres /usr/local/pgsql/test_name_space (3 rows)
2019-07-17 22:02:32赞同 展开评论 打赏 -
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
