问题标签 [database-partitioning]

我正在为我的应用程序构建一个数据库存储，该应用程序包含一个具有巨大数据量（数亿条记录）的表。我计划在日期字段上建立一个索引，因为我将不时在给定时间段内对所有记录进行批量恢复（例如，在第二天午夜检索所有记录）。

由于记录的数量很大并且性能是这个系统中的一个重要问题，我想知道是否有一种方法可以动态地对我的表进行分区，以便我可以更快地检索记录，创建和截断分区，因为它们没有更需要。例如，在处理完今天的记录后，我将如何为第二天创建一个分区并用其余数据填充它？

我正在使用六个数据库。数据库都具有相同的架构、相同的 SP 等。对于最初设计数据库的人来说，使用许多数据库的很大一部分动机是效率；另一种方法是在数据库中的几乎每个表和 sp 中添加一列，指示正在处理哪组数据，从而产生一个巨大的（因此速度较慢的）数据库，而不是几个小型数据库。代替有一个列来指示正在查询的数据集，连接字符串用于选择正在访问的数据库。

我真正不喜欢这个组织的唯一原因是它涉及大量代码重复，因此会损害维护。例如，每次我希望更改存储过程时，我都需要在每个数据库上运行 alter 语句。

我考虑过的一种解决方案是将所有数据合并到一个大数据库中，并在整个位置添加一个额外的列，以指示如果我没有合并数据将在哪个数据库中。然后，我可以按此列的值对所有表进行分区。从理论上讲，所有这一切的结果是所有数据本身的基本表示在道德上将与现在相同，但没有索引、模式、SP 等方面的冗余。

我的问题是这样的：

1. 这是一个好主意吗？有没有更好的方法来实现这一点？
2. 这样做有什么问题吗？
3. 这会对性能有什么影响吗？

我们的数据库模式存储在一个文件中，该文件旨在用于生产用途，但我们也在本地机器上运行功能测试时使用。我们删除数据库并从此文件重建它，然后添加一组已知的测试数据。一切运作良好。

最近我们添加了一些性能改进。当我们向其中一张表添加分区时，问题就来了。

毫不畏惧，我添加了一个 if 语句来检查我们是否在启用分区之前在 Enterprise 下运行：

不幸的是，这仍然失败。我认为 SQL Server 在解析时告诉我们这个问题，CREATE PARTITION FUNCTION所以即使我们不使用它也会抛出错误。

有什么建议么？

因此，我目前正在开展一个项目，该项目涉及收集和存储一些巨大的数据集（就我习惯使用的数据而言）。数据本质上由元信息组成，然后是实际值（这些值随时间变化）。

元信息本身相对较大，但没什么大不了的，我可能会说它会在未来几年内增长到 10-50 百万行大小。这对我来说似乎是可以管理的，如果索引得当（并且数据很容易索引，边界非常明确），一个强大的 SQL Server 应该足以提供对这些数据的快速访问......

然而，趋势数据是完全不同的故事。一年之内，我们很容易每天都会增加 40-5000 万行，而在接下来的 3 或 4 年内，这实际上可能每年翻一番。

这种趋势数据也有非常明确的边界，可以将其分成更易于管理的大小块。我希望我可以设置某种分区机制，将这些数据分布在多个物理数据库节点上。数据基本上都包含在一个表中。我研究了 SQL Server 表分区，但找不到将数据分布在多个服务器上的方法。

我的问题是是否有一些“相对简单”的方式在多个物理节点上实现表分区。我也花了一些时间查看 Sql Server PDW，但很难在网上找到信息，我不想继续这样做，直到我确定没有简单的方法来使用构建的功能来实现这种解决方案进入 SQL Server。

任何建议将不胜感激...

我想对一个非常大的 PostgreSQL 8.3 数据库进行分区。引用手册，

分区可以提供几个好处：

...

很少使用的数据可以迁移到更便宜、更慢的存储介质上。

将表格重新定位到其他媒体或计算机的正确方法是什么？亚当

我有一个巨大的数据库，其中包含成对的数字（A，B），每个数字的范围从 0 到 10,000 并存储为浮点数。

例如，

由于存储这些对的 PostgreSQL 表变得非常大，我决定将其划分为继承子表。我打算创建 100 个这样的表，每个表存储 1000x1000 的范围。

问题是这些数字往往是附近数字的大块。这意味着在未来，一些表将几乎是空的，而一些表将占据数据库的很大一部分。不幸的是，未来对的分布尚不清楚。

我正在寻找一种自动重新分区我的表的方法。这意味着如果某个子表包含的pairs超过特定数量，它将自动划分为四个子子表，依此类推。

我的问题是：

• PostgreSQL 8.3 中是否可以进行递归分区和继承？索引和查询计划会理解它吗？
• 一旦子表变得太大，拆分子表的最佳方法是什么？我应该指出，这不是一个实时数据库，所以每周几个小时的停机时间是完全可以接受的。
• 更新：我可能会将继承表拆分为四个表，以替换原来的表（即直接从主表继承）。我将避免拥有超过一级的继承，但如果表直接从一张表继承，则会有数千个。这种方法的优点和缺点是什么？

提前致谢，

亚当

我刚刚尝试根据日期配置分区，但似乎mysql仍然包含一个没有相关数据的分区。它将使用相关分区，但由于某种原因还包括最旧的分区。我做错了吗？

版本是 5.1.44 (MyISAM)

我首先添加了一些基于“day”的分区，它的类型是“date”

查询后，我发现它使用“旧”分区，不应该包含任何相关数据。

当我选择一天时，它按预期工作：

我想知道以下步骤是否可行以及速度有多快：

1. 在表 A 中创建一个名为 part1 的分区
2. 删除表 B 中的分区 part1
3. 将表A分区part1导入表B

如果确实有可能，你能给我举个例子吗？或者我可以查看的任何资源？

请注意，这些表将具有完全相同的结构。

我在 MacBook Pro 上尝试在 MySQL 上实现 505,000,000 行表的更新：按照给出的建议，我已经对表进行了分区，tr：

在 nu 上有一个范围。nu 应该是一个实数，但是因为我只有 6-dp 精度，并且 nu 的最大值是 30000。我将它乘以 10^8 使其成为 BIGINT - 我认为不能使用 FLOAT 或 DOUBLE 值对 MySQL 表进行分区。无论如何，我有 15 个分区（p0：nu<25,000,000,000，p1：nu<50,000,000,000 等）。我在想这应该加快一个典型的选择：

到仅由相关分区中的数据组成的表上的相同查询的顺序（<30 秒）。但是，如果查询是针对跨越两个（连续）分区的行，则需要 30 分钟以上的时间才能返回分区内查询的行。我意识到我可以只有 15 个不同的表，并分别查询它们，但是有没有办法用分区“自动”执行此操作？有没有人有任何建议？

在数据库中执行许多插入时，我通常会有这样的代码：

我现在想对数据库进行分片，因此需要根据插入的项目选择连接字符串。这将使我的代码运行得更像这样

这基本上意味着它正在为每个项目创建一个到数据库的新连接。这会起作用还是会为每个插入重新创建连接会导致可怕的开销？