Entlastung der Datenbank bei Live-search

Hallo!

Auf unserer PostgreSQL Datenbank läuft eine Routingengine, die den kürzesten Pfad von A nach B liefert. Die Geschwindigkeit ist derzeit noch in Ordnung, wobei wir noch nicht wissen, ob es später bei vielen gleichzeitigen Zugriffen zu erheblichen Geschwindigkeitksverlusten kommen kann. Nun soll daneben auch eine Autovervollständigung zur Namensfindung einer Straße eingebaut werden.

Dieses Script soll es sein: AutoCompleter Tutorial – jQuery(Ajax)/PHP/MySQL - Nodstrum

Eingebaut zu Testzwecken auf einem kostenlosen Hosting mit Postgresql-Datenbanken sieht das so aus: Ajax Auto Suggest
Bei jedem eingetippten Buchstaben finden eine Datenbankquery statt. Später kommen bestimmt weitere Abfragen hinzu (nicht nur bloßes Finden eines Namens, sondern auch Abfragen der entsprechenden Straßen-Koordinaten, die mit in der DB gespeichert sind, usw!). Dies könnte sehr datenbankbelastend sein, oder ?

Um die PG-Datenbank zu entlasten, könnte man doch eine zweite Datenbank wie SQLite , die die Straßennamen und Ähnliches enthält, auf dem Server laufen lassen. Wäre es ein Vorteil für uns es nach diesem Konzept zu machen?


Grüße
m.sirin

Die zweite Datenbank müsste ja immer mit der ersten abgeglichen werden. Das ist umständlich.

Warum speichert ihr die Ergebnisse einer Anfrage nicht z. B. in Memcache zwischen? Die häufigsten Anfragen werden dann aus dem Cache beantwortet.

macht das nicht das DBMS bereits? sowas ist doch ein alter hut?!

wie waere es, nicht jeden tastendruck in eine abfrage fuehren zu lassen … sondern die abfrage verzoegert absetzen … also wenn nach einem tastendruck eine sekunde lang kein weiterer folgte, oder das steuerelement verlassen wurde → vervollstaendigen …

das duerfte das abfrage-aufkommen drastisch reduzieren

Warum sollte es?
Und wo hast du so etwas bei PostgreSQL schon mal gesehen?

postgres hat kein resultset caching?

hmm nagut …

Nein.

Ich stufe dein vorheriges Posting also wieder mal in die Kategorie “Ich habe keine Ahnung und war zu faul, in die Dokumentation zu schauen” ein.


So ein Result Cache bringt (in der Datenbank) nur etwas, wenn sich die darunterliegenden Tabellen nicht ändern. Das kann man aber in einem MVCC-System nicht wirklich garantieren, da Datenänderungen unabhängig vom Zeitpunkt der Sichtbarkeit der Änderungen sind.

Wenn man Cachen möchte, lagert man das in die Applikation aus. Dabei macht man sich dann Gedanken, wie oft man den Cache invalidieren möchte.

dolles argument … lach

dann baut man deshalb nirgends caches - weil sich daten oder strukturen immer aendern koennen … und man keine garantie hat … sehr interessant … lach

… nur so nebenbei … ich habe das nichtvorhandensein eines resultset caches garnicht verurteilt - und nein ich habe nicht in die doku geschaut, weil ich es eigentlich fuer fast selbstverstaendlch hielt, dass das dbms sowas enthaelt …

und ja … es gibt gute gruende soetwas nicht in ein dbms zu integrieren …

und nein … diese gruende haben nichts mit der veraenderlichkeit der daten oder des modells zu tun



Du sprichst in wirren Worten.

Es ist bei dir also fast selbstverständlich, dass die Datenbank so etwas enthält. Es gibt bei dir aber gute Gründe, so etwas nicht zu integrieren.

Kopfschüttel

Hi,
ja daran habe ich auch schon gedacht, notfalls -wenn die Realisierung mit zwei DBS zu schwierig ist- wird es auch gemacht!


Die zweite Datenbank müsste ja immer mit der ersten abgeglichen werden. Das ist umständlich.

Hmm wie meinst du das? Wenn die Daten erst einmal in der 2.Datenbank drin sind, muss eigentlich kein Abgleich mit der 1.stattfinden. User sucht Straßennamen → Name wird von der 2.DB gefunden → liefert entsprechende Koordinaten zurück → php-Script (o.ä.) schickt die Koordinaten an 1.DB, welche für das Routing zuständig ist.

Ändern sich denn die Daten in der 1. DB überhaupt nicht? Niemals?

Außerdem: solange du alle Anfragen von einer Datenbank beantworten lässt - ob das nun PostgreSQL oder SQLite ist - kostet das Performance. Der Trick dabei ist es, gleiche Anfragen gar nicht erst mehrfach zur Ausführung zu bringen.

Ansonsten noch der Verweis auf den einen Hinweis von symbiont: z. B. erst ab dem 2. oder 3. Buchstaben überhaupt eine Anfrage per Ajax schicken. Das schränkt die mögliche Ergebnismenge - und damit die Menge zu durchsuchender Daten - schon mal erheblich ein. Bei einem Buchstaben musst du theoretisch 1/26 deiner Daten durchsuchen, bei zwei Buchstaben nur 1/676.

ich wuerde das in dieser weise grundsaetzlich empfehlen - wenn man geschickt ist - implementiert man das sowieso nur ein einziges mal … also nicht davon abhaengig machen ob man mit einer replik arbeiten kann oder nicht

außerdem - wenns nur um autovervollstaendigen geht → LIMIT 1

bei mehreren treffern ist es manchmal auch ganz nett wenn eine liste aufgeht (drop down etc) … auch diese liste sollte man auf ein vernuenftiges mass LIMITieren … da darf man ruhig drastisch sein → 50 treffer und keine 1000

ach ja … mit LIMIT n + 1 kann man sehr einfach feststellen, obs mehr als LIMIT treffer gibt … so kleine hinweise sind ganz nuetzlich fuer den user besonders beim autovervollstaendigen …

in diese geschichte darf man ruhig etwas zeit investieren …