关于存储大量数据的数据结构

[pastom]

有一个订单流管理，其中进入系统的订单量很大，如果只在系统中设置一个队列来存储订单对象，这个队列会很大，不切实际，如果采用缓存将一部分订单写入硬盘，这样查找进入系统的订单时需要先把数据读到内存中，而且由于是在大量订单中搜索，效率也是一个重要的问题，希望各位朋友提点意见。谢谢

[healer_kx]

你的系统中没有数据库嘛？千万别用文件写，搞不好适得其反，而且搞得逻辑复杂。

[pastom]

ding

[pastom]

2l的意思是说先把订单写入数据库?这样还是有问题啊，那样处理订单不是要频繁访问数据库？请您具体说下您的流程，谢谢

[pastom]

顶起，大家踊跃发言哈

[healer_kx]

写文件，和读文件，未必要比数据库的效率高，数据库的存储是极其优化的。
B+树，磁盘映射文件，等等，都为你告诉存取做好了准备。
而文件越大，你读写它越是不利。
而且你需求变化的时候，数据库对你的存储和查找非常有利，而文件就不具备这样的优势了。

而且你确实要搜索嘛，数据库的搜索都是依托算法的，你在文件里面找这些东西，你要先读文件到内存，再玩算法，
不是和你对内存的需求矛盾了。

流程就不说了，不是很明显嘛。

[pastom]

顶

[sunnylyy]

内存中的订单检索，可以用hash表实现，用订单的主键作hash表的key

[healer_kx]

对了，你的订单有多多啊？能比金山所有的网站的LOG还大嘛？

[pastom]

可能会达到10000以上，我刚开始做实际项目，对这些没有经验，请赐教，谢谢

[pastom]

还有就是要是将订单存入数据库中，那么操作数据库出现的多线程同步问题：
比如用户要求修改订单，然后从数据库读取数据正在修改，而后台订单处理
线程接着读取数据并且完成了处理，这时候用户的修改就不能完成了。

[pastom]

ding

[Coolfatman]

数据库本来就是用来访问的。频繁访问没什么问题。

[梦无痕123]

定有没有文件高手啊，给个策略，我也想知道文件存储的

[healer_kx]

如果你觉得数据库不划算，就用BDB，找找资料吧，有Java的接口，正好处理你这种需求。

[Dan1980]

数据库就是用来取代规模过大的文件存储的，10000以上对数据库来说绝对小case啦。。。正如甘草兄说的，数据库的方便性和效率都是不容置疑的。数据库也有支持多线程应用的同步管理功能，另外，数据库还支持约束和事务回滚以保证数据一致性，总之，数据库是首选。