Re: Storage options?
- From: Matthew Zito <mzito@xxxxxxxxxxx>
- To: HANDM@xxxxxxxxxxxx
- Date: Fri, 18 Mar 2005 11:35:33 -0500
WORM fits nicely into individual object read-only access (i.e. I have 2
million X-rays I need to back up for ten years), but it does very
poorly for relational databases, since there are so many secondary
relationships that need to be managed. For example, a query to
retrieve one BLOB could touch 3 different files, each one residing on a
different media.
There's a few things that apparently haven't been determined yet -
acceptable access times, throughput, and I/Os per second. If you're
not going to be able to hazard a guess at these things, then the
easiest and safest thing to do would be to get an EMC array and go from
there.
However, better/possibly more appropriate options are the NearStore
from Netapp or 3PAR. The NearStore is all SATA drives, very easy to
manage, very large raid groups, designed for high redundancy and
reasonable performance at a very high storage density. That's
appropriate if you need basically slow, reliable storage at a cheap
price point. For higher performance, 3PAR is designed to take
advantage of an internall distributed, internally scalable architecture
and is very easy to manage online. If you need higher performance
storage for cheaper than EMC, check them out. The last option, and the
cheapest and most dangerous, is to get a bunch of Nexsan storage arrays
and put them on a SAN with your databases. Then use something like
Veritas or ASM to stripe and mirror across them. Cheapest option,
performance should be pretty decent.
In the end, though, you're really going to need more information to be
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
> optical, though can't give you any price/performance vs SAN, NAS, JBOD.
>
> Regards,
> Mike Hand=20
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [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
> 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.
> =20
> 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?
> =20
> Thanks - Brian
> =09=09
> ---------------------------------
> Do you Yahoo!?
> Make Yahoo! your home page=20=20=20
>
> --
> //www.freelists.org/webpage/oracle-l
>
> --=20
> This transmission is intended only for use by the addressee(s) named
> herein=
> and may contain information that is proprietary, confidential and/or
> legal=
> ly privileged. If you are not the intended recipient, you are hereby
> notifi=
> ed that any disclosure, copying, distribution, or use of the
> information co=
> ntained herein (including any reliance thereon) is STRICTLY
> PROHIBITED. If =
> you received this transmission in error, please immediately contact
> the sen=
> der and destroy the material in its entirety, whether in electronic or
> hard=
> copy format. Thank you.
>
>
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts: