mixmastertobsi: MySQL MariaDB peformance

Hallo,

wir nutzen als DB System MariaDB und sind eigentlich mit der Performance zufrieden, doch könnte es schon noch etwas schneller sein. Ich habe bereits alles Abfragen mit Explain und Indexes optimiert, allerdings ist die Datenbank inzwischen schon so groß, dass wahrscheinlich langfristig die Größe eine Problem sein kann.

Nun bin ich auf noSQL gestoßen - sollte ich mich mit dem Thema mal beschäftigen, weil das die Zukunft ist, oder was könnt Ihr empfehlen?

Es gibt wohl auch für MYSQL ein JAVA Caching-System. Was haltet Ihr davon?

  1. hi,

    Es gibt wohl auch für MYSQL ein JAVA Caching-System. Was haltet Ihr davon?

    Was nützt denn ein Cache wenn die erste Abfrage so lange dauert, daß manch einer die Lust verliert auf die Antwort zu warten?

    MfG

    1. Was nützt denn ein Cache wenn die erste Abfrage so lange dauert, daß manch einer die Lust verliert auf die Antwort zu warten?

      Naja. Lieber einen darüber verlieren und die folgenden 10K erfreuen, statt die 10K + 1 zu vergraulen.

      Davon abseits gibt es Konzepte wie cache warming, um genau dem zu begegnen.

  2. Mir scheint Dein Anliegen zu unspezifisch. Erst, wenn Du genau identifiziert hast, wo genau warum welcher Flaschenhals besteht (oder wegen mir auch in der Pipeline ist), kannst Du Überlegungen anstellen, wie damit umzugehen ist.

    allerdings ist die Datenbank inzwischen schon so groß, dass wahrscheinlich langfristig die Größe eine Problem sein kann.

    scheint mir keine geeignete Grundlage für weitergehende Überlegungen.

    Es gibt wohl auch für MYSQL ein JAVA Caching-System. Was haltet Ihr davon?

    Mysql (MariaDB) hat einen guten Query-Cache. Wenn der zu selten antworten sollte: gucken, warum. Zu wenig RAM? Doofe Config?...

  3. Hallo mixmastertobsi,

    sich mit NoSQL zu beschäftigen ist sicher kein Fehler. Zumindest weißt Du dann, wo die Stärken und Schwächen liegen.

    Ich selbst habe das noch nicht gemacht; ich weiß nur, dass es zwei Deutungen des Begriffs gibt: "NO SQL" = Datenbank, die nicht per SQL zugreift und "NOT ONLY SQL" = Datenbank, die zwar SQL kann, aber mit den technischen Zusagen eines RDBMS bricht, um Performance zu gewinnen.

    Die Kritik an SQL DBs ist dabei, dass sie entweder gut darin sind, viele kleine Transaktionen zu bedienen und dann auch Updates gut abkönnen, oder aber große Batch-Transaktionen mit seltenen Updates zu fahren. Große Datenmengen liefern bei häufigen Updates bringt ein RDBMS in die Knie. Das sind unterschiedliche Optimierungsziele, die man nicht gleichzeitig erreichen kann (Quelle: Wikipedia NoSQL Artikel).

    NoSQL reduziert die Konsistenzgarantien und ermöglicht damit bessere Konkurrenz von Updates und SELECTs, ich kann mir aber vorstellen, dass einige Programmiermuster, die wir von ACID-unterstützenden RDBMS her kennen, dann scheitern und dass man die speziellen Eigenschaften eines NoSQL Systems genau kennen muss, um zu wissen, ob man die Programmierung bestimmter DB-Zugriffsmodule ändern muss oder nicht.

    Wie ist denn deine Architektur?

    • Webserver und SQL Server auf der gleichen Maschine?

      • wenn nicht: Machst Du viele kleine Abfragen und "von-Hand" Joins? Das Problem ist hier: Serverübergreifende Zugriffe haben Netzwerk-Overhead, und da lautet die Regel "be chunky, not chatty", d.h. ein großer Zugriff kann besser sein als viele kleine Zugriffe. Hier können ggf. Routinen helfen.
      • wenn ja: Ist der Server überlastet? Es gibt nur eins, was einer DB mehr nützt als viel RAM: Noch mehr RAM. Und vielleicht noch ein paar CPU Kerne.
    • Bist Du allein auf deinen Maschinen oder gibt es auch noch andere User (Shared Hosting)? Ist ein Konkurrent unterwegs, der Dir die Performance absaugt?

    • Manchmal kann es helfen, die typische Zweischichten-Architektur zu einer Dreischichten-Architektur zu erweitern. Man trennt dann die Business-Logik von der Darstellungs-Logik, d.h. Du hättest einen Web-Server, einen Application-Server und den Database-Server. Das lohnt aber eigentlich nur bei sehr vielen Anwendern, oder wenn man Security-Anforderungen hat die mit einer Firewall zwischen Web und App gelöst werden können.

    Rolf

    --
    sumpsi - posui - clusi