Summary of "Use of BLOB data types"

From: Carol Dionne <carold_at_corp.logica.com>
Date: Wed, 17 Nov 1993 18:12:18 GMT
Message-ID: <carold-171193100244_at_carold.logica.co.uk>

Here is are all the responses I've received regarding my post. I've merged followup responses into the original post to save space.

Return-Path: <li_at_sbctri.sbc.com>
From: li_at_sbctri.sbc.com (William Li)
Message-ID: <9311161718.AA18115_at_sbctri.sbc.com> Subject: Use of BLOB data types
To: carold_at_corp.logica.com
Date: Tue, 16 Nov 93 11:17:02 CST
X-Mailer: ELM [version 2.3 PL6]

---

We've used BLOB data type for image and voice using SYBASE. The BLOBs are retrieved in chunks (i.e. 4K, 8K). Depending on the application, the retrieved
chunk can be processed immediately, therefore, giving the appearance of immediate response. For example, display the data on the screen immediately
as each chunk is received. In this case the time to display the data is slower
than the time to retrieve each chunk.

For data insertion, the same method is used.

For small amount of data, some applications retrieve the data into local temporary files. Then, work with the file once the retrieval is complete.

We have experienced no delay problems.

In the near future, we will be examing the storage and retrieval of data greater than 2G, possibly using CDs.

The images are using a SQLServer on a 486 machine, clients are DOS/Windows. Approximately 20 concurrent users.

The voice application is using SUN Sparc10 with Sybase. This application is
in
beta, with an initial anticipated future volume of hundreds of concurrent users. This application is to eliminate telephone fraud of unauthorized use
of
calling cards by matching voice prints.

sbctri is Southwestern Bell Technology Resources, Inc., a small subsidiary of
Southwestern Bell Corp.

Bill Li

---

Return-Path: <grimes_at_access.digex.net> From: Seth Grimes <grimes_at_access.digex.net> Message-ID: <199311152154.AA00973_at_access.digex.net> Subject: Re: Use of BLOB data types
To: carold_at_corp.logica.com (Dionne, Carol) Date: Mon, 15 Nov 1993 16:54:42 -0500 (EST) In-Reply-To: <2CE7CF22_at_yankee.logica.co.uk> from "Dionne, Carol" at Nov 15, 93

    10:47:00 am
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0

Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 566
------------------------------------------------------------------------------

I've been doing some evaluation work with Blobs in both Oracle and Sybase

--
and in InterBase, which has superior Blob handling but which management
wouldn't support because of its small market share -- but no performance
data yet.  I'm storing arrays of numbers and not images or sound and my
Blobs tend to be relatively small, but I do get better performance out of
them because Blob storage saves a lot of disk space compared to storing
the data in conventional fields.  Maybe when I get some usable numbers
I'll post a note to the nets.

                        Seth, grimes_at_oecd.fr


==========================

Return-Path: <mvalente_at_draco.lnec.pt>
Date: Thu, 11 Nov 1993 17:23:10 +0100
From: mvalente_at_draco.lnec.pt
Message-ID: <9311111623.AA13051_at_draco.lnec.pt>
To: carold_at_corp.logica.com (Carol Dionne)
Subject: Re: Use of BLOB data types
Newsgroups:
comp.databases.oracle,comp.database.sybase,comp.database.informix
Organization: LNEC, Lab. Nac. de Eng. Civil, Lisboa, Portugal
X-Newsreader: TIN [version 1.1 PL8]
------------------------------------------------------------------------------
 In Oracle its LONG RAW that you have to use.

 I built a document storage tool [Intermedium]  using just this capabilty.
I not only
store data but I also use LONG RAws to store programs which are then used
to view the files.

 The tool is called Intermedium. It was built on a IBM RS6000 and uses
Oracle6
and Motif. I'm sending it to you on the next messages. Its uuencoded.

 About performamce: I didnt notice any problems. On the other hand I didn't
have a test database with that much volume.

 Check out Intermedium and tell me what you think.

 C U!

 By(e)

  Mario Valente


==========================

Return-Path: <mdb528_at_alaska.et.byu.edu>
Date: Wed, 10 Nov 93 15:35:13 -0700
From: mdb528_at_alaska.et.byu.edu (Matthew D. Bennett)
Message-ID: <9311102235.AA27420_at_alaska.et.byu.edu>
To: carold_at_corp.logica.com (Carol Dionne)
Subject: Re: Use of BLOB data types
------------------------------------------------------------------------------
I did a lot of work with long raw datatypes with my last client using
Oracle7.  There is a lot of fiddling around that you have to do and it is
not
the easiest thing in the world to do.

If you are trying to do an evaluation in order to find out whose database
you
really want to use, I would suggest talking to the vendors.

Good luck,
Matthew D. Bennett
----------------------
In response to your question about if I would do it again, yes.  I got paid
a lot of
money to do it the first time.  I do think you are better off using a file
manager
for anything over 2 MB, however.

Let me know if you need any more help.

Matthew D. Bennett


==========================

Return-Path: <jean_at_gso.SAIC.COM>
Date: Wed, 10 Nov 93 16:46:55 PST
From: jean_at_gso.SAIC.COM (Jean Anderson)
Message-ID: <9311110046.AA00829_at_ratatosk>
To: carold_at_corp.logica.com
Subject: Re: Use of BLOB data types
CC: jean_at_gso.SAIC.COM
------------------------------------------------------------------------------
Oracle long raw's are fully logged (even in Oracle 7). Rollback segments
and redo logs have to be large enough to accomodate the largest long raw.
All blob access has to be from C and you have to manage everything
yourself.
In my opinion, Oracle simply checked the blob box off on a list of
features.
I am told that Oracle 8 will have better blob support. Rather than use
long raws, we store pointers in the database to external files.

Sybase lets you bypass logging at the database level; we separate
databases between logged and unlogged blob data. That gets us further,
but blob management is still really thin; there aren't a lot of functions
to work with the data.

We have started working with Montage, a new object-relational database
that has much better support for large and binary data. You can bypass
logging at the transaction level. You can insert and remove objects,
and select the "handles" interactively with SQL.  You can also hook in
display functions to select the data from SQL and have it be visually
displayed. The C interface has functions for managing and seeking into
the object (i.e., you don't have to read data from the very beginning).

I have been working with seismic, climate, and linguistic data.  I
understand that Montage has an Image data type extension specifically
for multimedia data. If you are interested, they can be reached at
sales_at_montage.com.

My main problem with ODBM's is the general lack of standards (query
language,
interface, capabilities). An ODBMS standard is emerging (the Sep-Oct issue
of Object Magazine lays out some of it), but it comes too late for us.

And when all is said and done, we still want to take advantage of
relational
capabilities.  Montage and UniSql are both object-relational; in my view,
we get the best of both worlds.  I'm working closely with Montage, my
dba counterpart from the East Coast has been working with UniSql. We're
going to get together next week for a couple of days to compare notes.
It seems that Montage is more extensible. If you're interested, I'll
keep you posted.

     Montage Software, Inc.
     2000 Powell Street
     Suite 1405
     Emeryville, CA 94608
     Phone 510-652-8000
     fax 510-652-8050
     sales_at_montage.com

     UniSQL, INc.
     9390 Research II, Suite 200
     Austin, Texax 78759-6544
     (512)343-7297

regards,

 -jean
  jean_at_gso.saic.com


==========================

Return-Path: <GOGI_at_aster.si>
Date: Fri, 12 Nov 1993 12:29:10 +0200 (MET)
From: GOGI_at_aster.si (Mladen Gogala)
Message-ID: <931112122910.697_at_aster.si>
Subject: Re: Use of BLOB data types
To: carold_at_corp.logica.com
X-Vmsmail-To: smtp%"carold_at_corp.logica.com"
------------------------------------------------------------------------------
I had significant delays with loading RGB images in ORACLE7 7.0.12.2
on SGI Indigo2 (Irix 5.1.1),which I where resolved as follows:
a) Use OCI ,do not even dream of precompilers.I recommend the routine
   named "oflng" for fetching long values.
b) I have call mallopt which defines options for malloc&calloc.It
   can speed programs significantly.Study the man page for malloc.
3) Dump ORACLE's MTS interface and use 'F:',the fast pipe adapter.
   It is significantly faster then the usual one 'P:'

The performance gain was up to 40% with large images (~85MB).Fast pipe
driver takes the credit for the largest part of the improvement.

MTS stands for "Multi Threaded Server",the new way of communication
between user process and ORACLE.It isn't a separate product,it should be
bundled with RDBMS.MTS appeared with version 7,while pipe driver,fast-pipe,
and SQL*Net ver. 1.2 drivers belong to version 6.The difference is the
following: in version 6 each connection to ORACLE resulted in creation
of another process,so called shadow process which performed privileged
database access routines on behalf of the user who created it.This
means that there was 1-1 mapping between connections and shadow processes.
MTS makes shadow processes sharable:more then one connection can use the
same shadow process at the same time.This interface is still immature and
unreliable,particularly when transferring bulk of data between user
program and ORACLE.Exactly this is the case when you load the big RGB
image into ORACLE.(I dont know much about video sizes,but they are probably
even bigger).My advice is :wait for the version 7.0.15.4.x to use
ORACLE for such a purpose.

Hope it helps!
Kindest regards!          Tel  : ++386 61 1683-511
Mladen Gogala             FAX  : ++386 61 1683-165
ASTER Ljubljana           Email: gogi_at_aster.si

Snail-mail:
ASTER Ljubljana
Nade Ovcakove 1           The above statements represent The Absolute
Truth,
61000 Ljubljana           and therefore have nothing to do with the
opinions
Slovenia                  of my employer.


==========================

Received on Wed Nov 17 1993 - 19:12:18 CET