1，同时大概11个工位点生产，每个工位生产不同的批号电池（也可能一样）
2,，产线设备测试数据输出包含：电压，内阻，是否合格，要根据工位+批号唯一标识检索和存放
3，每天大概是60W数据，11个工位点同时进行，每个工位大概是2条/秒，一年大致是1.5亿
4，生产过程中界面上需要实时显示这个工位这批电池的电压、内阻：分布图（如1.21V多少个，1.25V多少个），不合格数，总是，以及电压内阻：最大值、最小值，平均值，标准差
13 个解决方案
#1
实时跟不实时 在你的描述中 意义不是很大.
其实无非就是 把这些数据采集的同时扔到数据库中 方便查看..
所以这根本没什么啊 就几个表 插入数据库不就行了?
当然如果你说你的数据太大了 那么你可以每个工位 每月 一个表.
比如
工位1-201701 那么一个月就是11个表 一年就是12*11=132个表 其实也还好..
那么数据大概一个表就是一千来万 其实也不多..况且都是数字 查询的话 也都是图形控件那种显示吧..
至于你说的实时的问题..就看你采集部分了.一般情况下 都是串口通讯 winform采集上来一边插入数据库一边显示
其实无非就是 把这些数据采集的同时扔到数据库中 方便查看..
所以这根本没什么啊 就几个表 插入数据库不就行了?
当然如果你说你的数据太大了 那么你可以每个工位 每月 一个表.
比如
工位1-201701 那么一个月就是11个表 一年就是12*11=132个表 其实也还好..
那么数据大概一个表就是一千来万 其实也不多..况且都是数字 查询的话 也都是图形控件那种显示吧..
至于你说的实时的问题..就看你采集部分了.一般情况下 都是串口通讯 winform采集上来一边插入数据库一边显示
#2
楼主的要求其实并不高，每秒才2个点，不论是采集数据还是显示都有足够时间。代码中用线程做多工位数据采集，数据发送给界面直接显示即可。如果是采集和显示以及存储分计算机的话，用以太网做个cs结构系统即可。数据存储建议用文件，不推荐用数据库。
#3
11个工位11张表，为什么不集中在一张，是因为数据量上亿后可能会有效率问题，那么早分表避免之后麻烦。你数据传输方式未知，不做讨论。数据库本身就支持多连接所以不用太在意并发插入数据。让你们DBA每个月或者每年至少把过往数据做一次备份，然后移动到其他表或库，需要过往数据做好统计数据单独存放，日志大了及时备份或者删除。
#4
11个工位点同时进行，每个工位大概是2条/秒
这难道还有任何难度可言吗？
就是数据量有点多。。做好分布式存储，其它就没什么问题了
这难道还有任何难度可言吗？
就是数据量有点多。。做好分布式存储，其它就没什么问题了
#5
就算容量每年也不会超过1个T，请问难点在哪？还是楼主看到60w就吓傻了？
#6
看你的思路，程序应该不难呀，
每天60W数据也不是很多
想想电信业务，哪数据才多
实实显示哪个也好搞了，搞个数据显示界面或柱状图，不难吧
整个程序用C/S架构。
我觉得我完全能胜任。
呵呵
每天60W数据也不是很多
想想电信业务，哪数据才多
实实显示哪个也好搞了，搞个数据显示界面或柱状图，不难吧
整个程序用C/S架构。
我觉得我完全能胜任。
呵呵
#7
看板通常是一个异步统计机制，跟生产数据并不同步。例如可能每10秒钟、或者（并且）每超过10条生产数据才异步计算一次看板。如果看板很多，那么分步到2个以上服务器去产生看板统计比较好。看板数据产生了之后，直接推送给各个前端显示屏设备，通常不需要落地保存（根本没有意义）。只要保存最底层的生产数据够够了，而且生产数据也是异步保存到数据库的。
我给你打一个比方，就好像是水流过了粗粗的管道，那么你的看板仅仅统计这个管道内一小段的数据，而不需要动不动就到大水库里去查询统计一次。
实际上你的数据量很小。同样的软件，可以给几千个点、几百种业务进行统计，能在内存中进行高速运算。不需要将数据落地！
我给你打一个比方，就好像是水流过了粗粗的管道，那么你的看板仅仅统计这个管道内一小段的数据，而不需要动不动就到大水库里去查询统计一次。
实际上你的数据量很小。同样的软件，可以给几千个点、几百种业务进行统计，能在内存中进行高速运算。不需要将数据落地！
#8
之所以有些人一旦实际设计这样的系统就拉稀了，那是因为它总是用刚学编程时“各个终端去查询数据库表、各个终端数据库编程进行sql统计查询”的思路，那么当终端数多一些，任务重一点点，服务器就卡死了。
#9
11个工位点，那么需要“实时显示”的显示屏就远远不止11个，至少有12个、15个或者更多。
#10
关于“管道计算”的比喻，更具体地描述就是，当你的生产数据从一个个看板对象中“流过去”，你只要将最近1分钟（或者、甚至10秒钟）的数据缓存在看板内，用来定时更新看板统计结果，然后推送看板统计结果给各个显示屏设备（是推送傻瓜化的最终结果，而不是让各个终端去反向统计）。所以这需要按照这个框架去设计算法，而不是到数据库里去“统计”。
对于大的、快的决策系统显示终端，傻瓜化地往前推送直截的、极端实用的最终显示结果，数据实体都是根据前端需求来设计的（而绝对不是根据什么数据库表来设计的），这样才是技术体现，才能保证大量显示屏频繁刷屏的需要。而那些还在学习 sql 统计函数“怎么用”的阶段的程序，只是最低级的程序，只能靠销售员去明骗用户。
对于大的、快的决策系统显示终端，傻瓜化地往前推送直截的、极端实用的最终显示结果，数据实体都是根据前端需求来设计的（而绝对不是根据什么数据库表来设计的），这样才是技术体现，才能保证大量显示屏频繁刷屏的需要。而那些还在学习 sql 统计函数“怎么用”的阶段的程序，只是最低级的程序，只能靠销售员去明骗用户。
#11
事实上，流程中会有一个“订阅看板”的消息，各个显示屏设备在启动时要给服务器发送一个消息说明自己订阅的是哪一个看板，那么服务器就会在看看板数据更新事件中，主动推送看板数据。
我说过了，你列出的数据级别比较小。假设你用一个3000块钱的服务器来支持这个系统，那么就应该用正规的软件设计。而假设你用一个30000块钱以上的服务器，那么你可以用比较初级的编程方式。
当你的系统软件设计好了之后，如果你稍加配置（配置一下各个看板对自己缓存数据的 sql 统计语句）就能产生更多的看板，给100个工位，150个显示屏推送实时报告，那么你比较正规地 设计这个软件，使得它有点技术。
我说过了，你列出的数据级别比较小。假设你用一个3000块钱的服务器来支持这个系统，那么就应该用正规的软件设计。而假设你用一个30000块钱以上的服务器，那么你可以用比较初级的编程方式。
当你的系统软件设计好了之后，如果你稍加配置（配置一下各个看板对自己缓存数据的 sql 统计语句）就能产生更多的看板，给100个工位，150个显示屏推送实时报告，那么你比较正规地 设计这个软件，使得它有点技术。
#12
3，每天大概是60W数据，11个工位点同时进行，每个工位大概是2条/秒，一年大致是1.5亿
------------------------------------------------------------------------------------------
1.5亿：数据量比较大的时候需要考虑分表，按照 年份+月份 进行分表（年+周也可以），每个表大概为 1kw，电压，内阻，工位，批号创建索引，不一定保证分析得对，还是根据实际测试情况调整一些。
2条/秒：如果数据库处理能力不强的话，考虑使用缓存，定时做一个批量插入处理。
4，生产过程中界面上需要实时显示这个工位这批电池的电压、内阻：分布图（如1.21V多少个，1.25V多少个），不合格
--------------------------------------------------------------------------------------------
实时数据最好不要从数据库里面取，从 上面提到的缓存取出数据，通过wcf回调客户端就好了。
以上只是一些经验之谈，lz根据实际情况做技术选型吧。
#13
推测你可能要做这样的系统，11个工位点就是11个独立的小程序，需要实时发送测量数据到一个大的“监控系统”中，后者负责并发处理这些数据，包括显示、统计、存储。这样的话我的想法如下：
1、用CS来实现（TCP），监控系统作为服务端，工位点程序任何时候都可以连接上去，实时发送数据
2、监控系统对数据进行实时统计，但是存入数据库可以异步，或者利用缓存
个人以为，11个工位点每秒2个记录的并放量，对服务器来说不管是接收、统计、还是UI展示，都没有太大压力，只要把数据接收到了，计算、显示、存储，都可以异步。可以根据实际需求做出相应的处理，比如是否要分组统计、存储。。。
1、用CS来实现（TCP），监控系统作为服务端，工位点程序任何时候都可以连接上去，实时发送数据
2、监控系统对数据进行实时统计，但是存入数据库可以异步，或者利用缓存
个人以为，11个工位点每秒2个记录的并放量，对服务器来说不管是接收、统计、还是UI展示，都没有太大压力，只要把数据接收到了，计算、显示、存储，都可以异步。可以根据实际需求做出相应的处理，比如是否要分组统计、存储。。。
#1
实时跟不实时 在你的描述中 意义不是很大.
其实无非就是 把这些数据采集的同时扔到数据库中 方便查看..
所以这根本没什么啊 就几个表 插入数据库不就行了?
当然如果你说你的数据太大了 那么你可以每个工位 每月 一个表.
比如
工位1-201701 那么一个月就是11个表 一年就是12*11=132个表 其实也还好..
那么数据大概一个表就是一千来万 其实也不多..况且都是数字 查询的话 也都是图形控件那种显示吧..
至于你说的实时的问题..就看你采集部分了.一般情况下 都是串口通讯 winform采集上来一边插入数据库一边显示
其实无非就是 把这些数据采集的同时扔到数据库中 方便查看..
所以这根本没什么啊 就几个表 插入数据库不就行了?
当然如果你说你的数据太大了 那么你可以每个工位 每月 一个表.
比如
工位1-201701 那么一个月就是11个表 一年就是12*11=132个表 其实也还好..
那么数据大概一个表就是一千来万 其实也不多..况且都是数字 查询的话 也都是图形控件那种显示吧..
至于你说的实时的问题..就看你采集部分了.一般情况下 都是串口通讯 winform采集上来一边插入数据库一边显示
#2
楼主的要求其实并不高，每秒才2个点，不论是采集数据还是显示都有足够时间。代码中用线程做多工位数据采集，数据发送给界面直接显示即可。如果是采集和显示以及存储分计算机的话，用以太网做个cs结构系统即可。数据存储建议用文件，不推荐用数据库。
#3
11个工位11张表，为什么不集中在一张，是因为数据量上亿后可能会有效率问题，那么早分表避免之后麻烦。你数据传输方式未知，不做讨论。数据库本身就支持多连接所以不用太在意并发插入数据。让你们DBA每个月或者每年至少把过往数据做一次备份，然后移动到其他表或库，需要过往数据做好统计数据单独存放，日志大了及时备份或者删除。
#4
11个工位点同时进行，每个工位大概是2条/秒
这难道还有任何难度可言吗？
就是数据量有点多。。做好分布式存储，其它就没什么问题了
这难道还有任何难度可言吗？
就是数据量有点多。。做好分布式存储，其它就没什么问题了
#5
就算容量每年也不会超过1个T，请问难点在哪？还是楼主看到60w就吓傻了？
#6
看你的思路，程序应该不难呀，
每天60W数据也不是很多
想想电信业务，哪数据才多
实实显示哪个也好搞了，搞个数据显示界面或柱状图，不难吧
整个程序用C/S架构。
我觉得我完全能胜任。
呵呵
每天60W数据也不是很多
想想电信业务，哪数据才多
实实显示哪个也好搞了，搞个数据显示界面或柱状图，不难吧
整个程序用C/S架构。
我觉得我完全能胜任。
呵呵
#7
看板通常是一个异步统计机制，跟生产数据并不同步。例如可能每10秒钟、或者（并且）每超过10条生产数据才异步计算一次看板。如果看板很多，那么分步到2个以上服务器去产生看板统计比较好。看板数据产生了之后，直接推送给各个前端显示屏设备，通常不需要落地保存（根本没有意义）。只要保存最底层的生产数据够够了，而且生产数据也是异步保存到数据库的。
我给你打一个比方，就好像是水流过了粗粗的管道，那么你的看板仅仅统计这个管道内一小段的数据，而不需要动不动就到大水库里去查询统计一次。
实际上你的数据量很小。同样的软件，可以给几千个点、几百种业务进行统计，能在内存中进行高速运算。不需要将数据落地！
我给你打一个比方，就好像是水流过了粗粗的管道，那么你的看板仅仅统计这个管道内一小段的数据，而不需要动不动就到大水库里去查询统计一次。
实际上你的数据量很小。同样的软件，可以给几千个点、几百种业务进行统计，能在内存中进行高速运算。不需要将数据落地！
#8
之所以有些人一旦实际设计这样的系统就拉稀了，那是因为它总是用刚学编程时“各个终端去查询数据库表、各个终端数据库编程进行sql统计查询”的思路，那么当终端数多一些，任务重一点点，服务器就卡死了。
#9
11个工位点，那么需要“实时显示”的显示屏就远远不止11个，至少有12个、15个或者更多。
#10
关于“管道计算”的比喻，更具体地描述就是，当你的生产数据从一个个看板对象中“流过去”，你只要将最近1分钟（或者、甚至10秒钟）的数据缓存在看板内，用来定时更新看板统计结果，然后推送看板统计结果给各个显示屏设备（是推送傻瓜化的最终结果，而不是让各个终端去反向统计）。所以这需要按照这个框架去设计算法，而不是到数据库里去“统计”。
对于大的、快的决策系统显示终端，傻瓜化地往前推送直截的、极端实用的最终显示结果，数据实体都是根据前端需求来设计的（而绝对不是根据什么数据库表来设计的），这样才是技术体现，才能保证大量显示屏频繁刷屏的需要。而那些还在学习 sql 统计函数“怎么用”的阶段的程序，只是最低级的程序，只能靠销售员去明骗用户。
对于大的、快的决策系统显示终端，傻瓜化地往前推送直截的、极端实用的最终显示结果，数据实体都是根据前端需求来设计的（而绝对不是根据什么数据库表来设计的），这样才是技术体现，才能保证大量显示屏频繁刷屏的需要。而那些还在学习 sql 统计函数“怎么用”的阶段的程序，只是最低级的程序，只能靠销售员去明骗用户。
#11
事实上，流程中会有一个“订阅看板”的消息，各个显示屏设备在启动时要给服务器发送一个消息说明自己订阅的是哪一个看板，那么服务器就会在看看板数据更新事件中，主动推送看板数据。
我说过了，你列出的数据级别比较小。假设你用一个3000块钱的服务器来支持这个系统，那么就应该用正规的软件设计。而假设你用一个30000块钱以上的服务器，那么你可以用比较初级的编程方式。
当你的系统软件设计好了之后，如果你稍加配置（配置一下各个看板对自己缓存数据的 sql 统计语句）就能产生更多的看板，给100个工位，150个显示屏推送实时报告，那么你比较正规地 设计这个软件，使得它有点技术。
我说过了，你列出的数据级别比较小。假设你用一个3000块钱的服务器来支持这个系统，那么就应该用正规的软件设计。而假设你用一个30000块钱以上的服务器，那么你可以用比较初级的编程方式。
当你的系统软件设计好了之后，如果你稍加配置（配置一下各个看板对自己缓存数据的 sql 统计语句）就能产生更多的看板，给100个工位，150个显示屏推送实时报告，那么你比较正规地 设计这个软件，使得它有点技术。
#12
3，每天大概是60W数据，11个工位点同时进行，每个工位大概是2条/秒，一年大致是1.5亿
------------------------------------------------------------------------------------------
1.5亿：数据量比较大的时候需要考虑分表，按照 年份+月份 进行分表（年+周也可以），每个表大概为 1kw，电压，内阻，工位，批号创建索引，不一定保证分析得对，还是根据实际测试情况调整一些。
2条/秒：如果数据库处理能力不强的话，考虑使用缓存，定时做一个批量插入处理。
4，生产过程中界面上需要实时显示这个工位这批电池的电压、内阻：分布图（如1.21V多少个，1.25V多少个），不合格
--------------------------------------------------------------------------------------------
实时数据最好不要从数据库里面取，从 上面提到的缓存取出数据，通过wcf回调客户端就好了。
以上只是一些经验之谈，lz根据实际情况做技术选型吧。
#13
推测你可能要做这样的系统，11个工位点就是11个独立的小程序，需要实时发送测量数据到一个大的“监控系统”中，后者负责并发处理这些数据，包括显示、统计、存储。这样的话我的想法如下：
1、用CS来实现（TCP），监控系统作为服务端，工位点程序任何时候都可以连接上去，实时发送数据
2、监控系统对数据进行实时统计，但是存入数据库可以异步，或者利用缓存
个人以为，11个工位点每秒2个记录的并放量，对服务器来说不管是接收、统计、还是UI展示，都没有太大压力，只要把数据接收到了，计算、显示、存储，都可以异步。可以根据实际需求做出相应的处理，比如是否要分组统计、存储。。。
1、用CS来实现（TCP），监控系统作为服务端，工位点程序任何时候都可以连接上去，实时发送数据
2、监控系统对数据进行实时统计，但是存入数据库可以异步，或者利用缓存
个人以为，11个工位点每秒2个记录的并放量，对服务器来说不管是接收、统计、还是UI展示，都没有太大压力，只要把数据接收到了，计算、显示、存储，都可以异步。可以根据实际需求做出相应的处理，比如是否要分组统计、存储。。。