用户名: 密码: 忘记密码? 注册
收藏此问题 发表新评论

如果没有数据库 ... 世界将会怎样 ..?

我是个病态的完美主义者 ... 天蝎座的性格使然 ...

这个从我之前的帖子里面也能看出来 ... 在纠结美观与效率等等问题 ...

现在这个纠结的范围扩大到了数据库 ...

我发现虽然我虽然考虑的很远拆分了表 ... 并且也按需的进行数据库连接 ...

但分析自己的代码还是发现了问题 ... 我发现我用到了很多次 LIMIT 0, 1 的查询 ...

而这些查询的条件不外乎都是 id = xxxx ... 但是为了一个这样的查询 ...

却要执行 mysql_connect / mysql_select_db / mysql_query / mysql_free_result / mysql_close 这一系列命令 ...

这显然不是最高效的 ...

于是想到解决方案 ... 我们是不是可以抛开 MySQL ...

回到没有数据库的时代 ... 回到文本储存的时代呢 ...

我做了如下的实验 ...

创建了一张 100k 条数据的表 ... 自增的主键和一个 text 字段 ...
[php]<?php
class data {
public $text = '测试测试测试测试测试测试测试测试';
}
$data = new data();
?>[/php]

重复了 100k 次把上面的对象序列化之后储存在一个文件夹里 ...

然后分别用 ...
[php]<?php
mysql_query( 'SELECT `text` FROM `test` WHERE id=50 LIMIT 0, 1' );
mysql_fetch_object();
?>[/php]
... 和 ...
[php]<?php
unserialize( file_get_contents( './test/50' ) );
?>[/php]
调用 ...

测试的结果是文本储存的效率是使用数据库的 7 - 12 倍 ...

就算不是单一主键的查询 ... 也可以通过自己建立索引系统来完成更高级的查询 ...

现在的服务器硬盘都很大 ... 应该不会在乎这个 ...

那么我们是不是可以考虑不再一切都依赖数据库了呢 ...

因为之前没看到有类似的讨论 ...

并且在很早很早以前的 CGI 时代 ... 纯文本的存储方式被很多人唾弃 ...

那时候我还不懂事儿 ... 完全不知道为什么会那样 ...

求指点我这个部分替代的方案是否可行 ... 以及文本存储为什么被大家遗忘了 ..?
昵称: Sunyanzi  时间: 2009-01-13 08:54:38
'SELECT `text` FROM `test` WHERE id=50 LIMIT 1' 可能会更快些
还有.一定会有个灵界值,在此容量下文本的读取速度和数据库是一样的.如果大于这个值数据库就会快.
你想吧.其实数据库也就是个文本文件.只不过在里面做了些优化而已.
就是因为这些优化.所以浪费了一些资源.导致在小容量的储存时候没有文本方式快

还有/不要把数据库单纯的看做就是一个存取内容的东西.一个数据库远远没有这么简单.他所囊括的复杂的SQL语句和各种函数.以及主键索引.存储过程.备份恢复等.都要比文本占有很大的优势
昵称: TankMe  时间: 2009-01-13 09:05:16
如果没有如果!
昵称: mizha  时间: 2009-01-13 10:54:46
学c语言时曾想过自做一个类似数据库的东西.可惜只是想过.
昵称: myBe  时间: 2009-01-13 11:05:53
:funk:
昵称: cnkiller  时间: 2009-01-13 11:16:47
看应用吧,如果简单应用是可以不用数据库的。
昵称: sueswriter  时间: 2009-01-13 11:54:28
楼主的测试简直就是垃圾(不好意思,我说话直接)
用你同样的方法,写入1000w条记录到你的数据库和文本,再来做查询,删除,更新。
然后再比较效果
昵称: ysixin  时间: 2009-01-13 12:37:03
简单讲,  多用户操作同一个txt时,  都拿你命....
昵称: 冯.于安  时间: 2009-01-13 13:01:03
原帖由 于安 于 2009-1-13 13:01 发表
简单讲,  多用户操作同一个txt时,  都拿你命....


昵称: flyhacker  时间: 2009-01-13 13:36:29
数据库本身就是文本 

你说的方法可以 可以把那一部分 静态或者缓存
昵称: 上善若水  时间: 2009-01-13 14:01:37
原帖由 ysixin 于 2009-1-13 12:37 发表
楼主的测试简直就是垃圾(不好意思,我说话直接)
用你同样的方法,写入1000w条记录到你的数据库和文本,再来做查询,删除,更新。
然后再比较效果


别说1000W,就是10W的数据,只文本处理的话...都会出现问题...

楼主这也叫完美主义者?楼主10W级别的项目都没做过吧...笑死人了...
昵称: UnicoRn  时间: 2009-01-13 14:21:50
看题目,如果没有,我去银行取你的钱去
昵称: wodoe  时间: 2009-01-13 14:27:41
原帖由 wodoe 于 2009-1-13 14:27 发表
看题目,如果没有,我去银行取你的钱去

如果没有,我就去找中国银行借贷..:smile:
昵称: UnicoRn  时间: 2009-01-13 15:03:35
直接当行长也行,反正没有办法说假的
昵称: wodoe  时间: 2009-01-13 15:52:45
100k 条记录也不一定要分表

如果只是实现简单的逻辑,文本未尝不可
如果发现数据库效率不如文本(指简单的txt,没有深层的算法),只是你没有发现mysql伸缩性罢了,去看看my.cnf
昵称: pylong  时间: 2009-01-13 16:33:28
原帖由 于安 于 2009-1-13 13:01 发表
简单讲,  多用户操作同一个txt时,  都拿你命....


会有啥问题 ..? 天塌了还有 LOCK_EX 顶着 ...

并且一般而言只有 选择 远大于 更新 的情况才会用我这个方法替代吧 ..?
昵称: Sunyanzi  时间: 2009-01-13 17:30:43
原帖由 Sunyanzi 于 2009-1-13 17:30 发表


会有啥问题 ..? 天塌了还有 LOCK_EX 顶着 ...

并且一般而言只有 选择 远大于 更新 的情况才会用我这个方法替代吧 ..?


如果同时10个用户往txt写数据..  会出现什么情况??
昵称: 冯.于安  时间: 2009-01-13 17:32:24
首先 ... LS 的诸位 ...

我在最早的帖子里面说了是部分替代 ... 没说要完全取代数据库 ...

原帖由 ysixin 于 2009-1-13 12:37 发表
楼主的测试简直就是垃圾(不好意思,我说话直接)
用你同样的方法,写入1000w条记录到你的数据库和文本,再来做查询,删除,更新。
然后再比较效果


额 ... 我是在本地测试的 ... 实在没能力做达到千万数量级 ...

单目录存储的文件如果超过一定数量 ... 使用文件名命中的时候会很慢么 ..?

原帖由 UnicoRn 于 2009-1-13 14:21 发表


别说1000W,就是10W的数据,只文本处理的话...都会出现问题...

楼主这也叫完美主义者?楼主10W级别的项目都没做过吧...笑死人了...


会出现什么问题 ..?

10w 级别的项目我做过不少 ... 只是没用过这种方式而已 ...
昵称: Sunyanzi  时间: 2009-01-13 17:32:46
原帖由 于安 于 2009-1-13 17:32 发表


如果同时10个用户往txt写数据..  会出现什么情况??


先来后到 ... 总有个毫秒级的先后顺序 ...
昵称: Sunyanzi  时间: 2009-01-13 17:37:46
我觉得其实保存成文本文件, 要符合下面几种情况:
1. 文件量比较少
2. 比较少写入
3. 数据不需要搜索查询

我之前也有类似的想法,
我一个朋友, 就遇到了数据量大, 数据库查询慢, 数据库负担重的问题.
我就建议使用文本文件保存, 把数据键存放成目录结构和文件名.  
改成文本文件保存后, 数据库的负担大大的减少了, 虽然好一些了, 但是硬盘的I/O操作的负担却增加了不少.
后来, 我们用内存来虚拟一个硬盘, 服务器的负担就减少了很多了.

这个问题可以看出, 如果文件很多的话, 会给硬盘增加负担的, 而存放在内存中就不会有这么多的负担.
而大多数据库就是有做了内存缓存这一层.
但数据库因为太复杂了, 要查询分析, 要管理数据结构, 要检索, 不像文本文件那么简单, 我们只要通过操作系统读一下就可以了.

而文件读写锁是一种比较原始的机制, 这方面当然不会有数据库中的强大了, 特别是访问量大的时候. 其实主要是有些系统上的PHP对文件操作锁支持并不好.

而文件的查询搜索这方面不用说了, 肯定没有数据库的灵活了.

如果PHP能有一个后台的守候进程管理这些数据就好了, 很多数据只要读取一次, 后面的都是在内存中的了.
每个客户访问的进程只要与这个进程会话, 读写所需要的数据.
其实数据库也可以看成是这样的一个进程, 只是它太复杂了, 且为了通用性也没有我们自己的专门守候进程好.
昵称: programmerhuang  时间: 2009-01-14 18:50:26
楼主的方法只实用于数据量小 查询少的情况下吧
查询多了 楼上的说了 I/O 的cost你算了吗 I/O 很占资源
昵称: icecoke  时间: 2009-01-17 16:31:01
这个想法在多年前就有过,结论是:
如果自己能写一个灵活处理文本数据的程序,那么就相当于自己写了一套独立的数据库管理系统。

现在数据从免费到收费的,从开源到闭源的,适合各个层次的都有。与其自己去写一套,不如选择一套适合自己项目的。

计算机上本来没有数据库,这样的需要多了,也便有了数据库。
昵称: super_fire  时间: 2009-01-17 20:44:42
楼主真是太有想法了,可惜想的不完全。。。 多用户,事务,并发。。。
昵称: dusdong  时间: 2009-01-18 18:01:33
唉,如此假设,如果没有文件系统呢
昵称: leric  时间: 2009-01-18 19:44:20
你想到的别人都想过了。难道开发数据库就为了玩啊。
昵称: rebill  时间: 2009-02-08 12:19:19
数据库 即 文本
昵称: huigenius  时间: 2009-02-09 12:54:42
BigTable
昵称: hemon  时间: 2009-02-13 22:00:34
如果想知道如何管理以文本文件为基础的文本数据库(textdb)的话,可以考虑看看ofstar(http://www.ofstar.net/)这个论坛程序的实现方式

[ 本帖最后由 horseluke 于 2009-2-14 01:05 编辑 ]
昵称: horseluke  时间: 2009-02-14 01:03:07
孙燕姿把程序和星座都联系上了。偶是双鱼座的。
昵称: debiangrub  时间: 2009-03-05 10:32:19
用文件之前还是要考虑些问题拉,上周项目增加一个模块,我懒得建数据库,就用文件存放数据(其实写起来还麻烦点),测试都通过拉,但是我们客服告诉我今天数据修改正常,但是到了第二天,数据又回到最原始状态,晕,那有这样问题啊,后来我才想起,我们数据存放在多台服务器上。。。。。。
昵称: guxiaochuan  时间: 2009-03-07 19:05:55
说到文件,我以前写过一个AJAX+文件的无刷新聊天室
当时是来练手的,但是后来一想,如果同时1万用户在线。。。

我的天拉。。。(当然,如果用文件存放聊天室数据应该也有解决办法,但是我还没想出来)
昵称: guxiaochuan  时间: 2009-03-07 19:09:51
世界还是那个世界,:lol:
昵称: kwlong2008  时间: 2009-03-25 09:33:24
楼主的测试简直就是垃圾(不好意思,我说话直接)
用你同样的方法,写入1000w条记录到你的数据库和文本,再来做查询,删除,更新。
然后再比较效果
昵称: kwlong2008  时间: 2009-03-31 15:09:07
串表 咋搞??
昵称: nsource  时间: 2009-04-01 08:46:49
不要重复历史!:lol: 也不要重复发明轮子!
昵称: hittlle  时间: 2009-04-01 11:45:14
浪费更多的纸.....:cry:
昵称: liuxingyuyuni  时间: 2009-04-02 20:30:42
还有XML,文件系统
昵称: witer666  时间: 2009-05-11 17:31:13
如果没有数据库,我也就不会在这学该死的数据库~~
昵称: 该怎么写  时间: 2009-05-11 17:38:36
楼主应该多注重基础的东西。
从你代码,
<?php
unserialize( file_get_contents( './test/50' ) );
?>
就可以看出,你要学的东西还很多。
昵称: 我要读书网  时间: 2009-05-13 12:01:47
小小的顶帖。。。
昵称: nsource  时间: 2012-07-23 16:16:42
世界还是一样的~
昵称: zdenfey  时间: 2013-06-06 17:52:51
发表评论
昵称:
内容:
验证: