Freunde von Freunden

[franksfotos]

Für einen höheren sozialen Vernetzungsgrad wünscht sich Jaron schon seit langem das "Freunde von Freunden"-Feature. Beim Suchen nach Freunden könnten Vorschläge kommen, die folgendermaßen ermittelt werden können:

• Iteriere über alle meine vorhandenen meine Freunde
• Jeder Freundes-Freund erhöht die Gesamtzahl der Freundesfreunde.
• Filtere nur die Freundes-Freunde, mit denen ich noch nicht befreundet bin
• Präsentiere die Top 3 (oder 5, mal ausprobieren) Noch-Nicht-Freundes-Freunde in einer Liste mit dem "+Add Friends" Button
• Bei Gleichstand: z.B. Nur ein eingener Freund, alle Freundes-Freunde sind 1x vorhanden eine Random Auswahl der Top 3 (oder 5)

[franksfotos]

Beispiel BeReal

[r0bs]

Danke, die Darstellung in der App aus dem Screenshot ist sehr cool zur Orientierung. Ich baue das Feature entsprechend ein

[r0bs]

@franksfotos zur schonung der ressourcen würde ich hier erstmal so vorgehen, dass nicht stets alle freunde von freunden gequeried werden - ich habe z.B. 66 freunde, wenn nun jeder meiner freunde ebensoviel hat, dann holten wir 66^2 namen aus der db um die dann zu sortieren und Y (= 3, =5) abzugreifen - sondern, dass wir random X freunde nehmen und nur für jene die daten aus der db holen (und dann so vorgehen wie von dir aufgezeigt)

ich würde X zum start auf 10 setzen und schauen wie es klappt. es hat so den charmanten effekt, dass nutzer gelegentlich auf dem freunde-such-view vorbeischauen können um neue recommendations zu erhalten

[r0bs]

Erster Wurf ist in der Beta

[franksfotos]

@franksfotos zur schonung der ressourcen würde ich hier erstmal so vorgehen, dass nicht stets alle freunde von freunden gequeried werden - ich habe z.B. 66 freunde, wenn nun jeder meiner freunde ebensoviel hat, dann holten wir 66^2 namen aus der db um die dann zu sortieren und Y (= 3, =5) abzugreifen - sondern, dass wir random X freunde nehmen und nur für jene die daten aus der db holen (und dann so vorgehen wie von dir aufgezeigt)

ich würde X zum start auf 10 setzen und schauen wie es klappt. es hat so den charmanten effekt, dass nutzer gelegentlich auf dem freunde-such-view vorbeischauen können um neue recommendations zu erhalten

Wie schon mitgeteilt, klappt das richtig gut. Den Impact auf die DB Performance kann ich so ganz greifen. Die 66^2 übersteigt ja bei weitem die Nutzerschaft. Ich hätte nicht gedacht, dass eine Datenbankabfrage mit 5000 Einträgen moderne Systeme vor Herausforderungen stellt (bei entsprechender Architektur). Aber wie auch immer - die Tatsache, dass da ein bisschen Varianz in den Empfehlungen ist möchte ich auf jeden Fall nicht missen.

[r0bs]

@franksfotos zur schonung der ressourcen würde ich hier erstmal so vorgehen, dass nicht stets alle freunde von freunden gequeried werden - ich habe z.B. 66 freunde, wenn nun jeder meiner freunde ebensoviel hat, dann holten wir 66^2 namen aus der db um die dann zu sortieren und Y (= 3, =5) abzugreifen - sondern, dass wir random X freunde nehmen und nur für jene die daten aus der db holen (und dann so vorgehen wie von dir aufgezeigt) ich würde X zum start auf 10 setzen und schauen wie es klappt. es hat so den charmanten effekt, dass nutzer gelegentlich auf dem freunde-such-view vorbeischauen können um neue recommendations zu erhalten

Wie schon mitgeteilt, klappt das richtig gut. Den Impact auf die DB Performance kann ich so ganz greifen. Die 66^2 übersteigt ja bei weitem die Nutzerschaft. Ich hätte nicht gedacht, dass eine Datenbankabfrage mit 5000 Einträgen moderne Systeme vor Herausforderungen stellt (bei entsprechender Architektur). Aber wie auch immer - die Tatsache, dass da ein bisschen Varianz in den Empfehlungen ist möchte ich auf jeden Fall nicht missen.

Da hast du recht, das ist keine Frage der technologischen Machbarkeit, aber eine Frage der Kosteneffizienz. In diesem Fall kann die Arbeit nicht vom DB-Server, sondern muss im Applikationscode verrichtet werden ( => separate Anfragen an die DB). Hier stehen also die Kosten von A (=10) Anfragen, der Anzahl der Freunde AF (z.B. 66) gegenüber. Die Kosten steigen linear mit A.

Daher traf ich die Annahme, dass ein hinreichender Nutzen mit einer Limitierung von A (auf. z.B. 10) erreicht werden kann.

Hätte man dieses Access Pattern inital beim Design antizipiert, könnte der Tradeoff hier anders aussehen (weil man z.B. eine andere DB Technologie einsetze). Ohne den technologischen Unterbau zu ersetzen, bleibt uns A einstweilen so einzustellen, dass wir den höchsten Nutzen erreichen. (Was auch heißen kann, dass wir A über die Zeit variieren.)