home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / arch / storage / 622 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.0 KB
  1. Xref: sparky comp.arch.storage:622 comp.databases:6529
  2. Path: sparky!uunet!stanford.edu!agate!triplerock.CS.Berkeley.EDU!mao
  3. From: mao@triplerock.CS.Berkeley.EDU (Mike Olson)
  4. Newsgroups: comp.arch.storage,comp.databases
  5. Subject: Re: Info on large, slow storage wanted (jukeboxes, etc.)
  6. Date: 3 Sep 1992 16:23:24 GMT
  7. Organization: University of California at Berkeley
  8. Lines: 35
  9. Message-ID: <185e5sINNjdd@agate.berkeley.edu>
  10. References: <1992Aug29.210553.8744@rhein-main.de>
  11. NNTP-Posting-Host: triplerock.cs.berkeley.edu
  12.  
  13. In <1992Aug29.210553.8744@rhein-main.de>, From: vhs@rhein-main.de
  14. (Volker Herminghaus-Shirai) writes:
  15.  
  16. > I need to design a retrieval system for ~15TB of data ...
  17. > 
  18. > Any kind of information is greatly appreciated (hints, pointers, ideas, etc.)
  19.  
  20. my master's work at berkeley was on how to incorporate tertiary storage
  21. into a database system cleanly.  i changed a bunch of internal interfaces,
  22. defined a new abstraction like the file system switch, and added support
  23. for a 327 gigabyte sony optical disk worm jukebox.
  24.  
  25. under this architecture, the database system manages the tertiary storage
  26. device directly, rather than using an external file system interface to
  27. it.  the advantage is that the dbms can make intelligent clustering,
  28. caching, and prefetching decisions, and can consider optical device
  29. performance characteristic (like very long pick times) when it optimizes
  30. a query.
  31.  
  32. the jukebox storage manager uses a magnetic disk cache and extent-based
  33. allocation to speed up accesses to data.
  34.  
  35. a description of the architecture is included in the postgres papers,
  36. available by anon ftp from postgres.Berkeley.EDU (128.32.149.1) in
  37. pub/postgres-papers.tar.Z.
  38.  
  39. this won't answer all your questions; in particular, you would have to
  40. figure out clustering and caching policies to guarantee the performance
  41. bounds you list.  it may help you out in identifying problems with these
  42. devices and things you need to think about if you're designing your own
  43. storage manager.
  44.                     mike olson
  45.                     project sequoia 2000
  46.                     uc berkeley
  47.                     mao@cs.berkeley.edu
  48.