问题标签 [partitioning]

由于分区的 mySQL 数据库目前不支持外键，我想听听一些优点和缺点，用于读取繁重的应用程序，每个表将处理大约 1-400 000 行。不幸的是，我在这方面还没有足够的经验来自己做出结论......

非常感谢！

参考：

分区时如何处理外键

对具有外键的 mySQL 表进行分区？

我正在使用 sybase。我有一个包含大约 200 万条记录的表 A，其中包含一些我想移出并使其成为单独的表 B 的列。我在这个过程中有一些问题...... 1. 我已经决定使用垂直分区。可以吗？2.或者我可以在这个过程中使用什么其他技术？

请在此提供您宝贵的意见。

谢谢。

我有一个包含数百万条记录的表，我们正在研究实现表分区。看着它，我们有一个我们想要分区的外键“GroupID”。这可能吗？

该组将添加更多条目，因此添加新的 GroupID 可以动态创建分区吗？

我们在 oracle 中使用范围分区对年值进行了大量数据分区。我们使用了范围分区，但每个分区只包含一年的数据。当我们编写针对特定年份的查询时，oracle 会从该分区中获取信息，但仍会检查年份是否是我们指定的年份。由于今年列不是索引的一部分，因此它从表中获取年份并进行比较。我们已经看到，每当查询去获取表数据时，它都会变得太慢。

我们能否以某种方式避免 oracle 比较年份值，因为我们肯定知道分区仅包含一年的信息。

更新：

1. 执行分区的年份数据类型为 number 类型。

2. 我们没有选择任何其他列。我只是在执行 acount(*)并且没有选择任何列。

3. 如果我们删除条件并将查询定位到特定分区，因为 select count(*) from table_name partition(part_2004)它更快而 select count(*) from table where year = 2004速度更慢。

4. 分区位于年份列上，该列是一个数字，并执行如下操作

   小于 2005 年部分_2004 年

   比 2006 年少的年份 part_2005

   比 2007 年少的年份 part_2006

...很快

我有一个包含分区表的模式。我可以使用 exp 创建一个 .dmp，但是当我将它导入 Oracle XE 时，我会收到错误，因为 Oracle XE 不支持分区表。

如何将 .dmp 导入 Oracle XE？我认为预先创建表可能会做到这一点，但是如何以某种自动化方式提取 DDL 来做到这一点？

或者我可以在没有分区的情况下以某种方式创建 exp 吗？

我有一个表（innodb），最终将有数十亿条记录。我预计每两周会有大约 50 万条记录被放入表中。我想根据导入数据的日期对该表进行分区-幸运的是，这是表中格式为 yyyy-mm-dd 的字段-是否可以根据此日期列对其进行分区？我尝试查看 mysql 文档的第 18 章，但不知道这是否可行。

在 Mongo 中，我的理解是您可以拥有数据库和集合。我正在开发一个社交类型的应用程序，该应用程序将包含博客和评论（以及其他内容），并且以前使用 MySQL 和相当重的分区以试图限制可能的并发问题。

使用 MySQL，我已将所有用户数据填充到具有多个表的 _user 数据库中，以进一步划分数据（博客、页面等）。

我对 Mongo 的直接反应是创建一个“用户”数据库，每个用户有一个集合。通过这种方式，用户“zach”的博客条目将与相关的评论一起进入“zach”集合，从而成为同一集合中的子对象。基本上就像在 MySQL 中为每个用户动态创建一个表一样，但显然没有可能强加的复杂性和限制。

当然，因为在我无法衡量这个想法的（咳咳……）质量以及它可能导致的潜在问题之前，我还没有真正使用过 Mongo。

我希望用户数据被视为非常像 *nix 环境中的用户目录，其中用户创建/非共享（大部分）被放置在一个地方（目前使用 MySQL，即上面提到的 appname_users）。

大多数用户数据将特定于用户页面。在所有站点用户（可搜索的用户配置文件）中查询的一些用户数据当前保存在单独的数据库/表中，我希望这样的内容可以放入 appname_system 数据库并分解为集合和/或特定于应用程序数据库（appname_profiles）。

无论如何，由于目前可用的文档有点薄，而且我的经验非常有限，我想我可能会从对系统工作有更好理解的人那里找到一些指导。

从好的方面来说，我真的已经在尝试将 MySQL 视为无模式的文档存储，并且使用 Mongo 执行此操作似乎更加直观/理智/合理，所以我真的很期待开始。

谢谢，扎克

如何为庞大的标签系统（如digg或delicious）设计数据存储？

已经有关于它的讨论，但它是关于集中式数据库的。由于数据应该会增长，因此我们迟早需要将数据划分为多个分片。那么，问题就变成了：如何为分区标记系统设计数据存储？

标记系统基本上有3个表：

如果表存储在一个数据库实例中，这对于查找给定标签的所有项目和查找给定项目的所有标签都很好。如果我们需要将数据分区到多个数据库实例中，那就没那么容易了。

对于表Item，我们可以用它的 key item_id对它的内容进行分区。对于表Tag，我们可以用它的 key tag_id来划分它的内容。例如，我们要将表Tag划分为 K 个数据库。我们可以简单地选择数字（tag_id % K）数据库来存储给定的标签。

但是，如何对表TagMapping进行分区？

TagMapping表表示多对多关系。我只能想象有重复。也就是说，TagMappping的相同内容有两个副本。一个用tag_id分区，另一个用item_id分区。在为给定项目查找标签的场景中，我们使用带有tag_id的分区。如果要查找给定标签的项目，我们使用带有item_id的分区。

结果，存在数据冗余。并且，应用程序级别应该保持所有表的一致性。看起来很难。

有没有更好的解决方案来解决这个多对多分区问题？

我正在实现等边双向分区算法的二进制表示，我想知道迭代具有相等（N/2）1 和 0 的 N 位的所有组合的最佳方法是什么。我试图找到最快的方法，而不是最容易编码的方法。谢谢。

在阅读了这篇很棒的Nettuts+ 文章的提示后，我想出了一个表模式，它将高度易变的数据与其他遭受大量读取的表分开，同时减少了整个数据库模式中所需的表数量，但是我'不确定这是否是一个好主意，因为它不遵循规范化规则，我想听听你的建议，这是一般的想法：

我在类表继承结构中建模了四种类型的用户，在主“用户”表中，我存储所有用户共有的数据（id, username, password, 几个flags, ...）以及一些TIMESTAMP字段（date_created, date_updated, date_activated, date_lastLogin, . ..)。

引用上面提到的 Nettuts+ 文章中的提示 #16：

示例 2：您的表中有一个“last_login”字段。每次用户登录网站时它都会更新。但是对表的每次更新都会导致该表的查询缓存被刷新。您可以将该字段放入另一个表中，以尽量减少对用户表的更新。

现在它变得更加棘手，我需要跟踪一些用户统计信息，例如

• 用户个人资料被查看的唯一次数
• 来自特定类型用户的广告被点击的唯一次数
• 特定类型用户的帖子被查看的唯一次数
• 等等...

在我完全规范化的数据库中，这增加了大约 8 到 10 个额外的表，虽然不是很多，但如果可以的话，我想保持简单，所以我想出了以下“ events”表：

基本上是ID指表中的主键（id）字段TABLE，我相信其余的应该很简单。在这个设计中我喜欢的一件事是，我可以跟踪所有用户登录，而不仅仅是最后一个，从而用这些数据生成一些有趣的指标。

由于events表的不断增长的性质，我还考虑进行一些优化，例如：

• #9：由于只有有限数量的表和有限（和预定）数量的事件，可以将TABLEandEVENTS列设置为ENUMs 而不是VARCHARs 以节省一些空间。
• #14 :将 s 存储IP为UNSIGNED INTs而INET_ATON()不是VARCHARs。
• 将 s存储DATE为TIMESTAMPs而不是DATETIMEs。
• 使用ARCHIVE(或CSV? ) 引擎代替InnoDB/ MyISAM。
  • 仅支持INSERTs 和SELECTs，并且动态压缩数据。

总的来说，每个事件只会消耗 14 个（未压缩的）字节，我猜这对我的流量来说是可以的。

优点：

• 能够存储更详细的数据（例如登录）。
• 无需设计（和编写代码）几乎十几个附加表（日期和统计数据）。
• 减少每个表的几列并保持易失性数据分离。

缺点：

• 非关系型（仍然没有 EAV 差）：
  • SELECT * FROM events WHERE id = 2 AND table = 'user' ORDER BY date DESC();
• 每个事件的 6 字节开销（ID和TABLE）EVENT。

我更倾向于采用这种方法，因为优点似乎远大于缺点，但我还是有点不情愿......我错过了什么吗？您对此有何看法？

谢谢！

@coolgeek：

我做的稍有不同的一件事是维护一个 entity_type 表，并在 object_type 列（在您的情况下为“TABLE”列）中使用其 ID。您可能希望对 event_type 表执行相同的操作。

为了清楚起见，您的意思是我应该添加一个附加表来映射表中允许的事件，并在事件表中使用该表的 PK 而不是TABLE/EVENT对？

@本：

这些都是从现有数据中得出的统计数据，不是吗？

附加表主要与统计信息有关，但我的数据尚不存在，一些示例：

如果我删除这些表，我将无法跟踪谁、什么或何时，不确定视图如何在这里提供帮助。

我同意它应该是分开的，但更多的是因为它是根本不同的数据。某人是什么和某人做了什么是两件不同的事情。我认为波动性并不那么重要。

我听说过这两种方式，但我在 MySQL 手册中找不到任何说明任何一种都是正确的。无论如何，我同意你的观点，因为它们代表了各种数据（具有比常规方法更具描述性的额外好处），它们应该是单独的表格。

我认为您可以说是只见树木不见森林。

您的表的谓词将是“从 IP IP 在时间 DATE EVENTed 到 TABLE 的用户 ID”，这似乎是合理的，但存在问题。

我所说的“不如 EAV 差”的意思是所有记录都遵循线性结构，而且它们很容易查询，没有层次结构，所以所有查询都可以用一个简单的SELECT.

关于你的第二个陈述，我认为你在这里理解错了；IP 地址不一定与用户相关联。表结构应如下所示：

IP 地址 ( ) 在日期 ( )对表 ( )的 PK ( IP) 做了一些事情 ( )。EVENTIDTABLEDATE

例如，在我上面示例的最后一行中，它应该显示 IP 217.0.0.1（某个管理员），在 2010-04-20 03:20:00 删除了用户 #2（其最后一个已知 IP 是 127.0.0.2） .

例如，您仍然可以将用户事件加入用户，但您不能实现外键约束。

确实，这是我最关心的问题。但是，我不完全确定这种设计会出现什么问题，而传统的关系设计不会出现问题。我可以发现一些警告，但只要与数据库混淆的应用程序知道它在做什么，我想应该不会有任何问题。

在这个论点中重要的另一件事是我将存储更多的事件，并且每个事件将比原始设计增加一倍以上，在ARCHIVE这里使用存储引擎非常有意义，唯一的事情是它没有支持FKs（既不支持UPDATEs也不支持DELETEs）。