Serverabschaltung durch Provider ohne Vorwarnung da zu viel HD Last???

GwenDragon

Registered User
@Muenzenwert Bis die Seite Content generiert hat bei einer Suche kann es bis zu 1 Minute dauern.

Ist die Datenbank so schlecht indiziert? oder sind die Einstellungen der DB nicht optimal?
 

Muenzenwert

New Member
@GwenDragon
es kommt darauf an wie man sucht..
Je weniger Daten man liefert, je allgemeiner Suchbegriffe sind, desto mehr Verkaufstexte müssen über Volltextsuche geprüft werden. In einer Tabelle mit 30 Millionen Records passiert das nicht in ein paar Sekunden. Für Volltextsuche gibt es nicht wirklich gute Indexes, InnoDB z.B. bietet keinen Index dafür an. Treffer werden anschließend berechnet, hat man 200000 Verkäufe gefunden werden daraus Durchschnittspreise je Jahr, Material, Nominal, Erhaltungsgrad, Verkaufsland, Verkaufskanal usw. berechnet plus eine entsprechende Preisentwicklung über die Zeit.. da kommen ein paar Sachen zusammen.
DB ist aktuell mit 100KB Cache nicht optimal, wird kommende Woche noch auf 20GB erhöht, zumindest müssen dann nur wenige Daten von der Platte gelesen werden.
Sobald nach "sinnvollen" Werten gesucht wird sollte es schneller gehen, z.B. Herstellungsjahr -> Suche über das Jahr mit Integer Index, Nominal, Währung, Zeitperiode, .... der Suchtext wird auf Hinweise analysiert.. gibt man BRD ein muss man keine Münzverkäufe von 1800 mehr ansehen.. sucht man 5 Mark dann kann man über Nominal und Währung im ersten Schritt filtern (Integer oder Text mit entsprechenden Index)
Ergebnisse werden in einem Cache gespeichert, Suchen sind nur beim ersten mal evtl. langsam..
Die Suchen der User werden gespeichert und Backend generiert dann regelmäßig alle Suchen die mehr als 2 mal in den letzten 6 Monaten gemacht wurden -> Einfache Suche über Index -> normalerweise so 0.1 bis 0.2 Sekunden.

Nach was hast Du denn gesucht?
 

DeaD_EyE

Blog Benutzer
Habe es schon wieder vergessen und möchte jetzt nicht nochmal alle Posts durchlesen.
Falls du nur Webspace gemietet hast, brauchst du den Rest nicht mehr zu lesen.
Es würde eine weitere Datenbank erfordern.

Das Problem, dass du hast, ist schon sehr oft gelöst worden.
Stichpunkt: Hashtables und Suchindex aufbauen

Python:
In [22]: d = {x: None for x in range(int(1e7))}                                                                                    

In [23]: len(d)                                                                                                                  
Out[23]: 10000000

In [24]: %timeit 6666 in d                                                                                                        
39.2 ns ± 0.104 ns per loop (mean ± std. dev. of 7 runs, 10000000 loops each)
40 ns um 6666 in einer Hashtable zu finden, die aus 1e7 Einträgen besteht.

1e8 Einträge konnte ich jetzt leider nicht testen, da er schon anfing wie blöde zu swappen :-D


Es würde helfen, wenn du so etwas wie einen Suchindex hast und das am besten key-value basiert, da der Lookup O(1) ist.
Dann muss einmal für alle Daten ein Suchindex erstellt werden. Die Keys sind die Wörter, die Values die
ids der Datensätze (am besten als liste oder tuple). Wenn du mehrere Wörter kombinierst, sind die Abfragen auch schnell.
Die Values in sets umwandeln und davon die Schnittmenge bilden (oder vereinigen) und somit hast du
dann auch für Wortkombinationen Ergebnisse. Lediglich das Erstellen des Suchindex wird einige Zeit in Anspruch nehmen.

Generell ist es so, dass das erstellen von Hashtables langsamer ist. Die Abfrage hingegen immer gleich schnell.

Nachdem der komplette Suchindex erstellt worden ist, müssen nur noch neue Datensätze hinzugefügt werden.
Lediglich das Löschen von Daten hinterlässt Lücken und würde dann auch auf Datensätze verweisen, die nicht mehr existieren.
Macht aber nichts, dann fragt man die Daten einfach ab und wenn ein Datensatz nicht mehr existiert, kann der Suchindex an der Stelle aktualisiert werden. Wenn es mehre Wörter sind, musst du alle Values der entsprechenden Keys (Wörter)

MySQL kann das glaube ich nicht. Redis und MongoDB sind solche Kandidaten.
Falls du das machst, mach es so einfach wie möglich oder gleich kommt jemand und postet einfach ein Link von irgendeiner bereits fertigen Lösung.
War doch ein VServer oder doch Webspace.
 

Muenzenwert

New Member
@DeaD_EyE
Danke für den Hinweis, ich habe es mir notiert.
Ich habe einen VServer mit 4 Kernen und 24GB Ram..

Die Suche ist für mich bisher noch kein Problem, Suche ca. 10% der Useranfragen (80% Münzkatalog / 10% Info Pages)
Von den Suchanfragen selbst werden 96% der Anfragen < 10 Sekunden beantwortet, die letzten Monate wurde < 500 Suchanfragen erstellt die über 10 Sekunden gedauert hatten. Im Vergleich es sind tausende von Anfragen die < 10 ms beantwortet wurden.
Zeit wird am Server gemessen zwischen Start mach HTML Header bis letzte Zeile Footer - Übertragung der Daten kommt noch dazu.
Kein Problem meint - keine Prio, schönere Bilder zu haben, aus Verkaufstexten Münzen zu erkennen, mehr Infos usw. hilft den Usern mehr, hat also Prio.
Ich schaue mir aber die Hashtables an, wäre die Suche weit schneller würden evtl. weit mehr User diese Suche nutzen..
Danke für den Hinweis





Ich habe mal schnell geschaut, aktuell keine Ahnung wie ich das umsetzen könnte...
Keyword Kombinationen gibt es je Sprache sehr schnell 50 bis 100 Millionen Möglichkeiten auch wenn man über Stemming die Keywords aufbereitet und Stopwords entfernt.
-> mir fehlt hier die Idee wie ich das sinnvoll machen könnte.

Bei Münzen gibt es ein paar Keys die Sinn machen wie das Herstellungsjahr, Währung, Material, Land, Nominal, ... hier lassen sich Indexe einfach erstellen.
Suchen ohne ein solches Keyword fehlt mir die Idee wie ich das sinnvoll aufbauen könnte.
 
Last edited:

PHP-Friends

Blog Benutzer
Hallo zusammen,

nur kurz zum Benchmark, der dem bisherigen Anbieter ja sehr wichtig zu sein scheint: Dieser ist uns bekannt und stammt aus unserer ersten SSD-Server-Generation, welche über drei Jahre alt ist. Damals haben wir noch, um mehr Speicherplatz anbieten zu können, auf RAID-6 gesetzt. Im Rahmen der G2 haben wir alles auf RAID-10 umgebaut, also auch die G1-Kunden, die - jetzt mal rein vertraglich betrachtet - nicht dafür bezahlen. Aber auch dort gab es noch Unterschiede, da wir sowohl mit SAS- als auch mit SATA-Backplanes gearbeitet und Hostsysteme mit acht sowie solche mit 16 SSDs gekauft haben. Insofern gab es auch in der G2 noch Unterschiede in der Storage-Performance, wobei wir Kunden auf Anfrage immer gerne auf (noch) schnellere Hosts migriert haben. Lange Rede, kurzer Sinn: Der Benchmark war schon für die G2 (erschienen am 29.09.2016) nicht mehr relevant bzw. aktuell und hat mit der jetzigen G3, die auf NVMe-SSDs läuft, überhaupt nichts mehr zu tun. Ich denke, das wird auch unserem Mitbewerber klar sein, denn wer so intensiv über uns recherchiert, dürfte auch über unsere News zur G3 gestolpert sein. So viele Neuigkeiten veröffentlichen wir ja nicht :)

Allen eine angenehme Woche!

Viele Grüße
Tim
 

killerbees19

★ ①③ ④ⓑ ✛ ␀
Bei solchen Antworten von einem Anbieter würde es mich nicht wundern, wenn es plötzlich ein Mini-DoS auf den neuen Server gibt. Nur um zu beweisen, dass der neue Anbieter ja so schlecht ist... :rolleyes:
 

Top