Импорт больших источников данных в виде плоских файлов с Drupal 7 с интеграцией Views 3

Моя цель - создать быстрый, надежный и автоматизированный метод доступа к данным только для чтения, содержащимся в нескольких очень больших источниках данных в виде плоских файлов ( CSV, документы с фиксированной шириной и XML), с использованием Drupal 7, к которым можно обращаться с помощью Views 3. модуль. Я бы предпочел использовать уже имеющиеся модули, но также возможно создание собственного модуля.

Чтобы помочь исключить модули и методы, не подходящие для этой задачи, вот статистика по файлам, с которыми я работаю:

• Годовой импорт: 8 500 000 строк файла CSV . (Чистится и перезагружается ежегодно. Имеет первичный ключ.)
• Еженедельный импорт: файл с фиксированной шириной 350 000 строк. (Чистится и перезагружается еженедельно. Нет первичного ключа .)
• Почасовой импорт: 3400 строк CSV- файла. (Хотел бы обновлять и синхронизировать как можно чаще, но не чаще, чем каждые 20 мин. Имеет первичный ключ)
• Ежедневный импорт: 200 элементов XML-файла. (Очищается и перезагружается ежедневно. Имеет первичный ключ)

Преобразование между этими тремя форматами не является проблемой и может быть выполнено, если это улучшит производительность импорта или позволит сделать лучшие инструменты доступными. ( AWK для фиксированной ширины в CSV и т. Д.) Автоматизация поиска и преобразования проста с помощью сценариев cron и sh , но все же необходимо автоматизировать интеграцию с Drupal 7. Использование пользовательских таблиц также возможно, если vews может ссылаться на данные, используя отношения.

Какова была бы наилучшая практика для интеграции этого типа данных с Drupal 7? Кроме того, я пропускаю какие-либо важные детали относительно данных или что я пытаюсь достичь?

Вот несколько проектов, которые я сейчас ищу, чтобы найти решение. Я хотел бы подробнее остановиться на этом, чтобы помочь другим решить, какой маршрут выбрать при работе с большими объемами импорта данных.

Импорт данных в узлы:

• Feeds (в настоящее время Alpha для D7)

Ленты будут импортировать данные надежно. Скорость приемлема для небольших источников данных, но слишком медленная для таблиц 300k +.

Автоматизация доступна с использованием cron и Job Scheduler (в настоящее время Alpha для D7).

• Перенести

Отсутствие индекса или уникального ключа в исходных данных затрудняет использование. Это быстрее, чем фиды, но все же медленно импортирует очень большие таблицы.

Автоматизация доступна через drush и cron.

Пользовательские таблицы вместо узлов

• Модуль данных (в настоящее время Alpha для D7)

Модуль Data выглядит очень многообещающе, но на данный момент он очень глючит для D7. Требования к автоматизации и скорости импорта могут быть легко выполнены с использованием данных, но их надежность недостаточна. Интеграция просмотров (ссылка на D6) выглядит очень перспективным.

• Мастер таблиц (Недоступно для D7)

Добавил это для справки. На данный момент нет кандидата в D7, но он может служить отправной точкой для пользовательского модуля.

• Схема видов (Заброшенный, только D6)

Добавил это для справки. Кажется, это было поглощено Table Wizard в Drupal 6. Опять же, добавлено только для справки.

• Импортер (RC2 для D7)

Кажется, требуется Мастер таблиц (только D6) для Views интеграции. Добавлено для справки, но не соответствует требованию Views.

@MPD - Добавлены «Пользовательские таблицы» в качестве возможного решения и расширены модули. Спасибо за это дополнение.

Моя интуиция говорит мне, что этот план заставит ваши серверы загореться ...

Серьезно, если вы собираете столько данных, я думаю, вам нужно сохранить данные во внешнем источнике данных, а затем интегрировать их с Drupal.

Моя первоначальная мысль заключалась в том, чтобы использовать две базы данных для внешних данных, чтобы вы могли делать еженедельный импорт без мешающих вещей. Другими словами, запустите базу данных A и запустите ее, а затем импортируйте в B. Когда импорт будет завершен, сделайте B активным источником. Затем протрите и импортируйте в A.

Я сделал много интеграции внешних источников данных в Drupal, и это действительно не так сложно. Я дал обзор плана перехода для мерзости PHP5 в Drupal . Это было для Drupal 6, но то же самое в основном относится к Drupal 7. По сути, вы моделируете, что CCK / Fields API делает с вашим собственным интерфейсом.

Отсутствие UUID для еженедельной базы данных, тем не менее, действительно вносит рывок в работу. Эта часть требует много, больше, что может быть предоставлено на форуме Q / A, как это.

Если вы действительно хотите пойти по пути импорта, я сделаю ставку на Feeds и Migrate и напишу ваш собственный скрипт импорта. По сути, вы выполняете начальный процесс bookstrap из index.php, запрашиваете источник данных, создаете узлы, а затем сохраняете их. Программно сделать узлы легко.

Лучший способ начать с этого - создать узел с пользовательским интерфейсом, затем напечатать его и скопировать объект с кодом в вашем скрипте импорта. Таксономия, файлы и noderefs являются сложными частями, но вам просто нужно ознакомиться с этими частями API для создания этих свойств объекта. Если у вас есть действительный объект узла, тогда вы можете просто выполнить node_save (). Убедитесь, что вы установили очень большой лимит с помощью set_time_limit (), чтобы ваш скрипт работал.

РЕДАКТИРОВАТЬ НИЖЕ, ЧТОБЫ ОБРАТИТЬСЯ К УТОЧНЕНИЮ / РАСШИРЕНИЮ:

Лично мы давно перестали использовать подходы, основанные на модуле contrib для импорта данных. Они работают в основном хорошо, но мы просто потратили слишком много времени на борьбу с ними и решили, что соотношение цены и прибыли было слишком низким.

Если вам действительно нужны данные в собственном Drupal, то мое мнение о собственном скрипте импорта не изменилось. Один из модулей, на который вы ссылаетесь, может быть использован в качестве отправной точки для построения объектов узлов, а затем просто перебрать все ваши узлы построения данных и сохранить их. Если у вас есть PK, вы можете легко добавить логику для поиска в базе данных и node_load (), изменить и сохранить. Скрипт импорта действительно работает всего несколько часов, если вы знаете API Drupal.

Если интеграция представлений является ключевой (и звучит так, как будто она основана на редактировании), и вы хотите использовать подход внешних таблиц, тогда лучше всего сделать пользовательский модуль и реализовать hook_views_data, чтобы ваши данные отображались в представлениях. Скорее всего, вы все равно настроите пользовательский модуль для поддержки вашего источника данных, поэтому добавление этого хука не должно быть намного более трудоемким. Модули TW и Data должны иметь какой-то пример, чтобы начать работу.

Лично я никогда не считал целесообразным интеграцию представлений с внешними данными. В тех случаях, когда я это рассматривал, данные были слишком «другими», чтобы хорошо работать с подходом, основанным на представлениях. Я просто использую метод, описанный в ссылке «мерзость» выше.

Я думаю, что подход, основанный на узлах (или даже объектах), сожжет ваш сервер миллионами узлов. Кроме того, если посмотреть на ваш почасовой импорт, это означает, что вы будете делать node_save () хотя бы раз в секунду. Это слишком много для Drupal и вызывает проблемы с производительностью.

Причина этого в том, что для этого контента вам не понадобится какой-либо механизм подключения, вам не понадобится pathauto (но вы можете создать псевдоним вручную, он намного дешевле, чем pathauto), вам не понадобятся поля ... простой запрос "INSERT" в 100 раз быстрее, чем node_save () или entity_save ().

1 / IMHO, лучшим вариантом является пользовательская таблица и пользовательский модуль для импорта данных, а затем написать обработчики Views для интеграции с Drupal.

2 / Кэш базы данных недействителен во время почасового импорта. Если это занимает слишком много времени, вы можете подумать о репликации. В простейшей форме создайте две идентичные таблицы, используйте первую, импортируйте во вторую, переключите свою конфигурацию Drupal для использования второй таблицы, синхронизируйте 2-ю таблицу с 1-й (а затем при необходимости переключитесь обратно на первую). Другое решение заключается в вашем пользовательском сценарии импорта, подготовьте и сгруппируйте запросы INSERT / UPDATE, а затем отправьте его только в конце за одну транзакцию, чтобы сократить время записи в базу данных.