1

The title says most of it, I'm wondering if MySQL is suitable, (and if not, what else would do better) for storing this data?

It would be most likely 3 to 6 floating point numbers delivered every quarter second. (Somewhere between 1-3 GB per year)

At the same time this data needs to be real-time (or close-to) accessible from the MySQL, so it can't miss a beat while running some (potentially large) queries on the database.

Can MySQL handle this? I have no concept of how this kind of database scales or what constitutes "a lot" of information at one time for these databases.

If the database were to receive the same information but clumped into one large update every 5-10 minutes would that change the answer?

Alex Gosselin
  • 2,942
  • 21
  • 37
  • 1
    For perspective, one single application here (admittedly, a major one) is generating over 13GB of new data per year; and that's not counting (needed, some unneeded) indicies. Of course, most of this is in one table (design issues)... Of course, this is on an iSeries with DB2. – Clockwork-Muse Nov 03 '11 at 23:58

1 Answers1

1

It depends on the table and the hardware. A Decent mysql server would have no problem with this. Especially if equipped with a SSD drive.

One large query inserting a large amount of data would be more efficient, as it would be a single index update and so on. There will be a sweet spot somewhere in there between the .25 second update and a 5 minute bulk. Testing would show that.

If you are doing replication, keep in mind that the slave is single threaded, and these updates would ultimate take longer there. You would also want to go with innodb as opposed to myisam to avoid table level locks during writes.

Jericon
  • 4,992
  • 3
  • 20
  • 22