如何管理百万用户?

18 mysql users

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

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

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

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

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

Aar*_*own 31

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

不要担心分片,直到你要这样做。您试图过早地针对可能存在或可能不存在的问题进行优化,在此过程中,您将严重削弱创新的速度。快速启动并发现问题。您无法提前预测您的扩展挑战将是什么。

当你达到这个规模时,如果你达到这个规模,你就会有相当多的资金和资源来解决这种问题。

  • `快速启动并发现问题`这部分非常好。确实如此。如果我们发现问题,那么以后就不会有任何严重的问题。+1 (4认同)

小智 16

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

关于一张表中的 10M 元组,如果您有良好的索引就可以了。我们需要在这里的一张表中存储几个 100M 元组(已售出的物品),这在大型 oracle 11g 上运行良好

这是 2010 年发布的带有 facebooks db design 地图的帖子:Facebook 数据库设计

您可能需要阅读有关分区类型的 mysql 文档,如下所示:MySQL 文档:分区

MySQL 支持以下类型:

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

LIST分区。类似于按 RANGE 分区,不同之处在于分区是基于与一组离散值中的一个匹配的列来选择的。请参见第 18.2.2 节,“LIST 分区”。

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

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


ken*_*orb 7

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

在 1000 万条记录之后,如果您对性能不满意(经过适当的优化和 db 配置更改后),那么您可以决定是否真的要通过不同的表来分隔用户。因此,您实际上可以通过添加包含用户记录保存位置信息的新表来扩展功能:UID 和 table_name。然后在任何其他表中请求这些信息,这个表会寻找合适的表。但我真的建议你为用户准备一张大表,除非你有超过 10-1 亿条记录。但它不会提高性能(数据库旨在处理海量数据)。最好保持信息简单。通常公司只是决定另一个数据库服务器(主和从),然后另一个,然后他们' 重新与负载平衡功能一起工作。如果您拥有那 1000 万用户,您可以为另一台数据库服务器付费,对吗?

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


小智 -3

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

  • 这是一个非常糟糕的主意。例如,如果用户更改姓氏,您的软件将必须自动迁移行......除非您不再关心一致性。这种策略会引发这些类型的意外事件。 (9认同)