使用数据库来进行图像分布式运算中的问题 100zhoujk]

发布时间:2017-1-24 0:57:55 编辑:www.fx114.net 分享查询网我要评论
本篇文章主要介绍了"使用数据库来进行图像分布式运算中的问题 100zhoujk]",主要涉及到使用数据库来进行图像分布式运算中的问题 100zhoujk]方面的内容,对于使用数据库来进行图像分布式运算中的问题 100zhoujk]感兴趣的同学可以参考一下。

当前有个应用,需要数据库作同步,我想了很久,有些问题需要请各位高人指点一下。     在图像运算中,有些需要接近实时运算,例如,每秒钟需要运算20次以上。但是算法又太复杂,于是我计划使用LAN上的N台机机进行分布式运算,其中的N可能是随时变化的,现在大致计划30台左右。而且每台客户机的速度也可能不一样。数据库平台没有定,SQL或ORACLE 均可,算法使用 C++.net 或者C# 来实现。      我是这么构想的。算法是存储在EXE文件中,客户机执行这个EXE。 服务器上的表A:内容为需要运算的图片,定段为:     int id //主键     string FileName //源图片的定位     int RunState //运算状态     string CFileName //结果图片的输出位置     服务器上对应每个需要运算的图像生成1张表,暂名为B。其字段为:     int ID, //主键     int PictID, //表A的对应ID     int LineNO, //行号     int Channel, //通道号,如果返回的结果不是灰度图,才需要这个字段     int RunState, //当前运算情况     string Count, //返回的结果     客户机根据表A的内容,确定当前需要运算的源图,查找对应的表B,查看有哪些行还没有被运算,然后运算这个行。因为可能要跨行获取运算所需的参数,因此要先载入整个源图(如果已经下载当然就不用重新下了),然后将源图和需运算的行号输入到算法,算法计算出这一行的结果,将它转换成 char[],然后输出到表B/Count。     当然了,里面的数据和文件同步算法很简单,就此略过。图像与字符串的相互转换已经完成,这个也不复杂。     在数据库效率方面有两个限制:     1.数据库的写入阶段需要锁定,否则会造成查询用户的返回错误。     2.太多的连接或者频繁的打开关闭都会影响数据库的性能     因为 1 和 2 的限制,使我不能采用频繁打开和关闭连接的方法,同时又不能打开连接,直到完成运算并写入数据才关闭。为此,我想了另外的一个方法,就是将结果字符串不写入数据表格中,将它以文本文件的方式传入文件服务器,然后连接到表B,将运算状态写入即可。     请问这样做的话,效率是否会高一些?还会出现什么问题?     事实上几乎所有的图像算法都是遂行遍历的,因此这个构架可以大范围推广,并且可以在WAN上运行。最后我打算用 JAVA 把算法和数据库操作都写成跨等平台的,MAC,UNIX都能够运行。

貌似主要是程序来实现 难 帮顶

引用 2 楼 fredrickhu 的回复:貌似主要是程序来实现 难 帮顶 程序部分不难,我基本上已经实现了。主要是关心数据库的效率问题

按照我朋友的说法,如果做得不好,可能比单机版还算得慢。。。纠结

在数据库效率方面有两个限制:      1.数据库的写入阶段需要锁定,否则会造成查询用户的返回错误。      2.太多的连接或者频繁的打开关闭都会影响数据库的性能  这个是并发问题,应该用事务隔离呀,没必要老断开老连接吧

可能出现的问题 运算端死掉,  解决办法-》某客户端一担开始进行某数据库中,来源数据行进行处理,对当行数据做处理中标记,统计记录当前数据库时间,,当其他客户端需要进行新的数据行运算时,查询当前正在运行的数据行,的开始运行时间,发现当前行处理时间过长(看你实际业务中算做异常的时间范围),则取代带他,自己去运算,同时覆写开始运算时间(当然也可以你做一个服务器端软件来做时时监控的方式实现)

1-2张图片肯定可能比单机慢 何况还是1秒处理20多张图片? ,,,因为你这个处理办法,,存在机器性能差异,,读取数据库时间,,,等 怎么能和一切内存搞定,,,何况现在电脑CPU又NB,,,做好多线程就搞定了 但是只要没有其他技术上的问题,,,,在处理大批量的图片时 绝对性能会优异很多,。。 所以建议一次性,,,从数据库度取N张图片(这个需要你自己多测试看怎样的情况是最优的) 别一张一张搞

1.并发问题,应该用事务隔离呀,没必要老断开老连接 2.注意死锁,多测试看看数据。 3.。。。,还在探索

引用 6 楼 starseeker7 的回复:可能出现的问题 运算端死掉,  解决办法-》某客户端一担开始进行某数据库中,来源数据行进行处理,对当行数据做处理中标记,统计记录当前数据库时间,,当其他客户端需要进行新的数据行运算时,查询当前正在运行的数据行,的开始运行时间,发现当前行处理时间过长(看你实际业务中算做异常的时间范围),则取代带他,自己去运算,同时覆写开始运算时间(当然也可以你做一个服务器端软件来做时时监控的方式实现) 高人还真的不少哈,不过这个问题我已经想到了,我的解决方法是这么设想的: 如果表B.RunState 为0,则表示该行还没有被安排。某个机机要运算这行时,先 B.RunState ++;返回结果以后,则该行的 RunState == 2,  当前客户机在完成了运算后,就查询 RunState = 0;如果有,则返回应计算的行,如果没有,则查询 RunState = 1; 也就是已经运算但是还没有完成,可能是机机性能太慢,或者死机造成的。就用当前机机再运算一下。这样可以有效地避免水桶效应的问题。

引用 7 楼 starseeker7 的回复:1-2张图片肯定可能比单机慢 何况还是1秒处理20多张图片? ,,,因为你这个处理办法,,存在机器性能差异,,读取数据库时间,,,等 怎么能和一切内存搞定,,,何况现在电脑CPU又NB,,,做好多线程就搞定了 但是只要没有其他技术上的问题,,,,在处理大批量的图片时 绝对性能会优异很多,。。 所以建议一次性,,,从数据库度取N张图片(这个需要你自己多测试看怎样的情况是最优的) 别一张一张搞 我现在的一个算法就是这么实现的,视频流中的每幅图都需要做图像增强运算,还要求实时,但是简化算法后,输出的效果完全无法接受。于是我就将流中的图片解压后分布到LAN上的很多台机机上运算,然后汇总后再压缩。这个问题其实可以理解成数据库设计中的粒度问题。 但是这么做有个麻烦,就是每张图仍然要很长的耗时以后才能返回结果,很多应用不能容许这么做,例好机器视觉,所以才想到拆分到行,效率肯定比遂帧运算要低些,但是如果设计得好,返回时间要快得多。 1-2张图片肯定可能比单机慢...我现在有个算法,光是核心就需要30',如果改成在N台机机上进行遂行运算的话,应该要快得多吧。

引用 5 楼 sql77 的回复:在数据库效率方面有两个限制:     1.数据库的写入阶段需要锁定,否则会造成查询用户的返回错误。     2.太多的连接或者频繁的打开关闭都会影响数据库的性能 这个是并发问题,应该用事务隔离呀,没必要老断开老连接吧 事务隔离,学习ing, 我现在也就是拼凑 SELECT 语句的水平,三克油

你可以考慮參考那種群集服務器實現方式,,, 网络负载平衡群集(简称NLB) 實現這種負載分配的問題 你圖片量大,,,牽涉個數據傳輸問題,,自然速度快不了,,, 要不處理完畢后圖片別回傳,,,就存在本地,,,只對數據庫中數據行,,做完成標記 所有行被標記完畢后,,再通過服務器端程式,,,去一一copy每個運算節點的文件 整合,並檢測是否有漏掉的,,,

引用 12 楼 starseeker7 的回复:你可以考慮參考那種群集服務器實現方式,,, 网络负载平衡群集(简称NLB) 實現這種負載分配的問題 你圖片量大,,,牽涉個數據傳輸問題,,自然速度快不了,,, 要不處理完畢后圖片別回傳,,,就存在本地,,,只對數據庫中數據行,,做完成標記 所有行被標記完畢后,,再通過服務器端程式,,,去一一copy每個運算節點的文件 整合,並檢測是否有漏掉的,,, 三克油,不过如果运算完的机机离线或死机了,上面的已运算内容岂不是也得不到了?总不能再让其它机机重算吧。我构架的系统中,要考虑客户机不稳定的情况哈

BD..

學習~~

那就只有一个批次一个批次处理完毕后上传 在服务器端,,做一个队列,, 一个客户端完成一个批次的图片处理,则在这个队列上加入,,,并传回客户端的完整的完成图片的绝对路径文件夹名,已经完成的图片张数 由服务器端主动去客户端拷贝已处理完的整个图片包,,,拷贝完毕后验证图片张数是否与客户提交的数量一致。。。 考虑到客户端挂掉情况,,可以在服务器加入重试次数,,, 建议在数据库做客户端分发图片批次的时候,,,再做一个总表,,已一个编号到一个编号为一行,,,把整行作为一个用户一次读取来标实,就不需要一次update大量标识行了, ,,

其实你这个程式数据库上的问题不大,,。 计算部分又在客户端,只要你一次拷贝足够量的图片到客户端,不太可能发生客户端频繁去访问服务器端的情况 主要是copy过来copy过去的时候,需要在服务器端做好输出队列,接收对列,避免大量的copy并发 当然如果条件允许,,,直接一次性让服务器用udp协议,像飞鸽传书一样(反正网络上又有源代码,借鉴过来用三),一次把处理源丢出去,基本就没有out数据的时候的问题,而接受的时候,只要服务器段有个数据表,来存储copy请求队列,基本就完全解决的并发问题了,, 但这必须要求客户端硬盘和服务器端硬盘一样大了, ,,, 还是得看你实际情况,和数据量大小问题

引用 17 楼 starseeker7 的回复:其实你这个程式数据库上的问题不大,,。 计算部分又在客户端,只要你一次拷贝足够量的图片到客户端,不太可能发生客户端频繁去访问服务器端的情况 主要是copy过来copy过去的时候,需要在服务器端做好输出队列,接收对列,避免大量的copy并发 当然如果条件允许,,,直接一次性让服务器用udp协议,像飞鸽传书一样(反正网络上又有源代码,借鉴过来用三),一次把处理源丢出去,基本就没有out数据的时候的问题,而接受的时候,只要服务器段有个数据表,来存储copy请求队列,基本就完全解决的并发问题了,, 但这必须要求客户端硬盘和服务器端硬盘一样大了, ,,, 还是得看你实际情况,和数据量大小问题 飞鸽传书是广播,不会建立双向通道和校验,可能造成源图文件传送出错。而且源图量大得很,视频文件独解压后的静帧

我可以这么做,文件服务器和数据服务器分开,数据服务器中有一个表存储源图文件所在的位置(位于文件服务器),然后数据接收和源文件的传送从两台服务器分别进行,瓶颈大概会在路由路上出来,这样就没问题了吧?

嘛。。。反正你数据源放哪哪就是瓶井 毕竟图片拷贝,,,及站网络,,又站硬盘读写,,,, 在我看来,,,应该多个数据源,,,来减轻这个问题,,, 把图片,,,多少编号到多少编号放在哪,,, 路径放在数据库里,,,然后让客户端分别读,,这样才是最好的办法,,,

引用 20 楼 starseeker7 的回复:嘛。。。反正你数据源放哪哪就是瓶井 毕竟图片拷贝,,,及站网络,,又站硬盘读写,,,, 在我看来,,,应该多个数据源,,,来减轻这个问题,,, 把图片,,,多少编号到多少编号放在哪,,, 路径放在数据库里,,,然后让客户端分别读,,这样才是最好的办法,,, 老大,在前面我说过,每台客户机都要考虑随时可以当机或非正常退出的情况,如果我再让他们来做分布式存储,系统就太不稳定了。而且每台机机都与文件服务器同步也不太现实,源图文件多得不得了,如果发布到每台机机,将产生海量数据,还要写这些数据的同步,可能效率还会降低

不我的意思是,,,服务器一个完整的,,,数据源 分别切成4-7分,,分别放在4-7个比较好的电脑中(各自只放属于他的那一份,不重复),,, 然后让客户端根据数据库的中的绝对路径,,,去对应 小数据源中获取数据,,, 存在异常,,再去主服务器中,,获取数据 这样不知道行不?

客户端处理后的上传目标必然是服务器,,, 缩小每次处理,上传颗粒大小,,, 就可以降低同步的时候,客户端出现问题的可能性和时间损失了啊,,, 处理每一批次向总服务器发送一次,请求拷贝进入服务器的拷贝队列,,, 请求完毕后,继续去新的数据源获取新的需要处理图片,,, 再进入处理状态,,, 而服务器只需要不停的,根据请求队列的依次去各个客户端拷贝数据,拷贝前当然先会确认客户端是否活跃状态,,,跳过不活跃的用户,,,每次拷贝完毕,准备拷贝下一个目标的时候,再去看下这些派在请求拷贝队列前面的,,,用户端是否已活跃,,,

引用 22 楼 starseeker7 的回复:不我的意思是,,,服务器一个完整的,,,数据源 分别切成4-7分,,分别放在4-7个比较好的电脑中(各自只放属于他的那一份,不重复),,, 然后让客户端根据数据库的中的绝对路径,,,去对应 小数据源中获取数据,,, 存在异常,,再去主服务器中,,获取数据 这样不知道行不? 每台机机上的文件是不一样的?对于我前面提到的以每幅图为粒度的方案,这样做是可行的。但是为了提高每幅图的返回速度,需要当前的客户机都运算某一张图,这样的话,每运算一运算一张图,存储这张图的机机就会累死,其它的文件服务器中旁边无所事事,应该是这种情况吧。除非很多台机机,存储的数据与服务器是同步的,然后客户机随机调用某台上面的图片。

我觉得没必要每台都完全可服务器同步,,,而是让服务器作为一个严整错误,或者出现拥塞的时候一个备选数据源这样 整体的情况嘛意思就是 客户端->服务器获取一个待处理图片批次-》在数据库中标实该批次为我处理/记录开始处理时间/获取该批次数据源路径(数据源路径不在服务器上)->从数据源中获取图片到本地->开始处理->处理完毕-》到服务器数据库中,向请求上传队列提交一个拷贝请求申请,已经拷贝绝对路径,以及信息(a),并对数据库中标市该批次数据已处理完毕,更改当批次运算状态(如待处理是 w ,处理中是,r,待拷贝是c)-》循环-》若已经到图片批次末未,查看之前的行是否存在处理中时间过长的,或待拷贝时间过长的,,,从而进行再次运算 服务器在拷贝客户端数据之前,总是监视自己的上传队列表中是否存在请求-》发现a请求-》验证客户端是否活跃-》拷贝完成的图片数据到服务器->拷贝完毕-》检查是否与客户端提供的拷贝请求申请中的数据大小,或数量一致,不一致就将该批次数据update为待处理,等待其他客户端重新去处理,一致就update状态已完成-》继续监控请求拷贝队列中是否有数据-》若发现循环上面动作

引用 25 楼 starseeker7 的回复:我觉得没必要每台都完全可服务器同步,,,而是让服务器作为一个严整错误,或者出现拥塞的时候一个备选数据源这样 我把QQ号已经给你了,我们QQ上聊吧,这个网页刷新太伤眼睛了

已一次处理一张图片的颗粒进行程式,,,那个效率必然低得可怜,,,毕竟你一张图片是1秒处理20张 光是去标记数据库行,再从数据源拷贝,,再考虑到并发的等待,,没1秒怕抓不下来吧,,, 这样相当于1/20的效率,,,等于你挂30台电脑 不如把程式拷贝到2个电脑上,,,分别各自运行自己那一半,,,

继续坐等高人

如果用 C# + SQL,只有跨WIN公司内的平台时较好用,MONO没试过,如果需要使用MAC或UNIX系列,用JAVA吗?请问对应的数据库是什么?

算了,无人回应就结了吧

上一篇:sql语句优化与sql原理相关书籍! 20KillerAwp]
下一篇:windows2003 web版本 装SQL2005只能安装工作站组件? 40touch_hand]

相关文章

相关评论