使用集成了Views 3的Drupal 7导入大型平面文件数据源

我的目标是使用Drupal 7 产生一种快速，可靠和自动化的方法，以访问包含在多个非常大的平面文件数据源（CSV，固定宽度和XML文档）中的只读数据，可以使用Views 3来查询该数据。模块。我希望使用已经可用的模块，但是构建自定义模块也是一种选择。

为了帮助排除不适合该任务的模块和方法，以下是我正在使用的文件的统计信息：

• 每年导入：850万行CSV文件。（每年清除和重新加载。具有主键。）
• 每周导入：350,000行固定宽度的文件。（每周清除和重新加载。无主键。）
• 每小时导入：3,400行CSV文件。（希望尽可能频繁地更新和同步，但不超过每20分钟一次。具有主键）
• 每日导入：200个项目的XML文件。（每天清除并重新加载。具有主键）

三种格式之间的转换不是问题，如果可以提高导入性能或允许使用更好的工具，则可以进行转换。（将AWK用于将固定宽度转换为CSV等）。通过cron和sh脚本可以很容易地进行检索和转换自动化，但是仍然需要使Drupal 7集成自动化。只要vews可以使用关系引用数据，也可以使用自定义表。

用Drupal 7完成此类数据集成的最佳实践是什么？另外，我是否遗漏了有关数据或要完成的工作的任何重要细节？

这是我目前正在寻找一些解决方案的项目。我想对此进行扩展，以帮助其他人决定在处理较大数据导入时应采取的路线。

将数据导入节点：

• 供稿（当前D7为Alpha）

Feed将可靠地导入数据。对于较小的数据源，速度是合理的，但对于300k +的表来说速度太慢。

可使用cron和Job Scheduler（当前为D7 使用Alpha）进行自动化。

• 迁移

源数据中没有可用的索引或唯一键，这使得此操作难以使用。它比提要快，但导入非常大的表仍然很慢。

可以通过drush和cron实现自动化。

自定义表而不是节点

• 数据模块（当前为D7为Alpha）

该数据模块看起来非常有前途，但对于D7非常错误的时刻。使用数据很容易满足自动化和导入速度的要求，但是缺乏可靠性。该意见整合（链接是D6）看起来非常有前途。

• 表格向导（不适用于D7）

添加此以供参考。目前没有D7候选者，但可以用作自定义模块的起点。

• 视图架构（已废弃，仅D6）

添加此以供参考。这似乎已经被Drupal 6中的Table Wizard吸收了。再次添加，仅供参考。

• 进口商（D2的RC2）

似乎需要使用表向导（仅D6）进行View集成。已添加以供参考，但不符合“视图”要求。

@MPD-添加了“自定义表”作为可能的解决方案，并扩展了模块。谢谢您的补充。

我的直觉告诉我，该计划将使您的服务器着火。

认真地说，如果您要搅动那么多数据，那么我认为您需要将数据保留在外部数据源中，然后将其与Drupal集成。

我最初的想法是使用两个数据库作为外部数据，这样您就可以每周进行导入而不会造成太多干扰。换句话说，启动并运行数据库A，然后将其导入到B。导入完成后，使B成为实时源。然后擦拭并导入A。

我已经做了很多将外部数据源集成到Drupal中的工作，这确实并不难。我概述了PHP5憎恶Drupal的过渡计划。那是针对Drupal 6的，但基本上同样适用于Drupal7。本质上，您可以使用自己的接口模拟CCK / Fields API的功能。

但是，没有每周数据库的UUID确实会费劲。该部分需要很多，但是在这样的Q / A论坛中可以提供更多。

如果您确实想沿导入路线走，我将为Feed和Migrate保释并编写您自己的导入脚本。基本上，您从index.php执行初始装订程序，查询数据源，创建节点，然后保存它们。以编程方式制作节点很容易。

最好的开始方法是使用UI创建一个节点，然后对其进行print_r，并使用导入脚本中的代码复制该对象。分类法，文件和noderefs是很难的部分，但是您只需要熟悉API的这些部分即可构建这些对象属性。一旦有了有效的节点对象，就可以执行一个node_save（）。确保使用set_time_limit（）设置很大的限制，以便脚本运行。

编辑下面的地址进行澄清/扩展：

就个人而言，不久前我们停止使用基于contrib模块的方法来进行数据导入。他们的确工作得很好，但是我们只是花了太多时间与他们战斗，因此认为成本/收益太低。

如果您确实需要Drupal中的数据，那么我对自定义导入脚本的看法没有改变。您引用的模块之一可以用作构建节点对象，然后遍历数据构建节点并保存它们的起点。如果您有PK，则可以轻松添加逻辑来搜索数据库和node_load（），进行修改并保存。如果您知道Drupal API，那么导入脚本实际上只需要几个小时。

如果视图集成是关键（而且听起来好像是基于编辑的），并且您想要执行外部表方法，那么最好的选择是执行自定义模块并实现hook_views_data以将数据导入视图。无论如何，您很有可能会自定义模块以支持您的数据源，因此添加此钩子应该没那么多工作。TW和Data模块应该有一些示例来帮助您入门。

不过，就我个人而言，我从未发现将视图与外部数据集成真的值得。在我考虑过的情况下，数据太“不同”而无法与基于视图的方法一起很好地工作。我最终只是使用了上面“无效”链接中描述的方法。

我认为基于节点（甚至基于实体）的方法将耗尽数百万个节点的服务器。此外，查看每小时导入一次，这意味着您至少每秒要创建一次node_save（）。对于Drupal而言，这太多了，并且会导致性能问题。

其背后的原因是这些内容，您不需要任何钩子机制，不需要pathauto（但您可以手动创建别名，它比pathauto便宜得多），您不需要字段...写一个简单的“ INSERT”查询比node_save（）或entity_save（）快100倍。

1 /恕我直言，最好的选择是自定义表和用于数据导入的自定义模块，然后编写用于Drupal集成的Views处理程序。

2 /在每小时导入期间，数据库缓存无效。如果花费太多时间，您可以考虑进行复制。在最简单的形式中，创建两个相同的表，使用第一个表，导入到第二个表，将您的Drupal配置切换为使用第二个表，将第二个表同步到第一个表（然后有选择地切换回第一个表）。另一种解决方案是在您的自定义导入脚本中，准备并分组INSERT / UPDATE查询，然后仅在一个事务中最后将其发送以减少数据库写入时间。