Subject | Re: [Firebird-Architect] Re: Record Encoding |
---|---|
Author | Jason Dodson |
Post date | 2005-05-12T20:48:20Z |
Why not simply transmit the BLOB without compression, and have the
server compress it? Perhaps in a different thread/process?
As for compression, I tend the bzip2 lib to be easy to use and quite
wonderful. I think you see over time, most open projects come to this
conclusion.
Jason
Jim Starkey wrote:
server compress it? Perhaps in a different thread/process?
As for compression, I tend the bzip2 lib to be easy to use and quite
wonderful. I think you see over time, most open projects come to this
conclusion.
Jason
Jim Starkey wrote:
> Roman Rokytskyy wrote:
>
>
>>>As I see the things in developing world wide are going into very low
>>>level of quality. More and more "developers" on forums are talking
>>>about putting in blob fields almost everything (Word files, Huge
>>>texts, Huge XMLs, etc). These things are compressed very well. So if
>>>we have the option - "BLOB WITH ZLIB COMPRESSION" - these developers
>>>will be very happy. That will be hit to performance - but if developer
>>>wants it - let give it such thing.
>>>
>>>
>>
>>The only thing that is missing is a BLOB filter that peforms such
>>compression shiped together with the server. As far as I understand,
>>rest of the stuff is already there.
>>
>>However, I'm not sure if it makes sense to use zlib compression on the
>>server - its CPU has other things to do. Just simply compress stuff on
>>the client side, and job's done.
>>
>>
>>
>
> I originally had in mind using blob filters for compression, but that
> really hasn't panned out. On the other hand, blob compression is a good
> thing, and almost always useful (the exception is where it is already
> compressed). It does take cycles to compress and decompress, but cycles
> are increasing much faster than disk bandwidth.
>
> The more I think about, the more I think that blobs should always be
> stored compressed, but that compression/decompression be performed
> primarily on the client side. The implication is that the plumbing
> needs to be compression aware at least at the lower levels of the API.
> If we're going to build in end to end compression, we pretty much need
> to standardize on a single compression schema, and zlib is the obvious
> candidate.
>
> Now, having taken a position, can we have the opposing opinion from Dmitry?
>