Postgresql内存表

目前Postgresql9.X以前版本里并没有什么内存表创建，不像MysqL一样，有相关的创建语句。目前网上更多的是采用系统的方式。

也就是创建一个目录，然后加载到内存区里，然后让Postgresql的表空间映射到此目录即可。

特将相关的命令转发过来：

mount -t ramfs swap /tmp/ram
chown -R postgres /tmp/ram
CREATE TABLESPACE ramtablespace LOCATION '/tmp/ram';
CREATE TABLE ramtable(id serial primary key USING INDEX TABLESPACE ramtablespace) TABLESPACE ramtablespace;

如果加载到内存里的话，就不能随便删除。
加载命令是:

mount -t ramfs none /RAM1/ -o maxsize=10000
首先要创建一个目录，这里是RAM1目录
删除时，如图：

多次运行mount命令会覆盖之前的内容。

关于ramfs的特点如下：

好处：内存，当然有着极高的读写速度，操作时通用文件系统接口

应用场景：对文件系统读写频繁，文件不大的地方！

坏处：一旦down机，需要重新运行挂载命令，信息将不存在
使用心得：
常规操作很快(insert/update/delete)，但是有时候就将无法正常启动，报错信息如下：
[root@chenyi3 16422]# /etc/init.d/postgresql-9.1 start
Starting Postgresql 9.1:
waiting for server to start........ stopped waiting
pg_ctl: could not start server
Examine the log output.
Postgresql 9.1 did not start in a timely fashion,please see /opt/Postgresql/9.1/data/pg_log/startup.log for details
[root@chenyi3 16422]#

日志里的内容如下：
[root@chenyi3 pg_log]# cat postgresql-2011-12-01_154553.log
2011-12-01 15:45:53 CST LOG: database system was interrupted while in recovery at 2011-12-01 15:41:33 CST
2011-12-01 15:45:53 CST HINT: This probably means that some data is corrupted and you will have to use the last backup for recovery.
2011-12-01 15:45:53 CST LOG: database system was not properly shut down; automatic recovery in progress
2011-12-01 15:45:53 CST LOG: consistent recovery state reached at 0/2650890
2011-12-01 15:45:53 CST LOG: redo starts at 0/2650890
2011-12-01 15:45:53 CST FATAL: tablespace 16447 is not empty
2011-12-01 15:45:53 CST CONTEXT: xlog redo drop ts: 16447
2011-12-01 15:45:53 CST LOG: startup process (PID 17895) exited with exit code 1
2011-12-01 15:45:53 CST LOG: aborting startup due to startup process failure

解决方式：
重新运行挂载命令：mount -t ramfs none /RAM1/ -o maxsize=10000

另一种方式是tmpfs的方式

命令如下：

mount tmpfs /RAM2/ -t tmpfs -o size=10M

不管是使用ramfs还是tmpfs，必须明白的是，一旦系统重启（这里是指机器重启，并不是postresql应用重启），它们中的内容将会丢失。所以那些东西可以放在内存文件系统中得根据系统的具体情况而定。
目前还需要找些其他的替代方式。
目前有一种第三方的工具pgfincore（用于9.1以前的版本），就是用来避免这种失效问题。目前我还没用过这个东东，接着会体验下这个工具。

目前在9.1以后的版本（包含这个版本），已经有了新特性UNLOGGED出来（可以提高写的速度），如下：

UNLOGGED

If specified,the table is created as an unlogged table. Data written to unlogged tables is not written to the write-ahead log (seeChapter 29),which makes them considerably faster than ordinary tables. However,they are not crash-safe: an unlogged table is automatically truncated after a crash or unclean shutdown. The contents of an unlogged table are also not replicated to standby servers. Any indexes created on an unlogged table are automatically unlogged as well; however,unloggedGiST indexesare currently not supported and cannot be created on an unlogged table.

UNLOGGED特性是在创建表的时候使用。语法如下：

CREATE [ [ GLOBAL | LOCAL ] { TEMPORARY | TEMP } | UNLOGGED ] TABLE [ IF NOT EXISTS ] table_name ( [
  { column_name data_type [ COLLATE collation ] [ column_constraint [ ... ] ]
    | table_constraint
    | LIKE parent_table [ like_option ... ] }
    [,... ]
] )
[ INHERITS ( parent_table [,... ] ) ]
[ WITH ( storage_parameter [= value] [,... ] ) | WITH OIDS | WITHOUT OIDS ]
[ ON COMMIT { PRESERVE ROWS | DELETE ROWS | DROP } ]
[ TABLESPACE tablespace ]

详细文档参考网址： http://developer.postgresql.org/pgdocs/postgres/index.html

接着我在9.1的版本上体验下这个新特性，后面会给出测试结果。该特性用来不错，正常关闭系统和启动，表里面的内容不会删除，但是一旦是非正常关闭（如kill掉），那么表里面的内容会清空（表还是存在的），不过此特性体现在写速度还不错，不过还是不是真正意义上的内存表的机制，

Postgresql内存表

猜你在找的Postgre SQL相关文章