百万级数据能这么干

    今天一上午就和供应商展开了激烈的火拼.
    我作为项目技术把关人，当然会鸡蛋里挑骨头。发现了系统的几个主要的缺陷，我觉得非常之不妥：
    1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
这不扯蛋吗？客户端要不程序死掉，要不内存溢出。服务器，广域网还不累个半死。
    2） 假设1）没有问题，下一步还得同时把数据写到类似银行的U盾（类似U盘）中去，如果写成功了，还得更新百万级数据的状态。U盘的速度能有多快呢？该过程会要持续很长。估计数据表都被锁定了。该表其它的用户就不能使用了。这真要命。应该分批分批的写入数据。
    3） U盘如果在系统运行过程中，如果松动或拔出，在重新插入，要把系统重启。这还不让人郁闷死？难道你把U盘拔出，还要重启操作系统？应该提供程序的健壮性。
    4） 6百个客户端直连数据库，保持长链接。这个一值保持怀疑的态度。我也写过测试，似乎没有问题，网上也说没有问题。但通常，较好的做法是在客户端和数据库中间有一个前置，由它统一处理。
    5） 客户端和服务端都通过数据库作为状态的同步。服务端根本不知道客户端处于什么状态，导致他们的数据不一致。通常都会用socket通讯，采用心跳机制。

    靠忽悠是不行的，还是要把系统设计好。价钱也不斐。

评论

31 楼 joykai 2010-11-30  

对楼主的问题，其实我的理解是：
问题1、2、3，客户方提的需求总结起来就两个：
    1）数据导出来了，并且在服务器上做了标志，表示这个数据已经导出了。
    2）数据在U盘上放一个
客户不需要关心你是一次性导出，还是批量导出，所以这个问题就好解决了！你把数据用批量处理的模式，导出到本地，可以做成按月或其它分类形式做成Access、excel或csv等，然后打包压缩为一个包，然后拷一个文件到U盘就ok了？对否？

问题4，600个并发对大型关系数据库应该不是什么问题。实在不行，让他们找数据库软件供应商来解决嘛！
问题5，这个太easy了，参考网站单点的登录。

希望对你有帮助！

30 楼 hgq0011 2010-11-30  

whxhz 写道

过一段时间再来看看，最后咋整了

拖着，问题不解决我们就耗着
我们也打太极。

29 楼 whxhz 2010-11-30  

过一段时间再来看看，最后咋整了

28 楼 抛出异常的爱 2010-11-26  

hgq0011 写道

lvzhaojun 写道

1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
这不扯蛋吗？客户端要不程序死掉，要不内存溢出。服务器，广域网还不累个半死

100W数据一般的机器就可以了，以文本CSV传输，装到DB2中也就几秒吧

数据库是SQL SERVER 2K的，网络是VPN组成的局域网，速度还可以。
此表有一百万甚至两百万的记录，此表是多用户使用的。比如我一个用户要把一百万的数据导出，如果导出成功，要对每一行数据进行更新。此时其它的用户会往此笔中些数据。那么会不会存在表锁的情况，导致其它的用户写入不成功或者写入的时间非常长？

事务如果长的话.....
很有可能会等待或超时
所以表最好就不改只查

分区的事交给log或其它表.

27 楼 hgq0011 2010-11-26  

lvzhaojun 写道

1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
这不扯蛋吗？客户端要不程序死掉，要不内存溢出。服务器，广域网还不累个半死

100W数据一般的机器就可以了，以文本CSV传输，装到DB2中也就几秒吧

数据库是SQL SERVER 2K的，网络是VPN组成的局域网，速度还可以。
此表有一百万甚至两百万的记录，此表是多用户使用的。比如我一个用户要把一百万的数据导出，如果导出成功，要对每一行数据进行更新。此时其它的用户会往此笔中些数据。那么会不会存在表锁的情况，导致其它的用户写入不成功或者写入的时间非常长？

26 楼 hgq0011 2010-11-26  

leemny 写道

看半天，你只是说了对方的解决方案和方案缺陷，自己的具体业务需求是个啥也没说啊，到底要干嘛不知道，而且也没bt点的解决方案，基本上都是老一套+旧技术

改天可以把我们的业务整理出来。和大家分享一下。
目前这么一些缺陷，很是头痛

25 楼 lvzhaojun 2010-11-25  

1） 月结一百万甚至两百万的记录，能直接从服务上一次性拿到普通的PC机上面？
这不扯蛋吗？客户端要不程序死掉，要不内存溢出。服务器，广域网还不累个半死

100W数据一般的机器就可以了，以文本CSV传输，装到DB2中也就几秒吧

24 楼 leemny 2010-11-25  

看半天，你只是说了对方的解决方案和方案缺陷，自己的具体业务需求是个啥也没说啊，到底要干嘛不知道，而且也没bt点的解决方案，基本上都是老一套+旧技术

23 楼 hgq0011 2010-11-22  

niumd 写道

几百万的数据量不大，文件格式，采用ftp，很方便，这个没啥值得怀疑的lz

传输没有问题。
但是整个过程要保证是不出错的，也就是事务回滚。

客户端的界面要展示1到2百万的数据，这个不行吧？

22 楼 niumd 2010-11-21  

几百万的数据量不大，文件格式，采用ftp，很方便，这个没啥值得怀疑的lz

21 楼 hgq0011 2010-11-20  

tedeyang 写道

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

这个也要控制整个过程不能出错

20 楼 vdgame 2010-11-19  

1) 月结的数据可以在每天导出到一个文件中（就是前一天的数据，这个数据总是不变了吧？），并且压缩，这样一个个文件下载到PC，每个文件不会很大
   客户端处理也可以按日分别处理
2) 写U盘也按日处理，更新服务器也是按日处理
3) 这是需求问题
4) 6百个客户端直接连数据库服务器也没啥问题，就是要做好异常处理，比如连接断开了
5) “客户端和服务端都通过数据库作为状态的同步”这个确实不好，不过也行

19 楼 hgq0011 2010-11-19  

zlowly 写道

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

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

18 楼 hgq0011 2010-11-19  

kingkan 写道

在下的一些愚见，呵呵。

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

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

17 楼 hgq0011 2010-11-19  

skzr.org 写道

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

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

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

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

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

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

16 楼 hgq0011 2010-11-19  

抛出异常的爱 写道

ukey根本是个笑话....
事务查出更新数据库更是扯
不如写日志.
一个批次.写二条日志.
日志一条开始写
另一条写结束
只要有开始有结束
就认为数据完整
有开始没结束或结束是error
就认为数据是不完整的.
银行还省这点小钱
拉根专线没几个钱.

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

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

15 楼 CManLH 2010-11-19  

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

14 楼 graykeel 2010-11-19  

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

13 楼 zlowly 2010-11-19  

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

12 楼 kingkan 2010-11-19  

在下的一些愚见，呵呵。

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