Queue

[tempel3]

Ich wollte vorschlagen die Arbeitsschritte aufzuteilen um etwas Performance bei den einzelnen Schritten zu gewinnen.

Ich stelle es mir so vor:

A. Wenn der Crawler ein Ergebnis hat:

1. Link oder File in eine Tabelle/Queue legen ohne etwas zu analysieren
2. Pullen und bei einem Link Bild herunterladen
3. Pullen und mit maschinellen Tags anreichern
4. Pullen und mit Instagram Daten anreichern
5. Bild mit allen Informationen in die Datenbank aufnehmen

B. Wenn ein Bild analysiert werden soll

1. Link oder File in eine Tabelle/Queue legen
2. Pullen und Bild herunterladen wenn Link
3. Pullen und mit maschinellen Tags anreichern
4. Pullen und Empfehlungen berechnen

Die GUI würde dann nicht blokiert werden in der Zeit und man könnte einen Status pro Bild anzeigen.

[DariosKrimsKrams]

Finde ich gut. An welche Stelle kommt der schritt "FolllwerCount zu dem Influencee des Bilder ermitteln"? Ist das Teil von (1)?

[tempel3]

Das fehlte. Instagram Daten würde ich bei A.4. abrufen. Influencees könnte man aber separat analysieren.

[SeidChr]

Ich würde erstmal keinerlei Bilder herunterladen außer denen die der Nutzer schickt. Clarifai versteht links. also sollen die sich darum kümmern (other peoples problem)
Ich glaube dass wir derzeit sehr gut ohne den Follower Count leben können. Tendenziell ist es ja auch positiv wenn ein User viele Follower hat. Irgendwie hat er die ja auch bekommen. Also macht es das bild erfolgreicher. Ich sehe da grad, auch im hinblick auf den Aufwand den es erzeugt, keinen Anlass es gegenzurechnen:
Der Follower Count ist ausschließlich auf der Profil-Seite eines Users zu bekommen.
Da ich derzeit mit dem SpeedCrawler™ so 3 bis 6 erfolgreiche Bilder pro Seitenaufruf mit bis auf Follower Count vollständigen Daten erhalte, und ich für jedes Bild einmal die Userseite aufrufen müsste, würde das den abfrage Aufwand und ggf. auch die Aufmerksamkeit von Instagramm (auf jeden Fall langfristig) deutlich erhöhen.
Was meinst du mit "Pullen" ?
Generelles Queueing können wir gerne machen. Eine Message Queue hatte ich im BigPicture schon angedacht.
Können das noch was aufsplitten in Einzelschritte.

Der Crawler muss 2 dinge können: die Daten zu bestehenden Bildern aktualisieren, und "wild in der Gegend herumcrawlen" um eine möglichst breite datenbasis zu erhalten.
aber aus ihm fallen auf jeden fall die instagram daten und bild-link schon mit raus.
Ggf. wenn letzteres nicht ausrecht. kann man ihm, sofern man dies vorher weiß, mit bestimmten hashtags füttern die man zu finden erwartet, und ihn damit laufen lassen.

PS: vielleicht wäre es cool, wenn der user bei der anfrage fürs bild auch noch ein paar hashtags die er zu sehen erwartet mitgeben kann. so können wir unser matching verbessern

[DariosKrimsKrams]

dass wir ohne FollowerCount leben können, da möchte ich dir widersprechen. Ja, wir könnten, aber ich bin mir sicher, dass die Qualität unserer vorgeschlagenen der Hashtags dadurch besser werden wird.

Zumal es nicht viel Mehraufwand Crawler-seitig sein sollten, den FollowerCount zu ermitteln. Datenbank/Query-seitig habe ich dies auch bereits in meinem relationalen Query berechnet, also hier auch kein Mehraufwand.
Edit: du schriebst "Pro bild die user-seite einmal aufrufen". Was hälst du davon, nach Bild1 auf die User-Seite zu gehen, und dann (von der User-Seite ausgehend) weitere Bilder des Users zu crawlen. So würde nur 1x die Userseite angerufen werden bei beliebig vielen Bildern

[DariosKrimsKrams]

was bilder-runterladen angeht: Ja, finde ich gut

"mit bestimmten hashtags füttern die man zu finden erwartet, und ihn damit laufen lassen." -> Finde ich super. Was hälst du davon, wenn der Crawler eine UI bekommt, wo man ihn manuell bestimmte Hashtags anstoßen kann (ein input, welche Hashtags und ein Count, wie viele maximal dazu gesucht werden soll, z.B. 200 Einträge)

[SeidChr]

Ich finde ein bis zu 6-faches abfrage aufkommen doch etwas mehr als "nicht viel Mehraufwand". Implementierungsseitig ist es (vermutlich) kein Problem. Aber die Anzahl der Abfragen gegen Instagram steigt unverhältnismäßig an, nur um eine kaum feststellbare Verbesserung bei den Ergebnissen zu bekommen.
Wir können vielleicht erstmal eine Referenz auf den Fotografen speichern und dann bei bedarf einfach die Profile auch crawlen. Aber upfront würde ich das nicht machen.

Die UI kann man gern machen. Vielleicht schau ich mir mal das Swagger gerät an und bau damit implizit eine UI :)

[DariosKrimsKrams]

glaube, du hast mich falsch verstanden. Zusätzlich zum random weiter zu crawlen, crawlen wir z.B. pro User maximal 10 seiner Fotos. natürlich den User NUR 1x crawlen. dadurch haben wir 11 Requests, um 10 Fotos zu bekommen. Kann man natürlich auch so erweitern, dass wir uns alle Fotos von ihm holen.