Strategia buforowania usługi zdalnej; co powinienem wziąć pod uwagę?

Question

Moja aplikacja internetowa zawiera dane zebrane z zewnętrznego interfejsu API, którego nie kontroluję. Ograniczam się do około 20 000 żądań interfejsu API na godzinę. Mam około 250 000 pozycji w mojej bazie danych. Każdy z tych elementów jest zasadniczo wersją buforowaną. Weź pod uwagę, że potrzeba 1 żądania aktualizacji pamięci podręcznej o 1 pozycji. Oczywiście w tych okolicznościach nie jest możliwe posiadanie doskonale aktualnej pamięci podręcznej. Więc, co należy wziąć pod uwagę przy opracowywaniu strategii buforowania danych. Są to rzeczy, które przychodzą na myśl, ale mam nadzieję, że ktoś ma dobre pomysły, o których nie myślałem.

• czas ponieważ pozycja została stworzona (mniej czasu oznacza ważniejszą)
• liczbę „lubi” konkretny przedmiot (może oznaczać większe prawdopodobieństwo oglądanego)
• czasu od ostatniej zaktualizowanej

Jeszcze kilka szczegółów: przedmiotem są zdjęcia. Każde zdjęcie należy do wydarzenia. Zdarzenia, które obecnie występują, są bardziej podobne do klientów (dlatego powinny mieć priorytet). Chociaż mam teraz tylko 250 000 pozycji w bazie danych, liczba ta rośnie dość szybko (nie potrwa długo, zanim osiągnie milion znaków, może 5 miesięcy).

Answer 1

Czy może być użyty jako http://instagram.com/developer/realtime/? Wygląda na to, że Instagram chce POST na twój serwer, gdy są nowe (i być może zaktualizowane?) Obrazy do sprawdzenia. Czy to wystarczy?

W przeciwnym razie, wydaje mi się, że twój problem brzmi podobnie do problemu, który ma każda wyszukiwarka - czy widziałeś już Wikipedia on crawler selection criteria? Masz do czynienia z wieloma problemami, przed jakimi stoją roboty sieciowe: co przeszukiwać, jak często je indeksować i jak unikać tworzenia zbyt wielu żądań do pojedynczej witryny. Możesz również spojrzeć na open-source crawlers (na tej samej stronie), aby uzyskać kod i algorytmy, których możesz nauczyć się.

Zresztą wyrzucić jakieś przemyślenia na temat standardów przeszukiwania:

• Aktualizuj rzeczy, które uległy zmianie, gdy często aktualizowana. Jeśli więc pozycja nie zmieniła się w ostatnich pięciu aktualizacjach, to możesz założyć, że nie zmieni się tak często i nie zaktualizuje go.
• Utwórz ocenę dla każdego obrazu i zaktualizuj te z najwyższymi wynikami. Lub najniższe wyniki (w zależności od rodzaju wyniku, którego używasz). Jest to podobne myśl do tego, co jest używane przez LilyPond do typeset music. Niektóre sposoby tworzenia danych wejściowych dla takiego wyniku:
  • Statystyczny model szansy na aktualizację obrazu i konieczność jego usunięcia.
  • Wynik ważności dla każdego obrazu, wykorzystujący rzeczy takie jak aktualność obrazu lub waluta jego wydarzenia.
• Aktualizuj często przeglądane rzeczy.
• Zaktualizuj elementy, które mają wiele widoków.
• Czy czas ma wpływ na prawdopodobieństwo, że obraz zostanie zaktualizowany? Wspomniałeś, że nowsze zdjęcia są ważniejsze, ale co z prawdopodobieństwem zmian na starszych? Zwolnij częstotliwość kontroli starszych zdjęć.
• Przydziel część swoich próśb o powolne aktualizowanie wszystkiego i podziel inne części, aby przetwarzać wyniki z kilku różnych algorytmów jednocześnie.Tak na przykład, masz następujące (numery są tylko dla pokazu/przykładu - po prostu wyciągnąłem je z kapelusza):
  • 5000 żądań na godzinę ubijanie całej zawartości bazy danych (o ile mają nie został zmodernizowany, ponieważ ostatni raz, że robot przedziera)
  • 2500 przetwarzania żądań nowych obrazów (które wymienione są ważniejsze)
  • 2500 rozpatrywania wniosków obrazów bieżących wydarzeń
  • 2500 wnioski przetwarzania obrazów, które są w górze 15 000 najczęściej oglądanych (o ile nastąpiła zmiana w ostatnich 5 sprawdzeniach tego obrazu, w przeciwnym razie sprawdź to w malejącym harmonogramie)
  • 2 500 żądań przetwarzania obrazów, które zostały obejrzane co najmniej
  • Razem: 15 000 próśb na godzinę.

Answer 2

Ile (niepowtarzalny) zdjęcia/zdarzenia są wyświetlane na swojej stronie na godzinę? Te zdjęcia, które nie są oglądane, prawdopodobnie nie muszą być często aktualizowane. Czy widzisz jakieś wzory w widokach starych wydarzeń/telefonów? Stare wydarzenia mogą nie być tak popularne, więc być może nie trzeba ich często sprawdzać.

andyg0808 ma dobre szczegółowe informacje, ale ważne jest, aby znać wzorce wykorzystania danych przed zastosowaniem w praktyce.

W pewnym momencie okaże się, że 20 000 żądań interfejsu API na godzinę nie wystarczy do aktualizacji często przeglądanych zdjęć, co może prowadzić do różnych pytań.