Mengimpor sumber data flat-file besar dengan Drupal 7 dengan integrasi Views 3

Tujuan saya adalah menghasilkan metode yang cepat, andal, dan otomatis untuk mengakses data hanya-baca yang terkandung dalam beberapa sumber data flat-file yang sangat besar ( CSV , Fixed Width, dan XML docs) menggunakan Drupal 7 yang dapat ditanyakan dengan menentang penggunaan Views 3 modul. Saya lebih suka menggunakan modul yang sudah tersedia, tetapi membangun modul khusus juga merupakan pilihan.

Untuk membantu menyingkirkan modul dan metode yang tidak cocok untuk tugas tersebut, berikut adalah statistik pada file yang saya kerjakan:

• Impor Tahunan: 8.500.000 file CSV baris . (Dibersihkan dan dimuat ulang setiap tahun. Memiliki kunci utama.)
• Impor Mingguan: 350.000 file dengan lebar tetap baris. (Dibersihkan dan dimuat ulang setiap minggu. Tidak ada kunci utama .)
• Impor Setiap Jam: 3.400 file CSV baris . (Ingin memperbarui dan menyinkronkan sesering mungkin, tetapi tidak lebih dari setiap 20 menit. Memiliki kunci utama)
• Impor Harian: 200 item file XML. (Dibersihkan dan dimuat ulang setiap hari. Memiliki kunci utama)

Konversi antara ketiga format ini bukan masalah dan dapat dilakukan jika akan meningkatkan kinerja impor atau memungkinkan alat yang lebih baik tersedia. ( AWK untuk Fixed Width ke CSV , dll.) Pengambilan dan otomatisasi konversi mudah melalui skrip cron dan sh , tetapi masih perlu mengotomatiskan integrasi Drupal 7. Penggunaan tabel khusus juga dimungkinkan selama vews dapat merujuk data menggunakan hubungan.

Apa praktik terbaik untuk mencapai jenis integrasi data ini dengan Drupal 7? Juga, apakah saya meninggalkan detail penting mengenai data atau apa yang ingin saya capai?

Berikut adalah beberapa proyek yang sedang saya cari untuk menemukan solusi. Saya ingin memperluas ini untuk membantu orang lain memutuskan rute mana yang harus diambil ketika bekerja dengan impor data yang lebih besar.

Mengimpor data ke dalam node:

• Feed (Saat ini Alpha untuk D7)

Umpan akan mengimpor data dengan andal. Kecepatan masuk akal untuk sumber data yang lebih kecil tetapi terlalu lambat untuk tabel + 300k.

Otomatisasi tersedia menggunakan cron dan Penjadwal Pekerjaan (Saat ini Alpha untuk D7).

• Migrasi

Tidak memiliki indeks atau kunci unik yang tersedia di data sumber membuat ini sulit digunakan. Ini lebih cepat daripada feed, tetapi masih lambat untuk mengimpor tabel yang sangat besar.

Otomasi tersedia melalui drush dan cron.

Tabel Kustom Alih-alih Node

• Modul Data (Saat ini Alpha untuk D7)

The modul data terlihat sangat menjanjikan, tetapi sangat kereta untuk D7 saat ini. Persyaratan kecepatan otomatisasi dan impor akan mudah dipenuhi menggunakan data, tetapi keandalannya masih kurang. The dilihat Integrasi (link adalah untuk D6) terlihat sangat menjanjikan.

• Table Wizard (Tidak tersedia untuk D7)

Menambahkan ini untuk referensi. Tidak ada kandidat D7 pada saat ini, tetapi dapat berfungsi sebagai titik awal untuk modul khusus.

• Skema Tampilan (Diabaikan, D6 saja)

Menambahkan ini untuk referensi. Ini tampaknya telah diserap oleh Table Wizard di Drupal 6. Sekali lagi, ditambahkan hanya untuk referensi.

• Importir (RC2 untuk D7)

Tampaknya membutuhkan Table Wizard (hanya D6) untuk integrasi Views . Ditambahkan untuk referensi, tetapi tidak memenuhi persyaratan Tampilan.

@MPD - Menambahkan "Tabel Kustom" sebagai solusi yang memungkinkan, dan memperluas modul. Terima kasih atas penambahan ini.

Nyali saya memberi tahu saya bahwa rencana ini akan membuat server Anda terbakar ...

Serius, jika Anda mengolah data sebanyak itu, maka saya pikir Anda perlu menyimpan data dalam sumber data eksternal dan kemudian mengintegrasikannya dengan Drupal.

Pikiran awal saya akan menggunakan dua database untuk data eksternal, sehingga Anda dapat melakukan impor mingguan tanpa mengganggu banyak hal. Dengan kata lain, dapatkan dan jalankan basis data A, lalu impor ke B. Saat impor selesai, buat B sebagai sumber langsung. Lalu bersihkan dan impor ke A.

Saya telah melakukan banyak integrasi sumber data eksternal ke dalam Drupal, dan itu sebenarnya tidak terlalu sulit. Saya memberikan ikhtisar dalam rencana Transisi untuk kekalahan PHP5 ke Drupal . Itu untuk Drupal 6, tetapi hal yang sama pada dasarnya berlaku untuk Drupal 7. Pada dasarnya, Anda mensimulasikan apa yang dilakukan CCK / Fields API dengan antarmuka Anda sendiri.

Tidak memiliki UUID untuk database mingguan benar-benar melemparkan kunci pas dalam karya, meskipun. Bagian itu membutuhkan banyak, lebih banyak yang dapat disediakan di forum Tanya Jawab seperti ini.

Jika Anda benar-benar ingin turun rute impor, saya akan memberi jaminan pada Umpan dan Migrasi dan menulis skrip impor Anda sendiri. Pada dasarnya, Anda melakukan proses pembukuan awal dari index.php, meminta sumber data Anda, membuat node Anda, dan kemudian menyimpannya. Membuat simpul secara pemrograman itu mudah.

Cara terbaik untuk memulai dengan ini adalah membuat simpul dengan UI, lalu print_r, dan mereplikasi objek dengan kode dalam skrip impor Anda. Taksonomi, file, dan noderef, adalah bagian yang sulit, tetapi Anda hanya perlu membiasakan diri dengan bagian-bagian dari API ini untuk membangun properti objek ini. Setelah Anda memiliki objek simpul yang valid, maka Anda bisa melakukan node_save (). Pastikan Anda menetapkan batas yang sangat besar dengan set_time_limit () agar skrip Anda berjalan.

EDIT DI BAWAH INI UNTUK ALAMAT CLARIFICATION / EXPANSION:

Secara pribadi, kami berhenti menggunakan pendekatan berbasis modul contrib untuk impor data beberapa waktu lalu. Mereka bekerja dengan baik, tetapi kami akhirnya menghabiskan terlalu banyak waktu untuk melawan mereka dan memutuskan biaya / manfaatnya terlalu rendah.

Jika Anda benar-benar membutuhkan data dalam Drupal yang benar, maka pendapat saya tentang skrip impor khusus belum berubah. Salah satu modul yang Anda referensi dapat digunakan sebagai titik awal untuk bagaimana membangun objek node, kemudian hanya loop melalui data Anda membangun node dan menyimpannya. Jika Anda memiliki PK, Anda dapat dengan mudah menambahkan logika untuk mencari di database dan node_load (), memodifikasi, dan menyimpan. Skrip impor sebenarnya hanya berfungsi beberapa jam jika Anda mengetahui Drupal API.

Jika integrasi tampilan adalah kunci (dan kedengarannya seperti itu didasarkan pada hasil edit) dan Anda ingin melakukan pendekatan tabel eksternal, maka opsi terbaik Anda adalah melakukan modul kustom dan mengimplementasikan hook_views_data untuk mendapatkan data Anda ke tampilan. Kemungkinan besar, Anda akan tetap membuat modul khusus untuk mendukung sumber data Anda, jadi menambahkan pengait ini seharusnya tidak terlalu banyak pekerjaan. Modul TW dan Data harus memiliki beberapa contoh untuk membuat Anda maju.

Namun secara pribadi, saya belum pernah menemukan bahwa integrasi pandangan dengan data eksternal benar-benar bermanfaat. Dalam kasus-kasus di mana saya telah mempertimbangkannya, data terlalu "berbeda" untuk bekerja dengan baik dengan pendekatan berbasis pandangan. Saya akhirnya menggunakan metode yang saya jelaskan di tautan "kekejian" di atas.

Saya pikir pendekatan berbasis simpul (atau bahkan berbasis entitas) akan membakar server Anda dengan jutaan simpul. Selain itu, melihat impor per jam Anda, itu berarti Anda akan membuat node_save () setidaknya satu kali per detik. Itu terlalu banyak untuk Drupal dan menyebabkan masalah kinerja.

Alasan di balik itu adalah untuk konten tersebut, Anda tidak memerlukan mekanisme pengait, Anda tidak perlu pathauto (tetapi Anda dapat secara manual membuat alias, ini jauh lebih murah daripada pathauto), Anda tidak perlu bidang ... Tulis a kueri "INSERT" sederhana adalah 100x lebih cepat dari node_save () atau entity_save ().

1 / IMHO opsi terbaik adalah tabel khusus dan modul khusus untuk impor data Anda, kemudian tulis Penangan tampilan untuk integrasi Drupal.

2 / Cache basis data tidak valid selama impor setiap jam. Jika terlalu banyak waktu, Anda bisa memikirkan replikasi. Dalam bentuk termudah, buat dua tabel yang identik, gunakan yang pertama, impor ke yang kedua, alihkan konfigurasi Drupal Anda untuk menggunakan tabel kedua, sinkronkan tabel ke-2 ke-1 (kemudian secara opsional beralih kembali ke yang pertama). Solusi lain ada di skrip impor kustom Anda, siapkan dan kelompokkan kueri INSERT / UPDATE, kemudian kirimkan saja di akhir satu transaksi untuk mengurangi waktu penulisan basis data.