Table partitioning is the way to go. Do not create all those identical table structure.
What table partitioning will give you
- You will have single table which is logically partitioned by the database.
- In your applications view, you are querying a single table just like any other database table.
- In the database perspective, it stores data by partition which is defined by a partition type and partition logic. In mysql, you can refer to
https://dev.mysql.com/doc/refman/5.7/en/partitioning-types.html
- Performance benefits if defined correctly. It will avoid scanning the 1 billion rows but instead scan the related partition when doing queries.
Table partition can be very database specific.
A simple example from mysql.
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '1970-01-01',
separated DATE NOT NULL DEFAULT '9999-12-31',
job_code INT NOT NULL,
store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
PARTITION p0 VALUES LESS THAN (6),
PARTITION p1 VALUES LESS THAN (11),
PARTITION p2 VALUES LESS THAN (16),
PARTITION p3 VALUES LESS THAN MAXVALUE
);
The employee is stored to a specific partition to either p0, p1, p2 or p3 depending on which store (store_id) the employee belongs.
You are still accessing it through a single table but the data is stored logically by partition depending on the store_id.
SELECT * FROM employee WHERE store_id = 10
The database will simply look at partition p1 and does not scan other partition (p0, p2 and p3) because simply that query will never find data in those partition.