home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / 8965 < prev    next >
Encoding:
Text File  |  1993-01-09  |  3.9 KB  |  83 lines

  1. Newsgroups: comp.databases
  2. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!spool.mu.edu!agate!rsoft!mindlink!a269
  3. From: Mischa_Sandberg@mindlink.bc.ca (Mischa Sandberg)
  4. Subject: Re: 500'000 records - who does best?
  5. Organization: MIND LINK! - British Columbia, Canada
  6. Date: Sat, 9 Jan 1993 17:18:19 GMT
  7. Message-ID: <19432@mindlink.bc.ca>
  8. Sender: news@deep.rsoft.bc.ca (Usenet)
  9. Lines: 72
  10.  
  11. > Ben Polk writes:
  12. > 900k rows, 250Mb?  That's not big for Sybase on an RS/6000, unless
  13. > you find yourself scanning tables...  I've talked to people that
  14. > start to run into data load and index performance problems when
  15. > their databases reach the multi-gigabyte range, but the query
  16. > performance is still good even up to 10Gb.  Loading a 10Gb database
  17. > at 250Mb per hour is the problem.
  18. I may be repeating what you've already read, but here goes:
  19. my company's clients have a "volatile" business: frequent database
  20. restructuring, reloading, adapting. "Transactions" amount to bcp'ing
  21. 5-40k rows into a scratch table, validating and altering it then
  22. applying it to a main table or two. Single-row updates and single-row
  23. queries never happen.
  24.  
  25. We also have very limited time windows in which to work. Typically,
  26. 2-4 hours to process several such transactions then emit a
  27. "net change to database" transaction which is replicated/split
  28. into relevant slices for 200-700 remote databases that maintain
  29. partial views of the central one.
  30.  
  31. Other than those transactions, our database users are query-intensive.
  32. Most queries use all rows of a given table, given that searches tend
  33. to be data-selective rather than key-selective; but even where indexes
  34. are usable, we frequently get queries that hit the time limit (about
  35. 10 minutes on a system with 10 interactive users performing 10
  36. queries per day, within a four-hour window). One simple form of query
  37. is such an incredible dog, we've taken it outside the Sybase database
  38. and process it using a multipage-indexed Unix file:
  39.         "Given 10000 customers buying from a range of 2000 products
  40. (typical), give me a list of which are the top ten products for
  41. each customer, according to sales."
  42.         If you have some insight into processing this query efficiently,
  43. I'd be happy to here it. It's what I mean by a data-selective query.
  44.  
  45. I'd agree that loading a 10Gb database with BCP would not be a problem,
  46. done once.
  47.  
  48. Unfortunately, there are foreign-key validations and summary-updating
  49. functions associated with each "load" in our world. As far as I can
  50. tell, we have optimal indexes, though in a couple of places I've had
  51. to force the query plan --- yes, *after* determining that the query
  52. optimizer was intent on choosing a silly plan when left to its own
  53. devices.
  54.  
  55. On a Sun, we can pull a few tricks that tend to bring a table into
  56. contiguous physical disk cylinders; under AIX, no such options.
  57. >
  58. > Mischa, one thing you should check: if you have Sybase 4.2, you should
  59. > never give it over 32Mb of memory, as performance will DEGRADE
  60. > as you feed it more memory than this.  Sybase 4.9.1 is supposed
  61. > to fix this.
  62. Thanks, yes, I was aware of this -- we lived through it on one
  63. of our Sun SPARC systems with 80Mb. Since 4.8 on the Suns fixed that
  64. problem, I certainly hope 4.9 didn't *lose* it :-).
  65.  
  66. Your comment on the TPC benchmarks was something the original poster
  67. ought to know; you didn't see me quoting such benchmarks, did you?
  68. Both the original poster and I seem to have applications to which
  69. that benchmark has no relevance at all, it appears.
  70.  
  71. Thanks for the comment. Given what I've said above do you still feel
  72. strongly confident that a mid/high-range RS6000 would have no problem
  73. with that? I'd appreciate being able to better understand what your
  74. 10Gb database looks like and does.
  75.  
  76. --
  77. Mischa Sandberg ... Mischa_Sandberg@mindlink.bc.ca
  78.                  or uunet!van-bc!rsoft!mindlink!Mischa_Sandberg
  79. *-*-*-*-*-*-*-*-*-*-*
  80. Engineers think equations are an approximation of reality.
  81. Physicists think reality is an approximation of the equations.
  82. Mathematicians never make the connection.
  83.