Hi, On Thu, 2002-02-28 at 04:43, Oscar Colino wrote: > I read your thread discussion Jan and it is certainly very interesting to > me. > There are though a couple of areas where I would (oh shit you wrote this > email in 1999, I hope you are still there anyway ..) be rather skeptical, > and these are:
Who is Jan? You didn't quote a full name/e-mail in your message.... I doubt that the original poster (if still around) would spot it. > Facts: > - An average DW will contain an average of 500Gb this could be in turn > around 7000.000.000 rows > - An average fact table will contain around 30Gb --> 400.000.000 rows > - There will be cases where a DW will go above 1Tb = 1000Gb MySQL Servers are in fact being used with production TB-size databases. > The way traditional RDBMS systems deal with this is: > > 1) Partitioning > There are systems like Teradata whose architecture is designed to be > able to hold as much data as needed without degradation, based on > multiprocessors and multidisks > and parallel IO/ parallel processing > In other databases like Oracle you have database level partitioning > where a big table of 30Gb could be partition by month in chunks of up to > 500Mb, each one of these chunks is got associated a different data file > Note that partitioning will be fundamental for performance on the > loading, querying, backing up and archiving data > > what is the support for Partitioning in mySql if any? With the InnoDB table type, you can specify multiple data files to distribute your table space. InnoDB can also use raw HD partitions. With the MyISAM table type, you can have MERGE tables (see manual). This feature is now very commonly used for things like logging, and would also be quite suitable for other similar tasks. You could start a new table every month, and either access these individually, or combined through the MERGE table. Additional tricks include: running the older tables through myisampack, making them compressed/read-only, saving heaps of disk space. You could even store them on a CD. > 2) Indexing > > MySql supports indexing but it just supports a class of indexing > (B-tree indexign), what about hash and bitmaps, those are very useful in > certain type of queries Other index types like R-trees will blink into your field of view shortly. > 3) What is the performance on loading and backup procedures in mySql? All depends on your system setup, the table types used, and the backup method used. There are lots of choices, so there's sure to be one option that will be suitable for your particular application. > I see mySql with very good potential to grow in the Dw arena, where no > referential integrity is needed ... (why should we need triggeres and so on > , they will slow down the queries), but there is key lack - support for > partitioning Uh, you asked the question above, but here you just state an unconfirmed assumption as if it were a fact... ohwell. Anyway: assumption incorrect, see above. Regards, Arjen. -- MySQL Training in Brisbane: 18-22 March, http://www.mysql.com/training/ __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Mr. Arjen G. Lentz <[EMAIL PROTECTED]> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Technical Writer, Trainer /_/ /_/\_, /___/\___\_\___/ Brisbane, QLD Australia <___/ www.mysql.com --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
