Postgresql内存表

前端之家收集整理的这篇文章主要介绍了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掉),那么表里面的内容会清空(表还是存在的),不过此特性体现在写速度还不错,不过还是不是真正意义上的内存表的机制,

原文链接:https://www.f2er.com/postgresql/196799.html

猜你在找的Postgre SQL相关文章