Importowanie dużych płaskich źródeł danych za pomocą Drupal 7 z integracją Views 3

Moim celem jest stworzenie szybkiej, niezawodnej i zautomatyzowanej metody dostępu do danych tylko do odczytu zawartych w kilku bardzo dużych źródłach danych o płaskich plikach ( CSV , stała szerokość i dokumenty XML) za pomocą Drupal 7, do których można uzyskać zapytanie przy użyciu Widoku 3 moduł. Wolałbym używać już dostępnych modułów, ale zbudowanie niestandardowego modułu jest również opcją.

Aby wykluczyć moduły i metody nieodpowiednie dla tego zadania, oto statystyki plików, z którymi pracuję:

• Roczny import: 8 500 000 linii pliku CSV . (Oczyszczane i ładowane co roku. Ma klucz podstawowy.)
• Cotygodniowy import: plik o stałej szerokości 350 000 linii. (Oczyszczane i ładowane co tydzień. Brak klucza podstawowego .)
• Import godzinowy: 3400 linii pliku CSV . (Chciałbym aktualizować i synchronizować tak często, jak to możliwe, ale nie częściej niż co 20 minut. Ma klucz podstawowy)
• Codzienny import: plik XML 200 pozycji. (Codziennie czyszczone i ładowane ponownie. Ma klucz podstawowy)

Konwersja między tymi trzema formatami nie stanowi problemu i można tego dokonać, jeśli poprawi to wydajność importu lub umożliwi udostępnienie lepszych narzędzi. ( AWK dla stałej szerokości do CSV itp.) Automatyzacja pobierania i konwersji jest łatwa dzięki skryptom cron i sh , ale nadal wymaga automatyzacji integracji Drupal 7. Korzystanie z tabel niestandardowych jest również możliwe, o ile vews mogą odwoływać się do danych za pomocą relacji.

Jaka byłaby najlepsza praktyka do osiągnięcia tego rodzaju integracji danych z Drupal 7? Czy pomijam również ważne szczegóły dotyczące danych lub tego, co próbuję osiągnąć?

Oto kilka projektów, nad którymi obecnie szukam rozwiązania. Chciałbym rozwinąć tę kwestię, aby pomóc innym w podjęciu decyzji, którą wybrać drogę podczas importowania większych danych.

Importowanie danych do węzłów:

• Kanały (obecnie Alpha dla D7)

Kanały będą niezawodnie importować dane. Prędkość jest rozsądna w przypadku mniejszych źródeł danych, ale jest zbyt wolna w przypadku tabel o wielkości 300 000+.

Automatyzacja dostępna za pomocą cron i Job Scheduler (obecnie Alpha dla D7).

• Migrować

Brak dostępu do indeksu lub unikalnego klucza w danych źródłowych utrudnia korzystanie z niego. Jest szybszy niż kanały, ale wciąż wolno importuje bardzo duże tabele.

Automatyzacja jest dostępna za pośrednictwem drush i cron.

Niestandardowe tabele zamiast węzłów

• Moduł danych (obecnie Alpha dla D7)

Moduł danych wygląda bardzo obiecujące, ale jest bardzo buggy dla D7 w tej chwili. Wymagania dotyczące automatyzacji i prędkości importu można łatwo spełnić przy użyciu danych, ale brakuje niezawodności. Integracja widoki (link jest na D6) wygląda bardzo obiecująco.

• Kreator tabel (niedostępny dla D7)

Dodano to w celach informacyjnych. W tym momencie nie ma kandydata na D7, ale mógłby służyć jako punkt wyjścia dla niestandardowego modułu.

• Schemat widoków (porzucony, tylko D6)

Dodano to w celach informacyjnych. Wygląda na to, że został zaabsorbowany przez Kreatora tabel w Drupal 6. Ponownie, dodano tylko w celach informacyjnych.

• Importer (RC2 dla D7)

Wydaje się, że wymaga integracji Kreatora tabel (tylko D6) do integracji widoków . Dodano w celach informacyjnych, ale nie spełnia wymagań Widoku.

@MPD - Dodano „Tabele niestandardowe” jako możliwe rozwiązanie i rozbudowano moduły. Dziękuję za ten dodatek.

Mój brzuch mówi mi, że ten plan spowoduje, że twoje serwery zapalą się ...

Poważnie, jeśli gromadzisz tyle danych, myślę, że musisz przechowywać dane w zewnętrznym źródle danych, a następnie zintegrować je z Drupal.

Początkowo myślałem, że użyję dwóch baz danych dla danych zewnętrznych, abyś mógł cotygodniowy import bez przeszkadzających rzeczy. Innymi słowy, uruchom bazę danych A i uruchom ją, a następnie zaimportuj do B. Po zakończeniu importu ustaw B jako źródło na żywo. Następnie wyczyść i zaimportuj do A.

Dokonałem dużej integracji zewnętrznych źródeł danych z Drupalem i to naprawdę nie jest takie trudne. Omówiłem w Planie przejścia abominację PHP5 do Drupala . Tak było w przypadku Drupala 6, ale to samo zasadniczo dotyczy Drupala 7. Zasadniczo symulujesz, co CCK / Fields API robi z twoim własnym interfejsem.

Jednak brak identyfikatora UUID dla cotygodniowej bazy danych naprawdę wrzuca klucz do prac. Ta część wymaga jednak wielu innych, które można uzyskać na takim forum pytań i odpowiedzi.

Jeśli naprawdę chcesz pójść ścieżką importu, zapłaciłbym kaucję za Feeds i Migrate i napisałem własny skrypt importu. Zasadniczo wykonujesz początkowy proces tworzenia paska z pliku index.php, przeszukujesz źródło danych, tworzysz węzły, a następnie je zapisujesz. Programowe tworzenie węzłów jest łatwe.

Najlepszym sposobem na rozpoczęcie jest utworzenie węzła z interfejsem użytkownika, a następnie print_r i zreplikowanie obiektu za pomocą kodu w skrypcie importu. Taksonomia, pliki i noderefy to twarde części, ale musisz tylko zapoznać się z tymi częściami interfejsu API, aby zbudować te właściwości obiektu. Gdy masz już prawidłowy obiekt węzła, możesz po prostu wykonać node_save (). Upewnij się, że ustawiłeś bardzo duży limit za pomocą set_time_limit (), aby skrypt działał.

EDYTUJ PONIŻEJ, ABY ADRESOWAĆ WYJAŚNIENIE / ROZSZERZENIE:

Osobiście przestaliśmy używać podejść opartych na module contrib do importowania danych jakiś czas temu. Działają one głównie dobrze, ale skończyło się na tym, że spędziliśmy z nimi zbyt dużo czasu na walce z nimi i zdecydowaliśmy, że koszt / korzyść są zbyt niskie.

Jeśli naprawdę potrzebujesz danych w Drupal, to moja opinia na temat niestandardowego skryptu importu się nie zmieniła. Jeden z modułów, do których się odwołujesz, może być używany jako punkt wyjścia do budowania obiektów węzłów, a następnie po prostu zapętlaj węzły kompilacji danych i zapisuj je. Jeśli masz PK, możesz łatwo dodać logikę, aby przeszukać bazę danych i node_load (), zmodyfikować i zapisać. Skrypt importu to tak naprawdę tylko kilka godzin pracy, jeśli znasz interfejs API Drupala.

Jeśli integracja widoków jest kluczem (i wydaje się, że opiera się na edycji) i chcesz zastosować podejście do tabel zewnętrznych, wtedy najlepszą opcją jest wykonanie niestandardowego modułu i wdrożenie hook_views_data, aby uzyskać dane w widokach. Jest bardziej niż prawdopodobne, że i tak dostosujesz moduł do obsługi źródła danych, więc dodanie tego haka nie powinno być o wiele więcej pracy. Moduły TW i Data powinny mieć jakiś przykład na początek.

Osobiście jednak nigdy nie uważałem integracji widoków z danymi zewnętrznymi za naprawdę wartościową. W przypadkach, w których to rozważałem, dane były po prostu zbyt „różne”, aby dobrze działać z podejściem opartym na widokach. Po prostu używam metody opisanej w linku „obrzydliwość” powyżej.

Myślę, że podejście oparte na węzłach (a nawet na jednostkach) wypali twój serwer milionami węzłów. Poza tym, patrząc na import co godzinę, oznacza to, że będziesz tworzył node_save () przynajmniej raz na sekundę. To za dużo dla Drupala i powoduje problem z wydajnością.

Powodem tego jest to, że nie potrzebujesz żadnego mechanizmu zaczepu, nie potrzebujesz pathauto (ale możesz ręcznie utworzyć alias, jest znacznie tańszy niż pathauto), nie potrzebujesz pól ... Napisz proste zapytanie „INSERT” jest 100 razy szybsze niż node_save () lub entity_save ().

1 / IMHO najlepszą opcją jest niestandardowa tabela i niestandardowy moduł do importu danych, a następnie napisz moduły obsługi widoków do integracji z Drupal.

2 / Pamięć podręczna bazy danych jest unieważniana podczas importu co godzinę. Jeśli zajmuje to zbyt dużo czasu, możesz pomyśleć o replikacji. W najprostszej formie utwórz dwie identyczne tabele, użyj pierwszej, zaimportuj do drugiej, przełącz konfigurację Drupala na drugą tabelę, zsynchronizuj drugą tabelę z pierwszą (następnie opcjonalnie przełącz z powrotem do pierwszej). Innym rozwiązaniem jest niestandardowy skrypt importu, przygotuj i zgrupuj zapytania INSERT / UPDATE, a następnie wyślij je na końcu tylko w jednej transakcji, aby skrócić czas zapisu bazy danych.