http://daihaixiang.blog.163.com/blog/static/3830134201111155381735/
If a website to the millions user volume, then I have to worship the site and the website operator, because the operation of such a website has been the author's dream: Well, return to the point, if such a system put you in front, let you design a station letter mass database, you should go, in short, The above two conventional approaches will certainly not work, because the huge amount of data can make the message table explode, even if your partition is useless. At this time as a system architect you, may not only from the technical point of view to consider this issue, but also from the user's actual situation to start to find solutions to the problem. Here, there is a concept called "active users", that is, users who are often logged into the site, compared to those who are on impulse to register and then never login, active users loyal to the site is very high, from a commercial point of view, loyal customers enjoy more high-end services.
According to this idea, we will explore a method. Suppose the site has 5 million registered users, of which the active user is 600,000 (this ratio is really good), now we want to send a letter of thanks to all users. Or the above two tables, first of all we can insert a message table in a mass identification of 1 message, here we use the field Sourcemessageid (original message) to identify (-1 for the original mass message itself, the other is the original message ID), so that the bulk of the work has been completed, The user can see the public message. But the user needs to have control of the message, so each user must have a message of their own. To achieve this, we can let the user log on to check whether the original message has been copied, if there is no copy, copy the original message and insert the message table, the bulk is identified as the original message ID, if there is already a copy of the original message, do nothing. In this way, we just need to consume the message space for the 600,000 active users. The specific database is designed as follows:
T_message
1234567 |
Id
bigint
--消息ID
SenderId
bigint
--发送者ID
ReceiverId
bigint
--接收者ID,如果为原始群发消息则为-1
SendTime datetime
--发送时间
ReadFlag tinyint
--已读标志,如果为原始群发消息则统一为0未读
SourceMessageId
bigint
--如果为-1则为原始群发消息,其他则为原始消息id
MessageTextId
bigint
--这里把消息正文内容换成消息正文Id
|
Table T_messagetext is the same as the above method.
Of course, if your active users reach 100%, then this method relative to the previous one has no advantage, but this situation is basically unlikely, so, I think this method to deal with large users of the mass of the message is still feasible.
4. Summary
This article is just about the principle of implementation, a lot of details are ignored without consideration, purely a design idea, interested friends can go to their own practice, in addition, the author of the database is not very proficient, if there is a wrong to explain also please point out, let us progress together.
5, if you like design and architecture, you may also like the following articles
Facebook and Renren's Web site background architecture comparison
Facebook Image Storage Architecture Technology full analysis
Major Website Architecture Summary notes
Build large Web sites in one step
10 Questions to consider for a large web site architecture
Inside the station letter