What is faster than 10 file requests or 10 database requests?

Question

PHP

When forming a page, it is necessary to take information from 10 local files and parse them, receiving data for the page and output it, or you can take it not from files, but from the mysql database - make 10 queries. What's better?

Answer 1

Which is faster: ask on the toaster or check it yourself?

Answer 2

The database is the same files, only on top there is a server that beautifully and optimized resolves all requests. It will be faster from the database, and even faster from the RAM.

Answer 3

There is no definite answer to your question. Similar to the question: which is faster, a train or a car? Someone will compare a Soviet train with a Bugatti, another will compare Japanese high-speed trains with a Zhiguli.
Databases with SQL support are different: MySQL, MsSQL, Oracle, etc. Each of them has its own method of working with the cache, indexes, memory. A lot depends on the size of the database, the size of the tables, the construction of indexes, the query itself, the settings of the database server and operating system. If the database is properly configured, tables with a normal architecture, indexes are correctly built, the server has enough memory, then the query will be faster than most do-it-yourself solutions for working with files.
If the files were designed by a group of highly qualified specialists, the strapping was designed specifically for such requests, then the speed gain can be significant in this option. But this "way of the samurai" involves transferring the amount of computation to a faster server area: the memory-processor. You will have less work with the disk system, but the entire logic of the application should be shoveled for this type of data. Without fundamental knowledge of programming algorithms and mathematics-informatics in general, it is better not to fence such bicycles. Graph theory, matrices, hashes, sorting algorithms should be at your level above the institute. You can forget about convenient tables for 5-10 fields. You will have a bunch of small ordered files with key-value lists. Indexes, hashes, hashes by hashes, indexes by hashes, etc. - this will be your nightmare for a long time, which you will have to imagine in your head. Working with files directly does not make sense if you do not plan to create a highly loaded application with large amounts of data. In this case, it will take you an order of magnitude more time to work out the data storage architecture than to work out the database architecture. Preliminary search for one character, two, three, a link to files that contain the next part, which is already being searched. Don't forget file locks, access error handling, broken transaction handling, uniqueness of values, indexes or keys, and so on. The lack of convenient selects with joins and blackjack will require you to work out possible types of queries so that the type of data storage itself is optimized for castrated capabilities. And from queries there will be only analogues of the simplest "SELECT xxx FROM file_yyy WHERE Id=zzz", "UPDATE file_xxx SET yyy WHERE Id=zzz", "INSERT INTO file_xxx yyy=zzz", "DELETE xxx FROM file_yyy WHERE Id=zzz". You will have to manage with these 4 operations.
Now there are ready-made noSQL "bicycles", but this is not the "Jedi way". A typical site with a dozen or a hundred uniques per hour is not worth such hemorrhoids.

Answer 4

From files. DB files + interface through which you pull the data.
But in fact, everything is somewhat more complicated. If there is not enough operatives on your server, the files will be forced out of it and the database may turn out to be faster.
A lot more depends on how many files are connected on each hit and how often these are connected. If every time - they will sit securely enough in the operative. If from case to case - not a fact.
And even the size of the files will affect. If each has 20 bytes, I would put it in the database. If they are large, it is more reasonable to leave them as files, but this is already from the point of view of convenience. Just think about how it will be more convenient to edit them when you have to do it.

Answer 5

What kind of files, let's start with this?
Text ?

Answer 6

Which is faster than 10 database queries on HDD or 1 file query on SSD?

Answer 7

Yesterday, a gentleman suggested to me a very interesting solution for this difficult choice.
Almost certainly you choose where it is better to store data and in order to get convenient system maintenance (without long SQL) and a quick search for results (which is just better in SQL, because in the case of a file you have to pour the entire "base" into the RAM, which means constantly buying more planks and kicking admins - they say put more, otherwise it slows down), the second again - arrays a couple of kilometers long are read and parsed by the editor for a long time, that is, change something "by opening file" - it will be difficult - you will have to do it through the API, which means problems or ingenious API.
I'm still on relational, although geniuses like Yandex and Google have been doing everything in files / nosql for a long time and there is probably an answer why like "if you have a billion records, the server can stupidly lie down."
There are such things as search engines. You throw data into them in the form of your own arrays, and they further distribute them in their database. You write a request and they themselves build and cache responses under the request.
Thus, you work with arrays and save to files, and the engine itself builds data structures and gives you cached results where possible. Fast service, fast search and life in chocolate.
I will try this combination soon.

Answer 8

It would be funny if it weren't so sad!
RETRACT
So many wise men divorced that a direct answer is no longer available.
You ask one, simple question, and in response - 10 clarifying and 5 paragraphs with digressions!
PEOPLE! You can’t answer, don’t dirty the Internet and be smart!!!
There is only YES and NO, the rest is verbiage and not knowing the answer.
That is, a comparison or an opinion, but not demagogy and reflections on spherical horses in an absolute vacuum.
ESSENTIALLY.
If there are short records and there are not many of them - to a file,
BUT if they are complex, structured, which will need quick access with filters and conditions - DB.
(BUT FOR ALL EQUAL). That is, the base is on the same screw and in the same system.