2011-01-17 12 views
8

Prowadzę witrynę do udostępniania obrazów, która ma ponad 1 milion obrazów (~ 150 GB). Obecnie przechowuję je na dysku twardym w moim dedykowanym serwerze, ale szybko brakuje mi miejsca, więc chciałbym przenieść je do Amazon S3.Przeniesienie 1 miliona plików graficznych do Amazon S3

Próbowałem wykonać RSYNC i zajęło RSYNC ponad jeden dzień tylko do skanowania i tworzenia listy plików graficznych. Po kolejnym dniu transferu zostało ukończone tylko 7% i spowolniło mój serwer do indeksowania, więc musiałem anulować.

Czy jest lepszy sposób to zrobić, na przykład GZIP je na inny lokalny dysk twardy, a następnie przenieść/rozpakować ten pojedynczy plik?

Zastanawiam się również, czy sensowne jest przechowywanie tych plików w wielu podkatalogach, czy też dobrze jest mieć wszystkie pliki z milionami w tym samym katalogu?

+3

To nie jest związane z programowaniem. – Alan

+0

Można go uruchomić w nocy, gdy serwer nie jest tak zajęty. Istnieje również "ładne" narzędzie, które może zmniejszyć problem spowolnienia. Ponieważ rsync można skonfigurować tak, aby pomijał duplikaty, prędkość w końcu się poprawi. Zdecydowanie podzielę obrazy na podkatalogi, ponieważ wiele poleceń Linuksa zaczyna się nie udać, gdy pojawi się> 100 000 plików. Kolejny problem, możesz zabraknąć i-węzłów, jeśli masz zbyt wiele plików. –

Odpowiedz

5
  1. zważywszy, że nie istnieją pliki (jeszcze) na S3, wysyłając je jako archiwum powinno być szybsze niż przy użyciu protokołu synchronizacji.

  2. Jednak kompresowanie archiwum nie pomoże (jeśli w ogóle) w plikach graficznych, zakładając, że pliki obrazów są już zapisane w skompresowanym formacie, takim jak JPEG.

  3. Przesyłanie ~ 150 Gb danych zużywa dużo przepustowości sieci przez długi czas. Będzie to takie samo, jeśli spróbujesz użyć HTTP lub FTP zamiast RSYNC, aby wykonać transfer. Transfer w trybie offline byłby lepszy, jeśli to możliwe; na przykład wysyłanie dysku twardego lub zestawu taśm lub dysków DVD.

  4. Umieszczenie miliona plików w jednym płaskim katalogu jest złym pomysłem z perspektywy wydajności. podczas gdy niektóre systemy plików radzą sobie z tym całkiem dobrze z czasami wyszukiwania nazw plików O(logN), inne nie z wyszukiwaniem nazwy pliku O(N). Pomnóż to przez N, aby uzyskać dostęp do wszystkich plików w katalogu. Dodatkowym problemem jest to, że narzędzia, które potrzebują dostępu do plików w kolejności nazw plików, mogą znacznie zwolnić, jeśli muszą sortować miliony nazw plików. (Może to częściowo wyjaśniać, dlaczego rsync zajęło 1 dzień indeksowania.)

  5. Umieszczenie wszystkich plików graficznych w jednym katalogu jest złym pomysłem z perspektywy zarządzania; na przykład do wykonywania kopii zapasowych, archiwizowania, przenoszenia elementów, rozszerzania do wielu dysków lub systemów plików itp.

+0

Czy rozsądne byłoby dzielenie 1m plików na 1000 podkatalogów? Nie ma powodu, aby mieć więcej niż 1 poziom plików? – makeee

+0

Tak, to by było. Można to zrobić na różne sposoby, w zależności od tego, jak są one nazwane i uporządkowane, jak chcesz nimi zarządzać, itp. –

+1

Jeśli mam dzielić pliki, gzip nie wydaje się mieć sensu. może po prostu przejrzeć każdy element w bazie danych, pobrać nazwę pliku, skopiować plik do S3, zmienić jego nazwę na identyfikator mysql autoincrement. Wtedy mogę po prostu podzielić pliki na podstawie ich identyfikatora (plus nie będę już musiał mieć kolumny plików w bazie danych). Nawet jeśli zajmie to miesiąc, mogę przynajmniej zrobić porcję każdego dnia i zacząć czytać od S3 dla plików, które są na S3, i usuwać stare pliki na serwerze, aby zaoszczędzić miejsce. Wydaje się to rozsądne? – makeee

4

Jedną z opcji, którą można użyć zamiast przesyłać pliki przez sieć, jest umieszczenie ich na dysku twardym i wysłanie do usługi Amazon import/export. Nie trzeba się martwić o nasycania połączenia swojego serwera sieciowego itd

+0

Niestety nie jest to opcja, ponieważ nie mam łatwego dostępu do centrum danych, aby zrobić coś takiego. – makeee

25

Jedną z opcji może być przeprowadzenie migracji w leniwy sposób.

  • Wszystkie nowe zdjęcia trafiają do Amazon S3.
  • Wszelkie prośby o zdjęcia, które nie są jeszcze dostępne w serwisie Amazon, powodują migrację tego obrazu do Amazon S3. (w kolejce)

To powinno dość szybko uzyskać wszystkie najnowsze lub najczęściej pobierane obrazy przeniesione do Amazon, a tym samym zmniejszyć obciążenie serwera. Następnie możesz dodać kolejne zadanie, które migruje pozostałe powoli, gdy serwer jest najmniej zajęty.

+1

ładna sugestia! – sdolgy

+2

Ostatnio zastosowałem to podejście, kiedy musiałem przenieść 40 milionów obrazów do S3. Umieściłem kod, którego użyłem na Githubie, mam nadzieję, że ktoś inny uzna to za przydatne: https://github.com/mikery/s3cacher –

+0

Podoba mi się również ten pomysł. Elegancki. –