问题标签 [sharding]

在 Rails 中处理分片数据库的最佳方法是什么？分片应该在应用层、活动记录层、数据库驱动层、代理层还是其他什么地方处理？各自的优缺点是什么？

我们有一个大约 70 GB 的 InnoDB 数据库，我们预计它会在未来 2 到 3 年内增长到数百 GB。大约 60% 的数据属于单个表。目前数据库运行良好，因为我们有一个 64 GB RAM 的服务器，所以几乎整个数据库都可以放入内存，但我们担心未来数据量会变得相当大。现在我们正在考虑某种拆分表格的方法（尤其是占数据最大部分的表格），我现在想知道，最好的方法是什么。

我目前知道的选项是

• 使用 5.1 版附带的 MySQL 分区
• 使用某种封装数据分区的第三方库（如休眠分片）
• 在我们的应用程序中自己实现它

我们的应用程序建立在 J2EE 和 EJB 2.1 之上（希望有一天我们会切换到 EJB 3）。

你有什么建议？

编辑（2011-02-11）：
只是一个更新：目前数据库的大小是 380 GB，我们的“大”表的数据大小是 220 GB，它的索引大小是 36 GB。因此，虽然整个表不再适合内存，但索引却可以。
系统仍然运行良好（仍然在相同的硬件上），我们仍在考虑对数据进行分区。

编辑（2014-06-04）：另一个更新：整个数据库的大小是 1.5 TB，我们的“大”表的大小是 1.1 TB。我们将服务器升级到具有 128 GB RAM 的 4 处理器机器（Intel Xeon E7450）。该系统仍然运行良好。我们接下来计划做的是将我们的大表放在单独的数据库服务器上（我们已经在软件中进行了必要的更改），同时升级到具有 256 GB RAM 的新硬件。

这种设置应该持续两年。然后我们要么必须最终开始实施分片解决方案，要么只购买具有 1 TB RAM 的服务器，这应该会让我们持续一段时间。

编辑（2016-01-18）：

从那以后，我们将我们的大表放在单独服务器上的它自己的数据库中。目前，这个数据库的大小约为 1.9 TB，另一个数据库（除了“大”表之外的所有表）的大小为 1.1 TB。

当前硬件设置：

• HP ProLiant DL 580
• 4 x Intel(R) Xeon(R) CPU E7-4830
• 256 GB 内存

此设置的性能很好。

关于解决大型网站的扩展问题，我曾多次听到“分片”技术。这是什么“碎片”技术，为什么这么好？

我正在开发一个介于电子邮件服务和社交网络之间的网络应用程序。我觉得它有潜力在未来变得非常大，所以我担心可扩展性。

我决定为每个活动用户创建一个单独的 SQLite 数据库，而不是使用一个集中式 MySQL/InnoDB 数据库，然后在那个时候对其进行分区：每个“分片”一个活动用户。

这样备份数据库就像每天一次将每个用户的小型数据库文件复制到远程位置一样简单。

扩大规模就像添加额外的硬盘来存储新文件一样简单。

当应用程序超出单个服务器时，我可以使用 GlusterFS 在文件系统级别将服务器链接在一起并保持不变地运行应用程序，或者安装一个简单的 SQLite 代理系统，允许每个服务器操作相邻服务器中的 sqlite 文件。

并发问题将是最小的，因为每个 HTTP 请求一次只会触及一个或两个数据库文件，在数千个中，而且 SQLite 无论如何只会阻塞读取。

我敢打赌，这种方法将使我的应用程序能够优雅地扩展并支持许多很酷和独特的功能。我赌错了吗？我错过了什么吗？

更新我决定采用一个不太极端的解决方案，到目前为止效果很好。我正在使用固定数量的分片 - 准确地说是 256 个 sqlite 数据库。每个用户都通过一个简单的散列函数分配并绑定到一个随机分片。

我的应用程序的大多数功能只需要每个请求访问一到两个分片，但有一个特别需要对 256 个分片中的 10 到 100 个不同的分片执行简单查询，具体取决于用户。测试表明，如果所有数据都缓存在 RAM 中，大约需要 0.02 秒或更短的时间。我想我可以忍受它！

更新 2.0我将应用程序移植到 MySQL/InnoDB 并且能够获得与常规请求大致相同的性能，但是对于需要分片遍历的请求，innodb 快 4-5 倍。出于这个原因，以及其他原因，我放弃了这个架构，但我希望有人能在某个地方找到它的用途......谢谢。

精简版

如果我将用户分成碎片，我如何提供“用户搜索”？显然，我不希望每次搜索都击中每个碎片。

长版

通过分片，我的意思是有多个数据库，每个数据库都包含总数据的一小部分。对于（一个天真的）示例，数据库 UserA、UserB 等可能包含名称以“A”、“B”等开头的用户。当一个新用户注册时，我简单地检查他的名字并将他放入正确的数据库。当返回的用户登录时，我会再次查看他的姓名以确定从中提取信息的正确数据库。

分片与读取复制的优势在于读取复制不会扩展您的写入。所有发送到主服务器的写入都必须发送到每个从服务器。从某种意义上说，它们都承载相同的写入负载，即使读取负载是分布式的。

同时，分片不关心彼此的写入。如果 Brian 在 UserB 分片上注册，则 UserA 分片不需要听到它。如果 Brian 向 Alex 发送消息，我可以在 UserA 和 UserB 分片上记录该事实。这样，当 Alex 或 Brian 登录时，他可以从自己的分片中检索所有发送和接收的消息，而无需查询所有分片。

到目前为止，一切都很好。搜索呢？在此示例中，如果 Brian 搜索“Alex”，我可以检查 UserA。但是，如果他用姓氏“史密斯”搜索亚历克斯呢？每个碎片都有史密斯。从这里，我看到两个选项：

1. 让应用程序在每个分片上搜索 Smiths。这可以缓慢（连续查询每个分片）或快速（并行查询每个分片）完成，但无论哪种方式，每个分片都需要参与每次搜索。就像读取复制不会扩展写入一样，搜索命中每个分片也不会扩展您的搜索。您可能会遇到搜索量高到足以压倒每个分片的时间，而添加分片对您没有帮助，因为它们都获得相同的量。
2. 某种本身可以容忍分片的索引。例如，假设我要搜索的字段数量恒定：名字和姓氏。除了 UserA、UserB 等之外，我还有 IndexA、IndexB 等。当新用户注册时，我会将他附加到我希望找到他的每个索引上。所以我把 Alex Smith 放到 IndexA 和 IndexS 中，他可以在 "Alex" 或 "Smith" 上找到，但没有子字符串。通过这种方式，您不需要查询每个分片，因此搜索可能是可扩展的。

那么搜索可以缩放吗？如果是这样，这种索引方法是否正确？还有其他的吗？

我正在使用遇到可伸缩性问题的数据库模式。架构中的一个表已增长到大约 1000 万行，我正在探索分片和分区选项，以允许此架构扩展到更大的数据集（例如，10 亿到 1000 亿行）。我们的应用程序还必须可部署到多个数据库产品上，包括但不限于 Oracle、MS SQL Server 和 MySQL。

一般来说，这是一个大问题，我想了解一下可用的选项。数据库分片和分区策略有哪些资源（书籍、白皮书、网站）？

这个问题说明了一切。

示例：我打算对数据库表进行分片。该表包含标记为“活动”、“完成”和“已删除”的客户订单。我也有三个碎片，每个标志一个。

据我了解，当更改标志时，必须将一行移动到正确的分片。

我对吗？最好的方法是什么？可以使用触发器吗？

我考虑过不立即移动该行，而只是在一天/周/月结束时，但随后不确定，具有特定标志的行驻留在哪个分片中，并且必须始终对所有分片进行搜索。

编辑：一些澄清：

一般来说，我必须选择一个标准来决定一行所在的分片。在这种情况下，我希望它成为上面描述的标志，因为这是对此类数据进行分片的最自然方式。（在我看来）只有有限数量的活跃​​订单经常被访问。有大量已完成的订单，很少被访问，并且有非常大量的数据行几乎从未被访问过。

如果我想现在特定数据行所在的位置，我不必搜索所有分片。如果用户想要加载一个活动订单，我已经知道我必须查看哪个数据库。

现在，作为我的分片标准的标志发生了变化，我想知道处理这种情况的最佳方法。如果我只是将记录保留在其原始数据库中，最终所有数据都会累积在一个表中。

我的 webapp 需要使用多个数据库分片，并且偶尔需要并行查询这些分片。是否有任何 Web 脚本语言对并行非阻塞数据库访问具有成熟、稳定的支持？如果是这样，你能指出我正确的方向吗？免费的开源是首选，但我主要想要一些可以工作的东西。

线程对我来说很好，但我不需要真正的多线程支持。我想要的只是对五个不同的数据库服务器进行五个 10 秒的数据库查询需要 10 秒而不是 50 秒。它实际使用了多少 CPU 对我来说并不重要。

我正在考虑在 ASP.NET MVC 中编写一个博客托管应用程序。我是 .NET 的新手，但我在 LAMP 世界中相当称职。我的问题涉及用户数据的水平缩放。

每个拥有博客的用户在数据库中都会有 6 个表。我想规划水平扩展，以便 20% 的用户可以在一个数据库服务器上，20% 在另一个数据库服务器上，等等。在 LAMP 世界中，我有一个“字典”表，我首先要查询找出用户在哪个数据库服务器上。然后该应用程序将只与该特定数据库服务器通信。

我看不到如何轻松地对 SqlMembershipProvider 使用的数据库进行分片。有小费吗？

我正在开发一个网站，一开始会有三个明确的子网站：论坛、新闻和日历。

每个子站点都有自己的数据库，所有这些数据库的共同点是一个用户表，该表需要在每个数据库中，以便可以完成连接。

如何同步所有用户表，以便在哪个数据库中进行更新无关紧要，所有数据库都将具有相同的用户表。

我不担心是否存在短暂的同步延迟（小于 1 分钟），我希望解决方案尽可能简单。