Wie sollte ich diese Datenbank verwalten?

Question

Ich habe ein Projekt von einem Kunden übernommen, bei dem ich einen Backend-Server und eine API (PHP) mit Kommunikation zu/von einer iOS-App einrichten muss. Ich kann nicht zu sehr ins Detail gehen über die App, aber zum größten Teil ist es sozial basiert und erfordert daher mich ständig die Datenbank nach Erhalt einer Anfrage zu aktualisieren.

Derzeit besteht die Datenbank aus drei Tabellen (eine vierte wird demnächst für Kommentare hinzugefügt): Benutzer, Veranstaltungsorte und Warteschlangen. Im Moment rufe ich bei jeder Anfrage einfach die entsprechenden Daten aus der Datenbank ab, aber ich beginne mich zu fragen, ob ich anfangen muss, Methoden zur Verbesserung der "Skalierbarkeit" der Datenbank zu implementieren oder (so etwas wie) Memcachd oder Redis zu verwenden, um etwas zu verbessern. Ist dies notwendig, da es sich um eine soziale App handelt, die potenziell eine große Nutzerbasis hat? Und verwende ich eine gute, leistungsfähige Datenbank für Hunderte von Anfragen pro Sekunde, oder sollte ich zu einer anderen wechseln?

Vielen Dank im Voraus,

Max.

P.S. Sie können meine Struktur gerne auseinandernehmen, ich habe sie in den Beitrag gestellt, falls jemand Interesse daran hat, sie sich anzusehen!

CREATE TABLE `Queues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userID` int(11) NOT NULL,
  `Creation_Date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  `venueID` int(11) NOT NULL,
  `Wait_Time` int(10) NOT NULL,
  `Line_Length` int(10) NOT NULL,
  `Note` varchar(250) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=13 ;

CREATE TABLE `Users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `First_Name` text NOT NULL,
  `Last_Name` text NOT NULL,
  `Username` text NOT NULL,
  `Password` text NOT NULL,
  `Email` text NOT NULL,
  `Signup_Method` text NOT NULL,
  `Signup_Date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Number_of_Lines` int(11) NOT NULL,
  `Number_of_Venues` int(11) NOT NULL,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=27 ;

CREATE TABLE `Venues` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `userID` int(11) NOT NULL,
  `foursquareID` int(11) NOT NULL,
  `Name` text NOT NULL,
  `Latitude` text NOT NULL,
  `Longitude` text NOT NULL,
  `Address_Line1` text NOT NULL,
  `Address_Line2` text NOT NULL,
  `Post_Code` text NOT NULL,
  `Country` text NOT NULL,
  `Description` text NOT NULL,
  `Created_At` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  `Last_Updated` timestamp NOT NULL DEFAULT '0000-00-00 00:00:00',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=2 ;

Answer 1

Sie können sich über Caching-Methoden erst dann Gedanken machen, wenn es nötig ist. In der Zwischenzeit sollten Sie sicherstellen, dass Ihre Datenbank ordnungsgemäß normalisiert ist. Sobald die Website reibungslos funktioniert und an Popularität gewinnt, wird das Einbinden von Memcached eine relativ triviale Aufgabe sein.

Mir ist aufgefallen, dass eine Warteschlange einem anderen Benutzer gehören kann als dem Benutzer, dem der Veranstaltungsort der Warteschlange gehört: Queues.userID y Venues.userID über Queues.venueID . Wenn Sie dies nicht wünschen, sollten Sie die Queues.userID da die Benutzerinformationen über den Veranstaltungsort der Warteschlange abgerufen werden können.

Außerdem, wenn Users.Number_of_Venues ist eine Zählung der Anzahl von Venues mit einer gewissen userID entfernen Sie sie, da es keinen Grund gibt, sie zu speichern, da diese Informationen durch eine schnelle COUNT(*) . Sie zu verlassen, würde einen Mangel an Normalisierung bedeuten.

Sobald Ihr Schema festgelegt ist, denken Sie daran richtig indizieren . Das wird Ihre Abfragen erheblich beschleunigen.