If you want it to be as fast as possible, you might want to consider doing
the following:
1. Arrange your data so that the records are fixed length.
2. If possible, switch to something other than a relational database. A
binary search on fixed-length, sorted records is probably going to be your
fastest option. It's also got MUCH less overhead in regards to meta-data.
This works great for read-only data.
3. Don't use PHP, ASP, Perl, Escapade, or any other interpreted language -
write your code in C, it will be MUCH faster than any sort of interpreted
language. Even with Escapade, which is far faster than any of the other
three, is put to shame by compiled C.
----- Original Message -----
From: "Matt Hargraves" <mhargraves@stripped>
To: "Joseph Monti" <joe@stripped>; <mysql@stripped>
Sent: Thursday, September 05, 2002 10:41 PM
Subject: Re: storing dabase on linux ramdisk
> I don't know anyone who's done it but I can think of no reason why it
> wouldn't be possible.
>
> Now whether it is a good idea is another idea entirely. Without a live
> backup server (slave) running off hard disk and a very powerful battery
> backup system, you're just begging to lose all your data. No matter how
> much you think that your data isn't important, you find out how much it is
> necessary right after you lose it.
>
> Another issue: data growth. You would think that it wouldn't need over
1GB
> of space, but it isn't uncommon for databases to grow well beyond their
> initial concepts... just like John Roach's statement about 640k... nobody
> will ever need more than that, right? Now we're running over 5,000 times
> that in systems and starting to need more for some tasks. While you
> probably won't need it today, having a system that will support addressing
>
> 4GB of RAM is not necessarily a bad idea in a situation like what you're
> talking about.
>
> Either way, you should get a HUGE performance increase from switching to
> running off RAMdisk. Is it practical? It can be... but only if you've
got
> a slave system with the data running off a nice, fast RAID 5 array with a
> big, fat read cache. Are there situations that I can think of where I
would
> want to do it? Sure, but they all involve massive conversational AI
> systems.
>
> Matt
>
> ----- Original Message -----
> From: "Joseph Monti" <joe@stripped>
> To: <mysql@stripped>
> Sent: Thursday, September 05, 2002 11:21 PM
> Subject: storing dabase on linux ramdisk
>
>
> > I've got a question about MySQL that I've been wondering but havn't been
> > able to try.
> >
> > Would there be a noticable performance gain if I were to put my tables
on
> a
> > Linux ramdisk (disregarding any size constraints)? Would it be feasible?
> and
> > under what conditions would there be a difference?
> >
> > I've got a database on a site I recently started
(http://joe.42llamas.com,> a
> > database of guitar tablature) and would like it to be as fast as
possible.
> >
> > Any input on this would be great.
> >
> > Thanks!
> > - Joe Monti
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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 <mysql-thread118899@stripped>
> > To unsubscribe, e-mail
> <mysql-unsubscribe-mhargraves=onlineworldsinteractive.com@stripped>
> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php> >
> >
>
>
> ---------------------------------------------------------------------
> 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 <mysql-thread118901@stripped>
> To unsubscribe, e-mail <mysql-unsubscribe-erc=pobox.com@stripped>
> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php>

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.