Project1

标题: 【高手进】数据库问题 [打印本页]

作者: 九夜神尊 时间: 2011-7-19 20:38
标题: 【高手进】数据库问题
本帖最后由九夜神尊于 2011-8-20 09:16 编辑

发帖，是为了让自己能静下心来写那东西。

喜欢Ruby的数据结构，喜欢死了。（←废话请无视）

写这么一个程序：程序在运行当中会不断产生对象，程序运行时间如果达到一定的长度，其大小可能会论G算。
因此这些对象光保存在内存里是不行的。

需要有这么一个数据库，能够存入对象（对象，对象，我想保存对象，就好像save_data那种），目前木有数据库，于是我只有这一种打算，放一个文件夹，一个对象创建一个文件。
于是，这文件数量几万神马的会是什么效果。。。。

有木有大神有建议的。

发帖其中一方面是为了让自己静下心来写那东西。dsu_plus_rewardpost_czw

作者: 淘金鸭 时间: 2011-7-19 22:13
为什么内存要增那么大

作者: 八云紫 时间: 2011-7-19 22:56
内存按 G 算那就是垃圾没有处理好才对。

把不需要的删掉，给需要内存的实力藤出空间。

说起来很容易，做起来有点麻烦。

VX 有自己的 GC ，只是实现原理或者使用方法，也就一句话 GC.start 。

只是效果感觉不明显。可以直接写一个内存管理类，用来处理内存。

作者: alyxms 时间: 2011-7-20 13:39
楼主的意思是：
写一个浪费硬盘空间的程序。
不断生成文件，但是不能保存到内存，要存到硬盘里以达到浪费空间，怎么处理……

作者: 神思 时间: 2011-7-20 13:53
如果上G的话.进数据库吧.

作者: 禾西 时间: 2011-7-20 13:56
簡單地dump出去就好了= =

作者: 忧雪の伤 时间: 2011-7-23 18:04
open啊dump啊难道你还想咋样……

作者: 苏小脉 时间: 2011-7-24 00:25
如果数据量很大的话，最好还是集成一个数据库系统吧，比如 SQLite。一来是你可以在抽象层上管理数据关系，数据操作限制以及进行高效的数据查询，二来是 DBMS 通常都通过自己的块 I/O 来实现文件操作，而不是建立在文件系统的抽象层上，这比程序语言在文件系统抽象层上操作文件的效率高。

作者: 九夜神尊 时间: 2011-7-24 00:31

苏小脉发表于 2011-7-24 00:25
如果数据量很大的话，最好还是集成一个数据库系统吧，比如 SQLite。一来是你可以在抽象层上管理数据关系， ...

有点点看不懂了，其实我要的很简单。
就是可以将多个RM的对象保存在数据库里，可以随时读取存入。

可否饭粒之？？

作者: 苏小脉 时间: 2011-7-24 22:50

九夜神尊发表于 2011-7-24 00:31
有点点看不懂了，其实我要的很简单。
就是可以将多个RM的对象保存在数据库里，可以随时读取存入。

如果你已经有一套管理数据的方案，那想必 Marshal.dump(obj) 就足够了。当管理、执行效率跟不上时，就可考虑集成一个数据库系统。

作者: 九夜神尊 时间: 2011-7-24 23:17

苏小脉发表于 2011-7-24 22:50
如果你已经有一套管理数据的方案，那想必 Marshal.dump(obj) 就足够了。当管理、执行效率跟不上时，就可 ...

我查看了一下你说的那个Marshal。这种玩意是按先后顺序写入，然后按先后顺序读出。

也许我要换一个方式表达我的需要了。
1：建立一个数据库（假设命名为database）
可以存入数据（以下方法名乱写的。）
save_data(对象,对象的索引,database)
save_data(对象2,对象2的索引,database)
save_data(对象3,对象3的索引,database)
save_data(对象4,对象4的索引,database)
以上，可以在任何时候春存入对象
当然也可以任何时候读出对象

obj = load_data(对象3的索引，database)
就可以读出对象3。

重要的是不用载入整个数据库的所有数据，写入也不需要覆盖整个数据库。
计划这个数据库内容好几个G，如果是Marshal……你懂得。

作者: 苏小脉 时间: 2011-7-25 04:47

九夜神尊发表于 2011-7-24 23:17
我查看了一下你说的那个Marshal。这种玩意是按先后顺序写入，然后按先后顺序读出。

也许我要换一个方式 ...

我不太清楚这是否就是你的所有需求，如果唯一的变量是对象索引的话，你把索引嵌入到文件名中，装载的时候去查找文件名是对应索引的文件就行了，这种简单的需求还是可以用 Marshal 实现的。如果你还有更复杂的需求，比如仅仅查询符合特定属性的对象 [1]，那最好还是弄一个 DBMS，虽然你目前的需求可能只会用到一个表。在需要把数据库嵌入到应用程序里而不是作为独立的服务程序时，大多数人会选择 SQLite。

[1] 即检查对象各种属性而不仅仅是单一的一个标识，如从数据库中查询 obj.field1 + obj.field2 > 5 的所有 obj。

作者: summer92 时间: 2011-7-25 10:42
所有东西都 dump 到同一个文件中，对象多了效率会不会下降？文件会不会太大，当数据库用

估计大也不会大过100M吧

作者: 九夜神尊 时间: 2011-7-25 12:35

苏小脉发表于 2011-7-25 04:47
我不太清楚这是否就是你的所有需求，如果唯一的变量是对象索引的话，你把索引嵌入到文件名中，装载的时候 ...

每隔一对象只有唯一的索引。其实这些对象都应该是保存到内存中的，读取这些对象只需要得到对象的地址。
同理，保存在数据库内只是为了缓解内存的压力，这里的索引也就相当于内存的地址。
你说的那方法可行，不过那文件数量很大，几千几万的说。

作者: 神思 时间: 2011-7-25 13:14
真那么大的话,用sqlite吧。

作者: 苏小脉 时间: 2011-7-25 13:19

九夜神尊发表于 2011-7-25 12:35
每隔一对象只有唯一的索引。其实这些对象都应该是保存到内存中的，读取这些对象只需要得到对象的地址。
...

保存在数据库内只是为了缓解内存的压力，这里的索引也就相当于内存的地址。

可以这么做，但是要注意反序列化之后，重新分配的地址就不会再和序列化后的索引所代表的地址一致了。如果每次都用对象本身的内存地址，那在反复保存 -> 读取 -> 保存后就会产生很多副本。这种情况下还是得额外开辟一个对象的域用以保存其唯一标识，这样就能保证对象的身份在不断的转储过程中一直都能持久。

不过那文件数量很大，几千几万的说。

这又回到我之前说的性能的问题了。用程序语言标准库提供的接口可以在本地文件系统（NTFS、FAT、ext2、ext3、……）之上进行简单的文件名匹配，但这通常比 DBMS 直接通过 block I/O 进行的数据库操作效率低。是否为了执行效率而复杂化工程结构，唯子实图利之。

欢迎光临 Project1 (https://rpg.blue/)