home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / storage / 613 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.5 KB
  1. Xref: sparky comp.arch.storage:613 comp.databases:6473
  2. Path: sparky!uunet!usc!isi.edu!rod
  3. From: rod@isi.edu (Rodney Doyle Van Meter III)
  4. Newsgroups: comp.arch.storage,comp.databases
  5. Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
  6. Message-ID: <22302@venera.isi.edu>
  7. Date: 1 Sep 92 07:29:08 GMT
  8. References: <1992Aug29.210553.8744@rhein-main.de> <1992Aug31.043738.19685@psg.com>
  9. Reply-To: rod@venera.isi.edu (Rodney Doyle Van Meter III)
  10. Organization: Information Sciences Institute, Univ. of So. California
  11. Lines: 48
  12.  
  13. In article <1992Aug31.043738.19685@psg.com> randy@psg.com (Randy Bush) writes:
  14. >vhs@rhein-main.de (Volker Herminghaus-Shirai) writes:
  15. >
  16. >> I need to design a retrieval system for ~15TB of data, of which ~5TB are
  17. >> retrieved with a high frequency (25 requests/second) and an access time
  18. >> of avg. 30 seconds (max. 120 seconds). Retrieval lacks any locality, so the
  19. >> 5TB are real random-access. The rest of the data is still accessed at a
  20. >> rate of 5 requests/second.
  21. >
  22. >Optical RW store, a la HP.
  23. >-- 
  24. >randy@psg.com   ...!uunet!m2xenix!randy
  25.  
  26.  
  27. The problem is not the volume -- 15 TB is huge but not enormous
  28. (like the distinction?:-)), the problem is the access rate. Even
  29. the fastest cart machines are ~15 seconds to replace a disk or tape
  30. (remove the AND insert the new), so to get 25 reqs/sec., you're
  31. looking at not 40 but 400 cart machines.
  32.  
  33. As pointed out, you probably want MO, not tape; VHS, 8mm, D-1, and
  34. D-2 are all fairly slow to load (I think Ampex' D-2 is the fastest),
  35. plus the seek times... w/ 400 cart machines, you'll have enough
  36. drives that seek time isn't a problem with your latency.
  37.  
  38. An important question is the size of an average data request --
  39. if it's a bank account balance, the throughput of the device is irrelevant.
  40. If it's CAD files or fluid-flow simulation, you need one of the
  41. higher-speed alternatives.
  42.  
  43. Are you prepared to handle acres of floor space, hundreds of
  44. drives, all the power, etc.?
  45.  
  46. By the time you add it all up, I think the only realistic solution
  47. is RAID arrays. Yes, they're small and expensive, but I think it's
  48. the only way to get that kind of throughput.  Oh, you'll need
  49. one mini-super for every several RAID arrays, too, don't forget.
  50.  
  51. What's the timeframe for implementation?  The capacity is
  52. easy, if not quite off-the-shelf, but meeting those performace
  53. characteristics is damn near impossible in the current generation
  54. of devices.
  55.  
  56.         --Rod
  57.  
  58. disclaimer: I work for a company with a vested interest in this
  59. area, but you don't know which one, so there! It's not the only
  60. company mentioned by name in this article.
  61.