MySQL Postgresql / PostGIS答案

【问题标题】：MySQL Postgresql / PostGISMySQL Postgresql / PostGIS
【发布时间】：2012-03-14 04:12:18
【问题描述】：

我在 4 亿行分区的 mysql 表中有纬度/经度坐标。该表每分钟增长 2000 条记录，并且每隔几周刷新一次旧数据。我正在探索对这些数据进行空间分析的方法。

大多数分析都需要确定一个点是否在特定的纬度/经度多边形中，或者哪些多边形包含该点。

我看到以下解决多边形点 (PIP) 问题的方法：

创建一个 mysql 函数，该函数接受一个点和一个几何图形并返回一个布尔值。简单但不确定如何使用几何来对纬度/经度坐标执行操作，因为几何假定平面而不是球体。
创建一个 mysql 函数，该函数接受一个点和自定义数据结构的标识符并返回一个布尔值。多边形顶点可以存储在表格中，并且函数可以使用球面数学计算 PIP。大量多边形点可能会导致表格庞大和查询缓慢。
将点数据留在 mysql 中，将多边形数据存储在 PostGIS 中，并使用应用服务器通过提供点作为参数在 PostGIS 中运行 PIP 查询。
将应用程序从 MySQL 移植到 Postgresql/PostGIS。这将需要在重写查询和过程方面付出很多努力。我仍然可以做到，但 Postgresql 在处理 4 亿行时有多好。在 google 上快速搜索“mysql 10 亿行”会返回许多结果。 Postgres 的相同查询不返回相关结果。

想听听一些想法和建议。

【问题讨论】：

我有使用 300M+ 行表运行 Postgres 的个人经验——毫不费力。 Skype 使用 Pg 来跟踪连接、用户、会计等。除了通信渠道本身之外的一切。那是数十亿条记录。
那么达到 300M 有多容易/多难？它需要多少调整/优化？我读过有关使用 Postgres 的 Skype 的文章，但大公司可以投入资源并让任何事情发挥作用。我正在寻找的是像你这样的输入。
我们的 PostgreSQL 数据库每秒处理多达约 5000 个事务，过去 2 年每月处理约 6 亿条记录。以前的 MySQL 服务器无法在相同的硬件上处理此问题。
@Priyank 不需要太多调整。通过默认的分发构建，Pg 能够使用大内存、磁盘和处理器资源来处理具有高并发性的大型数据集。有一些默认配置设置适用于较小的系统（例如 shared_buffers），但您只需更改少量配置值即可从适合您工作负载的大型机器中获得良好的性能。您将希望对其他数据库执行相同的操作来管理大数据：分区策略、备份和复制、确保您的存储系统能够满足要求等。
我已经设法获得了一个包含超过 27 亿条记录的 postgres 数据库，我可以通过查询告诉我使用 ST_Contains 在某个多边形内有多少记录。 .并且根据我的经验，Postgres 的规模比 Mysql 好得多...从这个角度来看，我建议使用选项 4。只是想问......这种地理空间需求是否纯粹是一种报告需求？是否可以让 MYSQL 继续使用该应用程序并创建一个每晚从 MYSQL 数据库加载的 Postgres 数据仓库？为您提供一个独立于您的产品环境的报告世界。

标签： mysql postgresql gis geospatial postgis

【解决方案1】：

一些想法。

在性能调整方面，首先 PostgreSQL 和 MySQL 是完全不同的野兽。因此，如果您选择移植路线，请准备好重新考虑您的索引策略。 PostgreSQL 不仅拥有比 MySQL 更灵活的索引，而且表方法也非常不同，这意味着适当的索引策略与策略一样不同。不幸的是，这意味着您可能会遇到一些困难。如果我可以提供建议，我会建议首先删除所有非关键索引，然后根据需要谨慎添加。

第二点是，由于我们不了解您程序的内部结构，因此目前没有人可能会给您大量实用的建议。在 PostgreSQL 中，您最好只索引您需要的内容，但您可以索引函数的输出（在这种情况下这非常有用）并且您可以只索引表的一部分。

我更喜欢 PostgreSQL 而不是 MySQL，所以我当然认为你应该使用 PostgreSQL。然而，与其告诉你为什么等等，让你在这个规模上挣扎，我会告诉你一些如果我试图这样做的话，我会考虑使用的东西。

功能索引
为相关分析的索引编写我自己的函数
PostGIS 非常棒，而且非常灵活

最后，在这个音量下切换数据库将是一个学习曲线，您需要为此做好准备。但是，PostgreSQL 可以很好地处理卷。

【讨论】：

【解决方案2】：

这里的行数无关紧要。问题是索引可以完成多少多边形工作。

答案取决于多边形有多大。

PostGIS 可以非常快速地找到多边形边界框中的所有点。然后需要更多的努力来确定该点是否真的在多边形内。

如果您的多边形很小（小边界框），则查询会很有效。如果您的多边形很大或具有使边界框变大的形状，那么它的效率就会降低。

如果您的多边形或多或少是静态的，则可以使用变通方法。您可以将多边形划分为较小的多边形并重新创建 idnex。那么索引效率会更高。

如果您的多边形实际上是多面体，那么第一步是使用 ST_Dump 将多面体拆分为多边形，然后在结果上重新创建和建立索引。

HTH

尼克拉斯

【讨论】：

各个点（约 4 亿）无论如何都要存储在数据库中。 PIP 是另一个问题。如果您指的是第 2 点，在这种情况下，它是一个存储多边形顶点的 mysql 表，并且 UDF 对表运行查询以确定 PIP 结果。