Ich denke, anstatt eine einzige friendRelations-Tabelle mit einer Liste von Beziehungen aller Benutzer in meinem Netzwerk zu pflegen, wäre es besser, eine separate Relationstabelle für jeden Benutzer im Netzwerk, die profileIDs von allen enthält Personen & Gruppen, die der Benutzer wählt, um zu folgen. Auf diese Weise wäre das Retreival viel schneller ... alle Vorschläge wären sehr willkommen ... !!Friend Relationships in einem sozialen Netzwerk
Denken Sie daran, dass Datenbanken im Allgemeinen ziemlich gut indexieren (vorausgesetzt, Sie geben ihnen geeignete Spalten zum Indexieren), so dass der Abruf für einen bestimmten Benutzer in jedem Fall schnell sein sollte. Das Erstellen von Bazillion-Tabellen kann insgesamt langsamer sein.
Ich erwarte von diesem Netzwerk eine große Benutzerbasis wie (ich würde sagen in Millionen (s) ..) und unter der Annahme, dass ein einzelner Benutzer über durchschnittliche Benutzer verfügt. 50 Freunde, die Größe des Tisches kann über 50 Millionen Zeilen betragen ... Denkst du nicht, dass ich eine bessere Lösung als einen einzigen "Friends" -Tisch mit 50 Millionen Zeilen benötige, um die Freundesliste eines Benutzers zu berechnen? Würdest du empfehlen, nach NoSQL-Lösungen zu suchen, oder kann MySQL dieses Problem und nachfolgende Probleme wie JOINS mit der Posts-Tabelle umgehen, um den Post für die Generierung von Newsfeeds zu berechnen. Vielen Dank für Ihre Antwort ..! –
Das Beste, was Sie tun können, ist, zuerst einige Leistungstests durchzuführen. Wenn Ihre Datenbank eine akzeptable Leistung mit einer Tabelle dieser Größe aufweist, sind Sie fertig. Wenn nicht, versuchen Sie es mit einer anderen Datenbank - einige sind leistungsfähiger als andere mit großen Tabellen. Seien Sie vorsichtig mit Ihrer Indizierung: Indizes sind der Schlüssel (wenn Sie das Wortspiel entschuldigen). Wenn andere Datenbanken immer noch nicht funktionieren, sollten Sie sich andere Optionen ansehen. –
vielen dank! –
Wenn Sie Leistungsprobleme mit Ihren Datenbankabfragen zum Abrufen von Informationen haben, empfehle ich Ihnen dringend, die Vertica-Datenbank zu verwenden, die unglaublich schnell ist.
Dies scheint eine drastische Designentscheidung zu sein, um ein Problem zu eliminieren, das wahrscheinlich nicht existieren wird. Da Sie sehr wenig darüber wissen, wie Ihre Datenbank aufgebaut ist und auf welche zugegriffen wird, ist es unmöglich zu sagen, ob dies eine schlechte Entscheidung ist (wahrscheinlich) oder ob Ihre Geschäftsanforderungen einzigartig sind und dies die Lösung (unwahrscheinlich) ist. Ich empfehle Ihnen, den Grad der Normalisierung zu ermitteln, den Sie benötigen, und versuchen Sie nicht, Leistungsprobleme zu beseitigen, die noch nicht vorhanden sind.
Vielen Dank Geo für Ihre Eingaben .. –
Vielen Dank! Ich erwarte, dass dieses Netzwerk eine große Benutzerbasis hat (ich würde sagen in Millionen (s).) Und davon ausgehen, dass ein einzelner Benutzer über durchschnittliche Benutzer verfügt. 50 Freunde, die Größe des Tisches kann über 50 Millionen Zeilen betragen ... Denkst du nicht, ich würde eine bessere Lösung brauchen als eine einzelne "Friends" -Tabelle mit 50 Millionen Zeilen, um die Freundesliste eines Benutzers zu berechnen. Würdest du empfehlen, nach NoSQL-Lösungen zu suchen, oder kann MySQL dieses Problem und nachfolgende Probleme wie JOINS mit der Posts-Tabelle umgehen, um den Post für die Generierung von Newsfeeds zu berechnen. Vielen Dank für Ihre Antwort ..! –
Das ist eigentlich eine schreckliche Idee. Wenn Sie eine angemessene Indexierung und Zwischenspeicherung benötigen, sollten Sie Ihre Leistungsprobleme beheben. –
Verwenden Sie ein Notebook mit einem Benutzer auf jeder Seite. Es dauert länger, durch die Seiten zu blättern, als wenn Sie jede Zeile auf der Seite ausgefüllt hätten. Sergey ist richtig mehrere Tische ist eine schreckliche Idee. –
Vielen Dank für die Aktualisierung meines Wissens .. –