#1 18. Juni 2012 Datenbankmodell für Soziales Netzwerk Hallo zusammen!, ich überlege mir gerade wie der Datenbankentwurf eines sozialen Netzwerks am besten aussehen sollte. Natürlich ist das jetzt sehr weit aber es geht mir dabei vor allem um ein Detail: Wenn Benutzer in irgendeiner Weise Informationen in das Portal stellen (Kommentare, Bilder/Filme veröffentlichen, Bewertung von dies und jenem, Teilnahme an irgendwas, Hinzufügen weiterer Informationen, usw.. ) kann ich diese zwar recht leicht in passenden Tabellen speichern doch wie erstelle ich am besten einen "Zeitsrtahl" ala Facebook Wall? Ich kann natürlich in all diesen Tabellen nach zurückliegenden Aktivitäten des Nutzers suchen und eine Reihenfolge erstellen doch ist das natürlich nach kurzer Laufzeit des Portals ein performanter Albtraum. Eine andere Mögichkeit wäre, eine separate Tabelle nur für die Benutzeraktivitäten, ohne Details dazu anzulegen: Code: - Zeitpunkt - Benutzer - Aktivitätsschlüssel (NEW_COMMENT,NEW_PICTURE,ADD_EVENT,usw...) - Referenzschlüssel auf den neu enstandenen bzw geänderten Datensatz Auf diese Weise würde es aber eine RIESIGE Tabelle geben. Das kann auch nicht wirklich performant sein zumal recht weit zurücliegende events ja kaum mehr gebraucht werden. Gibt es dazu etwas best-practice mäßiges? Ich bin dabei nicht auf die SQL-Datenbank beschränkt. Wenn es eine Möglichkeit mit Memcached oder dem Dateisystem direkt oder sonst irgendwas gibt wäre das auch gut. Grüße + Multi-Zitat Zitieren
#2 19. Juni 2012 AW: Datenbankmodell für Soziales Netzwerk Dir ist aber schon bewusst das Firmen mit der Größe von Facebook zig hundert Server unterhalten. Als Datenbank Server, Backup Server, Datei Server ..... etc etc .... Load Balancing ist ein Stichwort. Datenbankabfragen werden unglaublich minimiert. Die Datenbank selbst wird Optimiert. Der Code der Software (z.b. Mysql) wird optimiert. Facebook nutzt zum Beispiel eine Art C-PHP Übersetzer, um PHP Code in schnelleren C Code umzuschreiben. Es wird an allen Ecken und Enden gecached und es werden zig Spezialisten bezahlt, die an jedem Fitzelchen Code arbeiten. Server Administratoren, die jede Software und jede Config optimieren. Google hat mir direkt diesen Artikel rausgeworfen: Wie Facebook die Daten von 300 Millionen Nutzern verkraftet Ein anderes Stichwort zu dem Thema ist: Nested Sets – Wikipedia Hoffe ich konnte ein wenig Licht ins dunkle bringen... + Multi-Zitat Zitieren
#3 19. Juni 2012 AW: Datenbankmodell für Soziales Netzwerk Bei sozialen Netzwerken ist das relationale Datenbankmodell (Sprich: Tabellen wie in SQL üblich) nicht wirklich optimal. Gerade in sozialen Netzwerken ist zum Beispiel die Frage "Freunde eines Freundes eines Freundes" interessant. Alleine schon so eine Abfrage führt durch JOINS zu einer mitunter sehr langen Abfrage. Allgemein wirst du spätestens bei der konkreten Umsetzung feststellen dass du gewisse Daten vorhalten möchtest die nicht so recht in eine relationale Datenbank passen wollen. Also meine Empfehlung: NoSQL Datenbanken anschauen (insbesondere Graph Datenbanken) Und da ich nicht bei Facebook angemeldet bin weiß ich leider nicht was die Timeline ist - sorry kann dir da also nicht helfen. + Multi-Zitat Zitieren
#4 19. Juni 2012 AW: Datenbankmodell für Soziales Netzwerk Danke für euer bemühen soweit schonmal! Eine MySQL Datenbank will ich auf jeden Fall benutzen um die Daten normalisiert zu speichern (tut Facebook soweit ich weiß auch). Dass komplexere Abfragen aus dieser Art Datenbank ein Albtraum sind ist klar. Darum geht es mir dabei aber nicht. MySQL soll dazu dienen den "Zustand" des Netzwerks zuverlässig zu speichern, sodass ich im Falle eines Serverausfalls alle Caches und sonstige Backendprogramme wieder mit den Daten aus der MySQL-Datenbank füttern kann. Im produktiven Einsatz will ich Abfragen aus der Datenbank natürlich um alles in der Welt auf ein absolutes Minimum reduzieren. Graphen Datenbanken habe ich mir als Implementierung bei Neo4J schon angeschaut und bin davon begeistert. Da ich aber keine Zeit habe, mich mit diesem, für mich komplett neuem, Thema zu beschäftigen, ist das wohl eine Möglichkeit für die Zukunft. Mit Timeline meine ich eben nur die chronologische Darstellung der Nutzeraktivitäten. Mehr steckt auf bei FB nicht dahinter. Es geht mir eben darum, diese Abfolge von Events effizient den Application-Servern zur Verfügung zu stellen. Für den Fall, dass es jemanden interessiert erleutere ich mal den Ansatz, den ich bislang habe: Als eigenständige Backend-Anwendung werde ich einen Dämon schreiben, der exklusiv alle "EventStreams" von allen Konten verwaltet. Eben nur auf eine zusätzliche und sehr effiziente Weise. Die zugrundeliegenden Daten basieren auf den Daten der MySQL Datenbank. Ich stelle mir das so vor, dass mein eigentliches Backend im Falle einer Nutzeraktivität, diese natürlich in die MySQL Datenbank schreibt, aber auch an den Dämon meldet. Der Dämon führt zunächst eine lange Liste die aus allen Events von allen Konten bestehen. Auf natürliche Weise liegt diese Liste chronologisch vor. Die Listenelemente sind die einzelnen Events in einem kompaktem Datenformat: Code: Timestamp 4 Byte ( UNIX-Timestamp ) Konto 4 Byte ( Konto ID ) EventKey 2 Byte ( Schlüssel für die Art des Events ) RelatedKey 4 Byte ( Referenz auf den betroffenen Datensatz in der MySQL-Datenbank ) Flags 1 Byte ( zB Event ungültig da betroffener Datensatz gelöscht ) Durch diese Liste lassen sich die Events schonmal sehr effizient speichern. Zusätzlich zu dieser Liste, soll der Dämon intern und auch nur zur Laufzeit im RAM Listen von Events, sortiert nach dem jeweiligem Konto vorhalten. Dadurch ist eine Abfrage der Events, die einem bestimmten Konto zugeordnet sind sehr billig. Da natürlich auch dieses Datenformat irgendwann den Speicherbedarf sprengt, werde ich diesen EventStream in Teile zerlegen. Beispielsweise 1.000.000 Events = 1.000.000 * 15 Byte ~ 14 MB. Durch ein gutes Storage-System können diese Fragmente dann sehr effizient den App-Servern zur Verfügung gestellt werden. Kommentare oder mögliche Probleme dazu wären super! :] + Multi-Zitat Zitieren
#5 20. Juni 2012 AW: Datenbankmodell für Soziales Netzwerk Mit welchen Datenmengen planst Du? Die Groessenordnung koennte Dein Aufbau aendern. Bist Du sicher, dass Du 2^16 Arten von Events haben wirst? Erscheint mir als sehr viel. Bzgl. Facebook https://developers.facebook.com/opensource/ Du wirst, wie Facebook, also die SQL-Db nur als Datenspeicherung haben und die (vielen) Requests mittels extrem schnellen Key-Value-Servern (memcached, redis) beliefern. + Multi-Zitat Zitieren
#6 20. Juni 2012 AW: Datenbankmodell für Soziales Netzwerk Ich weiß nicht mit welchen Datenmengen ich wirklich planen soll. Will einfach mit dem ersten Datenbankkonzept möglichst weit kommen. Umstrukturieren kann man dann immer noch. 2^16 unterschiedliche Events werden tatsächlich zu viel sein doch 2^8 denke ich noch recht schnell auszureizen. Und die paar Bits die ich sparen würde wenn ich jetzt anfange die Bytes zu fragmentieren sind den Aufwand echt nicht wert. Deine Aussage was die Key-Value-Server angeht ist aber richtig. Wies aussieht werde ich auch alles an Lesezugriffen auf diese auslagern können. + Multi-Zitat Zitieren