Datenbank für eine Instagram ähnliche App

A

andrejedd

Benutzer
Beiträge
9
Hallo zusammen

Ich und ein Freund wollten mal eine Instagram ähnliche App entwickeln um Know-How in diesem Bereich aufzubauen. Wir haben idese Entwicklung gestoppt und nun wollen wir weiter machen.

Nun sind unklarheiten bezüglich der Datenbank aufgetreten. Wie verwaltet man das am besten? Wie würde das Instagram tun?
- Wo werden die Benutzerdaten gespeichert (username, password, email,...) ?
- Wo werden die Profilinformationen abgelegt?
- Bilder?
- Tags?
- Kommentare?
- Abonennten?
- Aktivitäten (wer, was von dir geliked, kommentiert hat, wer dich abonniert hat, markiert hat,...)?

Ich wollte dies mal nachstellen und habe alles eigendlich mit MySql umgesetzt ausser die Poriflinformationen.
Die Profilinformationen wurden in einem TXT-File abgelegt welches gleich benannt ist wie die unique user id um die richtigen Informationen für den richtigen Benutzer ganz einfach zu finden.

Ich nehme mal an, das dies aber nicht so simepl aufgebaut ist wie ich das getan habe. Nun spiele ich mit den gedanken das die Profilinformationen besser in einer MongoDb abgelegt werden um die Sache zu verschnellern. Aber wäre dies dann wirklich schneller oder langsamer?

Welche Datenbanken würdet ihr für was einsetzten und welche Tabellen bei welcher Datenbank?
 
Werbung:
Wieso alles ausser die Profildaten in eine DB? Ich würde keine unterschiedlichen Datenspeicher verwenden, wenn es geht.

Du solltest dir erstmal Gedanken über die Anforderungen der Applikation machen bevor du dir überlegst, welche DB du nutzt.
 
Die DB dient als Hauptspeichermedium. Bei FB ist es mir bekannt das die einzelnen Profile der Benutzer in Files abgelegt werden. Ob es nun wirklich einzelne TXT-Files sind oder eine File-DB weiss ich nicht. Diese Information habe ich von einem alten Mitarbeiter, welcher mal als Freelancer bei FB gearbeitet hat. Nun dachte ich mir, wenn es Facebook so gemacht hat, sollte es kein schlechter Ansatz sein so auch für Instagram zu erledigen. Ist es nicht so das die einzelnen Services teilweise nicht die selbe Datenbank dahinter haben? z.B. die Authentifizierungs Datenbank ist anders als die Datenbank wo normale Benutzerdaten sind?
 
Wie gesagt, es kommt auf die Anforderungen an und nicht wie es jemand anderes einmal gemacht hat (der evtl. andere Anforderungen hat).
 
Ja was für eine Anforderung kann eine Applikation wie Instagram haben. Die möglichkeit jegliche Daten zu storen (Strings, Images, ints) und die performance natürlich.
 
Werbung:
Also zunächst einmal verfolgt SQL einen relationalen Ansatz Daten abzubilden. Das hat Vorteile vor allem bei der Auswertbarkeit und Verknüpfung von Informationen. Es kann (die Betonung liegt auf kann) aber langsammer sein als alle Informationen z.B. in einer XML Struktur zu speichern. Das hängt davon ab wie die Informationen benötigt werden - bei Profilen z.B. gerne alles zu einer Person auf einmal, egal welcher Art diese Information ist.

SQL ist etabliert, gut dokumentiert und verständlich. Wenn du deine Daten sauber normalisierst wirst du viel dadurch lernen. Du wirst auch unterhalb der x-Millionen User keine Probleme mit der DB bekommen wenn du eine gute wählst (vielleicht darfs von Anfang an etwas besseres als MySQL oder seine Klone wie MariaDB, ich würde bei soetwas gleich mit Postgre anfangen).

Natürlich kannst du auch gleich unter der Annahme einsteigen das jetzt alles wahnsinnig schnell werden muss und deine Userzahlen explodieren. Du kannst auch gleich dein eigenes Filesystem entwickeln wie Google das tut und dein eigenes RZ planen. Aber eventuell schafft man sich erstmal eine saubere Datenbasis die man versteht und durchblickt.

Not-only-SQL Datenbanken sind aus meiner Sicht eher ein Trend. Natürlich haben diese auch ihre Daseinsberechtigung und sich damit zu befassen ist nicht verkehrt. "Besser" ist das aber vermutlich nicht, nur anders.
 
Zurück
Oben