Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Storage options?

RE: Storage options?

From: Mohan, Ross <>
Date: Fri, 18 Mar 2005 17:02:34 -0000
Message-ID: <>

seems to me you split the files at least, and the databases at best?

Do your "metadata" query in one db, go to WORMville (another db, or = <shock, horror>
some external files to get the 200K data. I don't see the need to treat = 200K pix as=20
atomic OLTP relational entities in the brief view you've given of your = needs.=20

p.s. nice to hear Polaroid's not out of business.=20

-----Original Message-----
From: =
[] On Behalf Of Matthew Zito Sent: Friday, March 18, 2005 11:36 AM
Subject: Re: Storage options?

WORM fits nicely into individual object read-only access (i.e. I have 2=20 million X-rays I need to back up for ten years), but it does very=20 poorly for relational databases, since there are so many secondary=20 relationships that need to be managed. For example, a query to=20 retrieve one BLOB could touch 3 different files, each one residing on a=20 different media.

There's a few things that apparently haven't been determined yet -=20 acceptable access times, throughput, and I/Os per second. If you're=20 not going to be able to hazard a guess at these things, then the=20 easiest and safest thing to do would be to get an EMC array and go from=20 there.

However, better/possibly more appropriate options are the NearStore=20 from Netapp or 3PAR. The NearStore is all SATA drives, very easy to=20 manage, very large raid groups, designed for high redundancy and=20 reasonable performance at a very high storage density. That's=20 appropriate if you need basically slow, reliable storage at a cheap=20 price point. For higher performance, 3PAR is designed to take=20 advantage of an internall distributed, internally scalable architecture=20 and is very easy to manage online. If you need higher performance=20 storage for cheaper than EMC, check them out. The last option, and the=20 cheapest and most dangerous, is to get a bunch of Nexsan storage arrays=20 and put them on a SAN with your databases. Then use something like=20 Veritas or ASM to stripe and mirror across them. Cheapest option,=20 performance should be pretty decent.

In the end, though, you're really going to need more information to be=20 able to plan these things.


Matthew Zito
GridApp Systems
Cell: 917-574-1858
Phone: 212-358-8211 x 359

On Mar 18, 2005, at 11:10 AM, Hand, Michael T wrote:

> When I hear huge amounts of read-only, archived data, I think WORM=20
> optical, though can't give you any price/performance vs SAN, NAS,=20
> Regards,
> Mike Hand=3D20
> -----Original Message-----
> From:
> [] On Behalf Of Brian Wisniewski
> Sent: Friday, March 18, 2005 10:44 AM
> To:
> Subject: Storage options?
> I just got pinged from one of our development directors about a
> possible
> project coming up in the next fiscal year and I need your input on
> storage options. This is going to be a massive 40TB+ project and it's
> mostly for archival of blob-type data. ~200,000,000 rows * ~200K=20
> blobs.
> Obviously we haven't even talked about indexes or access patterns but
> this is going to be a read-only type system of archived data. I'm =
> price is going to far exceed performance when the rubber hits the road
> at the mgmt level.
> =3D20
> We are currently an all EMC shop but we looked at IBM's storage and
> found it unacceptable. Looking for solid storage vendors who could
> provide this type of storage at a 'reasonable' price. Any thoughts?
> =3D20
> Thanks - Brian
> =3D09=3D09
> ---------------------------------
> Do you Yahoo!?
> Make Yahoo! your home page=3D20=3D20=3D20
> --
> --=3D20
> This transmission is intended only for use by the addressee(s) named
> herein=3D
> and may contain information that is proprietary, confidential and/or=20
> legal=3D
> ly privileged. If you are not the intended recipient, you are hereby=20
> notifi=3D
> ed that any disclosure, copying, distribution, or use of the=20
> information co=3D
> ntained herein (including any reliance thereon) is STRICTLY=20
> you received this transmission in error, please immediately contact=20
> the sen=3D
> der and destroy the material in its entirety, whether in electronic or =

> hard=3D
> copy format. Thank you.
> --
-- --
Received on Fri Mar 18 2005 - 12:06:19 CST

Original text of this message