home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / database / 8624 < prev    next >
Encoding:
Internet Message Format  |  1992-12-22  |  4.2 KB
  1. Xref: sparky comp.databases:8624 comp.databases.sybase:528 comp.databases.oracle:2597
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!bcm!mparsons
  3. From: mparsons@fleming.csc.bcm.tmc.edu (Mark Parsons)
  4. Newsgroups: comp.databases,comp.databases.sybase,comp.databases.oracle
  5. Subject: Re: 500'000 records - who does best?
  6. Date: 21 Dec 1992 20:45:05 GMT
  7. Organization: Baylor College of Medicine, Houston, Tx
  8. Lines: 81
  9. Distribution: world
  10. Message-ID: <1h5achINN2i2@gazette.bcm.tmc.edu>
  11. References: <1992Dec21.182948.16832@bernina.ethz.ch>
  12. NNTP-Posting-Host: fleming.csc.bcm.tmc.edu
  13. Originator: mparsons@fleming.csc.bcm.tmc.edu
  14.  
  15.  
  16. In article <1992Dec21.182948.16832@bernina.ethz.ch>, flog@open.ch (Florian Gutzwiller) writes:
  17. > If you'd have to realize a server client based database with Suns as servers  
  18. > and NeXT as clients. Single records would be an average of 30KB in size and  
  19. > there would be a number of 20 concurrent users. 
  20.  
  21. Ummmmmmmm, let's see . . .. a 30KB record size? Sounds like you just
  22. might want to rethink your table definition?  Or is a large chunk of
  23. this text or pic data?
  24.  
  25. In Sybase, data pages are limited to 2K(a little less for the actual
  26. data since there's some overhead).  Records do/will not span more than
  27. one page soooooooo, a 30KB record length is not possible in Sybase.
  28. Unless you're talking about text(and pic?) data.  If you have a column
  29. in your record that is TEXT type, what gets stored in the record
  30. is a pointer to a separate data page where the TEXT entry resides.
  31. And yes, TEXT entries CAN span data pages.
  32.  
  33. (We're using the 4.2 version of the server and I don't think
  34. the 4.8/4.9.1 versions are different in this respect . . . any
  35. comments?)
  36.  
  37. > 
  38. > Would you choose Sybase or Oracle ?
  39. > Who has experience with similar solutions/environments ?
  40.  
  41. As for having 500,000 records . .. and what kind of performance
  42. to expect . . . that's gonna depend on a slew of 'options':
  43.  
  44.     1) What is actual transaction/selection rate, one per user
  45.        per hour? 5 per user per minute? Is this table used 
  46.        primarily for selects or update/insert/deletes?  How
  47.        many indexes do you have defined and how are they 
  48.        defined?  The more indexes you have, the longer it
  49.        takes to do update/insert/deletes since each index has
  50.        to be updated.  The larger the indexes, the fewer that 
  51.        fit on a data page and so the longer it takes to do
  52.        reads and writes just to the indexes. The more users
  53.        doing more transactions the slower the system . . .
  54.  
  55.     2) How many devices do you have and how is the table (in
  56.        question) defined across them?  One disk is gonna cause
  57.        a bottleneck during read/write times.  More disks, with
  58.        separate disk controllers can relieve some of this
  59.        bottleneck.  By the way, 500Kx30K = 15 Terra Bytes so
  60.        you'll need separate disks anyway!!! ;-)  This doesn't
  61.        take into consideration the GB's (TB's???) worth of
  62.        disk space you'll need for indexes . . . unless you
  63.        were planning on going without indexes???
  64.  
  65.     3) Is all data equally likely to be selected?  Would it make
  66.        since to break the table up into some sort of time
  67.        frames, i.e., most recent(most selected) in one table
  68.        and older(less desired) data in 'history' tables?
  69.  
  70.     4) In any case(with 15TB!!) you're gonna need to look at
  71.        breaking the table, and the records up.  At this size
  72.        of a database, the time needed to do a table scan(ouch!),
  73.        update of multiple indexes, multiple/join selects is
  74.        gonna take mucho time . . . 
  75.  
  76.     5) More . . . 
  77.  
  78. If you are, in fact, working with a database that's this size . . 
  79. . . . . I don't envy you.  I would give some very serious thought
  80. to downsizing the database . . . separate tables, try to optimize
  81. on field types(tinyint vs int), think very serious about separate
  82. databases even . . on separate machines . . . 
  83.  
  84. 20 people hammering on 15TB++ worth of data on one machine(is
  85. this even possible . . technically possible, sure . . but
  86. realistically??) is not going to work.
  87.  
  88. I know: "Mark, Mark, it's a hypothetical question" . . . . but it's
  89. a hypothetical question that needs more than just a cursory
  90. answer to which database engine is best . . . 
  91.  
  92.  . . . . . $0.88 left!!  ;-)
  93.  
  94. Mark
  95.  
  96.