百万级数据能这么干

百万级数据应该不是很多，也就250MB以内，按照一个U盘5M/s的写入速度不到一分钟；
（一般读取速度都有30M/s 10s以内足够读取了）
如果采用压缩，相信性能还有30%左右的提升！

1）2）做月结的话数据是不是不可能发生变化了，锁定表也无所谓了！因为只有自己修改这些状态，别人只是读取和查询，问题应该不大

后面的3）4）5），第3点要重启就太变态了，真的有点怀疑他们的驱动
4）5）应该问题不大了












以上只是猜想，过于理想化，请大家自动越过

我做过的项目里有个与人民银行的数据交换，他们用的是分批次的纯文本（直接用c从数据库里导出来）。
譬如201003-1.txt,201003-2.txt...
每个文本控制在10M左右，ftp传输。
简单可靠。

在下的一些愚见，呵呵。

第一，在服务器将月结数据按用户写成自定规则格式数据到文件
第二，要求客户端用户自己下载自己的月结数据文件到本地
第三，用户在客户端通过这个文件写入U盾，增加对数据完整性的判断，来得出数据是否写入完成。
第四，要求用户自己申报写入U盾成功请求，本地判断非完整不准申报U盾写入成功请求。
第五，本地数据以及U盾数据验证通过，服务器接收请求认为该用户U盾写入成功。更新百万级数据的状态，服务器在缓存中加入标识，说明哪个用户的数据的状态数据已被更新。

我觉得这些方案只要考虑周全，技术上没什么问题。什么百万级、6百客户端长连接什么的别以为有什么特别。
在十年前B/S还不成熟时，随便个破小型机+Oracle 7+PB的C/S方式就轻松达到一千以上客户端同时在线连接呢，只要设计好cache机制，用u盘作数据存储也不难。

显然这个公司需求场景没有搞清楚。

边从数据库取，一边压缩进IO流，输出为压缩文件，百万级的文本记录也没多少M的

那个项目负责人，告诉我每次写数据一定能保障要么成功，要么失败。对于这一点我非常的怀疑，有什么办法能保证事务呢？。所以要求他们提供数据验证的工具，能够从Ukey中对比数据库中的数据是否一致。但业务部门的人，有点向着他们，说不用了。出了问题，IT不用负任何责任。我晕。

在我看来也应该分批分批的写。
有专线的。

我刚才大约计算了一下，假设一条记录大约400字节，月结记录1500000，那么应该有400*1500000/1024/1024＝572M
而整个数据事务读写过程应该非常的慢了。

虽然是月结，但是系统还是要正常运转的。他们没有采用分表冻结，所以同一张表，在月结是，还会有记录写入的。所以，我认为会有锁表的情况，甚至业务系统会瘫痪。

也是一种方案。
有成功的案例吗？

我也觉得他们的方案可以。
但是，如果能解决我这问题，那么就是一个非常成功的案例。那么他们的银子就大把大把的来了。