300分征求一个文件格式的设计思路

[Waiting4you]

要设计一种本地文件存储格式，可以象队列一样向队尾存数据，从队首取数据。
数据不定长，而且可能会很大，要求尽量快速。

大家有没有好想法？用access数据库不知道是不是可行（随着数据的不断存取，文件会不会越来越大？用什么SQL语句可以快速取到“队首”并删除之？），目前还有一个想法是用复合文件，不过同样对其效率不放心。故上来向弟兄们征求意见，谢谢！

[僵哥]

[Quote=引用 164 楼 moxien 的回复:]
NND，加班ing，再來看下。
看了樓主在156樓的內容，再結合前面說的話。有點糊塗了，不知道這個文件是不是一個臨時文件。
POP後相應數據出隊後數據將不再保留？我之前一直以為數據還要保存在原來文件中。汗一個啊。
那隊列POP完後，文件還要不要？
[/Quote]
相当于一个交换文件.

[JavaPeak]

给点分吧

[Waiting4you]

[Quote=引用 147 楼 PPower 的回复:]
再重提一次前面已經說過的：

對於“class TMyLargeQueue 超大隊列”來說，並不應該關心數據的貯存方式，其實現的只是數據部分Cache的策略。這是它的核心。

數據的貯存方式，可以交由數據保存策略去完成，可分離可組合的設計能夠得到更多的可重用模塊。如何組織各種各樣的類，完成給定任務，我認為是面向對象設計更要關注的內容。可重用的，一開始會稍慢，但設計更有彈性的，更富有組合性的類，更易得到強壯的應用程序。在完…
[/Quote]
PPower对loki比较推崇啊:-)，如果愿意，你可以把我上面那个代码看作是TMyLargeQueue的文件保存策略，你可以再加上线程策略，Cache策略啥的（小声地说:偶觉得loki有过度设计之嫌）。

[Quote=引用 150 楼 moxien 的回复:]
如果有刪除的話必然出現碎片，除非不進行刪除操作。這就和我上面說的意思一樣了。
[/Quote]
对于一个固定大小的文件，里面的数据存放方式是<大小><数据><大小><数据>...，它

只作为循环队列操作

。这种情况是不会存在碎片的。因为Push数据必然在有效数据块的下方/无效数据块的上方，而Pop数据必然在无效数据块的下方/有效数据块的上方。不知有没有说明白-_-

[Quote=引用 151 楼 wd1111 的回复:]
不是很清楚楼主在说什么
[/Quote]
不清楚偶在说什么可以再看看后面的讨论，不少人的文法比偶好多了:-)

[财富实验室]

队列？
那就分文件存储拉，给文件排个队，处理完了，就下个文件，给文件大小设置个值。

[ahu9870]

解答都不错.

不过有人想过问题本身的建模是否合理吗?

[Waiting4you]

[Quote=引用 164 楼 moxien 的回复:]
NND，加班ing，再來看下。
看了樓主在156樓的內容，再結合前面說的話。有點糊塗了，不知道這個文件是不是一個臨時文件。
POP後相應數據出隊後數據將不再保留？我之前一直以為數據還要保存在原來文件中。汗一個啊。
那隊列POP完後，文件還要不要？
[/Quote]
数据POP完后就不要了(文件还要不要与实现有关)，这个文件就象僵哥说的，是一个交换文件。
实际上是我有很多客户端以速度不定地产生数据（有突发性），而且客户端可能会在离线状态下使用，所以我不能把数据直接送给服务端(一是速度问题，有时会以相当快的速度产生出一大堆数据，有时半天没有-_-，另外就是解决离线或断线问题)。
so我考虑在客户端用一个文件来作为队列，产生数据时直接送到这个队列中，另一线程则以一定的速度Pop数据送到服务端(就象水库的作用)。

另外一个话题，SQLite并没有想象的那么快（也许是我的SQL写得不优化），我试验的方法是存入是加一个递增的键值，取出时就找键值最小的那个。这样取出显然有一个查找过程（存入它是怎么找空间的偶没看它的代码不太清楚）。 楼上推荐数据库的能否提出好一点的如何把它作为队列的解决方案？

[truelove7283159]

1 SQLite 你怎么找最小的阿. min(id)?
SQLite 查找要出队的那个,也就是你那个自增id最小的那个,肯定要有个查询的.

我的测试结果：
OS Microsoft Windows XP sp2
CPU Inter P1.73G
Memory 768M,DDR2
HardDisk: 60G, 5400bps,cache 8M
插入一个18M的文件
最快：1S, 最慢3S, 10次平均值1.45S.

你的sql贴一下。

2 僵哥说得MQ好像也可以存储的,原来我以为不可以保存的后来查了一下可以保存的.

[僵哥]

提出使用数据库的,存在几个方面的原因:
1. 崇拜主义，对某些团队，产品，甚至是个人，过于相信，微软再强，他们发布的东西也并不能保证没有BUG，好比很多人都说的，国产的东西就是垃圾，他们说这话凭的是什么呢？经验甚至是见闻，可是想想，如果真正全是垃圾的话那么这东西还有市场吗？事实告诉我们低价并不能真正换来市场，用一个比较客观的角度来看，我们不得不承认的是，所谓国产的东西，存在的问题机率比国外品牌的要大，一方面来自于经验的不足，二方面是管理制度有待完善，三方面来自于企业文化的造就的缺陷;
2. 懒惰主义，有什么就用什么，只要能实现就完事大吉;
2. 悲观主义，缺乏足够自信，不认为自己能把事情做好，所以只要有现成的资源必优先，这个对于完成任务是好的，但是对于完成好任务就不好说了，并且也不利于产品在市场中竞争力的提升;
3. 理想主义，所谓理想主义，就是把很多现存的东西理想化，认为他们什么都能做到，都能做好。

并不是说对于类似的问题我要反对使用数据库，只是作为一个技术讨论贴，在讨论实现（并且楼主已经在努力实现）的过程当中，就应该有一个更加客观性的评价。我们讨论算法也好，应该是从复杂度，耦合度，可控性来着手。那为什么就一味地去推崇某某东西如何如何地好，好在哪里说不上，只说性能好，却又说没有测试过。这不是天方夜谭？开源的东西虽然有更多的智慧和力量参与，但是也不一定就会很好，首先参与的任何一家企业都会有所保留，特别是个例化的应用。对于一个通用数据库来讲，所有参与的团体或个人，进行更新的时候，都会考虑到一个通用性，或者是否典型性，这是不可能避免的。你也可以说这些产品有着如何如何的经验，但是你不能忽略掉其他个人或团体的经验。所以我希望对待类似的问题的时候，不要一概地使用什么Microsoft之类他们技术一定比某某强之类的话。一方面是对个人或团体的忽视，另一方面也是对技术本身的不尊重，在没有具体到某某技术要点的时候，谁也无法确定谁强谁弱。

[僵哥]

[Quote=引用 167 楼 truelove7283159 的回复:]
1 SQLite 你怎么找最小的阿. min(id)?
SQLite 查找要出队的那个,也就是你那个自增id最小的那个,肯定要有个查询的.

我的测试结果：
OS Microsoft Windows XP sp2
CPU Inter P1.73G
Memory 768M,DDR2
HardDisk: 60G, 5400bps,cache 8M
插入一个18M的文件
最快：1S, 最慢3S, 10次平均值1.45S.

你的sql贴一下。

2 僵哥说得MQ好像也可以存储的,原来我以为不可以保存的后来查了一下可以保存的.
[/Quote]
对于这个测试，首先id需要索引，虽然是耗时的操作，但是10次的测试有点过少.

使用自增ID是否可行，还需要看应用的频繁度和持续度。也就是说对于一个id(最优的应该是与机器字长相等)，增到低，估计需要多少时间，在这个时间中间是否允许维护，维护是否会影响使用等等。

[僵哥]

我先说一下，我目前遇到的一个应用的设计需要，跟楼主的需求相当类似。
总用户数是500~800万，持续在线在100万人次左右，每秒钟的活动用户估计是10~30万，即每秒钟平均需要处理10万个请求，每个请求都需要记录日志，日志数据需要入库并支持检索。由于考虑到数据库的IO能力有限（不仅仅只是这些日志，还有其它检索等等一系列需要使用数据库作为单点数据中心），需要先将数据暂存到文件(数据库的IO能力，仅仅只是写入日志，我们实测的是8000笔/秒)。

[truelove7283159]

1 嘿嘿,我懒,但是我不崇拜什么,也有些悲观,楼主有时间努力实现中阿.可我每次都是没时间,
动不动就给我2 3天时间. 要是整2个星期某些人的眼睛都绿了 .
有时间自己做当然好了,可以掌握到很多技术,自己能力也有提升.


2 我知道数据库不好,还推荐了.后来看你们在讨论自己怎么实现,我就没发言阿.


数据库,要查询,要删除的,还支持一堆庞杂的功能, 未必是最好的技术方案.
但是自己做这个队列的话,push pop ,Cache,文件的存储,碎片整理等一些列问题都要自己考虑的.
另外还有进队成功不成功的问题, 不成功是不是这个数据就丢了,还是由机制重发等.毕竟不是一个简单的内存队列, 是一个文件队列.

另外我可能不会使用自增id的这个本来就慢.可以使用消息时间.
而且一次操作一条记录,说实在的快不到哪里去. 批量倒是很快的.

[僵哥]

[Quote=引用 171 楼 truelove7283159 的回复:]
1 嘿嘿,我懒,但是我不崇拜什么,也有些悲观,楼主有时间努力实现中阿.可我每次都是没时间,
动不动就给我2 3天时间. 要是整2个星期某些人的眼睛都绿了 .
有时间自己做当然好了,可以掌握到很多技术,自己能力也有提升.


2 我知道数据库不好,还推荐了.后来看你们在讨论自己怎么实现,我就没发言阿.


数据库,要查询,要删除的,还支持一堆庞杂的功能, 未必是最好的技术方案.
但是自己做这个队列的话,push pop ,Cache,文件的存储,碎片整理等一些列问题都要自己考虑的.
另外还有进队成功不成功的问题, 不成功是不是这个数据就丢了,还是由机制重发等.毕竟不是一个简单的内存队列, 是一个文件队列.

另外我可能不会使用自增id的这个本来就慢.可以使用消息时间.
而且一次操作一条记录,说实在的快不到哪里去. 批量倒是很快的.[/Quote]
我只是针对那些在前面已经讨论过很多关于数据库的局限性之后,还一个劲提数据库,却又说不出个所以然来,仅仅只是用一些,如"高效、安全、可控"之类的模糊字眼的人.

重发机制这些都跟队列的操作没有直接关系,那是通讯层的问题,即使使用数据库,也有可能存在如何检测断开如何重连等等一系列问题.

使用自增ID也并不一定会慢,反倒是使用消息时间,这个会不准确,最高精确度能到毫秒已经是相当高了,就算是精确到一毫秒,那么每秒钟的处理能力也仅只能是在一千笔以内,更何况如windows本身也只能保证15毫秒的精确度.

[CONLONG]

数据处理的时候可以参考orcale 存取日志的方式
我觉得可能会提高一点效率

[wjlsmail]

也许SQLite不是适合的方案，但不过是我和楼上一些朋友的建议，如果触动了某位的神经甚至还要上纲上线，那我就无语了，毕竟只是讨论而已，天这么热，犯不上。

至于说没有给你写明白所以然，也许是我的不对，但后面的回复已经给你写了理由，还要怎么详细呢？要想学习什么东西，最好的方式是别人给你引子，然后你自己去深入。

我对SQLite了解也不多，只做过一些简单调查，对比PostgreSQL看过一点点代码，如有说的不对的地方，还请多多指教。

我的参与似乎偏离了楼主的意图，抱歉抱歉，希望楼主问题得到圆满解决。

[Waiting4you]

谢谢大家，应该可以结贴了

[castlooo]

关注

[sundl2268]

看牛人们讨论就是不一样哦 ，呵呵，学习了

[四哥]

xml

[大朝书房]

mark，虽然不太懂，不过我想以后会懂的

[wesleyluo]

这个贴子很好，留下。