如题
回复于：2005-04-10 06:59:25
谁说数据库效率高的？
回复于：2005-04-10 22:48:16
数据库用很多CACHE技术.
回复于：2005-04-11 04:25:30
CACHE
回复于：2005-04-11 09:29:02
数据库是direct IO
不是用普通的read\write
并且有很多cache
回复于：2005-04-11 09:49:22
What's the meaning of "direct I/O"?
回复于：2005-04-11 09:56:27
我只知道大型数据库用raw IO，绕过文件系统直接和驱动层打交道，速度能提高不少。
回复于：2005-04-11 10:48:39
引用：原帖由 "aero"]What's the meaning of "direct I/O"?
发表：
就是bleem1998和albcamus所说的，
绕过了文件系统，读写数据并不是用read和write系统调用，
看这个。
回复于：2005-04-11 10:50:35
Thank you, I got it.
回复于：2005-04-11 12:01:33
引用：原帖由 "lenovo" 发表：
绕过了文件系统，读写数据并不是用read和write系统调用，
看这个。
绕过了文件系统读写数据就不用read、write了？那你怎么操作裸设备？汇编？
回复于：2005-04-11 12:10:36
direct-io也用系统调用read, write吧。
哪个数据库不用系统调用读写文件，而自己读写磁盘？ 请给出具体例子。
回复于：2005-04-11 12:55:51
不是传统意义上的read/write了
没有了VFS维护的各种cache和buffer
即使没有ext3之类的日志文件系统
如果出现掉电数据也不会丢失
回复于：2005-04-11 12:59:49
嗯，不经过陷入内核，数据在外设和用户空间之间直接传输。
组成原理忘了大半了，似乎跟DMA控制有关吧？
回复于：2005-04-11 13:38:29
引用：原帖由 "思一克" 发表：
direct-io也用系统调用read, write吧。
哪个数据库不用系统调用读写文件，而自己读写磁盘？ 请给出具体例子。
你说的对，我理解错了。 :oops:
不过具体的我也不懂，到底数据在数据库
和硬盘之间是怎么传输的。是使用DMA吗？
回复于：2005-04-11 13:50:51
To lenovo,
我也不是很清楚，我也不熟悉DB。只是觉得不大相信和明白
回复于：2005-04-11 13:57:22
牺牲空间换取时间呗。
回复于：2005-04-11 19:52:53
第一次听说数据库比文件系统效率高。
正常情况读写文件系统比数据库快一到两个数据级
回复于：2005-04-11 21:37:54
数据库通过主要两种途径提高ＩＯ性能．
１．把ＩＯ动作尽可能的在自己的ＢＵＦＦＥＲ里面实现，对于必须的物理ＩＯ操作，通过对要写入的数据的预先组织（预先读取，按物理顺序排队，分块写入，小数据量写入等操作实现，比如对Ｐ－ＬＯＧ和ＬＯＧＩＡＬ ＬＯＧ）．
２．对于物理ＩＯ动作，ｄｂ可以通过ＲＡＷ／ＣＯＯＫＥＤ设备来实现，在ＲＡＷ设备上操作的话，ＤＢ自己管理设备以及数据在ＲＡＷ设备上的存储细节，也就是说ＤＢ对于实际的物理存储是了解的，比如说，有２块ＤＥＶＩＣＥ，上面各自分别有２个ＲＡＷ ＤＥＶＩＣＥＳ，那么ＤＢ可以用２个ＴＨＲＥＡＤ在２个ＤＥＶＩＣＥ上面同时动作，对于同一ＤＥＶＩＣＥ上面的ＬＯＧＩＣＡＬ ＶＯＬＵＭ，ＤＢ对数据的预先安排可以大大提高ＩＯ性能．而文件系统上的ＩＯ由于有ＤＯＵＢＬＥ－ＢＵＦＦＥＲ，所以数据库所有对ＩＯ的优化基本上没作用（因为ＤＢ的ＢＵＦＦＥＲ通常比ｏｓ的ｉｏ ＢＵＦＦＥＲ大的多，当ＤＢ ＢＵＦＦＥＲ对应的ＯＳ ＢＵＦＦＥＲ映射失败的时候，ＩＯ就要通过物理ＩＯ来完成了，并且ＤＢ并不知道实际的ＩＯ操作在物理设备上的实现细节（比如文件系统在物理设备上的位置））．
３．所有物理的ＩＯ动作最后还是对应到了ＲＥＡＤ／ＷＲＩＴＥ操作，只不过在ＲＡＷ方式下的ＲＥＡＤ／ＷＲＩＴＥ是对设备直接操作的，不需要借助于文件系统实现．
回复于：2005-04-11 22:46:29
引用：原帖由 "北京野狼" 发表：
第一次听说数据库比文件系统效率高。
正常情况读写文件系统比数据库快一到两个数据级
严重同意！
回复于：2005-04-11 23:56:35
主要原因是CACHE, 有空档才读写 I / O, DIRECT I/O相信是避免其它不明因素影响读写的完整性.
回复于：2005-04-12 11:21:40
DIRECT-IO如果自己不buffer一定比普通IO慢。
数据库自己要BUFFER。
它也用系统调用read, write, open, close等，只是不用OS的buffer.
//一个简单DIRECT-IO例子 (linux i386)。 JOHN SEEKER
#include ;
#include ;
#include ;
#include ;
#include ;
#define _XOPEN_SOURCE 600
#include ;
//int posix_memalign(void **memptr, size_t alignment, size_t size);
//#include ;
char buf[4096] = "123456kasf dklasfkasfkldkladsfklafskldsfkl";
char buf1[256];
main()
{
int fd;
int i, r;
char *bp;
r = posix_memalign(&bp, 512, 4096*8);
printf("r = %d\n", r);
memcpy(bp, buf, 4096);
fd = open("data", O_CREAT | O_RDWR | O_TRUNC | O_DIRECT, 0644);
printf("fd = %d\n", fd);
r = write(fd, bp, 4096);
printf("%d bytes written.\n", r);
close(fd);
}
回复于：2005-04-12 11:50:11
长见识!!呵呵
请教几个问题，再劳烦思兄一下：
1, 象传统的write系统调用，通过文件系统象磁盘文件写数据，写入的过程是在内核态中完成的；上面的这个程序是不是?
2, 你说的“不用OS的buffer”，是什么意思呢？APUE把write/open这些系统调用称为“unbuffered IO”（与标准C库相比），跟你的意思有何区别呢？
Sorry，这个问题一直没弄明白 :D
回复于：2005-04-12 11:55:19
引用：原帖由 "思一克"]
发表：
你有这个经历，干嘛不试试读写一个文件，和读写数据库
到底速度差别多少
回复于：2005-04-12 11:56:11
数据库的特性决定了它在进行写操作的时候必须确实写物理磁盘，而不能使用延时写的方式。当然写入的内容可以放在cache中方便下次读取。
否则使用write等api，实际上os内部还是有buffer的，如果这个时候crash了，事务又已经提交了，但是具体的log没有更新到磁盘上，数据就corrupt了，recover都没有机会。
回复于：2005-04-12 11:59:41
To albcamus,
2). 之所以read write 叫UNBUFFER/IO是和fread, fwrite比，因为后者有自己在函数库中的BUFFER。前者直接交给OS，无库BUFFER。但OS中有PAGE BUFFER（linux的buffer_head等结构）。比如write写文件，不是一定写到盘上（比如你写了，然后硬关电，数据可能丢失）。
1). direct/io饶过了OS page buffer,调用驱动将数据直接写盘。所以应该不怕关电。
DIRECT/IO和普通IO写盘调用的驱动完全相同，调用的系统调用相同（除了O_DIRECT项目外）。对用户几乎是透明的。
回复于：2005-04-12 11:59:52
引用：原帖由 "linux_newbie" 发表：
否则使用write等api，实际上os内部还是有buffer的，如果这个时候crash了，事务又已经提交了，但是具体的log没有更新到磁盘上，数据就corrupt了，recover都没有机会。
你的意思是不是说，文件系统的日志功能是不可靠的? 因为日志未必总是与磁盘上的保持同步。
有点理解了。。
回复于：2005-04-12 12:03:06
谁知道怎样mount一个direct I/O的文件系统
solaris就可以
linux可以咩
回复于：2005-04-12 12:04:10
还有两者读写文件都是在KENREL中执行的，但DIRECT/IO DIO是直接将数据搞到用户的BUFFER，而普通IO先搞到page buffer, 再COPY到用户buffer.
所以如果仅仅写一次一个文件DIO应该快，但对于一般的文件操作（读写，SEEK，再读写），因为无PAGE BUFFER，DIO应该慢许多。
回复于：2005-04-12 12:07:26
引用：原帖由 "思一克" 发表：
还有两者读写文件都是在KENREL中执行的，但DIRECT/IO DIO是直接将数据搞到用户的BUFFER，而普通IO先搞到page buffer, 再COPY到用户buffer.
所以如果仅仅写一次一个文件DIO应该快，但对于一般的文件操作（读写，SE..........
一般的文件，读写，SEEK，再读写，仍然比数据库快的多。
回复于：2005-04-12 12:21:35
谁知道怎样mount一个direct I/O的文件系统
是不是用raw命令？
回复于：2005-04-12 12:39:56
>;>;你的意思是不是说，文件系统的日志功能是不可靠的? 因为日志未必总是与磁盘上的保持同步。
应该是你write成功了不见得就确实磁道记录了。 不是有个工具sync 30秒运行一次吗？
回复于：2005-04-12 12:45:20
引用：原帖由 "思一克"]还有两者读写文件都是在KENREL中执行的，但DIRECT/IO DIO是直接将数据搞到用户的BUFFER，而普通IO先搞到page buffer, 再COPY到用户buffer.
发表：
旷若发懵啊。多谢多谢!!
前阵子看page buffer和io调度，头都大了，早问您就好了。。
回复于：2005-04-12 13:00:49
To albcamus,
你过奖了。我都是临时实验（学习）的。原来也不是知道多少
回复于：2005-04-13 14:35:08
以 Oracle 为例
1。读
使用数据库有时候比file 要慢
比如说第一次使用某个数据时，Oracle肯定会比直接读file慢
但是，如果第二次要用到这个数据，Oracle直接从mem里读取，这样就比file要快
2。写
Oracle对data update / insert 的确是可以延迟写到磁盘的
它是先在mem里作修改，再由专门的dbwr 来写数据到磁盘。
3。个人认为，数据库和文件并不存在可比性
用文件，很难实现sql语句。
但是，使用数据库会耗用更多的系统资源。
回复于：2005-04-13 15:01:31
引用：原帖由 "rollingpig" 发表：
以 Oracle 为例
1。读
使用数据库有时候比file 要慢
比如说第一次使用某个数据时，Oracle肯定会比直接读file慢
但是，如果第二次要用到这个数据，Oracle直接从mem里读取，这样就比file要快
2。写
Oracle对data..........
无论第几次读写，数据库都无法和文件系统的速度比较。
在普通的PC机器上，各自只有一行记录比较。如果是mysql会比文件系统慢30到50倍
要是采用oracle就更慢，至少差别70,80倍
回复于：2005-04-13 18:50:17
文件系统总是比较快的。不用一再强调数据库的Cache，文件操作时OS也使用了Cache机制，在回忆回忆Unix原理课本中的内容？。
回复于：2005-04-13 21:45:35
都是从那里得出的数据库直接读写慢的结论?
如果是有数量级的差别的话，数据库厂家早就倒闭了.
还30~40,70~80的数量级差别呢.
单纯一条记录如果有这么大的差别的话,只能说明数据库的应用设计有问题.文件系统的DATA BUFFER肯定没有DATABASE的效率高,文件系统的PAGE BUFFER在DATABSE也有实现,并且比文件系统的PAGE BUFFER优化了很多,比如DATABASE采用了并发物理IO的算法,在文件系统里面是没有的.数据库系统的物理IO的排队机制是自身实现的,在调用DRIVER读写的时候,效率要比PAGE BUFFER的高(DATABASE参与的工作单位多,而PAGE BUFFER只有一个工作单位).
DATABASE比文件系统消耗资源多,但是能处理的数据能力是文件系统不能比拟的?DATABASE可以实现T级数据量的ONLINE并发访问,文件系统也能?
DATABASE对实际物理设备的可并发操作性有要求,那是因为他自身的机制比文件系统复杂,也就是说,在单一一块设备上的DATABASE没有优势,但是如果设计的合理的话,DATABASE的性能和文件系统不在一个档次上.(比如一个TABLE可以设计成跨越多个DEVICE,并且应用的设计者有效的使用了DATABASE的优化机制的话,那么不管如何读写,DATABASE的效率都要比文件系统高).但是,你不能拿DATABASE的顺序读写和文件系统按位置读写的比较,因为这是数据库应用系统设计者的问题,不是数据库本身的问题.
回复于：2005-04-13 23:49:33
就随机数据的突发读取而言，肯定是数据库慢。
但问题是简单的文件访问的话，你能在数百G数据中迅速找到你要的数据吗？你能迅速地删除数据吗？你能有效处理尺寸跨度极大的变长数据吗？你能实现并发版本控制吗？......
当你的程序实现了这些的时候，你随机数据读取的效率恐怕还不如现在这些成熟的数据库呢。
回复于：2005-04-14 10:50:52
引用：原帖由 "柳五随风" 发表：
都是从那里得出的数据库直接读写慢的结论?
如果是有数量级的差别的话，数据库厂家早就倒闭了.
还30~40,70~80的数量级差别呢.
单纯一条记录如果有这么大的差别的话,只能说明数据库的应用设计有问题.文件系统的DATA..........
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也高不到那里去．
你列出那些资料可能都毫无意义，数据库的查询，大量并发的时候可能最浪费时间的是connect和close，数据库的优势是体现的大量数据的查询、统计以及并发读写，不是在速度上．
回复于：2005-04-14 11:12:37
引用：原帖由 "北京野狼" 发表：
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也?.........
个人比较赞同这个观点。。。
回复于：2005-04-14 11:37:00
俺们这里就是三大DATABASE的厂家之一.
另外,我谈的是数据库ENGINE的IO问题,不是数据库系统应用的问题,比如我用STORAGE PROCEDURE实现的话,基本不需要考虑CONNECT/CLOSE的问题.
另外DATABASE ENGINE自身的IO操作也可以看做和本地FILESYSTEM操作等同的.
至于你作的实验假设,需要考虑IO分布问题,我说了,单一设备两者差别很小,到IO并发情况下,我测试过,性能大约和设备数量成正比的(在IO可以并发的情况下).
如果非要拿应用DATABASE环境和文件系统比较的话,那么也应该是和NFS,JFS,GFS.XFS等比较.
回复于：2005-04-14 16:59:42
引用：原帖由 "柳五随风" 发表：
俺们这里就是三大DATABASE的厂家之一.
另外,我谈的是数据库ENGINE的IO问题,不是数据库系统应用的问题,比如我用STORAGE PROCEDURE实现的话,基本不需要考虑CONNECT/CLOSE的问题.
另外DATABASE ENGINE自身的IO操作也?.........
总算遇到一个真做数据库的 :D
我问个问题对于一个没有主键没有索引的大表。我数据库不是很熟悉。
select出一条再有什么BUFFER，难道不是遍利大文件？还有什么捷径？
回复于：2005-04-14 17:15:48
只要没有索引
任何操作都要遍历整个表
术语大约叫做：full table scan
除非你用了sql server里的top之类的东东
:)
回复于：2005-04-14 19:21:08
引用：原帖由 "北京野狼" 发表：
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也?..........
又一个喜欢透过现象“想”本质的，事实可以作证，这种思维通常都是错误的。
如果你真的想了解这两者之间的差别，建议你认真的找一点资料看看，了解一下什么叫做文件系统，什么叫做数据库。只有当你真正的理解了这两者的区别与他们之间的联系，我想你真正有资格去评判这两者的优缺点。
回复于：2005-04-14 20:50:09
引用：原帖由 "sunsroad" 发表：
又一个喜欢透过现象“想”本质的，事实可以作证，这种思维通常都是错误的。
如果你真的想了解这两者之间的差别，建议你认真的找一点资料看看，了解一下什么叫做文件系统，什么叫做数据库。只有当你真正的理解?.........
你有什么理论就说出来，没话说就回家去睡觉。
回复于：2005-04-14 21:14:47
FULL TABLE SCAN
SCAN的是TABLESPACE,不一定就是大文件,也可以是RAW DEVICE.
另外:大表上面没有INDEX(不管是存储索引(B-TREE等),还是算法索引(比如HASH算法)的话,只能是FULL TABLE SCAN了，性能非常差.不推荐这样使用.小的静态表可以是FULL TABLE SCAN的,对性能没影响,甚至稍微好一点.
回复于：2005-04-14 22:42:00
引用：原帖由 "柳五随风" 发表：
FULL TABLE SCAN
SCAN的是TABLESPACE,不一定就是大文件,也可以是RAW DEVICE.
另外:大表上面没有INDEX(不管是存储索引(B-TREE等),还是算法索引(比如HASH算法)的话,只能是FULL TABLE SCAN了，性能非常差.不推荐这..........
那我理解数据库无论如何也不能赶的上文件系统。
数据库可能在文件查找的方法更有效一些。
我刚写了程序试验，的确数据库比文件系统速度差别很大啊
回复于：2005-04-14 23:47:03
:)
你能在DATABASE ENGINE里面测试?:),恐怕还是在应用级别上吧?:)
我说了,用DATABASE应用和本地文件系统相比较,不公平,即使要比较的话,也是要在海量数据级上比较.另外DATABASE是面向关系运算的,所以你也得在这上面比较.你总不能拿DATABASE当文件系统用吧?:)
回复于：2005-04-15 00:08:19
谁说的数据库的IO效率高？IO永远是计算机心中的痛！
不管是操作系统，还是数据库，概么能外。
回复于：2005-04-15 01:53:06
我看过有书说大型数据库改写了操作系统的磁盘io部分
回复于：2005-04-15 11:24:33
引用：原帖由 "柳五随风" 发表：
:)
你能在DATABASE ENGINE里面测试?:),恐怕还是在应用级别上吧?:)
我说了,用DATABASE应用和本地文件系统相比较,不公平,即使要比较的话,也是要在海量数据级上比较.另外DATABASE是面向关系运算的,所以你也得在这..........
我不太理解，为什么不能在应用级别比较，而且为什么一定要比海量的．
测试两辆车那个跑的快当然去马路上跑，让我去比较发动机的好坏，我即没那能力，也没必要啊．
你肯定比我知道数据库存储数据的格式，大量数据的数据库和大量数据库的文件，比如文件格式，每行定长的，只要给一个类似数据库索引的信息，去第几行找，肯定也比数据库快得多
回复于：2005-04-16 12:35:39
文件系统和数据库文件这是两回事，数据库的文件可以建立在文件系统上也可以建立在RAW 设备上。如果建立在文件系统上，数据库的读写必然要经过文件系统，这样比没有可比性。
回复于：2005-04-18 10:43:45
引用：原帖由 "fengwy"]文件系统和数据库文件这是两回事，数据库的文件可以建立在文件系统上也可以建立在RAW 设备上。如果建立在文件系统上，数据库的读写必然要经过文件系统，这样比没有可比性。
发表：
其实很多时候非常需要比较的．系统设计时候，很多时候需要选择信息是存储在数据库里面还是在文件里．
回复于：2005-04-18 13:46:56
引用：原帖由 "北京野狼" 发表：
我不太理解，为什么不能在应用级别比较，而且为什么一定要比海量的．
测试两辆车那个跑的快当然去马路上跑，让我去比较发动机的好坏，我即没那能力，也没必要啊．
你肯定比我知道数据库存储数据的格式，大量?.........
个人支持这种观点，也对这位兄台的风格很欣赏。
这个问题争起来其实没有多大的意思，数据库也好，文件也好，说起都是一样的东西，数据库不也是文件吗？所以从应用的角度上来看，数据库读写相对直接文件读写来说要做许多额外的工作，所以看上去直接操作文件更快，我们的应用除非必要否则就不用数据库，效率确实低，我们的数据也不算多，一般不会过亿，
说数据库好的同志不要生气，这是肯定的因为数据库的锁很浪费资源，而且日至也占用资源，这里并不是说数据库慢，尽管它的确慢，但是慢是有原因的。
谁能举例说明数据库比操作文件快？有索引的情况下查询数据吗？还是别的？
楼上的楼上的楼上。。说什么本质了，本质是什么？还不是存储的读写速度？
回复于：2005-04-18 17:15:30
引用：原帖由 "北京野狼" 发表：
你有什么理论就说出来，没话说就回家去睡觉。
我申明：恕我不与井蛙鼓噪。
回复于：2005-04-18 17:17:36
首先，我希望大家搞清楚我们所讨论的本质：不是说数据库将系统I/O的速度提高，而是说其效率要高过文件系统，这两者是有区别的。对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。数据库跟文件系统也有这方面的区别。如果你可以认可并理解NTFS跟UFS或者VXFS有不同的效率的话，你就应该可以明白文件系统跟数据库之间的差别。
其次，我认为大家在讨论一个事情的时候，能够首先了解事物的本质，能够明白我们是在说什么事情，在把事物的什么特性做比较。其实如前面那位兄弟说的，可能你在读写操作一个记录的时候感觉文件系统更加快一些，但是你并没有将你所做的测试环境描述出来：你的数据库是用的裸设备还是文件系统？如果是文件系统的话，那这是很明确的，数据库一定不会快过文件操作。因为你在打开数据库的时候首先要打开文件，也就是说：你所说的数据库的操作时间其实是文件操作跟数据库操作的总和。还有，丢开这个不说，你设计的这个试验也是有问题的：打开与关闭一个文件并不是数据库的全部，当然也不是文件系统的全部，还有很多其他的事情要做，譬如插入、检索，删除。对于一个事物的好坏应该全面的分析其每一个特性之后作出全面的判断，而不是断章取义的进行极端情况下的诡辩。我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统？！用户好象也没有都那么傻，花几十万去买一个无用的东西。我知道你要问的问题，裸设备，既然裸设备快，为什么不用裸设备？！因为裸设备的管理太麻烦，或者是因为用户的问题:他根本就没有管理裸设备的能力，或者是因为人的问题：即使是能管理裸设备，但他不想那么麻烦，或者是其他的原因：譬如用户要求利用文件系统进行数据库系统的备份，等等。不用裸设备是有理由的。
再次，其实文件系统跟数据库之间也是有一些相似的东西的，他们之间虽然有很大的区别，但也会有很多关系。不管是使用文件系统，还是使用裸设备。跟文件系统一样，数据库也是对其上层（下层）的设备（裸设备或者是文件系统）的一个抽象，是在其上层（下层）设备上建立的一个数据结构。只是他的组织比我们在具体的语言中学习到的结构更加复杂一些。
最后，我还是建议大家在分析这个问题之前，把数据库跟文件系统的本质的东西了解一下。我相信一旦你真正的理解了他们的本质，你就会认同我的这句话：数据库实质上也是一个特殊的文件系统，只是其重点不在跟人交互，而是在跟数据库管理系统交互。
注:其一我是搞系统的，不是搞数据库的，所以我不通晓数据库的管理知识。所以不要跟我讨论如何管理数据库系统。其二我这里提到的效率就是指数据库系统在操纵数据方面的效率，请大家不要再做引深，任何引深恕我不作回应。其三，我愿跟任何愿意理性的考虑问题，文明交流的朋友进行真诚的交流，但对于无礼的冒犯恕我将...。
回复于：2005-04-18 17:31:37
请教各位一个基础问题
linux下怎样创建一个direct I/O的文件系统?
回复于：2005-04-18 17:38:25
引用：原帖由 "sunsroad" 发表：
首先，我希望大家搞清楚我们所讨论的本质：不是说数据库将系统I/O的速度提高，而是说其效率要高过文件系统，这两者是有区别的。对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。数据库跟文件系统也有这方面的区别。如果你可以认可并理解NTFS跟UFS或者VXFS有不同的效率的话，你就应该可以明白文件系统跟数据库之间的差别。
其次，我认为大家在讨论一个事情的时候，能够首先了解事物的本质，能够明白我们是在说什么事情，在把事物的什么特性做比较。其实如前面那位兄弟说的，可能你在读写操作一个记录的时候感觉文件系统更加快一些，但是你并没有将你所做的测试环境描述出来：你的数据库是用的裸设备还是文件系统？如果是文件系统的话，那这是很明确的，数据库一定不会快过文件操作。因为你在打开数据库的时候首先要打开文件，也就是说：你所说的数据库的操作时间其实是文件操作跟数据库操作的总和。还有，丢开这个不说，你设计的这个试验也是有问题的：打开与关闭一个文件并不是数据库的全部，当然也不是文件系统的全部，还有很多其他的事情要做，譬如插入、检索，删除。对于一个事物的好坏应该全面的分析其每一个特性之后作出全面的判断，而不是断章取义的进行极端情况下的诡辩。我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统？！用户好象也没有都那么傻，花几十万去买一个无用的东西。我知道你要问的问题，裸设备，既然裸设备快，为什么不用裸设备？！因为裸设备的管理太麻烦，或者是因为用户的问题:他根本就没有管理裸设备的能力，或者是因为人的问题：即使是能管理裸设备，但他不想那么麻烦，或者是其他的原因：譬如用户要求利用文件系统进行数据库系统的备份，等等。不用裸设备是有理由的。
再次，其实文件系统跟数据库之间也是有一些相似的东西的，他们之间虽然有很大的区别，但也会有很多关系。不管是使用文件系统，还是使用裸设备。跟文件系统一样，数据库也是对其上层（下层）的设备（裸设备或者是文件系统）的一个抽象，是在其上层（下层）设备上建立的一个数据结构。只是他的组织比我们在具体的语言中学习到的结构更加复杂一些。
最后，我还是建议大家在分析这个问题之前，把数据库跟文件系统的本质的东西了解一下。我相信一旦你真正的理解了他们的本质，你就会认同我的这句话：数据库实质上也是一个特殊的文件系统，只是其重点不在跟人交互，而是在跟数据库管理系统交互。
注:其一我是搞系统的，不是搞数据库的，所以我不通晓数据库的管理知识。所以不要跟我讨论如何管理数据库系统。其二我这里提到的效率就是指数据库系统在操纵数据方面的效率，请大家不要再做引深，任何引深恕我不作回应。其三，我愿跟任何愿意理性的考虑问题，文明交流的朋友进行真诚的交流，但对于无礼的冒犯恕我将...。
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？
回复于：2005-04-18 18:08:18
引用：原帖由 "wangyih" 发表：
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念？它有它自个的格式！附件是没有办法从文件中提取出来的！！我并没有告诉你什么都要用数据库系统，因为数据库系统对人的交互并不友好，它所擅长的是数据的操纵？我可以告诉你邮件系统对数据操纵的要求是很低的！！
希望你在回复的时候能够看清楚帖子的意思，为一个意识形态争吵是短视的，更是可悲的。
其次，我怕你根本就不了解什么是文件系统，跟你的讨论不会有什么结果的：对牛弹琴而已。所以我后面拒绝跟你讨论，这个观念我已经在我发表的第二贴表达了，自重！！
回复于：2005-04-18 18:09:15
引用：原帖由 "wangyih" 发表：
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法从文件中提取出来的，从数据库中提取有成本的考量！！我也并没有告诉你什么都要用数据库系统，因为数据库系统对人的交互并不友好，它所擅长的是数据的操纵？我可以告诉你邮件系统对数据操纵的要求是很低的！！既然数据库系统不能给它带来什么好处，又要增加费用，为什么一定要选用数据库系统？！！
希望你在回复的时候能够看清楚帖子的意思，怕是你根本就没有看完我的帖子。为一个意识形态争吵是短视的，更是可悲的。我拒绝这种争吵。
其次，我怕你根本就不了解什么是文件系统，既然如此跟你的讨论也不会有什么结果：对牛弹琴而已。所以我后面拒绝跟你讨论，这个观念我已经在我发表的第二贴表达了，自重！！
回复于：2005-04-18 20:58:17
引用：原帖由 "sunsroad" 发表：
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法?.........
无论多大的邮件系统都不采用数据库存储邮件。国内有比sina更大的吗。
邮件系统就是是一堆文件组成的系统
邮件不选用数据库系统就是因为效率的问题。
邮件系统对数据操纵的要求非常高，你知道sina一天有上亿封邮件吗？
邮件系统的格式就是存文本，附件就是从文件中提取出来的。
数据库系统对人的交互比文件系统友好的多
真是难为你一个帖子能说出这么多错误，没一句对的。
而且你是不是脑子有问题，什么都不懂上来和谁都想吵架
回复于：2005-04-18 23:48:18
引用：原帖由 "sunsroad"]对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。
发表：
我很赞同这位兄台的这种观点，但是不敢苟同下面这种观点
引用：原帖由 "sunsroad"]我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统?
发表：
我觉得用户选择数据库而不是文件，是因为易操作性，并发处理，安全，开发成本等方面的考虑，而不是效率高。
回复于：2005-04-19 12:34:39
引用：原帖由 "sunsroad" 发表：
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法?..........
其一、因为文件系统在数据读写方面的效率上远远于高数据库，数据库的众多特性决定无论在什么情况下其效率一定要比文件系统低几个档次。那为什么还要花很多钱买数据库呢，因为有如此众多的特性，关系、事务、回滚、触发、并发、安全等，要文件系统支持这些也可以，但是需要再开发，那就成为另一个数据库了，特性越多效率也就越低。如果你说要把所有特性都除去再比，那还是一个数据库吗？
其二、正文和附件没有理由不能存入数据库的，可以重新封装邮件数据进行存储，只是读写效率和空间利用率都低得可怕，而数据库众多优秀的特性一个都用不上。
以上所指的读写效率都不是说设备的读写能力有变化，而是文件系统和数据库能利用多少设备的读写能力。就象一个程序能利用CPU100%，而另一个只能利用50%因为有其它的瓶颈在。数据库在读写方面的效率低就是因为有众多的特性造成的，所以我觉得让文件系统和数据库来比没有什么意义。让它们都在合适的地方做合适的事就是最好的。
回复于：2005-04-19 13:16:59
这样实验是合理的吧，
有一个100M数据库文件F1（足够大），
REBOOT系统确保它没有任何部分在OS BUFFER中，和在DATABASE BUFFER中。
1）然后有数据库将它打开，做一个复制操作，产生另一个内容相同的文件F2
重复REBOOT
2）用fread, fwrite, 或cp做一个复制操作。
看哪个快？DB速度和OS速度应该在一个级别上，或许还慢些。
至于你比较复制第10000个记录，那DB有索引，OS无，这不是IO的问题，而是应用程序设计问题。
回复于：2005-04-19 20:58:17
好啊，开眼界，不过据我所知：
1、lotus notes就是利用数据库存放邮件的哦！
2、在海量数据处理时，无论谁快，都必须使用数据库！谁见过有人用系统文件存放海量数据并处理数据的？别说海量，超过几M的数据不用数据库就够你忙的！君不见光在桌面环境下就有许多数据库的使用吗？
所以啊，在应用的角度来看，不必讨论谁的速度快了，系统的作用就是系统，数据库的作用就是数据处理！
处理少量数据，你可以用系统文件，处理大量的数据，你不用数据库，那是你牛B!
回复于：2005-04-20 00:19:32
notes不是利用数据库存放邮件的，所谓notes邮件数据库，类似outlook的邮件，就是一个文件非叫数据库也成，但和oracle完全不同。notes会有多少用户一般几十几百而已。yahoo,sina的几十T的邮件都是完全存文本储存，这个问思一克 版主。
建议版主把这个帖子置定大家讲些笑话解闷算了。
一个说要给做本质的比较，但是却说不懂数据库，那本质在哪里?
再一个2003-09-19注册，2005-04-19 发第一个帖子就是这个。但是这几天CU出问题，正常的上下页可是很难找出这个帖子的。这么准，真是T MD的太牛了。
回复于：2005-04-20 02:24:19
单单比较速度是没有意义的，关键是什么才是数据库，什么是文件系统，两者之间本来就有不少灰色的区域，什么都不懂，也没有前提讨论这种问题实在是可笑 :D
数据库要有事务？文件系统也有日志，也可以回滚，而且也有不支持事务的数据库。
数据库有索引？文件系统没有么？大家用的索引技术其实也没有本质区别，按照某种方式组织的树而已
数据库可以读裸设备？不少数据库只能基于文件，而且文件系统本身就是读写裸设备，搞不好比数据库更加底层，呵呵
数据库有SQL，方便查询？这个文件系统倒没有，不过不支持SQL的数据库倒有不少，尤其是SQL还没有出现以前，哈哈，那时候的所有数据库都不支持SQL
cache？什么没有cache？文件系统本身也是层层cache。。。
嘿嘿，要吵架的人先搞懂了自己想问什么，是什么数据库和什么文件系统，储存什么数据，主要是什么操作，然后再慢慢吵吧 :em24:
回复于：2005-04-20 02:28:26
引用：原帖由 "wangyih" 发表：
无论多大的邮件系统都不采用数据库存储邮件。国内有比sina更大的吗。
邮件系统就是是一堆文件组成的系统
邮件不选用数据库系统就是因为效率的问题。
邮件系统对数据操纵的要求非常高，你知道sina一天有上亿封?..........
sina就别说了，邮件系统垃圾得要命，又慢又会丢信。某次我要发一个几十M的东西给新浪的员工，他说收不了。我很奇怪问，你们不是有G级邮箱？他的回答是，我自己不用这个。。。。。。
嘿嘿，还是gmail好 :lol:
回复于：2005-04-20 09:48:52
所以----有结论
1）DB的文件I/O不可能比OS快。
2）DB适合处理大量由记录构成的有关系的数据，文件系统不适合。
关于邮件系统---北京野狼 和PLAYMUD等说的对，
LOTUS NOTES存邮件其实不是DB，仅仅是MAILBOX的一种，就是将邮件存入一个大文件，他本质上不是数据库，仅仅名字而已。OUTLOOK EXPRESS， MS OUTLOOK都是如此做的。在邮件系统中，人们早以认识到，这是不好的办法，所以后来MAIL SERVER的格式大都由MAILBOX变为MAILDIR（直接用单独文件存放每个MESSAGE）。MAILDIR非常稳定，不怕掉电。MS为什么用MAILBOX？ 因为邮件都比较小，如果用MAILDIR，硬盘90%空间会浪费。
还有MAIL系统的可靠性，和抗XXX性是DB无法比的。比如一个配置的好的MAIL系统，可以多少年不用人工干预，其可靠性和CISCO的路由器相同。DB系统，你胡乱关电开电可以吗。
至于丢邮件等问题，是有其他原因的，不是MAIL SERVER的文件系统引起。
回复于：2005-04-20 11:41:01
引用：原帖由 "abcdfq" 发表：
好啊，开眼界，不过据我所知：
1、lotus notes就是利用数据库存放邮件的哦！
2、在海量数据处理时，无论谁快，都必须使用数据库！谁见过有人用系统文件存放海量数据并处理数据的？别说海量，超过几M的数据不用数..........
lotus notes最多算一个小型邮件服务，作为邮件服务放不上台面。
很多程序运行的时候都有临时文件会产生，没人会把这些信息往数据库里写作为为临时记录？因为慢！
操作系统的磁盘缓存有用文件的，有用裸设备的，为什么不用数据库？因为慢！
其实我们说数据库和文件系统的时候本身就有可能存在定义问题
干脆具体化，数据库中的oralce、mysql、mssql、db2等随便挑一个和文件系统中jfs、xfs、ufs、ext3、ntfs等相比，在相同的硬件环境中和操作系统环境中，往写数据库中读写10G的数据和文件系统中读写10G数据谁更快，数据随便组织。
最后为了重申不是说数据库不好，是数据库和文件系统都有自己适合的方面，作为单纯的读写效率来说，就是文件系统好。
回复于：2005-04-20 12:34:47
这是要看数据量和应用而定的。
不能简单说数据库就比文件高效。
数据库的b-tree结构查询比文件方便，但是插入比文件低效。
fopen一个文件显然比连接一个数据库要高效的多。
cache可以提高速度，但是迟早是要写回disk的。
raw-io,现在很多文件系统非常高效，例如linux上的ext3的读写速度不亚于rawio. 裸设备比文件系统读写速度快很多倍的说法已经过时了。就算快，也就是个10%左右。
回复于：2005-04-20 13:19:06
哎,"文件"与"数据库"根本就不是一个层次上的概念。数据库就是一个或若干个特殊格式的文件的集合。数据库的任何读取操作最终要转化为对文件的操作。数据库与文件的关系就象是mp3文件与文件的关系一样,也就是说,数据库也是文件!数据库文件由应用程序DBMS(相对OS而言,DBMS本质上就是一个普通的应用程序,尽管其大而复杂)识别和操作,MP3文件由MP3播放程序识别和操作,你自己定义的特定格式的文件由你自己编写的应用程序识别和操作!
也就是说,DBMS就相当于你自己编写的应用程序,DB就相当于你自己定义的特殊格式的文件或文件的集合. 不要跟我说数据库有什么cache啊等功能,说到底取决于DBMS这个应用程序想实现什么,我的意思是,DBMS能实现这些功能,我们自己的应用程序也能实现,因为大家都是应用程序! 虽然自己的程序实现DBMS所具有的功能不现实,我主要是想表明,数据库与文件根本就不是同一个层次的问题!不是同一层次的两种东西相互比较是不合逻辑的!
回复于：2005-04-20 13:32:40
是不是一个层次上的东西,但可以比较.尤其是有人需要存储某些文件时,是决定用DB存储,还是直接用OS文件?
就好像,fread()和read()不是一个层次上的函数,但人们还常常比较,因为有时要决定到底用哪一个.
回复于：2005-04-21 08:48:42
个人理解：
数据库，像oracle，其实实现了一种自己的日志文件系统，他直接对硬盘进行block级操作，而不是一般的文件级，他自己分配和管理这些block，日志就是记录了对这些block的读写操作，同日志文件系统相似，只要日志不损坏，就可以做到备份数据和数据的恢复。而且他是用了很多buffer，专门为数据库的操作设置了许多buffer区。我理解中的数据库就是一个为检索，存储，管理专门做了很多工作的文件系统。
回复于：2005-04-21 09:40:20
我不知道ORACLE的配置。
请专家给出ORACLE直接读写硬盘BLOCK的具体情况。
我要看看是否真是如此。
回复于：2005-04-21 09:44:42
数据库的效率主要还是体现在空间冗余和数据检索上吧．至于Ｉ／Ｏ还没有看见哪个数据库把它体现在性能特点上．
回复于：2005-04-21 09:55:45
bleem1998说的对，一些大型的数据库不使用OS的fs，而是自己的fs，同时对IO操作进行了cache、合并写入等优化措施，还通过进行查询优化减少IO访问。尽量提高访问效率。
回复于：2005-04-21 10:20:36
谁说大型DB用自己的fs? 举出例子。
看oracle是最好的大型DB吧。
看这个
如何是oracle运行的更有效率。
这里没说oracle有自己的fs
回复于：2005-04-21 11:00:50
但是据我了解，确实是这样的啊……使用raw，自己去做……
回复于：2005-04-21 11:46:25
你看我给的那个ORACLE连接,在LINUX上使用RAW是最慢的,使用EXT3是效率最高的.
ORACLE研制了自己的CLUSTER_FS,是为CLUSTER使用的.
我是说,给出例子和使用证据,
回复于：2005-04-21 13:26:18
再给一个权威的TEST结果
ORACLE的数据INPUT和OUTPUT
用ext3最快，ext2次之， 用RAWIO和OCFS（ORACLE自己的RAWFS）慢许多。
还是那句话，如果用朋友用ORACLE自己的OCFS，请给出例子和结果。
回复于：2005-04-21 16:13:29
呵呵，是啊，我只是说一种可能，大家都喜欢自己做fs，好像连mysql都有自己的fs。
不过现在很多fs也使用了数据库的高级技术（比如reiserfs也使用了b树），所以直接使用fs的接口可能比dbms自己的fs还要好用。dbms的fs主要使用b树，在检索方面很有优势，而单纯的io优化可能ext等os的fs更厉害些。
我本人没有对性能进行过对比，但感觉和兄台说的并不矛盾啊。我对dbms的fs设计没有什么研究，我自己开发的dbms的fs就是基于os fs的cellfs matrics，速度也是很快的：）
回复于：2005-04-21 16:51:12
所以，楼主的题目中的命题就不应该成立。
回复于：2005-05-06 20:21:11
数据库是用share memory做的
回复于：2005-05-06 23:06:41
引用：原帖由 "rainyor"]数据库是用share memory做的
发表：
倒！
回复于：2005-05-07 04:59:18
如果非要比较数据库和文件系统的效率，我想为了公平起见，还是在同一个层次上比较的好
1。如果在数据存取这个层次上比，我想因为oracle的确绕过了操作系统而用自己的方式来使用磁盘，当然因为不存在文件系统这一层，所以要比read和write快。
2。如果在应用层级上比，可以这样来做，同样是1000个学生的成绩纪录，从中抽取想要的纪录。一个用数据库实现，一个用文件系统来实现，数据库可以不使用索引，当然文件系统也不能使用辅助的查询信息，比如hash等。我们来比一下谁先找到结果。我想这种比较的结果不说大家也都知道，因为在IO的这一块，文件系统可是不如oracle的奥，再有你的搜索算法不见得比oracle的要强吧。
3。文件系统和数据库的应用领域也不同，如果是信息管理，现在会有人用文件系统自己作起么？对于定长纪录，如工业控制的现场采集数据，因其数据结构已经定死，所以一般都使用文件来存取数据，因为文件的随机存取的效率肯定要比数据库的查询效率要高（即使带索引）
回复于：2005-05-07 14:46:12
晕哦，大家都严重偏题了。
数据库与单纯的文件根本没有比较的必要。数据库有一些额外的操作，自然是跑不过直接的读写的，因为数据库不管利用了多少优化技术，最终还是要从硬盘中读写数据的。
其实数据库只是为了更有效的管理数据而产生的，它仅仅是将大量的数据以一定的格式保存在一个或者多个文件中。他的效率高高在在正常的应用下比你一条数据放在一个文件中高一些，方便一些，而不是高在读取文件上。
你将若干条数据放到一个文件中，所放入的这个文件加上你的读写等操作程序也可以说是构成了一个简单的文本数据库系统。
对于特定的应用，比如某些人提到的定长数据这种情况，你用自己开发的数据库系统（就是我前面提到的文本数据库）当然很可能会比其它的数据库系统来得更高效。
数据库利用文件保存数据，但所用来保存数据的一个或者多个文件是数据库的一部分，但却不是全部。我认为数据库和文件没有任何可比性，根本不是一个概念。
回复于：2005-05-07 15:04:43
就算非要将这两个本来就不是一个概念的东西拿来对比，也是根本无法比的。
有谁能测出数据库本身花在随机读写一万个文件所用的准确时间？你能看到的是总的时间吧？
同理你也不是无法知道你写的程序花在随机读写一万个文件所用的时间的，你所能得到的也是你的程序运行的总的时间，到底有多少时间是真正花在读写磁盘上面的你能算出来吗？而且你所用的这个总的时间也可能因为你所用的程序语言而有所不同。
早点休息吧，不用再在这里争吵了，如果有人坚持认为使用文件效率更高（也许应该说是使用他自己的程序来组织自己的数据＝自己的数据库系统），就用文件好了。
回复于：2005-11-07 17:55:40
初始化参数db_file_multiblock_read_count 影响Oracle在执行全表扫描时一次读取的block的数量.
db_file_multiblock_read_count的设置要受OS最大IO能力影响，也就是说，如果 你系统的硬件IO能力有限，
即使设置再大的db_file_multiblock_read_count也是没有用 的。
理论上，最大db_file_multiblock_read_count和系统IO能力应该有如下关系:
Max(db_file_multiblock_read_count) = MaxOsIOsize/db_block_size
当然这个Max(db_file_multiblock_read_count)还要受Oracle的限制，
其实使用文件还是数据库，完全取决于你的数据与用途，如果你有大量的数据需要做各种操作和分析，而且比较复杂，那当然还是数据库为最好的选择。
回复于：2005-11-07 19:08:54
怎么有这么垃圾的帖子？无语。
回复于：2005-11-07 19:46:56
估计楼主的机子都是一次性把所有的数据都读到内存，再去内存里找，这样真的很快
回复于：2005-11-08 11:02:00
数据库就是比文件要快！我测试过但是具体原因不太清楚
回复于：2005-11-08 14:40:40
引用：原帖由 北京野狼 于 2005-4-20 00:19 发表
notes不是利用数据库存放邮件的，所谓notes邮件数据库，类似outlook的邮件，就是一个文件非叫数据库也成，但和oracle完全不同。notes会有多少用户一般几十几百而已。yahoo,sina的几十T的邮件都是完全存文本储存， ...
几十百用户的notes？？？？
哈哈哈哈
笑死我了，真没见识
回复于：2005-11-25 22:41:23
呵呵，一堆人在讨论鸡蛋和蛋炒饭谁更好吃的问题！
那个数据库不是基于文件的？
为什么要有数据库，还不是简单的自己管理文件大家受不了了！
回复于：2005-11-26 00:50:36
引用：原帖由 bennie 于 2005-11-25 22:41 发表
那个数据库不是基于文件的？
应该说哪个数据库不是基于磁盘的.
比如oracle,可以基于文件系统来存储数据, 也可以基于raw device来存储.相同点是都写到磁盘上,但写的方式可能不一样.
把大量数据写到磁盘上去可以有不同的算法. 同时写到10个盘片上肯定比一个盘片一个盘片写要快.
海量数据的应用都采用磁盘阵列(n多的硬盘)的.数据库完全可能在这方面快过文件系统.
回复于：2005-11-26 11:12:22
引用：原帖由 mengwg 于 2005-11-26 00:50 发表
应该说哪个数据库不是基于磁盘的.
比如oracle,可以基于文件系统来存储数据, 也可以基于raw device来存储.相同点是都写到磁盘上,但写的方式可能不一样.
把大量数据写到磁盘上去可以有不同的算法. 同时写到 ...
我说文件系统了么？好像没有吧！
而且文件和磁盘也没有必然联系，磁盘只是文件的一种存储设备而已。
此外，你那个磁盘阵列和这个没有关系，如果有磁盘阵列的话，一般会做到对应用程序透明。
[ 本帖最后由 bennie 于 2005-11-26 11:13 编辑 ]
回复于：2005-11-26 12:04:07
引用：原帖由 bennie 于 2005-11-26 11:12 发表
我说文件系统了么？好像没有吧！
而且文件和磁盘也没有必然联系，磁盘只是文件的一种存储设备而已。
此外，你那个磁盘阵列和这个没有关系，如果有磁盘阵列的话，一般会做到对应用程序透明。
oracle数据库的确可以做一部分类似操作系统的工作. 这个层面比应用程序做得工作要多.
印象中, 涉及多个磁盘时,tablespace如何划分(指针对盘片的分布)对访问效率有影响,不是简单的搞几个文件那样.
回复于：2005-11-26 12:12:33
写个小品文：
在遥远的古希腊，有一天柏拉图正在学院里看书，停下来休息的时候，正看到他的学生亚里士多德从外面走来。
亚：老师，马其顿王刚才有个任务交给我们，让我们处理一下学院内所有学生的资料。老师，我们怎么做呢？我听说遥远的东方那边有一个新东西，叫关系数据库，据说还不错，我们是不是拿来用一下。
柏：撇了撇嘴角：切，我们伟大的希腊，伟大的柏拉图学院怎么会用它们的东西，不就是存一些学生的数据么，我们自己来解决。你过来，我们设计一下。
亚走进前来，柏从书架上拿出一卷羊皮纸，开始画图，并给亚解释：嗯，你看我们在羊皮纸上顺序的存所有的学生，然后给每个学生编一个连续的号码，然后直接根据学号跳到对应的页数，不就可以了么。这样的效率可是O(1)的。听说那个数据库光准备阶段就要10张羊皮纸，还得把一些张做成服务型，真是没必要。慢死了。
亚：可是老师，如果某些学生被征去兵役，或者病死，那不是中间的某些号码就要缺失了么？
柏：嗯，这是个问题，这样吧，我们依旧要顺序存储，但是是排序的，找的时候像查字典那样，对半翻，这样效率也可以达到O(lgN)。怎么样？
亚：这样很好，不过我们可能会在前面插入学生的，因为听说那些长老院的子弟很喜欢带8的数字，他们一定会插到前面的。
柏：那我们可以做成链接的，有一个索引的表，就像两千多年后的B+树那个样子，这样就解决了插入的效率问题。。
亚：老师，可是。。
柏：你怎么这么多问题，真是的。
亚：老师，我是说，你连2000年后的事情都知道，真是希腊最伟大的哲学家！
柏：呵呵。。
亚：对了，老师，但是王一般都是按着名字来找人的，那我们怎么办？
柏：嗯，这个难不住我，我们另建一个索引表，把名字进行HASH查找，这样的效率是近似于O(1)的。
亚：老师真厉害，不过王还需要根据别的多个条件，比如大于18岁，家里父母健在的要去服兵役的。
柏：这个王也够麻烦的，那我们创造一个结构化查询语言好了，就叫他SQL好了，他的语法是这样这样的。。。。，对了，还得弄个接口去解释他。还有，后面那些东西业的弄个东西去管理。
不知不觉中，柏所画下的图已经铺满了整个大厅。
亚：老师，可是我听说东方那个关系数据库就是这个样子的，既然这样，我就去东方学系好了，因为听说他们已经作了很多年了，应该有很多人用！
说完，亚转身走出了学院，对这遥远的东方，亚喃喃自语：吾爱吾师，吾更爱真理！
[ 本帖最后由 bennie 于 2005-11-26 12:19 编辑 ]
回复于：2005-11-26 12:13:56
引用：原帖由 mengwg 于 2005-11-26 12:04 发表
oracle数据库的确可以做一部分类似操作系统的工作. 这个层面比应用程序做得工作要多.
印象中, 涉及多个磁盘时,tablespace如何划分(指针对盘片的分布)对访问效率有影响,不是简单的搞几个文件那样.
看一下我的小品文，你说的这些我自己处理文件也都可以作！而且，oracle能做的这些并不是数据库本身的性质，那只是一种针对特定环境的优化而已。
[ 本帖最后由 bennie 于 2005-11-26 12:16 编辑 ]
回复于：2005-11-26 12:23:39
引用：原帖由 bennie 于 2005-11-26 12:13 发表
看一下我的小品文，你说的这些我自己处理文件也都可以作！而且，oracle能做的这些并不是数据库本身的性质，那只是一种针对特定环境的优化而已。
呵呵,小品文不错. 不过有点离题了. 你可以另开一贴去讨论.
操作系统和数据库针对存储考虑的重点不完全是一致的.
回复于：2005-11-26 12:32:21
引用：原帖由 mengwg 于 2005-11-26 12:23 发表
呵呵,小品文不错. 不过有点离题了. 你可以另开一贴去讨论.
操作系统和数据库针对存储考虑的重点不完全是一致的.
实际没有离题，没有任何一个数据库会脱离操作系统而存在。实际上，大多数数据库会依托操作系统的服务来做自己的文件管理。你说的不一致，是和操作系统的通常的文件管理来说。而不是和操作系统来说。不是一个范畴上的东西。你说的仅仅是Oracle实现的文件系统和操作系统默认文件系统的对比。实际是跑题的!
这和本主贴的标题一样： 读写文件不是效率很低的嘛，那么数据库为何效率高呢？
所以我说是讨论鸡蛋和蛋炒饭的问题！
可讨论的只能是蛋炒饭和扬州炒饭的区别。
回到本贴，数据库的重点是如何在文件系统的基础上更有效的组织数据，可对比的自己来组织数据，比如我在小品文里说的那些方法。
[ 本帖最后由 bennie 于 2005-11-26 12:35 编辑 ]
回复于：2005-11-27 19:19:35
看了半天，也不知道确切讨论什么，题目是讨论文件和数据库，转来转去变成文件系统和数据库了。
数据库也是构建在文件的基础上面的呀，裸设备也是文件呀。
在应用中，涉及到数据的使用和管理。数据量的大小与采用何种方式是直接相关的。
下面是4种常见的数据组织形式及简单的对比
方式 I/O 数据量 数据组织 使用 API 数据管理/查看
普通文件 高 小 简单 难 自己设计I 无法直接查看/借助通用编辑器
文件DB 高 中 简单 中 专有的API 借助偕同工具查询
LDAP 中 大 中 中 统一的API 可以直观察看
SQLDB 低 超大 复杂 易 专有丰富API及SQL语言 借助标准SQL语言
文件DB指专有的一些以专有方式的文件数据组织形式，代表的如BekleyDB，存放一些key-value对，是非常方便快捷的。
SQLDB特指关系型数据库。
数据量增大，相关的组织管理复杂度就会增高，也就意味着I/O的下降。而我们的数据使用不是简简单单的，而往往带有复杂的条件的。但对于事务操作的性能反而由于良好的数据组织而得到大幅度的提高。将简单的文件I/O和事务性能(I/O)比较，是没有可比性的。
[ 本帖最后由 mirnshi 于 2005-11-27 19:27 编辑 ]
回复于：2005-11-28 09:58:09
引用：原帖由 sunsroad 于 2005-4-18 17:17 发表
首先，我希望大家搞清楚我们所讨论的本质：不是说数据库将系统I/O的速度提高，而是说其效率要高过文件系统，这两者是有区别的。对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我 ...
分析精辟，偶来顶一个。
回复于：2005-11-28 10:44:32
write/read 过程实际上就是操作系统调用某个中断的过程int 13
所以读写文件的过程可以看成: 操作系统fs -> int 13中断
数据库系统在没有使用裸设备的时候， 数据库系统 -> 操作系统fs -> int 13中断
数据库系统在使用裸设备的时候: 数据库系统fs -> int 13中断
绕过了操作系统，直接对硬盘进行读写，
所以在使用裸设备的情况下，并且算法效率相同的情况下，数据库系统和操作系统在从硬盘读写数据的效率应该是一样。
至于CACHE , 数据库和操作系统fs都可以用，不是使用数据库而不直接用文件的根本原因。
引用101楼的“数据库的重点是如何在文件系统的基础上更有效的组织数据”在下强烈同意。
在下认为，这才是使用数据库的原因。
[ 本帖最后由 hubertCD 于 2005-11-28 10:47 编辑 ]
回复于：2006-04-08 14:29:35
认真看了这么多回帖，谈谈我对大家的话的理解。
首先，我们认为数据库高效，其实是指通过数据库对数据的有结构的组织使得我们可以高效的查询到我需要的那部分数据；
第二，很大一部分人把数据库的高效归结为数据库绕过了操作系统的I/O服务，而直接去操作硬件，在自己操作I/O时利用内了缓存和“有组织”的读写硬盘因而提高了I/O效率，所以高效。但是另一部分人反对这个观点，认为文件系统的I/O操作效率比数据库的i/o效率高。正如楼上“hubertCD ”兄台所言，我认为后者正确；因为数据库采用缓存、文件系统同样可以采用缓存，而且现在的文件系统确实也采用了缓存，不见得你数据库采用了缓存就比文件系统采用缓存后效率高了。数据库绕过操作系统直接读写硬盘，文件系统也是通过驱动直接读写硬盘的；凭什么你数据库直接操作读写硬盘就会比文件系统快？所以，如何提高我以为I/O的效率这件事，我认为还是应该让文件系统来做。数据库要作的是按照某种结构组织数据，提高查询等操作的效率。
第三，因为数据库在读写数据时还有很多附加操作，所以在都知道数据在哪里的前提下，从文件系统中读取数据效率比从数据库读取数据的效率高。
结论：数据库的高效是体现在对于关系数据的组织、访问、查询上。设计优良的数据库I/O效率最多和设计优良的文件系统的I/O效率在同一数量级。关于数据库的高效我觉得前面一位兄台的小品文写得很好。
这是我的理解，请指正。
[ 本帖最后由 2eye 于 2006-4-8 14:31 编辑 ]
回复于：2006-04-08 23:29:43
引用：原帖由 FH 于 2005-4-10 06:59 发表
谁说数据库效率高的？
同意！
往一个文件中写20万条记录，和往数据库中插入20万条记录试试。
内存访问-->文件访问-->数据库访问
时间大概都是1000倍的差。
文件主要是顺序组织，而数据库可以按照键值来组织。
如果一个表中的数据没有键值（定位一条记录顺序遍历）那还不如使用文件来的快（前提数据库不要搞成内存数据库）。
回复于：2006-04-09 01:31:34
根本看不懂嘛,英语不好
回复于：2006-08-05 13:25:58
乱七八糟的.有点.
回复于：2006-08-05 16:54:32
看了这么多，感觉乱七八糟，而且大多数没有价值，当然有价值的是有的．
首先，讨论的是什么问题好象很多人都不统一，就感觉是一活人在互相讨论不同的问题。
文件系统，文件系统，文件的系统，文件是什么？堆放数据，整理成格式的就叫文件。
一般文件系统，数据库，都是拿来存放文件的，我们的虚拟机，windows上看来就一个文件，难道就不是文件系统。
在那里比较谁快谁慢，感觉就如同讨论每天上厕所和每个星期去一趟超市哪个更爽一样。
无可比性，不同的东西不同的用途。
数据库要实现的是如何快速的在海量数据里面快速插入，查找，删除，整理等。你说它速度慢，那么我倒想问问
单一的find，grep 很快吗？
一般文件系统是给人一个清晰的界面。
用处不同，不要用一个东西的这个用处比较另外一个东西的那个用处
回复于：2006-08-05 17:50:05
DMA技术的重要性在于，利用它进行数据传送时不需要CPU的参与。每台电脑主机板上都有DMA控制器，通常计算机对其编程，并用一个适配器上的ROM(如软盘驱动控制器上的ROM)来储存程序，这些程序控制DMA传送数据。一旦控制器初始化完成，数据开始传送，DMA就可以脱离CPU，独立完成数据传送。
在DMA传送开始的短暂时间内，基本上有两个处理器为它工作，一个执行程序代码，一个传送数据。利用DMA传送数据的另一个好处是，数据直接在源地址和目的地址之间传送，不需要中间媒介。如果通过CPU把一个字节从适配卡传送至内存，需要两步操作。首先，CPU把这个字节从适配卡读到内部寄存器中，然后再从寄存器传送到内存的适当地址。DMA控制器将这些操作简化为一步，它操作总线上的控制信号，使写字节一次完成。这样大大提高了计算机运行速度和工作效率。
回复于：2006-08-05 20:35:48
引用：原帖由 giniouswr 于 2006-8-5 17:50 发表
DMA技术的重要性在于，利用它进行数据传送时不需要CPU的参与。每台电脑主机板上都有DMA控制器，通常计算机对其编程，并用一个适配器上的ROM(如软盘驱动控制器上的ROM)来储存程序，这些程序控制DMA传送数据。一旦控 ...
DMA的过程虽然不需要CPU参与，但是不要忘了仍然需要总线参与，而现在的X86系统下，总线恰恰是瓶颈所在。另外，DMAC对于总线的使用不像CPU那样讲究，长时间地占用总线和RAM子系统究竟带来效应一定要充分考虑。
所以DMA对于系统的运行效率究竟提高多少是需要论证的，尤其对于总线结构的SMP系统而言，DMA对于系统效率的影响更要小心论证。
回复于：2006-08-19 15:51:22
没仔细研究过，我认为最重要的一点是数据库采用了索引，
查找速度很快。也就是取某个记录时，能快速在文件中定位。
回复于：2006-08-21 10:23:16
数据库系统 在存取大批量数据的时候，多数情况下都比由操作系统管理文件系统快。
回复于：2006-08-21 14:47:59
还是那个小品文写得不错
回复于：2006-11-12 16:29:10
除了利用raw IO直接写文件外,还有很重要的一点就是DBMS会利用B+ B-树等结构来组织文件中数据的结构 这样在更新,删除以及增加操作时速度会更快
回复于：2006-11-12 18:49:55
引用：数据库通过主要两种途径提高ＩＯ性能．
１．把ＩＯ动作尽可能的在自己的ＢＵＦＦＥＲ里面实现，对于必须的物理ＩＯ操作，通过对要写入的数据的预先组织（预先读取，按物理顺序排队，分块写入，小数据量写入等操作实现，比如对Ｐ－ＬＯＧ和ＬＯＧＩＡＬ ＬＯＧ）．
２．对于物理ＩＯ动作，ｄｂ可以通过ＲＡＷ／ＣＯＯＫＥＤ设备来实现，在ＲＡＷ设备上操作的话，ＤＢ自己管理设备以及数据在ＲＡＷ设备上的存储细节，也就是说ＤＢ对于实际的物理存储是了解的，比如说，有２块ＤＥＶＩＣＥ，上面各自分别有２个ＲＡＷ ＤＥＶＩＣＥＳ，那么ＤＢ可以用２个ＴＨＲＥＡＤ在２个ＤＥＶＩＣＥ上面同时动作，对于同一ＤＥＶＩＣＥ上面的ＬＯＧＩＣＡＬ ＶＯＬＵＭ，ＤＢ对数据的预先安排可以大大提高ＩＯ性能．而文件系统上的ＩＯ由于有ＤＯＵＢＬＥ－ＢＵＦＦＥＲ，所以数据库所有对ＩＯ的优化基本上没作用（因为ＤＢ的ＢＵＦＦＥＲ通常比ｏｓ的ｉｏ ＢＵＦＦＥＲ大的多，当ＤＢ ＢＵＦＦＥＲ对应的ＯＳ ＢＵＦＦＥＲ映射失败的时候，ＩＯ就要通过物理ＩＯ来完成了，并且ＤＢ并不知道实际的ＩＯ操作在物理设备上的实现细节（比如文件系统在物理设备上的位置））．
３．所有物理的ＩＯ动作最后还是对应到了ＲＥＡＤ／ＷＲＩＴＥ操作，只不过在ＲＡＷ方式下的ＲＥＡＤ／ＷＲＩＴＥ是对设备直接操作的，不需要借助于文件系统实现．
描述得太复杂了，其实事情本来并没这么乱。很简单：
write 是操作系统提供的系统调用，用不用到缓冲其实并不重要。数据库系统在写硬盘时也调用write，当查询处于事务处理方式时，write之后再调用一下另一个系统调用sync()，这样read/write所使用的buffer被立即提交，也即硬盘与内存同步了。换句话说，数据库系统在写操作时，并不设置fcntl()是否缓冲，而是每write一次就跟随一次sync()，以此来保证内存数据与硬盘数据的一致性和完整性。
至于性能，数据库是没有速度性能可言的。
gucuiwen 回复于：2006-11-13 17:40:18
引用：原帖由 北京野狼 于 2005-4-14 10:50 发表
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率 ...
呵呵，似乎有道理。
[ 本帖最后由 gucuiwen 于 2006-11-13 17:43 编辑 ]
回复于：2007-01-29 11:52:58
引用：原帖由 albcamus 于 2005-4-11 09:56 发表
我只知道大型数据库用raw IO，绕过文件系统直接和驱动层打交道，速度能提高不少。
不是绕过文件系统，而是绕过文件系统的cache
回复于：2007-01-29 14:30:18
引用：原帖由 bennie 于 2005-11-26 12:12 发表
写个小品文：
在遥远的古希腊，有一天柏拉图正在学院里看书，停下来休息的时候，正看到他的学生亚里士多德从外面走来。
亚：老师，马其顿王刚才有个任务交给我们，让我们处理一下学院内所有学生的资料。老师， ...
牛！！！！
回复于：2007-01-30 03:05:35
现在的文件系统都朝数据库方向迈进了。
回复于：2007-01-30 08:46:52
引用：原帖由 longshort 于 2006-11-12 18:49 发表
描述得太复杂了，其实事情本来并没这么乱。很简单：
write 是操作系统提供的系统调用，用不用到缓冲其实并不重要。数据库系统在写硬盘时也调用write，当查询处于事务处理方式时，write之后再调用一下另一个系 ...
数据库要维护自己的buffer. 字典表会一直保存在数据库维护的buffer, 还有表的索引. 数据的缓存策略数据库间又不同. 数据库的缓存策略还要和SQL语句优化相结合, 会影响buffer分配, 进而影响到哪些文件会写回磁盘
[ 本帖最后由 Edengundam 于 2007-1-30 08:56 编辑 ]
回复于：2007-01-30 08:54:46
引用：原帖由 hubertCD 于 2005-11-28 10:44 发表
write/read 过程实际上就是操作系统调用某个中断的过程int 13
所以读写文件的过程可以看成: 操作系统fs -> int 13中断
数据库系统在没有使用裸设备的时候， 数据库系统 -> 操作系统fs -> ...
DB的目标应该是ACID. 为什么就是数据库让应用开发人可以摆脱对数据的管理, 并提供并发, 可靠性还有一致的数据操作, 定义接口.
操作系统的文件系统对于数据库来说粒度太粗了. 数据库经常用的heap file. 就是为了细粒度的进行管理. ORACLE的裸设备也是为了能绕过OS, 自己管理文件系统.
回复于：2007-01-30 13:19:38
多简单一个问题,如果数据库比不上文件,那数据库卖给谁?
还有informix的数据库就有建立在裸设备上的(裸设备就是连文件分配表都没有的分区),你怎么read?
还一套一套的
回复于：2007-01-30 13:21:33
我只看了前面几页,中间得没看,不知道有没有人说到这个
回复于：2007-02-06 23:28:02
B＋树的结构，CACHE+I/O
回复于：2007-07-26 23:13:16
好帖子收藏了
回复于：2007-07-27 16:28:32
内存数据库速度比较快～
回复于：2007-11-10 22:10:11
很多人都没自己建过裸设备就在这儿乱说，裸设备对于操作系统的文件系统来讲是不可见的，
操作系统可以看到这个设备，但没有把这块设备用来存放文件，你想用操作系统的命令来在这个设备上建文件是不可能的。
有人说用read,write来操作裸设备，read,write是操作系统的文件操作指令，连裸设备在哪儿都找不到，怎么可能把数据
写到裸设备上，真是可笑。
回复于：2008-02-06 17:33:08
单纯读写一个字符文件系统更快没问题吧？有人非得要用什么海量数据的读写来比较他们的速度，不是这么比的。你用你自己写的读写算法来和成熟的数据库厂商花了若干亿做出来的数据库系统比，可能比得过吗？问哪个快，是文件读写快，说海量数据读写，那设计高效的文件读写算法（包括算法、缓存思想等）来比，数据库还是比不过的。
还有人说数据库慢为什么还要用数据库？因为数据库管理大量的数据比较方便。去找一本数据库书，看看，在从文件存储到数据库存储转变的时候没有人说是因为发现了速度更快的方法而去用数据库的，一直都是说数据库在管理数据方面的优势才去用数据库的。
就算再爱数据库这东东也不能认为数据库都是好的啊。搜索引擎有用数据库系统的吗？
如果GOOGLE、百度的数据服务器用哪个数据库来存储，可能你现在用GOOGLE得慢死。按一个网页的内容10K来算，五亿个页面来多少G的数据量？用数据库？每天几百万上千万的用户查询不同的关键字，用数据库来在五亿或十亿条数据里查找，数据库的速度远远达不到，所以他们开发了自己的存储系统，做大量的索引文件。
回复于：2008-02-06 19:39:43
引用：原帖由 haiyan_qi 于 2007-11-10 22:10 发表 [url=]
很多人都没自己建过裸设备就在这儿乱说，裸设备对于操作系统的文件系统来讲是不可见的，
操作系统可以看到这个设备，但没有把这块设备用来存放文件，你想用操作系统的命令来在这个设备上建文件是不可能的。
有 ...
前面内容太多了, 没看全. 不过, 我看很多人都有误解.事实上:
1. 数据库使用裸设备, 其实也是通过read/write来做的, 只不过访问的对象不是文件系统,而是字符设备文件, 即/dev/rXXX之类的文件. read/write是系统调用, 访问字符设备时是直接无缓存的访问, 因此数据的更新会比文件系统及时(文件系统的文件读写都是缓存过的). 不过, 如果建库时不使用字符设备文件,而使用块设备文件,例如/dev/hd0b之类的文件,就会发现速度慢下来了,因为块设备是有读写缓存的. 是否直接访问设备,与read/write无关,其实是与设备自身的驱动程序有关.
2. 如果是遍历查找, 全记录更新,直接从后插入新记录,那么文件是要比数据库快上一个数量级的. 例如在INFORMIX/DB2/ORACLE等数据库上,每秒可以插入1万行记录的话,往文件系统中写同样的内容,可以达到10万行/秒以上, 这是早就测试过的. 但数据库的优势也很明显,按索引查找和更新速度快,删除记录或修改记录结构操作方便,容易实现关联查询和分组统计和聚集计算等,这才是数据库的强项.
3. 用文件还是用数据库,是根据应用的需求来看的,例如大机上一直就不使用数据库,而是使用通过COBOL程序访问ISAM或者VSAM文件,能管理的数据规模和处理速度都远高于数据库,但数据库的ACID特性尤其是事务的原子性,文件系统就很难保证了.
回复于：2008-02-13 11:39:39
陈年老贴，不错！
回复于：2008-05-08 12:55:34
引用：原帖由 albcamus 于 2005-4-11 09:56 发表 [url=]
我只知道大型数据库用raw IO，绕过文件系统直接和驱动层打交道，速度能提高不少。
kidding me?
虽然不懂DB，但是有个疑问，比如在Linux上用个“绕过文件系统直接和驱动层打交道” 的DB，那么就要给他个单独的block device？
不然的话这个DB肯定是要毁坏文件系统的啊。
回复于：2008-05-15 10:14:35
引用：原帖由 思一克 于 2005-4-21 13:26 发表 [url=]
再给一个权威的TEST结果
ORACLE的数据INPUT和OUTPUT
用ext3最快，ext2次之， 用RAWIO和OCFS（ORACLE自己的RAWFS ...
感觉应该用操作系统的文件, 但如果数据库也是用文件系统,那NAS 为何不能支持数据库? 不解!:em14:
回复于：2008-07-24 23:41:27
数据库安装的时候还是安装在文件系统上面的，只是数据库的用来存放数据的表空间是建立在裸设备上面的。然后由数据库来不经过文件系统的cache，直接读写裸设备上的数据。
回复于：2008-07-25 00:27:16
:) 讨论的不错.
回复于：2008-07-25 00:28:30
不论是否缓冲,读写的动作还是要通过OS的.
[ 本帖最后由 system888net 于 2008-7-25 00:32 编辑 ]
回复于：2008-07-25 08:54:10
direct I/O ?
是不是相当于DMA啊
回复于：2008-07-25 12:22:00
引用：原帖由 虑而后能得 于 2008-7-25 08:54 发表 [url=]
direct I/O ?
是不是相当于DMA啊
这里说的direct I/O和DMA是不同的东西.
回复于：2008-07-25 12:27:26
引用：原帖由 system888net 于 2008-7-25 12:22 发表 [url=]
这里说的direct I/O和DMA是不同的东西.
raw I/O又是什么东东
回复于：2008-07-25 12:42:06
引用：原帖由 zengit 于 2008-7-25 12:27 发表 [url=]
raw I/O又是什么东东
直接读磁盘（没有经过中间缓冲机制),详见linux 的raw io 代码
当然这是逻辑说法上的,实际上缓冲无处不在,只是缓冲的层面和定位不同而已.
回复于：2008-10-08 12:07:51
好贴留名!
|
