RE: Storage options?
- From: "Mohan, Ross" <RMohan@xxxxxxxxxxx>
- To: <Oracle-L@xxxxxxxxxxxxx>
- Date: Fri, 18 Mar 2005 17:02:34 -0000
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@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Matthew Zito
Sent: Friday, March 18, 2005 11:36 AM
To: HANDM@xxxxxxxxxxxx
Cc: Oracle-L@xxxxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxxxx=20
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Brian Wisniewski
> Sent: Friday, March 18, 2005 10:44 AM
> To: Oracle-L@xxxxxxxxxxxxx
> 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
>
> --
> //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.
>
>
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
