Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: Database options to lower bandwidth

  • Subject: Re: Database options to lower bandwidth
  • From: Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx>
  • Date: Mon, 28 Nov 2005 09:25:54 +0000
  • Newsgroups: alt.www.webmaster
  • Organization: schestowitz.com / MCC / Manchester University
  • References: <1133133728.342315.237490@g49g2000cwa.googlegroups.com>
  • Reply-to: newsgroups@xxxxxxxxxxxxxxx
  • User-agent: KNode/0.7.2
__/ [Jason] on Sunday 27 November 2005 23:22 \__

> My website includes a message board program (my own design) that
> utilizes a series of text files for data. Each subject creates a new
> text file, and the posts are saved in this text file.
> This worked out great in the beginning, but now the site has grown
> substantially to the point that I have more than 4000 of these text
> files taking up about 30MB of space. I've recently attained regional
> notice, and my site is growing... fast.
> I was told by my hosting provider that my monthly bandwidth is now at
> about 50G a month, and growing exponentially. I'll have about 5 million
> page views in a month... this is getting to be expensive!

Like John said, there are hosts that will give you 100GB of bandwidth per
month for just a few dollars a month. I can name some if you wish. Some
would even include gigabytes of Webspace, though it doesn't seem like you
require it.

> So, I'm thinking about moving everything over to a different database
> system to see if I can save some money on bandwidth. I thought about
> using MySQL as a single database with 4000 tables (each table
> constituting a different thread), but I don't know if this is going to
> save me any bandwidth, or if it will be any faster. I'm actually
> concerned that it will be slower, since the single database will be
> huge in comparison to the 4000 smaller databases.

The issue here is not bandwidth. If so much bandwidth if devoured in the
process of fetching data (e.g. scanning gigantic text files), you might
sooner or later suffer from latency in page delivery. I suggest a makeover
that involves MySQL, or maybe better -- PostgreSQL. Better do something
sooner than later. Set an experimental re-design aside, then test and
embellish until happy.

> Is MySQL going to be a good option, or should I consider something
> else? Or are text files the best choice still?

To make the transition less painful, is there any simple way of splitting
these text files? Relational databases are more elegant, but they are not a


Roy S. Schestowitz      | LINUX - (L)ove (I)s (N)ever (U)tterly eXPensive
http://Schestowitz.com  |    SuSE Linux     |     PGP-Key: 0x74572E8E
  9:15am  up   8:59,  4 users,  load average: 1.41, 1.39, 1.08
      http://iuron.com - next generation of search paradigms

[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index