Developing web-oriented solutions was always believed to be as basic as ABC, because the algorithm of displaying a web page was quite transparent. Nevertheless, considering that a look of those web-services like Google, Facebook, Instagram and others, that idea has actually become incorrect. Because of the web applications’ transformation, which has happened over the last few years, appeal of websites has raised dramatically. Ultimately, that situation compelled developers to develop new ways of overcoming the high load of their services, which is the subject of this post.
1. Discover a lot about sharding
The meaning of sharding should be represented as follows: it is a type of horizontal database separating that separates large databases into smaller and quicker parts called “fragments”. In words of one syllable, there are different databases with content partitioned equally in between them by a certain algorithm.
The advantages of the sharding technique are beyond doubt: the size of a single database part is less, the request ability under intensive load is enhanced. However, there is a considerable probability that an application of sharding will need a code rework in order to interact with a partitioned database.
Take for instance the most common use of a web service partitioning – “user” objects. The visitors’ information and theirs related data (such as purchases, actions and others) is divided between numerous servers using a shard database. Everything appears to be perfect until there is time to attune an interaction process in between web and database server.
The very first issue has to do with searching for the server that keeps the sought user. Normally, the number of a desired database is identified as the remainder after division of user’s id by N, where N is a quantity of databases. Despite the fact that it seems to be fairly effortless, the implementation of switching between databases typically needs a developer to be accurate and cautious. If he/she leaves a query without switching a database’s tip back to a previous state, it will be far more complex to learn the bug later on.
The second problem is related to data choice. As quickly as the sharding is implemented, the concern to choose a lot of rows from database will be a headache task of a developer. From now onwards, query’s conditions will have an impact only on a set of rows saved in a picked database. Put in a different way, the ability to obtain all the requested data by a single query is not appropriable anymore, since the query needs to be executed on every database in the set.
2. There is always something that can not be divided
Lets think of that many posts about sharding read, a set of databases is developed and it is time to start the development. It is commonly the case that the issue of segmenting data will reveal itself in a really uncomfortable minute, someplace between a Friday’s evening and a pre-alpha release.
Usually, problems with data splitting belong to application’s objectives. For example, there is a table in databases that shops users. Everything was fine until one day there comes a task to show every user the top of 10 users sorted by some rating value (which is extremely popular practice in online video games). From now on, the concept of saving user’s ratings in users’ tables does not seem much affordable because it requires you to go through all the databases one by one and perform different inquiries. The only practical solution is to calculate the leading list in a background using cron or to store scores data in a shared database that is not splitted. Both of the options are great, but it worth to find out about the health problem in advance.
Otherwise, it might be connected to a developer’s choices. The first and foremost error that leads to dreadful penalties is about an usage of “signs up with”. There is no doubt that sql joins is a very useful tool in lots of ways, however when it comes to a fragment database, it ends up being the most complicated task to address. The reason is relevant to sql signs up with’ purposes – it gives one a possibility to easily combine some data from different tables using one query. Once it is made use of in a project – you have a reliance between those tables and it is difficult to split them any longer. That is why it is objectively suggested not to use joins if there is a chance that the project will be scaled to handle the load.
3. Use cache
The tip to use cache is ideal not only for sharding solutions but for every web application, due to the fact that nearly each of them outputs restarted data. Take for example the most typical case – paper websites. In many cases the variety of the page updates is less than a hundred changes daily, that equates to one upgrade every twenty five minutes. Subsequently, the page stays not changed for a long period of time, but it’s every review calls a few demands to a database to construct an output HTML code. The easiest solution in this case is to conserve the outcome page in cache until it is changed in future.
Lets go further. When it comes to a scalable application, it is typically the case that you have to merge a lot of data from various databases. For example, it is normally about the wall of buddies’ updates. The algorithm is to repeat between all the buddies user has and to collect all the most current updates they did. This task generally requires to link and request every each database in the list, which might cause issues in a high crammed environment. The very best solution here would be caching the result of the combine and to work out the condition when the cached outcome has actually to be flushed and updated.
It is not suggested to count on the luck, believing that “when we have lots of users we will do caching”, because the issue usually exposes itself unexpectedly in the weekend’s evening (that is not a joke, since the majority of the time it is the peak of usage) when the response time might be fairly long. Additionally, if you have not seen the health problem when it had begun to believe hard, then you would most likely find the servers turned off due to the fact that of the load excess.
4. Inspect if the load is correctly stabilized
Frankly speaking, this kind of concerns continues to be the most dangerous problem for your simple servant even at present time. Although it is certainly that the objective of scalable application is to divide the load between servers, the most devastating and typical mistake is that it is refrained from doing appropriately.
Lets consider example an interesting case which is associated to an unnamed online social game. All the games hosted on a social media network website has its mechanism to communicate with your good friends, and typically it includes a forced top-level friend who is managed by a server and provides some sort of help to a player (in the developers’ circle of contacts we call it “a super-friend”). If we think of the video game as a simulator of farming, then this super-friend has its own home location, a house, and we should examine it through clicking on a pal’s badge. Generally, on a server side the super-friend technically is a common user and it is kept and operating identically as everyone else. Following these ideas, it is quickly understandable, that if somebody wishes to take a look on its farm, then the request for a user’s data goes to the single server keeping the super-friend. As a result, having a super-friend who is revealed to every player and recommending gamers visiting its farm lead us to an unbalanced model, where this just server has multiply time much load than others.
The solution to this problem is evident: aim to avoid this sort of out of balance situations beforehand (when a single object is accessible far more than the others) or execute caching of often asked for items.
5. Think about multitasking
When it concerns a PHP scalable application, the term “scalable” not just describes a database. When the variety of requests is fairly high, it is important to set up another frontend/backend server to handle the load. Usually, when it pertains to enthusiastic jobs, it is done prior to a release. Lets see another example from reality experience.
Simply envision you execute the hotel booking system for all the hotels in your town. It is normally the case that there is the just one space stays vacant and there are 2 men who want to buy out the space. They are pressing the button “buy” at the same time and these two demands go to different servers in your set of backend servers. In many cases, the algorithm of booking a space is as follow: check if its uninhabited -> check if user has cash -> withdraw the cash from its account -> mark the space as reserved. In this circumstance, the most typical issue is about absence of locking a room reserving deal or about locking it AFTER checking its state. There is a possibility that these requests will be processed at the same time and the check of the room’s accessibility will give a positive response to both users. What will happen next depends upon an algorithm: there might be an error while marking a space as reserved (although money is taken) or a confirmation of reserving to both of them. Frankly speaking, I would not want to be the hotel’s manager if the 2nd case is taken place.
Because case, it is evident that executing of deal locking is needed. However, there are a great deal of various cases, when it is not so clear at the very first look.
Summary
As a conclusion, it is essential to point out that nowadays PHP continues to be not very ideal for scaling and sharding, since it does not have integrated mechanisms and a single technique to a problem. Even though, having enough experience gives one possibility to develop complex and colossal systems using among the most easiest programming language in the world.
Source: LinkedIn Pulse
