Opening Note: The following text does not have a lot of technical vocabulary, so as long as people interested in PHP can see.
Is Phper a root?
From the day Php was born, PHP began to serve the vast majority of programmers in Web applications. At the same time, as a tailor-made scripting language for Web development, PHP has been adhering to the idea of simple, open source, which also enables the rapid development of PHP, and vigorously promote the emergence and development of Web2.0. However, for a long time, phper (PHP programmers) is considered to be a grassroots programmer, and is considered to be a low-level programmer with less technical content. This is particularly prominent in the country.
Remember a technical director said such a thing. He assigned a programmer to the development of PHP task, did not expect the programmer actually said: "I am learning Java origin, you asked me to write PHP, you this is not to belittle me?" This thing impressed me very much and touched me a lot. Although this does not represent the majority of the programmer's views, but so that people should be a lot. Others say that now, if it is a large government project, PHP is certainly not going to be included in the scope of consideration.
So why is Phper considered grassroots because it is so simple that everyone can learn, so it's not difficult? I used to think so. PHP Getting started quickly, processing files, data, remote connections, network programming is very convenient, the official also has the saying: PHP learning cost is very low, so you are easy to use it. This idea is also common, even most of the phper themselves think so.
Speaking of which, I think everyone will think of why I write these words. Because more than a year of PHP promotion work let me know a lot of PHP use of the company's approximate situation. In these processes I slowly realized the root cause. Here I say is the root cause although it is a personal opinion, but I think the fact is so.
So why Phper is seen as a grassroots, the root cause is that phper do (through code) is the most of the performance layer of things, this familiar with the PHP people know. Of course, there will also be PHP that he wrote with the MVC structure of a certain framework with how to function. But these are the performance layers. So programmers who only deal with the performance layer are seen as grassroots. In fact, this is true, because PHP is really hard to construct large applications.
That's why we found it, no. Why Phper is always in charge of the performance layer of things. The answer is the underlying data processing (the Web application is the datastore and the lookup) we generally do not touch! OK, so here are some people who might have thought, that's not the database! Yes, that's the database! Let Phper always be the root of the culprit is the database. Why?
Because the current popular web architecture, the front-end is a load-balancing system, the middle of the Web server, followed by the database server. So, most phper work at the Web server level. Because the database has been very good for us to organize the data. So there are not too many algorithms in PHP, and everyone subconsciously feel that no need, not to mention will affect performance.
In this case, Phper becomes a database user, and he is always manipulating the database. Rather than doing a program. One of the simplest PHP scripts is to connect the database, get the data out, and then output the command to the browser. The entire process does not exceed 10 lines of code. The feeling of giving is too simple. There is no technical content. Why, because the data Processing section has been completed by the database. Especially the use of MySQL! MySQL is free, so most programmers are free to use it, and MySQL is fast enough, so making a PHP application is very simple. It's equivalent to giving you a gun. You don't feel the need to learn Kung fu. Of course, I'm not saying that guns are not good at Kung Fu. It is said that the appearance of guns, children can easily and conveniently kill.
Let's go into the details of why the database! Here I say an example. I have been to a very famous website in Beijing, when we have a more senior PHP programmer to say something about the system architecture. I remember when the programmer asked everyone about an algorithmic problem in the data structure, no one in the audience could answer it (including me). Then the programmer began to tell us something about the basic data structure. Let me suddenly think of the university time to learn data structure class. The problem of sorting, finding, and delivering data is very common in other high-level languages such as C. But not in PHP! Phpchina.com's forum also has a plate called PHP data structure and algorithm. There are also few posts in this section.
In retrospect, the current network on the most of the discussion is two aspects of the problem. One is the use of the PHP class (encapsulation of the process), and one is the development framework issue. But we carefully analyzed, found that these so-called PHP in the more complex concept of no data processing! Why, there is a database! With a ADODB or PHP5 PDO can be done! Is it really done? No, these are nothing but the connection to the database, no data processing! So Phper seems to have nothing to take on the surface of things.
Again, a specific code problem, no class classification. This concept I think we are not unfamiliar with it. I've seen two ways of dealing with it. The first one is the phper of the authentic way, and is now more popular. is to use the database to deal with. And there are few fields, just add the fields of the parent class and judge the line. And this method is very practical. Efficiency is also high! But this is not the category of data processing, but the search for the database!
The second is a C programmer written in PHP, he put all the classified information from the database, and then use the data structure algorithm to arrange the distribution, and then output.
Here we do not compare the efficiency of these two ways, I think we all have their own ideas. But I would like to point out one question, that is, the essential difference between the two approaches. Phper habitually use the database to deal with, and have a very skillful way of handling, the efficiency is also very high! This is the database query. And the second method is more characteristic. He thinks that the database is the place where the data is stored, and the concrete logic processing depends on its own logic.
Therefore, the conclusion is that the user of the second method feels better, because the logic of the data is organized by him! and feel that the phper way is to query the database. So he thinks phper is grass-roots, only know how to manipulate the database and arrange the page (smarty).
Here, I think we have already recalled a lot of their usual use of PHP to do development experience it, whether we found that everyone is actually operating the database.
So let's talk about the problem. Is the database not good? Why I have been using the database to process the data is OK. I would like to say that the database is problematic, and there are a lot of problems! Of course I'm not saying that you can't use a database or degrade the performance of a database. Instead, we are not fully aware of the role that the database plays.
My idea originated in such a thing that once a website's technical director asked me why their site was so slow and what to do. At that time, my MSN Zend Headquarters engineer just online, I asked him the PHP response is slow, how to do? He was telling me directly, the database problem! The database is definitely not optimized for design. So, I didn't give the technical director the exact answer, because their database design is not for us to deal with. So I gave you some advice about database optimization. This happened repeatedly, I began to doubt, why Zend headquarters of the engineers each time to tell me that the problem is a database, can we not from the PHP level to solve this problem? The answer is NO! Because PHP is running at a very fast pace, Through the performance analysis of Zend can also see a user clicks, PHP running time is only 10% less, that PHP is doing? It's waiting. The query results for the database. This aspect in the current PHP product has a very big improvement, that is caching and Web page static two of programs. Caching may be unfamiliar, but the web is also static now even users of PHP products are very clear. Fast, easy to be searched and so on, the benefits are self-evident. Jokingly, now the homepage of the website to achieve static Web page only requires a hard disk large enough. J As for the caching is more complicated, but also most of the phper feel headache place. Even some people will use C to achieve. Because the data validity in caching, find, extract, update and so on are more difficult to deal with. Of course, some people will use the database to deal with caching problems.
So, when the volume of traffic surges, the PHP architecture of the site will appear many problems due to the database. The database synchronization problem is nothing. The key is that the database's response speed will be exponentially lower. This question I asked the vice president of MySQL on the October 23 lamp press conference. He did not give me the perfect answer (which I expected), because the database will always have bottlenecks, unless it is the immortal database, haha!
Here's an aside, when I was talking to a tech executive at the Lamp conference, I asked him what Yahoo was thinking about when he chose MySQL or Oracle, and his answer surprised me. He said most of the time we will use MySQL, because its performance has reached our requirements. But when are we going to use Oracle when we need to store the data for our billing users? I asked why, is Oracle more stable than MySQL? He said, this is not a special consideration. The key is that if Oracle is used, we can find the person in charge when there is a problem, Oracle will be responsible for the incident, but if we use MySQL, who should we call?
Therefore, our view of the database should be corrected, that is, the database is not omnipotent. If you have the strength to develop your own database. I heard that Google is like that.
So what do we think of the database? My personal understanding is that the database is just a means to reduce the cost of development. Because we do not need to consider the storage of data, especially sorting and lookup, after using the database. But what's the problem? It is when the business expands, the database becomes the bottleneck! This is a tricky problem! Because this is the underlying data processing. Far-reaching
So I think the correct view is that the database is a data backup machine! How to understand, we just need to ensure that the data storage effectiveness on the line. And this is the core function of the database, just because of the convenience of database sorting functions so that we put too much processing to the database to operate. A user clicks on PHP to put a lot of tasks to the database, and then arrange the results to the user is finished. This is not fair to the database! So everyone starts complaining about the performance of the database.
To this point, for example, one time I went to visit a large network company (which is basically known as the Internet at home), and they used PHP very little, but I learned how their other businesses used the database. They proudly told me that they had a second database on the periphery of the database (my name is the second database). Why call the second database, it is a caching system. So how does a development engineer get data from the caching system? The technical director proudly said that they had this caching system made up of SQL query statements! I was surprised, but then I thought I really needed this. Because when your cache system reaches a certain level of time to get data from the cache is very complex, simply write a SQL query to let the cache system analysis, processing and return data. And they told me that, in their case, PHP was also used to read data to the cache system.
So, if you can handle this problem, put the data in the database, and then the database will only play a backup role. Then you use your own middle layer to process the analysis data, the effect is more than 90% of the user access to the database. Someone would say, isn't that something like a connection to the pool? Because the database bottleneck is unresolved, we can only buffer the Web server and the database by adding a middle tier.
Maybe people will say, cut, this we already know! Well, here's what I'm going to say about the two points that it triggers:
<!--[if!supportlists]--> First, <!--[endif]--> Some languages already have connection pooling technology, and those programmers can easily use connection pooling to build large applications. So if they think that Phper will only be using the database, then can we say that they will only use the connection pool? What is the difference between connection pooling and database in this concept?
Second, when Phper started building his own caching system, did he break through the phper only to use the database hierarchy? Because he was involved in the processing of data logic. So he's still a root?
Finally, the new generation of Phper is grassroots?