Views 3 entegrasyonu ile Drupal 7 ile büyük düz dosya veri kaynaklarını içe aktarma

Amacım , Views 3'ü kullanarak sorgulanabilen Drupal 7 kullanarak birkaç çok büyük düz dosya veri kaynağında ( CSV'ler , Sabit Genişlik ve XML dokümanları) bulunan salt okunur verilere erişmek için hızlı, güvenilir ve otomatik bir yöntem üretmektir. modülü. Zaten mevcut modülleri kullanmayı tercih ederim, ancak özel bir modül oluşturmak da bir seçenektir.

Göreve uygun olmayan modüllerin ve yöntemlerin dışlanmasına yardımcı olmak için, birlikte çalıştığım dosyaların istatistikleri:

• Yıllık İthalat: 8.500.000 satır CSV dosyası. (Yıllık temizlenir ve yeniden yüklenir. Birincil anahtarı vardır.)
• Haftalık İthalat: 350.000 satır sabit genişlikli dosya. (Haftalık temizlendi ve yeniden yüklendi. Birincil anahtar yok .)
• Saatlik İthalat: 3.400 satır CSV dosyası. (Mümkün olduğunca sık güncelleme ve senkronize etmek istiyorum, ancak her 20 dakikada bir olmamalıdır. Birincil anahtarı vardır)
• Günlük İçe Aktarma: 200 öğe XML dosyası. (Günlük temizlendi ve yeniden yüklendi. Birincil anahtarı var)

Üç biçim arasında dönüştürme yapmak bir sorun oluşturmaz ve içe aktarma performansını artıracak veya daha iyi araçların kullanılmasına izin verecekse yapılabilir. ( CSV'ye Sabit Genişlik vb. İçin AWK ) Alma ve dönüştürme otomasyonu cron ve sh komut dosyaları aracılığıyla kolaydır , ancak yine de Drupal 7 entegrasyonunu otomatikleştirmesi gerekir. Özel tabloların kullanımı, vews ilişkileri kullanarak verilere başvurabildiği sürece de mümkündür.

Drupal 7 ile bu tip veri entegrasyonunu gerçekleştirmek için en iyi uygulama hangisidir? Ayrıca, verilerle veya neyi başarmaya çalıştığımla ilgili önemli ayrıntıları dışarıda bırakıyor muyum?

İşte bir çözüm bulmak için aradığım birkaç proje. Diğerlerine daha büyük veri içe aktarmalarıyla çalışırken hangi rotayı izleyeceklerine karar vermek için bunu genişletmek istiyorum.

Verileri düğümlere aktarma:

• Yayınlar (Şu anda D7 için Alfa)

Feed'ler verileri güvenilir bir şekilde içe aktarır. Daha küçük veri kaynakları için hız makul, ancak 300k + tablolar için çok yavaş.

Otomasyon, cron ve Job Scheduler (Şu anda D7 için Alpha) kullanılarak kullanılabilir.

• Göç

Kaynak verilerde bir dizin veya benzersiz anahtar bulunmaması bunu kullanmayı zorlaştırmaktadır. Özet akışlarından daha hızlıdır, ancak yine de çok büyük tabloları içe aktarmak yavaştır.

Otomasyona drush ve cron üzerinden ulaşılabilir.

Düğüm Yerine Özel Tablolar

• Veri Modülü (Şu anda D7 için Alfa)

Veri modülü çok umut verici görünüyor, ama şu anda D7 için çok adamcağız. Otomasyon ve içe aktarma hızı gereksinimleri veriler kullanılarak kolayca karşılanacaktır, ancak güvenilirlik eksiktir. Görünümler entegrasyonu (link D6) çok umut verici görünüyor.

• Tablo Sihirbazı (D7 için mevcut değil)

Referans için bunu ekledi. Bu noktada D7 adayı yoktur, ancak özel bir modül için bir başlangıç ​​noktası görevi görebilir.

• Görünümler Şeması (Terk Edildi, yalnızca D6)

Referans için bunu ekledi. Bu, Drupal 6'daki Tablo Sihirbazı tarafından absorbe edilmiş gibi görünüyor. Yine, sadece referans için eklendi.

• İthalatçı (D7 için RC2)

Gerektirecek gibi görünüyor Tablo Sihirbazı için (D6 için) Görüntüleme entegrasyonu. Referans için eklendi, ancak Views gereksinimini karşılamıyor.

@MPD - Olası bir çözüm olarak "Özel Tablolar" ve genişletilmiş modüller eklendi. Bu ekleme için teşekkür ederim.

Bağırsak bana bu planın sunucularınızı ateşe vereceğini söylüyor ...

Cidden, eğer bu kadar veriyi çalkalarsanız, o zaman verileri harici bir veri kaynağında tutmanız ve sonra Drupal ile entegre etmeniz gerektiğini düşünüyorum.

İlk düşüncem, dış veriler için iki veritabanı kullanmaktı, böylece rahatsız edici şeyler olmadan haftalık içe aktarma yapabilirsiniz. Başka bir deyişle, A veritabanını çalıştırın ve çalıştırın ve sonra B'ye alın. Alma işlemi tamamlandığında B'yi canlı kaynak yapın. Ardından silin ve A'ya aktarın.

Harici veri kaynaklarının Drupal'a çok fazla entegrasyonu yaptım ve gerçekten o kadar da zor değil. Drupal'a PHP5'in iğrençliği için Geçiş planında bir genel bakış verdim . Bu Drupal 6 içindi, ancak aynı şey temel olarak Drupal 7 için de geçerlidir. Temel olarak, CCK / Fields API'sının kendi arayüzünüzle neler yaptığını simüle edersiniz.

Haftalık veritabanı için bir UUID'ye sahip olmama, çalışmalarda gerçekten bir anahtar atar. Bu bölüm, bunun gibi bir soru-cevap forumunda sağlanabilecek daha çok şey gerektirir.

Eğer gerçekten ithalat rotasına inmek istiyorsanız, Feeds and Migrate'dan kefalet alıp kendi ithalat betiğinizi yazarım. Temel olarak, index.php dosyasındaki ilk bookstrap işlemini gerçekleştirir, veri kaynağınızı sorgular, düğümlerinizi yapar ve kaydedersiniz. Programlı olarak düğüm yapmak kolaydır.

Bununla başlamanın en iyi yolu, kullanıcı arabirimiyle bir düğüm yapmak, ardından print_r yapmak ve nesneyi içe aktarma komut dosyanızda kodla çoğaltmaktır. Taksonomi, dosyalar ve noderef'ler zor parçalardır, ancak bu nesne özelliklerini oluşturmak için API'nin bu bölümlerini tanımanız yeterlidir. Geçerli bir düğüm nesnesine sahip olduğunuzda, sadece bir node_save () yapabilirsiniz. Komut dosyanızın çalışması için set_time_limit () ile çok büyük bir sınır belirlediğinizden emin olun.

ADRES AÇIKLAMASI / GENLEŞME AŞAĞIDAKİ DÜZENLEME:

Şahsen, bir süre önce veri alımı için katkıda bulunan modül tabanlı yaklaşımları kullanmayı bıraktık. Çoğunlukla iyi çalışıyorlar, ama biz onlarla savaşmak için çok fazla zaman harcadık ve maliyet / fayda çok düşük olduğuna karar verdik.

Drupal'daki verilere gerçekten ihtiyacınız varsa, özel bir içe aktarma komut dosyası hakkındaki düşüncem değişmedi. Referans verdiğiniz modüllerden biri, düğüm nesnelerinin nasıl oluşturulacağı için bir başlangıç ​​noktası olarak kullanılabilir, daha sonra veri oluşturma düğümleriniz arasında dolaşıp bunları kaydedebilirsiniz. Bir PK'niz varsa, veritabanında arama yapmak ve node_load (), değiştirmek ve kaydetmek için kolayca mantık ekleyebilirsiniz. Drupal API'sini biliyorsanız bir içe aktarma komut dosyası gerçekten yalnızca birkaç saat çalışır.

Views entegrasyonu bir anahtarsa ​​(ve düzenlemeye dayalı gibi görünüyorsa) ve harici tablolar yaklaşımını yapmak istiyorsanız, en iyi seçeneğiniz özel bir modül yapmak ve verilerinizi görünümlere almak için hook_views_data uygulamaktır . Muhtemelen, veri kaynağınızı desteklemek için yine de özel modül olacaksınız, bu nedenle bu kancayı eklemek çok daha fazla iş olmamalıdır. TW ve Data modüllerinin sizi yönlendirecek bazı örnekleri olmalıdır.

Şahsen, dış veri ile görüş entegrasyonunun gerçekten değerli olduğunu hiç bulamadım. Bunu düşündüğüm durumlarda veriler, görüşlere dayalı bir yaklaşımla iyi çalışamayacak kadar "farklıydı". Ben sadece yukarıdaki "iğrenç" bağlantısında tarif ettiğim yöntemi kullanarak.

Düğüm tabanlı (hatta varlık tabanlı) bir yaklaşımın sunucunuzu milyonlarca düğümle yakacağını düşünüyorum. Ayrıca, saatlik içe aktarma işleminize bakmak, en az saniyede bir kez bir node_save () yapacağınız anlamına gelir. Bu Drupal için çok fazla ve bir performans sorununa neden oluyor.

Bunun nedeni, bu içerik için, herhangi bir kanca mekanizmasına ihtiyacınız olmayacak, pathauto'ya ihtiyacınız olmayacak (ancak manuel olarak takma ad oluşturabilirsiniz, pathauto'dan çok daha ucuz), alanlara ihtiyacınız olmayacak ... basit "INSERT" sorgusu node_save () veya entity_save () yönteminden 100 kat daha hızlıdır.

1 / IMHO en iyi seçenek, veri içe aktarmanız için özel bir tablo ve özel bir modüldür, ardından Drupal entegrasyonu için Views işleyicileri yazın.

2 / Veritabanı önbelleği saatlik alma sırasında geçersiz kılınır. Çok fazla zaman alırsa, bir çoğaltma hakkında düşünebilirsiniz. En kolay formda, iki özdeş tablo oluşturun, birincisini kullanın, ikincisine içe aktarın, Drupal yapılandırmanızı ikinci tabloyu kullanmak için değiştirin, 2. tabloyu 1.'e senkronize edin (sonra isteğe bağlı olarak ilkine geri dönün). Özel içe aktarma komut dosyanızda başka bir çözüm, INSERT / UPDATE sorgularını hazırlayın ve gruplandırın, ardından veritabanı yazma süresini azaltmak için yalnızca bir işlemin sonunda gönderin.