| FH 回复于：2005-04-10 06:59:25
|
谁说数据库效率高的？
|
| Alligator27 回复于：2005-04-10 22:48:16
|
数据库用很多CACHE技术.
|
| muzhu 回复于：2005-04-11 04:25:30
|
CACHE
|
| bleem1998 回复于：2005-04-11 09:29:02
|
数据库是direct IO
不是用普通的read\write
并且有很多cache
|
| aero 回复于：2005-04-11 09:49:22
|
What's the meaning of "direct I/O"?
|
| albcamus 回复于：2005-04-11 09:56:27
|
我只知道大型数据库用raw IO，绕过文件系统直接和驱动层打交道，速度能提高不少。
|
| lenovo 回复于：2005-04-11 10:48:39
|
[quote:15bd4d3b46="aero"]What's the meaning of "direct I/O"?[/quote:15bd4d3b46]
就是bleem1998和albcamus所说的，
绕过了文件系统，读写数据并不是用read和write系统调用，
看这个。
http://www.linuxeden.com/edu/doctext.php?docid=3189
|
| aero 回复于：2005-04-11 10:50:35
|
Thank you, I got it.
|
| river_wave 回复于：2005-04-11 12:01:33
|
[quote:a7015c7498="lenovo"]
绕过了文件系统，读写数据并不是用read和write系统调用，
看这个。
http://www.linuxeden.com/edu/doctext.php?docid=3189[/quote:a7015c7498]
绕过了文件系统读写数据就不用read、write了？那你怎么操作裸设备？汇编？
|
| 思一克 回复于：2005-04-11 12:10:36
|
direct-io也用系统调用read, write吧。
哪个数据库不用系统调用读写文件，而自己读写磁盘？ 请给出具体例子。
|
| bleem1998 回复于：2005-04-11 12:55:51
|
不是传统意义上的read/write了
没有了VFS维护的各种cache和buffer
即使没有ext3之类的日志文件系统
如果出现掉电数据也不会丢失
|
| albcamus 回复于：2005-04-11 12:59:49
|
嗯，不经过陷入内核，数据在外设和用户空间之间直接传输。
组成原理忘了大半了，似乎跟DMA控制有关吧？
|
| lenovo 回复于：2005-04-11 13:38:29
|
[quote:47d81fc53d="思一克"]direct-io也用系统调用read, write吧。
哪个数据库不用系统调用读写文件，而自己读写磁盘？ 请给出具体例子。[/quote:47d81fc53d]
你说的对，我理解错了。 :oops:
不过具体的我也不懂，到底数据在数据库
和硬盘之间是怎么传输的。是使用DMA吗？
|
| 思一克 回复于：2005-04-11 13:50:51
|
To lenovo,
我也不是很清楚，我也不熟悉DB。只是觉得不大相信和明白
|
| JohnBull 回复于：2005-04-11 13:57:22
|
牺牲空间换取时间呗。
|
| 北京野狼 回复于：2005-04-11 19:52:53
|
第一次听说数据库比文件系统效率高。
正常情况读写文件系统比数据库快一到两个数据级
|
| 柳五随风 回复于：2005-04-11 21:37:54
|
数据库通过主要两种途径提高ＩＯ性能．
１．把ＩＯ动作尽可能的在自己的ＢＵＦＦＥＲ里面实现，对于必须的物理ＩＯ操作，通过对要写入的数据的预先组织（预先读取，按物理顺序排队，分块写入，小数据量写入等操作实现，比如对Ｐ－ＬＯＧ和ＬＯＧＩＡＬ ＬＯＧ）．
２．对于物理ＩＯ动作，ｄｂ可以通过ＲＡＷ／ＣＯＯＫＥＤ设备来实现，在ＲＡＷ设备上操作的话，ＤＢ自己管理设备以及数据在ＲＡＷ设备上的存储细节，也就是说ＤＢ对于实际的物理存储是了解的，比如说，有２块ＤＥＶＩＣＥ，上面各自分别有２个ＲＡＷ ＤＥＶＩＣＥＳ，那么ＤＢ可以用２个ＴＨＲＥＡＤ在２个ＤＥＶＩＣＥ上面同时动作，对于同一ＤＥＶＩＣＥ上面的ＬＯＧＩＣＡＬ ＶＯＬＵＭ，ＤＢ对数据的预先安排可以大大提高ＩＯ性能．而文件系统上的ＩＯ由于有ＤＯＵＢＬＥ－ＢＵＦＦＥＲ，所以数据库所有对ＩＯ的优化基本上没作用（因为ＤＢ的ＢＵＦＦＥＲ通常比ｏｓ的ｉｏ ＢＵＦＦＥＲ大的多，当ＤＢ ＢＵＦＦＥＲ对应的ＯＳ ＢＵＦＦＥＲ映射失败的时候，ＩＯ就要通过物理ＩＯ来完成了，并且ＤＢ并不知道实际的ＩＯ操作在物理设备上的实现细节（比如文件系统在物理设备上的位置））．
３．所有物理的ＩＯ动作最后还是对应到了ＲＥＡＤ／ＷＲＩＴＥ操作，只不过在ＲＡＷ方式下的ＲＥＡＤ／ＷＲＩＴＥ是对设备直接操作的，不需要借助于文件系统实现．
|
| FH 回复于：2005-04-11 22:46:29
|
[quote:5fd0ee0609="北京野狼"]第一次听说数据库比文件系统效率高。
正常情况读写文件系统比数据库快一到两个数据级[/quote:5fd0ee0609]
严重同意！
|
| zerozero_nine 回复于：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.
[code:1:e846fcb884]
//一个简单DIRECT-IO例子 (linux i386)。 JOHN SEEKER
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <asm/fcntl.h>
#include <unistd.h>
#define _XOPEN_SOURCE 600
#include <stdlib.h>
//int posix_memalign(void **memptr, size_t alignment, size_t size);
//#include <fcntl.h>
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);
}
[/code:1:e846fcb884]
|
| albcamus 回复于：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
|
[quote:23172f09be="思一克"][/quote:23172f09be]
你有这个经历，干嘛不试试读写一个文件，和读写数据库
到底速度差别多少
|
| linux_newbie 回复于：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项目外）。对用户几乎是透明的。
|
| albcamus 回复于：2005-04-12 11:59:52
|
[quote:4d7ed19858="linux_newbie"]
否则使用write等api，实际上os内部还是有buffer的，如果这个时候crash了，事务又已经提交了，但是具体的log没有更新到磁盘上，数据就corrupt了，recover都没有机会。
[/quote:4d7ed19858]
你的意思是不是说，文件系统的日志功能是不可靠的? 因为日志未必总是与磁盘上的保持同步。
有点理解了。。
|
| bleem1998 回复于：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
|
[quote:589cd9c93b="思一克"]还有两者读写文件都是在KENREL中执行的，但DIRECT/IO DIO是直接将数据搞到用户的BUFFER，而普通IO先搞到page buffer, 再COPY到用户buffer.
所以如果仅仅写一次一个文件DIO应该快，但对于一般的文件操作（读写，SE..........[/quote:589cd9c93b]
一般的文件，读写，SEEK，再读写，仍然比数据库快的多。
|
| bleem1998 回复于：2005-04-12 12:21:35
|
谁知道怎样mount一个direct I/O的文件系统
是不是用raw命令？
|
| linux_newbie 回复于：2005-04-12 12:39:56
|
>>你的意思是不是说，文件系统的日志功能是不可靠的? 因为日志未必总是与磁盘上的保持同步。
应该是你write成功了不见得就确实磁道记录了。 不是有个工具sync 30秒运行一次吗？
|
| albcamus 回复于：2005-04-12 12:45:20
|
[quote:b127e9197b="思一克"]还有两者读写文件都是在KENREL中执行的，但DIRECT/IO DIO是直接将数据搞到用户的BUFFER，而普通IO先搞到page buffer, 再COPY到用户buffer.[/quote:b127e9197b]
旷若发懵啊。多谢多谢!!
前阵子看page buffer和io调度，头都大了，早问您就好了。。
|
| 思一克 回复于：2005-04-12 13:00:49
|
To albcamus,
你过奖了。我都是临时实验（学习）的。原来也不是知道多少
|
| rollingpig 回复于：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
|
[quote:61f2d31c3e="rollingpig"]以 Oracle 为例
1。读
使用数据库有时候比file 要慢
比如说第一次使用某个数据时，Oracle肯定会比直接读file慢
但是，如果第二次要用到这个数据，Oracle直接从mem里读取，这样就比file要快
2。写
Oracle对data..........[/quote:61f2d31c3e]
无论第几次读写，数据库都无法和文件系统的速度比较。
在普通的PC机器上，各自只有一行记录比较。如果是mysql会比文件系统慢30到50倍
要是采用oracle就更慢，至少差别70,80倍
|
| mep 回复于：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的顺序读写和文件系统按位置读写的比较,因为这是数据库应用系统设计者的问题,不是数据库本身的问题.
|
| JohnBull 回复于：2005-04-13 23:49:33
|
就随机数据的突发读取而言，肯定是数据库慢。
但问题是简单的文件访问的话，你能在数百G数据中迅速找到你要的数据吗？你能迅速地删除数据吗？你能有效处理尺寸跨度极大的变长数据吗？你能实现并发版本控制吗？......
当你的程序实现了这些的时候，你随机数据读取的效率恐怕还不如现在这些成熟的数据库呢。
|
| 北京野狼 回复于：2005-04-14 10:50:52
|
[quote:27abf84b03="柳五随风"]都是从那里得出的数据库直接读写慢的结论?
如果是有数量级的差别的话，数据库厂家早就倒闭了.
还30~40,70~80的数量级差别呢.
单纯一条记录如果有这么大的差别的话,只能说明数据库的应用设计有问题.文件系统的DATA..........[/quote:27abf84b03]
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也高不到那里去．
你列出那些资料可能都毫无意义，数据库的查询，大量并发的时候可能最浪费时间的是connect和close，数据库的优势是体现的大量数据的查询、统计以及并发读写，不是在速度上．
|
| 黑帮老大 回复于：2005-04-14 11:12:37
|
[quote:e2b8998a7b="北京野狼"]
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也?.........[/quote:e2b8998a7b]
个人比较赞同这个观点。。。
|
| 柳五随风 回复于：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等比较.
|
| wangyih 回复于：2005-04-14 16:59:42
|
[quote:9faf628c3d="柳五随风"]俺们这里就是三大DATABASE的厂家之一.
另外,我谈的是数据库ENGINE的IO问题,不是数据库系统应用的问题,比如我用STORAGE PROCEDURE实现的话,基本不需要考虑CONNECT/CLOSE的问题.
另外DATABASE ENGINE自身的IO操作也?.........[/quote:9faf628c3d]
总算遇到一个真做数据库的 :D
我问个问题对于一个没有主键没有索引的大表。我数据库不是很熟悉。
select出一条再有什么BUFFER，难道不是遍利大文件？还有什么捷径？
|
| bleem1998 回复于：2005-04-14 17:15:48
|
只要没有索引
任何操作都要遍历整个表
术语大约叫做：full table scan
除非你用了sql server里的top之类的东东
:)
|
| sunsroad 回复于：2005-04-14 19:21:08
|
[quote:d2abe881d5="北京野狼"]
你应该做过实验再发表评论．写个程序读写数据库和文件个10万次。
必定是几十倍甚至百倍的差别．
记住各自只有一行记录比较，不需要检索，和数据库的应用设计毫无关系．即便大量数据检索，数据库没有索引效率也?..........[/quote:d2abe881d5]
又一个喜欢透过现象“想”本质的，事实可以作证，这种思维通常都是错误的。
如果你真的想了解这两者之间的差别，建议你认真的找一点资料看看，了解一下什么叫做文件系统，什么叫做数据库。只有当你真正的理解了这两者的区别与他们之间的联系，我想你真正有资格去评判这两者的优缺点。
|
| 北京野狼 回复于：2005-04-14 20:50:09
|
[quote:ff8e9777e3="sunsroad"]
又一个喜欢透过现象“想”本质的，事实可以作证，这种思维通常都是错误的。
如果你真的想了解这两者之间的差别，建议你认真的找一点资料看看，了解一下什么叫做文件系统，什么叫做数据库。只有当你真正的理解?.........[/quote:ff8e9777e3]
你有什么理论就说出来，没话说就回家去睡觉。
|
| 柳五随风 回复于：2005-04-14 21:14:47
|
FULL TABLE SCAN
SCAN的是TABLESPACE,不一定就是大文件,也可以是RAW DEVICE.
另外:大表上面没有INDEX(不管是存储索引(B-TREE等),还是算法索引(比如HASH算法)的话,只能是FULL TABLE SCAN了，性能非常差.不推荐这样使用.小的静态表可以是FULL TABLE SCAN的,对性能没影响,甚至稍微好一点.
|
| wangyih 回复于：2005-04-14 22:42:00
|
[quote:d8e11ef143="柳五随风"]FULL TABLE SCAN
SCAN的是TABLESPACE,不一定就是大文件,也可以是RAW DEVICE.
另外:大表上面没有INDEX(不管是存储索引(B-TREE等),还是算法索引(比如HASH算法)的话,只能是FULL TABLE SCAN了，性能非常差.不推荐这..........[/quote:d8e11ef143]
那我理解数据库无论如何也不能赶的上文件系统。
数据库可能在文件查找的方法更有效一些。
我刚写了程序试验，的确数据库比文件系统速度差别很大啊
|
| 柳五随风 回复于：2005-04-14 23:47:03
|
:)
你能在DATABASE ENGINE里面测试?:),恐怕还是在应用级别上吧?:)
我说了,用DATABASE应用和本地文件系统相比较,不公平,即使要比较的话,也是要在海量数据级上比较.另外DATABASE是面向关系运算的,所以你也得在这上面比较.你总不能拿DATABASE当文件系统用吧?:)
|
| fengwy 回复于：2005-04-15 00:08:19
|
谁说的数据库的IO效率高？IO永远是计算机心中的痛！
不管是操作系统，还是数据库，概么能外。
|
| 艾斯尼勒 回复于：2005-04-15 01:53:06
|
我看过有书说大型数据库改写了操作系统的磁盘io部分
|
| 北京野狼 回复于：2005-04-15 11:24:33
|
[quote:0786313c20="柳五随风"]:)
你能在DATABASE ENGINE里面测试?:),恐怕还是在应用级别上吧?:)
我说了,用DATABASE应用和本地文件系统相比较,不公平,即使要比较的话,也是要在海量数据级上比较.另外DATABASE是面向关系运算的,所以你也得在这..........[/quote:0786313c20]
我不太理解，为什么不能在应用级别比较，而且为什么一定要比海量的．
测试两辆车那个跑的快当然去马路上跑，让我去比较发动机的好坏，我即没那能力，也没必要啊．
你肯定比我知道数据库存储数据的格式，大量数据的数据库和大量数据库的文件，比如文件格式，每行定长的，只要给一个类似数据库索引的信息，去第几行找，肯定也比数据库快得多
|
| fengwy 回复于：2005-04-16 12:35:39
|
文件系统和数据库文件这是两回事，数据库的文件可以建立在文件系统上也可以建立在RAW 设备上。如果建立在文件系统上，数据库的读写必然要经过文件系统，这样比没有可比性。
|
| wangyih 回复于：2005-04-18 10:43:45
|
[quote:44825063e8="fengwy"]文件系统和数据库文件这是两回事，数据库的文件可以建立在文件系统上也可以建立在RAW 设备上。如果建立在文件系统上，数据库的读写必然要经过文件系统，这样比没有可比性。[/quote:44825063e8]
其实很多时候非常需要比较的．系统设计时候，很多时候需要选择信息是存储在数据库里面还是在文件里．
|
| playmud 回复于：2005-04-18 13:46:56
|
[quote:d7af421f37="北京野狼"]
我不太理解，为什么不能在应用级别比较，而且为什么一定要比海量的．
测试两辆车那个跑的快当然去马路上跑，让我去比较发动机的好坏，我即没那能力，也没必要啊．
你肯定比我知道数据库存储数据的格式，大量?.........[/quote:d7af421f37]
个人支持这种观点，也对这位兄台的风格很欣赏。
这个问题争起来其实没有多大的意思，数据库也好，文件也好，说起都是一样的东西，数据库不也是文件吗？所以从应用的角度上来看，数据库读写相对直接文件读写来说要做许多额外的工作，所以看上去直接操作文件更快，我们的应用除非必要否则就不用数据库，效率确实低，我们的数据也不算多，一般不会过亿，
说数据库好的同志不要生气，这是肯定的因为数据库的锁很浪费资源，而且日至也占用资源，这里并不是说数据库慢，尽管它的确慢，但是慢是有原因的。
谁能举例说明数据库比操作文件快？有索引的情况下查询数据吗？还是别的？
楼上的楼上的楼上。。说什么本质了，本质是什么？还不是存储的读写速度？
|
| sunsroad 回复于：2005-04-18 17:15:30
|
[quote:04cd54c335="北京野狼"]
你有什么理论就说出来，没话说就回家去睡觉。[/quote:04cd54c335]
我申明：恕我不与井蛙鼓噪。
|
| sunsroad 回复于：2005-04-18 17:17:36
|
首先，我希望大家搞清楚我们所讨论的本质：不是说数据库将系统I/O的速度提高，而是说其效率要高过文件系统，这两者是有区别的。对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。数据库跟文件系统也有这方面的区别。如果你可以认可并理解NTFS跟UFS或者VXFS有不同的效率的话，你就应该可以明白文件系统跟数据库之间的差别。
其次，我认为大家在讨论一个事情的时候，能够首先了解事物的本质，能够明白我们是在说什么事情，在把事物的什么特性做比较。其实如前面那位兄弟说的，可能你在读写操作一个记录的时候感觉文件系统更加快一些，但是你并没有将你所做的测试环境描述出来：你的数据库是用的裸设备还是文件系统？如果是文件系统的话，那这是很明确的，数据库一定不会快过文件操作。因为你在打开数据库的时候首先要打开文件，也就是说：你所说的数据库的操作时间其实是文件操作跟数据库操作的总和。还有，丢开这个不说，你设计的这个试验也是有问题的：打开与关闭一个文件并不是数据库的全部，当然也不是文件系统的全部，还有很多其他的事情要做，譬如插入、检索，删除。对于一个事物的好坏应该全面的分析其每一个特性之后作出全面的判断，而不是断章取义的进行极端情况下的诡辩。我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统？！用户好象也没有都那么傻，花几十万去买一个无用的东西。我知道你要问的问题，裸设备，既然裸设备快，为什么不用裸设备？！因为裸设备的管理太麻烦，或者是因为用户的问题:他根本就没有管理裸设备的能力，或者是因为人的问题：即使是能管理裸设备，但他不想那么麻烦，或者是其他的原因：譬如用户要求利用文件系统进行数据库系统的备份，等等。不用裸设备是有理由的。
再次，其实文件系统跟数据库之间也是有一些相似的东西的，他们之间虽然有很大的区别，但也会有很多关系。不管是使用文件系统，还是使用裸设备。跟文件系统一样，数据库也是对其上层（下层）的设备（裸设备或者是文件系统）的一个抽象，是在其上层（下层）设备上建立的一个数据结构。只是他的组织比我们在具体的语言中学习到的结构更加复杂一些。
最后，我还是建议大家在分析这个问题之前，把数据库跟文件系统的本质的东西了解一下。我相信一旦你真正的理解了他们的本质，你就会认同我的这句话：数据库实质上也是一个特殊的文件系统，只是其重点不在跟人交互，而是在跟数据库管理系统交互。
注:其一我是搞系统的，不是搞数据库的，所以我不通晓数据库的管理知识。所以不要跟我讨论如何管理数据库系统。其二我这里提到的效率就是指数据库系统在操纵数据方面的效率，请大家不要再做引深，任何引深恕我不作回应。其三，我愿跟任何愿意理性的考虑问题，文明交流的朋友进行真诚的交流，但对于无礼的冒犯恕我将...。
|
| bleem1998 回复于：2005-04-18 17:31:37
|
请教各位一个基础问题
linux下怎样创建一个direct I/O的文件系统?
|
| wangyih 回复于：2005-04-18 17:38:25
|
[quote:a618957a8d="sunsroad"]首先，我希望大家搞清楚我们所讨论的本质：不是说数据库将系统I/O的速度提高，而是说其效率要高过文件系统，这两者是有区别的。对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。数据库跟文件系统也有这方面的区别。如果你可以认可并理解NTFS跟UFS或者VXFS有不同的效率的话，你就应该可以明白文件系统跟数据库之间的差别。
其次，我认为大家在讨论一个事情的时候，能够首先了解事物的本质，能够明白我们是在说什么事情，在把事物的什么特性做比较。其实如前面那位兄弟说的，可能你在读写操作一个记录的时候感觉文件系统更加快一些，但是你并没有将你所做的测试环境描述出来：你的数据库是用的裸设备还是文件系统？如果是文件系统的话，那这是很明确的，数据库一定不会快过文件操作。因为你在打开数据库的时候首先要打开文件，也就是说：你所说的数据库的操作时间其实是文件操作跟数据库操作的总和。还有，丢开这个不说，你设计的这个试验也是有问题的：打开与关闭一个文件并不是数据库的全部，当然也不是文件系统的全部，还有很多其他的事情要做，譬如插入、检索，删除。对于一个事物的好坏应该全面的分析其每一个特性之后作出全面的判断，而不是断章取义的进行极端情况下的诡辩。我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统？！用户好象也没有都那么傻，花几十万去买一个无用的东西。我知道你要问的问题，裸设备，既然裸设备快，为什么不用裸设备？！因为裸设备的管理太麻烦，或者是因为用户的问题:他根本就没有管理裸设备的能力，或者是因为人的问题：即使是能管理裸设备，但他不想那么麻烦，或者是其他的原因：譬如用户要求利用文件系统进行数据库系统的备份，等等。不用裸设备是有理由的。
再次，其实文件系统跟数据库之间也是有一些相似的东西的，他们之间虽然有很大的区别，但也会有很多关系。不管是使用文件系统，还是使用裸设备。跟文件系统一样，数据库也是对其上层（下层）的设备（裸设备或者是文件系统）的一个抽象，是在其上层（下层）设备上建立的一个数据结构。只是他的组织比我们在具体的语言中学习到的结构更加复杂一些。
最后，我还是建议大家在分析这个问题之前，把数据库跟文件系统的本质的东西了解一下。我相信一旦你真正的理解了他们的本质，你就会认同我的这句话：数据库实质上也是一个特殊的文件系统，只是其重点不在跟人交互，而是在跟数据库管理系统交互。
注:其一我是搞系统的，不是搞数据库的，所以我不通晓数据库的管理知识。所以不要跟我讨论如何管理数据库系统。其二我这里提到的效率就是指数据库系统在操纵数据方面的效率，请大家不要再做引深，任何引深恕我不作回应。其三，我愿跟任何愿意理性的考虑问题，文明交流的朋友进行真诚的交流，但对于无礼的冒犯恕我将...。
[/quote:a618957a8d]
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？
|
| sunsroad 回复于：2005-04-18 18:08:18
|
[quote:11e26f50d9="wangyih"]
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？[/quote:11e26f50d9]
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念？它有它自个的格式！附件是没有办法从文件中提取出来的！！我并没有告诉你什么都要用数据库系统，因为数据库系统对人的交互并不友好，它所擅长的是数据的操纵？我可以告诉你邮件系统对数据操纵的要求是很低的！！
希望你在回复的时候能够看清楚帖子的意思，为一个意识形态争吵是短视的，更是可悲的。
其次，我怕你根本就不了解什么是文件系统，跟你的讨论不会有什么结果的：对牛弹琴而已。所以我后面拒绝跟你讨论，这个观念我已经在我发表的第二贴表达了，自重！！
|
| sunsroad 回复于：2005-04-18 18:09:15
|
[quote:d00cbbe879="wangyih"]
除了发表了一个观点实在不知道，打这么多字干吗。
没看出说出什么本质啊。
但你这句话是完全错误的理解。你见过邮件系统采用数据库存储邮件的吗？[/quote:d00cbbe879]
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法从文件中提取出来的，从数据库中提取有成本的考量！！我也并没有告诉你什么都要用数据库系统，因为数据库系统对人的交互并不友好，它所擅长的是数据的操纵？我可以告诉你邮件系统对数据操纵的要求是很低的！！既然数据库系统不能给它带来什么好处，又要增加费用，为什么一定要选用数据库系统？！！
希望你在回复的时候能够看清楚帖子的意思，怕是你根本就没有看完我的帖子。为一个意识形态争吵是短视的，更是可悲的。我拒绝这种争吵。
其次，我怕你根本就不了解什么是文件系统，既然如此跟你的讨论也不会有什么结果：对牛弹琴而已。所以我后面拒绝跟你讨论，这个观念我已经在我发表的第二贴表达了，自重！！
|
| wangyih 回复于：2005-04-18 20:58:17
|
[quote:34460c2018="sunsroad"]
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法?.........[/quote:34460c2018]
无论多大的邮件系统都不采用数据库存储邮件。国内有比sina更大的吗。
邮件系统就是是一堆文件组成的系统
邮件不选用数据库系统就是因为效率的问题。
邮件系统对数据操纵的要求非常高，你知道sina一天有上亿封邮件吗？
邮件系统的格式就是存文本，附件就是从文件中提取出来的。
数据库系统对人的交互比文件系统友好的多
真是难为你一个帖子能说出这么多错误，没一句对的。
而且你是不是脑子有问题，什么都不懂上来和谁都想吵架
|
| playmud 回复于：2005-04-18 23:48:18
|
[quote:7a69f47326="sunsroad"]对于一个特定的设备，譬如说一个硬盘，你是很难通过软件的手法来提高他的性能的。我们能作的就是通过适当的算法提高其效率，尽量减少读写不需要的资料，将设备的性能尽可能的利用到有效的系统IO上面。这也就是为什么你会看到尽管大家都采用一家的硬盘，其他的规格也都一样或者是接近，但是却发现不同的厂家的存储会有不同的性能表现。[/quote:7a69f47326]
我很赞同这位兄台的这种观点，但是不敢苟同下面这种观点
[quote:7a69f47326="sunsroad"]我可以以我得名誉断言，在规划合理的状况下，数据库系统的总体效率是必然的超过文件系统的（即使他的IO可能会慢一些，这个没有做过测试，不得而知），要不然的话既然已经有了文件系统为什么还要发展数据库系统?[/quote:7a69f47326]
我觉得用户选择数据库而不是文件，是因为易操作性，并发处理，安全，开发成本等方面的考虑，而不是效率高。
|
| cx6445 回复于：2005-04-19 12:34:39
|
[quote:b7f36c34d8="sunsroad"]
其一你见过的邮件系统有多大？你以为他在这个级别上可以跟数据库系统来比较吗？！
其二我告诉你，邮件系统也不是一个文件系统的概念，不选用数据库系统不是因为效率的问题，它有它自个的格式！附件是没有办法?..........[/quote:b7f36c34d8]
其一、因为文件系统在数据读写方面的效率上远远于高数据库，数据库的众多特性决定无论在什么情况下其效率一定要比文件系统低几个档次。那为什么还要花很多钱买数据库呢，因为有如此众多的特性，关系、事务、回滚、触发、并发、安全等，要文件系统支持这些也可以，但是需要再开发，那就成为另一个数据库了，特性越多效率也就越低。如果你说要把所有特性都除去再比，那还是一个数据库吗？
其二、正文和附件没有理由不能存入数据库的，可以重新封装邮件数据进行存储，只是读写效率和空间利用率都低得可怕，而数据库众多优秀的特性一个都用不上。
以上所指的读写效率都不是说设备的读写能力有变化，而是文件系统和数据库能利用多少设备的读写能力。就象一个程序能利用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的问题，而是应用程序设计问题。
|
| abcdfq 回复于：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的太牛了。
|
| spirn 回复于：2005-04-20 02:24:19
|
单单比较速度是没有意义的，关键是什么才是数据库，什么是文件系统，两者之间本来就有不少灰色的区域，什么都不懂，也没有前提讨论这种问题实在是可笑 :D
数据库要有事务？文件系统也有日志，也可以回滚，而且也有不支持事务的数据库。
数据库有索引？文件系统没有么？大家用的索引技术其实也没有本质区别，按照某种方式组织的树而已
数据库可以读裸设备？不少数据库只能基于文件，而且文件系统本身就是读写裸设备，搞不好比数据库更加底层，呵呵
数据库有SQL，方便查询？这个文件系统倒没有，不过不支持SQL的数据库倒有不少，尤其是SQL还没有出现以前，哈哈，那时候的所有数据库都不支持SQL
cache？什么没有cache？文件系统本身也是层层cache。。。
嘿嘿，要吵架的人先搞懂了自己想问什么，是什么数据库和什么文件系统，储存什么数据，主要是什么操作，然后再慢慢吵吧 :em24:
|
| spirn 回复于：2005-04-20 02:28:26
|
[quote:fa61745c08="wangyih"]
无论多大的邮件系统都不采用数据库存储邮件。国内有比sina更大的吗。
邮件系统就是是一堆文件组成的系统
邮件不选用数据库系统就是因为效率的问题。
邮件系统对数据操纵的要求非常高，你知道sina一天有上亿封?..........[/quote:fa61745c08]
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，硬盘100%空间会浪费。
还有MAIL系统的可靠性，和抗XXX性是DB无法比的。比如一个配置的好的MAIL系统，可以多少年不用人工干预，其可靠性和CISCO的路由器相同。DB系统，你胡乱关电开电可以吗。
至于丢邮件等问题，是有其他原因的，不是MAIL SERVER的文件系统引起。
|
| cx6445 回复于：2005-04-20 11:41:01
|
[quote:0bc581cf30="abcdfq"]好啊，开眼界，不过据我所知：
1、lotus notes就是利用数据库存放邮件的哦！
2、在海量数据处理时，无论谁快，都必须使用数据库！谁见过有人用系统文件存放海量数据并处理数据的？别说海量，超过几M的数据不用数..........[/quote:0bc581cf30]
lotus notes最多算一个小型邮件服务，作为邮件服务放不上台面。
很多程序运行的时候都有临时文件会产生，没人会把这些信息往数据库里写作为为临时记录？因为慢！
操作系统的磁盘缓存有用文件的，有用裸设备的，为什么不用数据库？因为慢！
其实我们说数据库和文件系统的时候本身就有可能存在定义问题
干脆具体化，数据库中的oralce、mysql、mssql、db2等随便挑一个和文件系统中jfs、xfs、ufs、ext3、ntfs等相比，在相同的硬件环境中和操作系统环境中，往写数据库中读写10G的数据和文件系统中读写10G数据谁更快，数据随便组织。
最后为了重申不是说数据库不好，是数据库和文件系统都有自己适合的方面，作为单纯的读写效率来说，就是文件系统好。
|
| hannibal 回复于：2005-04-20 12:34:47
|
这是要看数据量和应用而定的。
不能简单说数据库就比文件高效。
数据库的b-tree结构查询比文件方便，但是插入比文件低效。
fopen一个文件显然比连接一个数据库要高效的多。
cache可以提高速度，但是迟早是要写回disk的。
raw-io,现在很多文件系统非常高效，例如linux上的ext3的读写速度不亚于rawio. 裸设备比文件系统读写速度快很多倍的说法已经过时了。就算快，也就是个10%左右。
|
| nhw_cs 回复于：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()不是一个层次上的函数,但人们还常常比较,因为有时要决定到底用哪一个.
|
| crackpot 回复于：2005-04-21 08:48:42
|
个人理解：
数据库，像oracle，其实实现了一种自己的日志文件系统，他直接对硬盘进行block级操作，而不是一般的文件级，他自己分配和管理这些block，日志就是记录了对这些block的读写操作，同日志文件系统相似，只要日志不损坏，就可以做到备份数据和数据的恢复。而且他是用了很多buffer，专门为数据库的操作设置了许多buffer区。我理解中的数据库就是一个为检索，存储，管理专门做了很多工作的文件系统。
|
| 思一克 回复于：2005-04-21 09:40:20
|
我不知道ORACLE的配置。
请专家给出ORACLE直接读写硬盘BLOCK的具体情况。
我要看看是否真是如此。
|
| eagerly1 回复于：2005-04-21 09:44:42
|
数据库的效率主要还是体现在空间冗余和数据检索上吧．至于Ｉ／Ｏ还没有看见哪个数据库把它体现在性能特点上．
|
| narkissos 回复于：2005-04-21 09:55:45
|
bleem1998说的对，一些大型的数据库不使用OS的fs，而是自己的fs，同时对IO操作进行了cache、合并写入等优化措施，还通过进行查询优化减少IO访问。尽量提高访问效率。
|
| 思一克 回复于：2005-04-21 10:20:36
|
谁说大型DB用自己的fs? 举出例子。
看oracle是最好的大型DB吧。
看这个
http://www.oracle.com/technology/oramag/webcolumns/2002/techarticles/scalzo_linux02.html
如何是oracle运行的更有效率。
这里没说oracle有自己的fs
|
| narkissos 回复于：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结果
http://www.oracle.com/technology/tech/linux/pdf/Linux-FS-Performance-Comparison.pdf
ORACLE的数据INPUT和OUTPUT
用ext3最快，ext2次之， 用RAWIO和OCFS（ORACLE自己的RAWFS）慢许多。
还是那句话，如果用朋友用ORACLE自己的OCFS，请给出例子和结果。
|
| narkissos 回复于：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
|
所以，楼主的题目中的命题就不应该成立。
|
| rainyor 回复于：2005-05-06 20:21:11
|
数据库是用share memory做的
|
| FH 回复于：2005-05-06 23:06:41
|
[quote:60e9eddcc4="rainyor"]数据库是用share memory做的[/quote:60e9eddcc4]
倒！
|
| apollolegend 回复于：2005-05-07 04:59:18
|
如果非要比较数据库和文件系统的效率，我想为了公平起见，还是在同一个层次上比较的好
1。如果在数据存取这个层次上比，我想因为oracle的确绕过了操作系统而用自己的方式来使用磁盘，当然因为不存在文件系统这一层，所以要比read和write快。
2。如果在应用层级上比，可以这样来做，同样是1000个学生的成绩纪录，从中抽取想要的纪录。一个用数据库实现，一个用文件系统来实现，数据库可以不使用索引，当然文件系统也不能使用辅助的查询信息，比如hash等。我们来比一下谁先找到结果。我想这种比较的结果不说大家也都知道，因为在IO的这一块，文件系统可是不如oracle的奥，再有你的搜索算法不见得比oracle的要强吧。
3。文件系统和数据库的应用领域也不同，如果是信息管理，现在会有人用文件系统自己作起么？对于定长纪录，如工业控制的现场采集数据，因其数据结构已经定死，所以一般都使用文件来存取数据，因为文件的随机存取的效率肯定要比数据库的查询效率要高（即使带索引）
|
| gamester 回复于：2005-05-07 14:46:12
|
晕哦，大家都严重偏题了。
数据库与单纯的文件根本没有比较的必要。数据库有一些额外的操作，自然是跑不过直接的读写的，因为数据库不管利用了多少优化技术，最终还是要从硬盘中读写数据的。
其实数据库只是为了更有效的管理数据而产生的，它仅仅是将大量的数据以一定的格式保存在一个或者多个文件中。他的效率高高在在正常的应用下比你一条数据放在一个文件中高一些，方便一些，而不是高在读取文件上。
你将若干条数据放到一个文件中，所放入的这个文件加上你的读写等操作程序也可以说是构成了一个简单的文本数据库系统。
对于特定的应用，比如某些人提到的定长数据这种情况，你用自己开发的数据库系统（就是我前面提到的文本数据库）当然很可能会比其它的数据库系统来得更高效。
数据库利用文件保存数据，但所用来保存数据的一个或者多个文件是数据库的一部分，但却不是全部。我认为数据库和文件没有任何可比性，根本不是一个概念。
|
| gamester 回复于：2005-05-07 15:04:43
|
就算非要将这两个本来就不是一个概念的东西拿来对比，也是根本无法比的。
有谁能测出数据库本身花在随机读写一万个文件所用的准确时间？你能看到的是总的时间吧？
同理你也不是无法知道你写的程序花在随机读写一万个文件所用的时间的，你所能得到的也是你的程序运行的总的时间，到底有多少时间是真正花在读写磁盘上面的你能算出来吗？而且你所用的这个总的时间也可能因为你所用的程序语言而有所不同。
早点休息吧，不用再在这里争吵了，如果有人坚持认为使用文件效率更高（也许应该说是使用他自己的程序来组织自己的数据＝自己的数据库系统），就用文件好了。
|
