[thelist] Very Large MySQL Table

[Hans Zaunere]

> > If you're using a MyISAM as your storage engine, the count(*) should
return
> > instantly.  If you're using InnoDB, then you'll need more RAM and
> > horsepower.  You probably should be using MyISAM in this case.
> 
> First try at converting failed--it just crashed. But I will try again.
> Perhaps I will upload first. :)

Converting a table from one storage engine to another (among other
operations), will use typically 2 * table-size and gallons of RAM - so this
won't work, especially on a small box.  But why not create the table and do
the import as MyISAM (not sure the format of the data you're actually being
supplied with)?

> > If you're dealing with 6gb tables, a web hosting account isn't going to
give
> > you very usable environment.  I'd recommend getting some modern
dedicated
> > server or even VPS with a nice allotment of RAM.  Don't jump through
hopes
> > with fancy partitioning schemes to overcome a lack of hardware - end of
the
> > day, you will always have 185 million rows to search through.
> 
> Good point. :)

...

> But what I am wondering now is how do DNS's work? Unless I am
> mistaken, when I request evolt.org in my browser, it goes to my local
> DNS who looks up that domain name and then directs my request to the
> correct server. Even if you will say that more commonly requested
> domain names are cached, I have never (ever) had more than an
> instant's delay going to any site I have ever visited, aside from the
> occasional slow site which I always attributed to the host of that
> site.

They don't use relational databases - relational databases are relatively
slow in the "database" world.

> How do these machines do these lookups so fast? And I presume they're
> high-traffic machines as well, generally speaking. Perhaps I am
> misunderstanding how they work.

Oh, and they don't use a shared web hosting account :)

---
Hans Zaunere / Managing Member / New York PHP
      www.nyphp.org  /  www.nyphp.com