Will mysql work with a load of about a trillion records?

Question

PHP

Good afternoon! I know the question sounds strange, but suppose we have a database with a trillion records, will it function normally and how will this affect the response time from the database?
Thank you in advance!

Answer 1

in general, a trillion records of 1 byte is already a terabyte. those. here we are talking about a database with a volume of not even tens - hundreds of terabytes. Very IMHO - but it's strange to talk about any SQL here. Maybe hadup?

Answer 2

The question was poorly addressed. A trillion records in one table or a million tables in a few. What are the main operations to be done? What data structure and so on and so forth. What capacity do you have. For such a large number of entries, there is a lot to consider. Maybe something from NoSQL is more suitable for you.

Answer 3

stackoverflow.com/questions/1276/how-big-can-a-mys...

Answer 4

The problem is unlikely to be in the database itself. It usually boils down to three things:

1. The queries themselves and their optimization.
2. Configuration of the database and the server itself. Well and correctly placed indexes.
3. Server resources with a database.

Answer 5

Usually, when data of this volume is operated on, there is a division at the application level.
For example, records from 1-1m lie on one server, data from 1m-2m on another, etc. MySQL is up to the task, Facebook is up to it. But you won't be able to do JOINs, and to link your data, you will need to implement a script server.
The main thing is to understand what types of data will be stored, perhaps for your tasks, MySQL is simply not suitable

Answer 6

If you have a purely theoretical question, then I will answer it without specific implementations))) It will work relatively quickly if you regularly perform partitioning or segmentation (read on the Internet, a very useful thing even for small databases). In short, this is the division of the entire database into partitions, with which the muscle is much easier to work with than with one large database. Muscle itself provides excellent tools for this. Moreover, he himself determines in which partition the necessary data is stored already at the time of the request. Also, there are absolutely no restrictions on working with joins and indices. The only downside is that it has to be done manually. Although for this it is enough to run a simple cron script that will execute about a hundred partition requests just once a month. It will hardly create a load, however, the muscle itself will be very grateful to you that you unload it from the unnecessary work of carrying heavy bases. Sometimes sharding is also implemented in conjunction with it, when a new table is automatically created in the database, when a certain number of records have accumulated in the old one (usually 10,000), with the names table1, table2, table3, etc. In this case, different databases it is possible to spread it across different servers, however, in most cases, due to some subjective factors, its implementation is usually not feasible, therefore, in most cases, partitioning is used everywhere.
Also, as mentioned earlier, it is not known under what conditions your database will be used: if there are more requests for adding than for reading, you need to use MyISAM, otherwise InnoDB, the difference is noticeable. Strongly.

Answer 7

PostgreSQL will be))) MySQL well, maybe, in principle, probably, perhaps even one index by id will be rebuilt for quite a long time when new records are inserted.