Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you an overall analysis of the structure of the database. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

We seldom talk about architecture, mainly because it is indeed an area that requires a high level of knowledge and depth of knowledge, whether it is the choice of development language, the architecture of the code, the collocation of the server, the architecture of the network, the architecture of the database or the selection of third-party software, etc., each aspect is a great direction, and each direction is worth studying for a lifetime. Whenever I see someone like the chief architect of a so-and-so website (but many are spongy), I always feel that that is the ultimate goal of people who are willing to do technology, and there is always a sense of admiration.

Limited to the limitations of work and knowledge, as well as the attitude of being responsible to all friends, the architecture discussed in this article is limited to the database, and is based on the SQLserver database, so as not to mislead you.

SQLServer

After years of development, SQLServer has a lot of good technologies to use, such as Replication, SSB, Cluster, Mirroring, etc. (you can refer to my technical knowledge in SQLServerDBA 30 and SQLServer high availability, high performance and high protection extension), and these technologies have been recognized by the market in terms of reliability. There are many companies in order to improve the reliability, security and efficiency of their programs more or less use some of these technologies, the following I have come into contact with the application of these technologies, mainly aimed at the website this kind of traffic is very large, read more and write less application, do some discussion on the database architecture, hope to be helpful to you, if there is something wrong, welcome to correct and communicate.

Issues to consider for database architecture:

Data reliability and consistency

Data disaster recovery

When the amount of data and access pressure increases, it is easy to expand.

Highly available, timely recovery in case of problems, no single point of failure

There should not be a sharp decline in the performance of the whole network because of a problem with one machine.

Convenient maintenance

A description of the following architecture:

The core server uses Cluster, and SSD is used as disk array (SSD can store data such as index).

The data changes of the core server are distributed to two Replication hosts through SSB (this step can be roughed first, processed into a data form that is convenient for users to query, and then distributed through SSB packaging). Two SSB distributors are used, which can not only share the pressure, but also achieve no single point of failure. SSB can be used to ensure that the data of the core database is consistent with that of the Replication host. Of course, this step can also be achieved directly using Replication, but the pressure on the core server will increase.

Next, the data of the Replication host is distributed to the three subscribers, that is, the QUERYDB server, through the distributor.

Six QUERYDB control access through F5, while adding a MemoryCache server in the previous section to increase cache and reduce query pressure (in this part, many companies use search engine technology to generate data in the database into XML files, and then use index files to find data)

The function of B3 and B4 SSB is to forward SSB messages from QUERYDB to core server. What is the use of sending SSB messages from QUERYDB to core server as well as from core server to QUERYDB;? It is very useful, because there is only one core server. If we concentrate all the operations of the website on the core server, then during the peak period of business, the data changes very frequently, and the pressure on the core server must be very great, which may not be able to resist. In order to prevent such problems, we are bound to share some of the pressure, so we can first put the operations in the QUERYDB when users register, place orders, and so on. Then send the message to the core server through SSB. After receiving the SSB message, the core server will first put it in the queue and then process it one by one, so that the core server will not crash because it processes too many requests at the same time. At the same time, after the core server processes the information, it will distribute the changes of these data to each QUERYDB through Replication, so that the QUERYDB data will still be consistent with the core server. It realizes the effect of recording the operation through QUERYDB, and then using SSB technology to divide the pressure. Because there are six QUERYDB (and can be expanded), the SSB pressure on the QUERYDB is dispersed, so it will not put much pressure on the QUERYDB (there may be a small delay in the message, so you should try to use the optical network on the SSB channel). Even if the core server crashes, you can still query data, register and place orders, and SSB will always retain the message.

The above is the editor for you to share how to carry out the overall analysis of the structure of the database, if you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.