Usually I hear something like this:
“Help me, my database is so slow because it is so big”
“Well… about 1,000 rows”.
That usually makes me laugh. Adding some indices and convincing programmers not to get all rows with every select usually helps. Suddenly it turns out the database is not so big.
OK, but when someone says that there are over 1M records does it mean that this database is big?
Lets define the
big database some other way.
The number of rows shouldn’t be considered when classifying a database to be big. In databases sometimes we just store data. We have tables used for logging some data. So those tables can be really big, but who cares about the size, if they are not used? We also have tables with much less data, but with many indices, which are used for many much more complicated queries.
The main problems with databases are all about the speed of getting the data. Depending on the database usage type. We can have problems with inserts, or updates, or selects.
Usually we more often select from a database than we change the data.
There is no such problem as
The Big Database.
The problem is always
The Slow Database.
So what is a slow database?
Database can be slow because there is too much data. Then usually we use indices and speed all up to some extent. However sometimes we need to replace the server with something better and faster, more ram and faster drives, more CPUs and so on. Then the problem with the Slow (aka the Big) Database doesn’t exists. It suddenly looks like there is not a problem called
The Big Database. The Database is a problem if it is slow, not big. Big doesn’t mean slow, and slow doesn’t mean big.
When a database is slow there are many ways to improve that. To some extent. After that I can say that the database is Big if it is still slow. But that simply means that the database, and all database operations don’t fit the server.
The database is Big, when it’s just too Slow for our requirements.