RE: Storage options?

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

• Three Blind Mice

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

-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Matthew Zito Sent: Friday, March 18, 2005 11:36 AM
To: HANDM_at_polaroid.com
Cc: Oracle-L_at_freelists.org
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.

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 917-574-1858
Phone: 212-358-8211 x 359
http://www.gridapp.com


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

> JBOD.

>

> Regards,

> Mike Hand=3D20

>

> -----Original Message-----

> From: oracle-l-bounce_at_freelists.org=20

> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Brian Wisniewski

> Sent: Friday, March 18, 2005 10:44 AM

> To: Oracle-L_at_freelists.org

> 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 =

sure


> 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

>

> --

> http://www.freelists.org/webpage/oracle-l

>

> --=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

> PROHIBITED. If =3D

> 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.

>

>

> --

> http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l