- All tables in the database have one timestamp column [
float]
followed by an arbitrary amount of parameter columns [integer]
(usually less than 5, but more than 1), and one value column
[float]. - All queries are without any joins, and they are based on giving the database a set of parameters, and receiving the timestamp and value columns back.
- The amount of rows are counted in low 10s of millions.
- Small number of users, less than 10.
- More reads than writes, but both can be simultaneous.
- Should meet ACID properties.
Back in the day all MySQL was chosen, but this is a moot point. SQLite is quick and effortless on a computer local basis, but in this example it needs to be a proper server/client database. Up until this point no optimization has taken place, except for indexing.
EDIT:
I didn’t mention it properly, but the traffic is not an issue. That is, it’s not really an optimization for meeting certain volume criteria, it’s an optimization on pure speed.
Use InnoDB for ACID support.
Memory, memory, memory. The single best MySQL tuning optimization you can do for reads is to increase
innodb_buffer_pool_size. But of course not so high that it grows larger than your physical RAM because that can cause mysqld to go into swap.Structure your table’s primary key along the column you most frequently search against. That is, take advantage of InnoDB’s clustered index on the primary key.