如何管理数百万的用户?


17

我即将推出一个非常大的东西。我需要准备服务器和数据库。

我想将每组100,000个用户的组分别放在单独的用户表中,但是我不知道如何关联试图登录到相应用户表的一个用户。

例如,我怎么知道该用户jay@mail.com与用户表#36相关?

在一个用户表中拥有1000万用户还是在100,000中有100个用户会是一样的?

Facebook怎么样?我不敢相信他们会拥有一个包含9.5亿个条目的全局用户表。


I can't believe they would have one global user table with 950 million entries.我可以,它没有那么大。我曾使用较大的桌子。它很常见。如果您还有许多其他数据,我会考虑的另一个选择是NoSQL数据库。
NimChimpsky

5
如果您打算拥有大量用户和大量数据,则需要聘请数据库专家来进行设计。我不会看那些没有至少十年数据库经验和至少五年大型数据库设计经验的人。这是一个复杂的子喷射器,需要广泛的知识。
HLGEM 2012年

Answers:


30

明天您将不会有十亿用户,MySQL可以毫无问题地处理几百万行。我的用户表中有500万用户,请相信我,这甚至不在我担心的范围之内。

需要分片之前,不必担心分片。您正在尝试针对可能存在或可能从未存在的问题过早地进行优化,并且在此过程中,您将严重削弱创新的速度。迅速启动并发现问题。您无法预先预测扩展挑战。

当您达到这种规模时,您将有大量的金钱和资源来解决这种问题。


4
Be fast to launch and find the problems as they come这部分很棒。确实如此。如果我们发现问题,以后再也不会有什么大问题了。+1
ALH

16

如果您要处理非常大的数据集并且需要从头开始,我不确定外部顾问是否会为您的公司提供更好的支持。请不要误会我的意思,但是如果有人搞砸了这么多客户的项目,那将对您的公司产生公关影响。

关于一张表中的10M元组,如果索引良好,那就很好了。我们需要在一个表中存储几个100M元组(已售商品),这在大型Oracle 11g上可以正常工作

这是2010年的贴子,上面有facebook db design的地图:Facebook数据库设计

您可能需要阅读有关分区类型的mysql文档:MySQL文档:Partinioning

MySQL支持以下类型:

范围分区。这种类型的分区根据列值在给定范围内将行分配给分区。请参见第18.2.1节“ RANGE分区”。

列表分区。类似于通过RANGE进行分区,不同之处在于,基于匹配一组离散值之一的列选择分区。请参见第18.2.2节“列表分区”。

HASH分区。使用这种类型的分区,将根据由用户定义的表达式返回的值来选择一个分区,该表达式将对要插入表中的行中的列值进行操作。该函数可以包含在MySQL中有效的任何产生非负整数值的表达式。也可以使用这种类型的扩展名LINEAR HASH。请参见第18.2.3节“ HASH分区”。

密钥分区。这种类型的分区类似于通过HASH进行的分区,除了仅提供一个或多个要评估的列,并且MySQL服务器提供了自己的哈希函数。这些列可以包含非整数值,因为MySQL提供的哈希函数可以保证整数结果,而与列数据类型无关。此类型的扩展名LINEAR KEY也可用。请参见第18.2.4节“密钥分区”。


7

首先,不要将用户分成单独的表。它将使事情变得复杂而毫无意义。像MySQL这样的数据库和其他数据库可以与同一表中数百万条记录的数据库一起使用,而不会出现任何问题(设置了正确的PRIMARY KEYS)。为每个用户(在主用户表中)使用数据库AUTO_INCREMENT AND PRIMARY唯一键字段,因此每个记录都是唯一的(UID)。然后,在其他表中,您使用该唯一ID进行引用。然后确保在每个表中都将其设置为PRIMARY KEY,这将加快数据库服务器中信息的处理速度。您可以从Drupal CMS了解它如何存储用户信息。经过数百万用户和大型公司(大型媒体公司,政府,甚至世界上最大的银行使用)的十多年的测试。在www.drupal。org,您会发现在同一张表中存储了超过1,600万个页面(节点),并且每月有超过一百万的唯一访问者,并且该网站正常运行。一切都与正确的优化和配置有关。

经过一千万条记录后,如果您对性能不满意(经过适当的优化和数据库配置更改后),则可以决定是否真的要通过不同的表将用户分开。因此,您实际上可以通过添加新表来扩展功能,该表包含有关用户记录的保存位置的信息:UID和table_name。然后在其他任何表中请求这些信息,该表将寻找合适的表。但我确实建议您为用户提供一张大桌子,除非您有10亿至1亿条记录。但这并不能提高性能(数据库旨在处理海量数据)。最好使信息保持简单。通常,公司只是决定要另外一个数据库服务器(主服务器和从服务器),然后再决定 与负载平衡功能一起工作。如果您拥有这1000万用户,则可以购买另一台数据库服务器,对吗?

请参阅user.install文件中的user表架构示例。


3

正如其他答案所建议的那样,将用户分成多个表不是一个好主意。大多数在userid上具有索引的数据库可以处理百万行。但是,每个查询的延迟可能会增加,具体取决于索引中条目的总数。只要数据集很小,就可以使用普通数据库中的单个表进行管理。

如果您的记录增长超过一百万左右,我将尝试提出不同的想法,供您将来考虑。拥有如此众多的客户,您不希望有任何停机时间。因此,您可能需要查看大量nosql数据库。他们将为您执行分片,而不是您自己从应用程序管理分片。它们还将提供数据冗余,从而增加正常运行时间。Facebook和所有人都大量使用memcache等作为其缓存。但是我不确定他们将其用作永久存储。

您应该注意的一件事是您不能使用nosql数据库进行联接等。因此,为您的用例进行规划并做出决定。如果需要联接和多记录事务,则nosql数据库不适合您。


-3

为什么不根据字母范围划分?如果您将拥有数百万的用户,则为每个字母或一对字母创建一个单独的表(表'a'用于用户名以'a'开头的用户)。起初会有很多开销,但是由于您期望使用大型数据库,并且希望能够区分应针对特定用户使用的表-我想字母顺序是最明显和最简单的选择。


9
这是一个超级坏主意。例如,如果用户更改姓氏,则您的软件将必须自动迁移行。...除非您不再关心一致性。这种策略会引发此类意外事件。
randomx 2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.