主页 / server / 问题 / 124396
In Process
Remiz
Asked: 2010-03-20 11:45:37 +0800 CST

MySQL：具有高更新频率的非常大集合的表组织

  • 772

我在选择我的 MySQL 模式应用程序时面临两难境地。所以在我开始之前是一张我的数据库非常简化的图片：

这里的架构：http: //i43.tinypic.com/2wp5lxz.png

一句话：对于每个客户，应用程序收集文本数据并将标签附加到收集的每个数据中。

作为每个表的使用的近似值，这是我所期望的：

  • 客户：~5000，不应该快速增长
  • 数据：每位客户 500 万，大客户可能翻倍或三倍。
  • 标签：〜1000，相当固定的大小
  • data_tag ：每个客户轻松上亿。每个数据都可以标记很多。

收集过程是永久性的，这意味着大约每 15 分钟就会有新数据出现并被标记，这需要非常持续的索引刷新。

我的很多查询都是特定日期之间的 DATA SELECT COUNT 并用特定 CUSTOMER 上的特定 TAG 标记（很少会涉及多个客户）。

情况就是这样，你可以想象在这种数据量的情况下，我在数据组织和索引方面面临挑战。同样，它是我的结构的一个非常简约和简化的版本。我的问题是，它更好吗：

  1. 坚持这个模型并管理疯狂的索引优化？（这涉及 data_tag 表中可能有数十亿行）
  2. 更改架构并为每个客户使用一张数据表和一张 data_tag 表？（这涉及在我的数据库中有 5000 个表）

我在复制的 MySQL 5.0 专用服务器（四核，8Go 内存）上运行所有这些。我只使用 InnoDB，我还有另一台运行 Sphinx 的服务器。所以知道这一切，我迫不及待地想听听你对此的看法。

谢谢。

编辑

感谢您的回答，我意识到这个数字有多疯狂。所以这里是更新的更现实的表格用法（基于只是一个基本机架空间盒的实际服务器）。

  • 客户：2000（固定）
  • 数据：每个客户 100 万（固定，归档旧数据。而且非常不公平：有些客户有几千，最大的 500 万）
  • 标签：1000（固定）
  • data_tag ：每个客户约 3 或 5 百万（取决于数据，也很不公平）。

谢谢你。

performance mysql scaling indexing

3 个回答

  1. 根据我多年使用 MySQL 的经验，我的 2 美分是您的后一种选择听起来更合乎逻辑和现实。

    与您当前的模式相比，每个客户使用一个 Data 和一个 data_tag 具有更简单的整体可管理性。为您的第二个选项编码也将更简单。

    你可以问更多的 MySQL 专家；你的第二个选择是最好的。

    如果您愿意，我可以详细介绍，这是对大问题的简化问题的简单答案。它是双向的

    • 2

  2. 除了您在此处放置的内容之外，如果不了解您的应用程序的全部内容，则很难说。您的数据模型非常简单，正如您所期望的那样，这对您有利，实际上是数十亿行。我会避免创建超过 5k 个表，因为如果您尝试这样做，您可能会遇到文件描述符问题和缓存限制。

    当然，您可能可以 ulimit/configure 它们离开，它仍然不是最佳配置。

    您是否也在为非关键数据创建索引？例如，这些名称列？这可能会降低您的写入性能，以便备份 15 分钟的批处理作业。

    老实说，如果这是我的应用程序，我会考虑两种可能的解决方案：

    1. 如果性能成为问题，请使用您现在拥有的并将客户拆分到多个 MySQL 服务器之间。除非您有这些数据并且这些客户排队，否则这还不是问题。不要花太多时间来设计“假设”。坚持简单的模式并将您的第一组用户介绍给第一台服务器。当您开始达到容量时，请引入第二台服务器并将这些新用户隔离到该数据库。分片，可以这么说。使用资源监控和良好的管理技术对其进行备份，以便您知道“满负荷”线何时接近。

    2. 像 Cassandra 或 MongoDB 这样的东西会起作用吗？我对您的查询知之甚少，无法提出建议或排除。MongoDB 可能是一个选择。值得一试。

    所以，我想简而言之，让 MySQL 做它擅长的事情，只运行更多它们。或者，如果可能的话，看看像 Mongo 这样的东西。

    • 1

  3. 嗯，根据我的经验——你确定 MySQL 是最好的数据库吗？尝试查看 Oracle 或 SQL Server（尽管 oracle 集群在这里可能有优势）？

    如果您认为许可成本会杀死您，我只想说您还不知道运行它需要什么硬件。一旦您获得所需的 SAN 的第一个报价 - 您可能会嘲笑相应软件的价格。

    只是一个想法。

    • 客户 - 假设是 10.000，因为您表示它会快速增长。
    • 数据 - 让我们假设一个普通客户有 700 万。数据表已经有 700 亿行。是的，抱歉，4 个零确实加起来了。
    • 如果每个数据有 10 个标签（您没有指明任何内容），我们将密切讨论 data_tag 字段的 7000 亿行。

    变得更疯狂。

    • 如果 DataTag 没有索引并且没有开销（它有），则 data:tag 是每个条目 10 个字节 - tag_id 有 2 个字节（65536 就足够了），遗憾的是 data_id 有 8 个字节 - 你不能在 4 个字节中处理 7000 亿个条目。这总共有大约 7800 GB 的原始数据（700.000.000.000 * 12 / 1024 / 1024 / 1024）。索引可能会加倍。

    为了有效地处理，这是一个高端 SAN。我们在这里不谈论“10 个磁盘”，我们谈论一个可能有 400 个向上磁盘的高端 SAN，以处理所有这些数据 - 不要忘记到目前为止我们还没有任何索引。

    我在复制的 MySQL 5.0 专用服务器（四核，8Go 内存）上运行所有这些。

    不错的尝试。那到底有什么用？抱歉问，但 8gb RAM 不会真正有帮助（这里没有留下深刻印象），去买一台 256gb 的机器......这可能需要 AMD 和其中一个非常昂贵的 Opteron 8000。但你需要 RAM。

    无论如何，这将是（我怀疑你是否正确地代表了事实）世界上最大的数据库安装之一。

    你肯定想要一些可以处理这个问题的东西——如果你真的必须这样做，Oracle 集群或 SQL Server 集群可能会加快这个速度。这比免费数据库甚至可以想到的处理方式要好得多。真的。

    而且您需要适当的备份程序（MySQL 缺乏）。您也可能喜欢 SQL Serve 2008 数据页压缩，它可以将磁盘上的数据大小减少约 50%。不仅是为了节省磁盘成本，而且因为这意味着更少的 IO - 这在这里直接转化为更高的性能（因为您不能将表缓存在内存中）。

    尽管我不想这么说，但您可能还想考虑在一个不错的大型机上使用 IBM DB2——我并不是说在其上运行 Linux VM。由于硬件架构，VMS 非常适合处理超大规模数据库。不要问价格；）

    • 1

相关问题