blocks|key|1323673|text|如果您计划处理大量数据(当然，数百万甚至都不符合大型数据的标准)，那么请聘请一位数据库专业人员。针对大型数据集的高效和有效的数据库设计是一个复杂的问题，需要专家。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1323674|回答你的问题是，如果设计良好，mysql可以轻松处理数百万条记录，如果设计不好，将是一场噩梦，就像任何其他现代数据库一样。|1323675|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you are planning to handle large amounts of data (of course millions doesn't even come close to qualifying as large), then hire a datbase professional. Efficient and effective database design for large data sets is a complex issue and requires a specialist.

In answer to your question yes mysql can handle millions of records easily if the design is good and will be a nightmare if the design is bad, pretty much like any other modern datbase.

blocks|key|1108682|text|只要您将表设置为关系表，并设置表之间的关系，MySQL就可以了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1108683|我也可以推荐Postgres吗？|1108684|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

As long as you setup your tables to be relational and set the relationships between tables, MySQL should be fine.

Might I also suggest Postgres?

blocks|key|1108761|text|脸书是从MySQL开始的，只有当他们拥有超过1亿用户的7TB收件箱数据时，他们才转移到Cassandra。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1108762|来源：Lakshman,+Malik:+Cassandra+-+A+Decentralized+Structured+Storage+System。|1108763|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Cassandra_(database)|1|http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf^0|17|9|0|0|3|1Y|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

Facebook started with MySQL and they only moved to <a href="http://en.wikipedia.org/wiki/Cassandra_(database)" rel="noreferrer">Cassandra</a> when they had 7TB of inbox data for over 100 million users. 

Source: <a href="http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf" rel="noreferrer">Lakshman, Malik: Cassandra - A Decentralized Structured Storage System</a>.

blocks|key|1108836|text|如果你有预算，可以从MySQL开始，使用像Zend::DB这样的系统或者更高级别的Doctrine。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1108837|更重要的是让切换数据库变得容易，而不是一开始就选择数据库管理系统。|1108838|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you are on a budget, start with MySQL and use a system like Zend::DB or on a higher level Doctrine.

It's more important to make it easy to switch DMBS then to choose your DBMS at the beginning.

blocks|key|1108934|text|只要您正确地设计数据库，MySQL就不会有数百万或数亿条记录的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1108935|话虽如此，“像Facebook这样的消息功能”是一个相当宽泛的定义。通常，您将定义一个将每封邮件链接到创建它的用户的messages表(即，在messages表中有一个userId列)。如果希望将消息发送给多个用户，可以使用一个message_recipients表，通过存储由messageId和recipientId组成的多个记录来定义一对多关系。将适当的索引添加到这些表中，您就完成了80%25的工作。|offset|length|style|CODE|1108936|话虽如此，剩下的20%25可能是一个杀手。不幸的是，您如何使用数据库将决定您还需要做什么，并且在做出这些判断之前，您必须提供有关应用程序的更多详细信息。例如，您可能希望考虑使用自动归档解决方案，使主表相对较小，并在必要时将旧数据移动到可以访问的备份表中。您可能不会立即需要它，但它在未来可能会有所帮助。|1108937|entityMap^0|0|1M|8|2C|6|36|I|3V|9|45|B|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]|$D|T|E|U|F|G]|$D|V|E|W|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|X|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$]]

MySQL has no problem with millions or hundreds of millions of records as long as you design you database correctly.

That being said, a "messages feature like Facebook" is a pretty broad definition. Generally, you would define a <code>messages</code> table that links each message to the user that created it (ie, have a <code>userId</code> column in the messages table). If you want messages to go to multiple users, you have a <code>message_recipients</code> table defining the 1-to-many relationship by storing multiple records consisting of the <code>messageId</code> and a <code>recipientId</code>. Add the proper indexes to these tables and you're 80% of the way there. 

That being said, that remaining 20% can be a killer. Unfortunately, how you use your database is going to determine what else you need to do, and you'd have to provide a lot more detail about your application before those judgments can be made. For example, you might wish to consider having auto-archiving solution which keeps the main table relatively small, and moves old data to backup tables that can be accessed if necessary. You probably won't need this right away, but it could help in the future.

blocks|key|1108997|text|对于你“广泛”的需求，分片当然不是必须的……我处理过大量的数据，甚至没有考虑过分区表和分片的实现，直到有大量的表容纳了超过十亿条记录(然后连接这些表可能会变得有点慢)。使用智能键为表建立索引，您甚至可以考虑使用eav类型的结构来缩小表的范围，避免查询时返回空值。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1108998|上面是在半睡半醒的时候写的，所以忽略打字错误;)|1108999|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Sharding is certainly not necessary for your "broadly" based requirements...I have dealt with a fair amount of data and didn't even consider partitioned tables and shard implementation until there were numerous tables housing over a billion records (then joining those could get a little slow). Index your tables with smart keys, and you may even consider using an eav type structure to keep the tables narrow and relieve yourself of null returns on queries.

Above was written while half asleep so ignore typos ;)

blocks|key|1109059|text|如果您的意思是“我的mysql表对于消息系统应该是什么样子的”，我在消息系统中使用以下列：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109060|message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread|code-block|syntax|javascript|1109061|显然，Message_id就是auto_increment。Fromuser和touser是显而易见的。Fromstatus和tostatus为active、deleted、purge、draft等。Fromview和toview被设置为'yes‘和'no’。标题、文本和“poston”日期很明显。根据您的html表单和消息显示脚本的不同，线程可能需要您做一些工作。|1109062|对于表单，基于"to:“字段创建一个foreach循环，并为每个收件人保存一份副本。|1109063|我希望这个消息系统能容纳数百万人，但这可能是几年后的事。我会保持它的小巧和简单。|1109064|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|R|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

If you mean "what should my mysql table look like for a message system", I use the following columns in my message system:

<pre><code>message_id
fromuser
fromview
fromstatus
touser
toview
tostatus
title
text
poston
thread
</code></pre>

Message_id is auto_increment, obviously. Fromuser and touser are obvious. Fromstatus and tostatus is active, deleted, purge, draft, and likewise. Fromview and toview are set to 'yes' and 'no'. Title, text, and 'poston' date are obvious. Thread might take a little effort on your part depending on your html forms and message display scripts.

For your form, create a foreach loop based on the "to:" field and save a copy for each recipient.

I expect this message system to hold millions, but that millions is probably a couple of years away. I'm keeping it small and simple.

blocks|key|1109136|text|我要说的是阅读面向对象的数据库以及nosql系统，这是一个非常有趣的概念，被著名的框架如Ruby+on+rails积极使用，它允许您减少对数据的担忧，因为您可以简单地将对象直接转储到数据库中，我知道这有点离题，但较简单的数据库意味着更容易过渡到可伸缩的系统，我只是在传播意识|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1109137|然而，权衡的是，没有像关系数据库那样强大的用户基础，这使得在进行过程中更难找到问题的答案，并且需要同样长的时间来适应使用它，但是在编写业务逻辑的每个阶段都包含数据而不考虑数据库设计是一件令人惊叹的事情，并加快了您的开发时间，然而，稍后当您面临瓶颈和性能问题时，它将更难解决，因为周围的帮助更少。|1109138|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

I'd say read about object oriented databases as well as nosql systems, it is a very interesting concept, actively used by famous frameworks like Ruby on rails, which allows you to worry less about your data, since you can simply dump your object straight into the database, I know it is a little off topic but less complex databases mean easier transition 
into scalable systems, and I'm just spreading awareness

However the tradeoff is, not having an as strong userbase as relational databases, which makes it harder to find answers to problems as you go along, and an equally longer amount of time it takes to adapt into using it, but consisting data without thinking about database design at every stage writing your business logic is an amazing thing to have and quickens your development time, however later on, when you face bottle necks and performance issues it will be harder to solve since there is less help around.

I am currently planning a new system in PHP/MySQL and want to make sure my database can handle the amount of data that I am planning to store. One of the features of my new project is a "messages" feature like Facebook. I want to make sure I create the best possible experience for the end user. The website will eventually handle 1000's of users with potentially millions of messages collectively. What would be the best approach for the database design? Is MySQL even the right database to use?

Database Design for Facebook-like messages

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我目前正在规划一个PHP/MySQL的新系统，并希望确保我的数据库可以处理我计划存储的数据量。我的新项目的一个功能是像Facebook一样的“消息”功能。我想确保我为最终用户创造了尽可能好的体验。该网站最终将处理数以千计的用户，可能有数百万条消息。数据库设计的最佳方法是什么？MySQL甚至是正确的数据库吗？

问类Facebook消息的数据库设计
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问类Facebook消息的数据库设计EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问类Facebook消息的数据库设计
EN