Імпорт великих джерел даних з плоскими файлами за допомогою Drupal 7 з інтеграцією Views 3

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

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

• Щорічний імпорт: 8 500 000 рядкових файлів CSV . (Очищено та перезавантажено щорічно. Має первинний ключ.)
• Щотижневий імпорт: файл з фіксованою шириною 350 000 рядків. (Очищено та перезавантажено щотижня. Без первинного ключа .)
• Погодинний імпорт: 3,400 рядковий файл CSV . (Хочеться оновлювати та синхронізувати якомога частіше, але не більше кожні 20 хв. Має первинний ключ)
• Щоденний імпорт: XML-файл із 200 позицій. (Чистять і перезавантажують щодня. Має первинний ключ)

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

Яка найкраща практика для інтеграції такого типу даних з Drupal 7? Крім того, я залишаю якісь важливі подробиці щодо даних або того, що я намагаюся виконати?

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

Імпорт даних у вузли:

• Канали (зараз Альфа для D7)

Канали надійно імпортуватимуть дані. Швидкість розумна для менших джерел даних, але занадто повільна для таблиць 300k +.

Доступна автоматизація за допомогою програми cron та Job Scheduler (в даний час Alpha для D7).

• Міграція

Якщо у вихідних даних немає індексу чи унікального ключа, це ускладнює використання. Це швидше, ніж канали, але все ж повільно імпортувати дуже великі таблиці.

Автоматизація доступна за допомогою барабану та крона.

Спеціальні таблиці замість вузлів

• Модуль даних (в даний час альфа для D7)

Модуль даних виглядає дуже перспективно, але на сьогоднішній день дуже невдалий для D7. Вимоги до автоматизації та швидкості імпорту легко було б виконати за допомогою даних, але надійності бракує. Інтеграція переглядів (посилання на D6) виглядає дуже перспективним.

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

Додано це для довідки. Наразі немає кандидата на D7, але він може послужити відправною точкою для спеціального модуля.

• Схема переглядів (покинута, лише D6)

Додано це для довідки. Це, здається, було поглинене Майстром таблиці в Drupal 6. Знову ж, додано лише для довідки.

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

Здається, потрібен майстер таблиці (лише D6) для інтеграції переглядів . Додано для довідки, але не відповідає вимогам "Перегляд".

@MPD - Додано "Спеціальні таблиці" як можливе рішення та розширені модулі. Дякую за це доповнення.

Мій кишечник скаже мені, що цей план змусить ваші сервери загорітися ...

Якщо серйозно, якщо ви збираєте стільки даних, то, я думаю, вам потрібно зберегти дані у зовнішньому джерелі даних, а потім інтегрувати їх у Drupal.

Моя початкова думка полягала б у використанні двох баз даних для зовнішніх даних, так що ви можете робити щотижневий імпорт без надто тривожних речей. Іншими словами, запустити базу даних A та запустити її, а потім імпортувати в B. Після імпортування зробіть B джерелом живого потоку. Потім витріть і імпортуйте в A.

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

Не маючи UUID для бази даних щотижня, справді кидається гайковий ключ у роботі. Ця частина вимагає дуже багато, але більше, що можна надати на такому форумі запитань.

Якщо ви дійсно хочете спуститись із маршруту імпорту, я б посилався на канали та міграцію та написав власний сценарій імпорту. В основному ви робите початковий процес bookstrap з index.php, запитуєте свій джерело даних, робите свої вузли, а потім зберігаєте їх. Програмно зробити вузли легко.

Найкращий спосіб почати з цього - це зробити вузол з користувальницьким інтерфейсом, потім print_r його та копіювати об’єкт з кодом у вашому сценарії імпорту. Таксономія, файли та noderefs - важкі частини, але вам потрібно просто ознайомитися з цими частинами API, щоб створити ці властивості об'єкта. Після того, як у вас є дійсний об'єкт вузла, ви можете просто зробити node_save (). Переконайтеся, що ви встановили дуже великий ліміт за допомогою set_time_limit (), щоб ваш сценарій запускався.

ВИДАЛИТИ ВНІШНЯ ДЛЯ КРИФІКАЦІЇ / ПОШРЕННЯ АДРЕСИ:

Особисто ми деякий час тому перестали використовувати підходи, засновані на модулі contrib, для імпорту даних. Вони працюють в основному добре, але ми просто закінчили витрачати занадто багато часу на боротьбу з ними і вирішили, що вартість / вигода є занадто низькою.

Якщо вам справді потрібні дані в Drupal належним чином, то моя думка щодо користувацького сценарію імпорту не змінилася. Один з модулів, на які ви посилаєтесь, може бути використаний як відправна точка для створення об'єктів вузла, а потім просто проведіть через ваші вузли збирання даних і збережіть їх. Якщо у вас ПК, ви можете легко додати логіку для пошуку в базі даних та node_load (), зміни та збереження. Сценарій імпорту дійсно працює лише за кілька годин, якщо ви знаєте API Drupal.

Якщо інтеграція поглядів є ключовим (і це здається, що це засноване на редагуванні), і ви хочете виконати підхід до зовнішніх таблиць, то найкращим варіантом буде зробити спеціальний модуль та реалізувати крюкові_види_даних, щоб перевести ваші дані у представлення даних. Більше ніж, швидше за все, ви все одно будете користувальницьким модулем для підтримки вашого джерела даних, тому додавання цього гака не повинно бути набагато більшою роботою. Модулі TW та Data повинні мати приклад для того, щоб ви рухалися.

Однак особисто я ніколи не вважав, що інтеграція поглядів із зовнішніми даними справді вартує. У тих випадках, коли я це вважав, дані були занадто "різними", щоб добре працювати з підходом, заснованим на поглядах. Я просто закінчую використання методу, який я описав у посиланні "гидота" вище.

Я думаю, що підхід на основі вузла (або навіть на основі сутності) випалить ваш сервер з мільйонами вузлів. Крім того, дивлячись на годинний імпорт, це означає, що ви зробите node_save () хоча б раз на секунду. Це занадто багато для Drupal і може спричинити проблеми з продуктивністю.

Причина в тому, що для цього вмісту вам не знадобиться жоден механізм гака, вам не знадобиться патауто (але ви можете вручну створити псевдонім, це набагато дешевше, ніж патауто), вам не знадобляться поля ... Напишіть простий запит "INSERT" на 100 разів швидше, ніж node_save () або entit_save ().

1 / IMHO найкращим варіантом є власна таблиця та спеціальний модуль для імпорту ваших даних, а потім запишіть обробники переглядів для інтеграції з Drupal

2 / Під час погодинного імпорту кеш бази даних недійсний. Якщо це забирає занадто багато часу, ви можете подумати про реплікацію. У найпростішій формі створіть дві однакові таблиці, використовуйте першу, імпортуйте до другої, переключіть свою конфігурацію Drupal на другу таблицю, синхронізуйте другу таблицю з першою (потім необов'язково переключіться назад на першу). Інше рішення полягає у вашому користувальницькому сценарії імпорту, підготуйте та групуйте запити INSERT / UPDATE, після чого надсилайте їх лише в кінці однієї транзакції, щоб зменшити час запису в базу даних.