如何提高长字段的访问效率；(100分)

  • 主题发起人 主题发起人 zhaoyipeng
  • 开始时间 开始时间
Z

zhaoyipeng

Unregistered / Unconfirmed
GUEST, unregistred user!
我做的程序需要一长字段保存数据，该数据最长可达几十兆，用10M局域网，
保存10M左右的数据要将近1分钟，试过MS SQL Server和Oracle都差不多，
谁有好的建议。
 
没有！
 
保存需要改动的地方。
 
该表的记录数多吗?
你的长字段内容是什么类型? 是图象?, 是OLE数据? 还是视频或音频,
用在什么方面?
对矛盾的方面有较全面的了解, 才能更好的解决矛盾.
 
该表的记录数每年增加大概几千至几万条。
记录的数据是一种测试数据，长度从几十K到几十兆不等，
关键要解决的是数据长度达到几兆时初始数据存入数据库中的速度问题。
 
你可以重新设计的数据结构, 将大的数据字段分段保存, 做
成1 对多的数据结构. 长数据的分离标准,根据自身数据
性质来确定.
 
我想也许你应该采取某种数据压缩编码技术比如自适应Huffman或自适应算术编码等,因为这类数据一般具有比较强的冗余.
 
SeaSky说的似乎不行，因为无论怎么分段，这些数据都要一次性使用，
因此效率不会有什么提高。

liaobin说的似乎有些道理，也不是没有这么想过，但不想在这上面投
入太大精力，要是有现成工具就好了。要有请寄一份给我好吗？

另外我想在系统方面有没有好方法，因为即使使用压缩算法压缩，数
据长度应该还在同一数量级上，效率还是没有质的飞跃。听说国外有
些公司采用类似的方法用数据库提供视频点播服务，能否提供有关系
统的一些信息，如硬件配置、操作系统、数据库系统等。
 
数据能否优化一下, 上兆的数据中肯定有上兆的垃圾.
 
1.同意优化数据库的观点
2.如果的确需要如此超级数据库,那么升级网络到100M或者ATM网
3.在保存时.用一个线程执行SQL(没做过)
4.压缩也可暂时环节矛盾,但是对于不能压缩的数据就惨了:(
 
huizhang所说的方法不行，数据必须完整保存。

CJ所说的升级网络倒可一试，但我认为不一定起多大作用，因为同样环境下用FTP
传递相同大小文件速度很快，考虑到数据库额外的操作也不应有这么大的差别。

我又重新看了一编程序，感到可能是客户端的效率太低，我用的是TBlobStream
往数据库写，看来有些问题。现在有个想法，可否分段向长字段提交数据。

另外，请教一下如上情况下，回滚段(在ORACLE 7.3.3上)应设置多大合适。
 
1. 如果可能, 建议把该数据以文件形式保存, 数据库里只放文件路径,
通过client存取方式设定来保证数据文件的完整一致
2. 当然,如果跨出windows网络, 就很难存取网络文件, 但现在大部分数据库
对BLOB数据支持不好, 效率很低. 建议采用IBM DB2 5.0 UDB (NT, Unix版本都有)
加上一些附件, 可以非常完美地利用文件系统保存大规模数据(例如多媒体数据),
但是对于用户开发时和数据库字段一样, 只需要在DBMS里配置就可以, 而且可以
实现数据的完整性, 甚至备份和复制.

当然, db2代价不小, 可以去ibm站点看看
 
lzl说的还能叫数据库吗？？？
 
第一种方法自然是折衷使用数据库
第二种方法如何不叫数据库? 普通我们使用的都是关系数据库, 用来存放关系型数据
是很方便的, 但是遇到多媒体数据就会出问题, 性能上和效果上都大打折扣, 目前也
只有DB2有比较好的解决方案能够即不破坏数据完整性(存取,备份, 恢复, 索引功能),
又利用文件系统提高效率. 据我所知IBM庞大的Digital Library解决方案就是用
这种方法的. 否则大到几个GB图像数据你也用BLOB往数据库字段里写吗? 不要开玩笑了.
 
lzl先生：
就你提出的看法我有以下意见：
1、第一种方法早在几年前就已经有了，并有人用了，并且也正是我要否定的；
2、第二种方法自然有他的合理性，但由于具体原因，我不会选用IBM DB2，原因很
简单，我身边正好有一台很好的SUN Solaris服务器，并有Oracle 7.3.3数据
库，因此我基本原则是使用Oracle，另外购买Solaris版DB2系统不现实；
3、我提出这个问题主要目的是讨论在现有条件下如何提高效率的问题，尽管数据库
在处理这样数据方面能力欠佳，但我认为不应有如此差距，应该在方法上有探讨
的余地；
4、我的数据量还大不到数据库能力范围之外，BLOB至少有2GB的容量，而我的数据
不会超过100M，应该不成问题。
 
一般来说,现有一般的关系数据库都不适合于存储大型记录.
BLOB理论上的容量没有任何意义,效率和容量是完全不等价
的.现有数据库不仅在存储大记录时成问题,在存储大量中等
规模的记录时也是低效的.我们在SQL6.5上存储几万个大约
几K~几十K的记录,数据库的速度就无法忍受了(我们在本地
做的,没有经过网络).现在的关系数据库主要针对MIS这类
应用优化-小记录,但库可以很大.超过这个范围讨论其性能
的优化,只能得到很小的提高.在矛盾的本质已经转变后仍
不改变处理的方法,是不能解决矛盾的.

就本问题来说,也许还可以优化一点点.但不可能有质的提高.
要达到FTP的速度,必须更换方法.DELPHI本身也是针对MIS优
化的,所以你认为客户端效率低也是有可能的.但我认为问题
可能并没有那么简单.你应该测试一下是否真是客户端的问题.
测试的方法是替换法:用ORACLE和SQL自己的客户端软件添加
相同规模的数据,是否效率相同?用ODBC呢?另外,在操作进行
过程中,客户端和服务器的CPU/IO占用率中是否有已经饱和
的现象?通过全面的分析,确定问题出在哪里,才能做下面的优
化.
 
不会有这么慢吧?
我刚才做了一个测试:在我负荷很大的WWW服务器放一个MSSQL Server!
在一个10M Hub上接了一台NT做客户机.用网上邻居传一个9.28M的文件用了:14S
用Delhpi编的程序MSSQL 客户程序传用了:30S.
没办法!通过MSSQL是要慢一点,大约是1倍吧?
我测试了几个小的文件的传输:这个比例大约是1:2.
关于FTP?我不得不说它是非常快的!我只用了:12.01S就传完那个文件!
了不起!
DB2也没用!在NT上MSSQL比DB2好象要快点呢?(只是我的个人观点).
C/S数据库的传输速度是不能和FTP比的!
想想如果C/S都比FTP快了,FTP还能活下去吗?FTP是网上最快的传输服务(只是我
的个人感受).大多数情况下FTP比局网协议都跑得快!
提高速度的跟本点应是对数据库服务器的特殊配置和对客户机特殊配置!
如对:数据库服务器的备用缓存扩到足够大,还有对日志记录也应特殊处理.
在客户端,请关心一下BlobField的 Blod Size 和缓存大小.
不过,我认为:一条记录真的大到了几十M???同时也说明一点,你的数据库设计是不
成功的.
最后祝你成功!
--------------------我是古代的MAX!
 
对不起各位了，近来很忙，没能及时对各位的意见作出回应，实在抱歉。
网络传输慢最后证明是网线有问题，速度问题已基本解决。
现补充以下两问：
1、就本问题回滚段的大小应该设多大；
2、BLOB可否分段提交和修改。

分不够的话可以再加。
 
俺以前的经验(是对付大图象的)
更新前使用 ZIP之类的压缩控件对数据进行压缩， 压缩后数据可以以流方式
先保存到本地，然后传到SERVER端， 数据库里建议只保存文件的网络路径

 
请继续讨论或结束问题，谢谢
 
您必须登录或注册才可回复。

Similar threads

S
[原]pgdac和unidac插入效率究竟差多少？
回复
0
查看
835
SUNSTONE的Delphi笔记
S
S
[原]pgdac和unidac插入效率究竟差多少？
回复
0
查看
765
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(6)—加强服务程序对访问者的控制能力
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(6)—加强服务程序对访问者的控制能力
回复
0
查看
1K
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
后退
顶部