Ein Shop auf Odoo mit mehr als hunderttausend Produkten hat ein Problem, das die Demo-Datenbank nie zeigt: Die Suche ist nicht mehr sofort da. Bei uns dauerte sie mit gesetzten Filtern acht bis zehn Sekunden. Das Lager wartete, der Vertrieb wartete, und alle hatten gelernt, einen zweiten Tab zu öffnen, während der erste nachdachte.
Was tatsächlich langsam war
Der erste Impuls ist, den Server zu beschuldigen, und er ist fast immer falsch. Der Arbeitsspeicher reichte, die Platten langweilten sich. Die Zeit ging in eine einzige Abfrage, und der Ausführungsplan erklärte, warum.
Eine Katalogsuche ist nicht eine Frage, sondern mehrere auf einmal: Zeilen finden, deren Text ein Fragment enthält, sie über mehrere Attribute einschränken und zählen, wie viele Produkte hinter jedem Filterwert übrig bleiben, damit die Zahlen neben den Häkchen stimmen. Bei ein paar tausend Produkten ist das umsonst. Bei hundertzehntausend Zeilen mit langen Beschreibungen und mehreren verbundenen Attributtabellen muss die Datenbank fast alles durchgehen - bei jedem Tastendruck und für jeden Besucher.
Indizes retten das nicht. Eine Suche nach einem Fragment mitten im Wort kann einen gewöhnlichen Index grundsätzlich nicht nutzen, und die Filterzähler werden per Definition bei jeder Anfrage neu berechnet: Sie hängen davon ab, was der Besucher bereits ausgewählt hat.
Und der Katalog war auf dieser Maschine nicht allein. Dasselbe Odoo bediente neununddreißig weitere Shops aus einem gemeinsamen Worker-Pool, sodass jede langsame Suche allen gleichzeitig einen Worker wegnahm.
Erst messen
Zwei Zahlen entscheiden, was als Nächstes zu tun ist: wie lange die Datenbank für die Abfrage braucht und wie lange der Browser für alles andere. Läge die Antwort beim Browser, hätten wir eine Woche lang die falsche Hälfte des Systems optimiert.
Es war nicht der Browser. Das Slow-Query-Log und der Ausführungsplan zeigten auf dieselbe Stelle, und das machte die Entscheidung einfach.
Was sich geändert hat
Die Suche zog aus der Datenbank nach Elasticsearch um, das einen eigenen Index führt und genau für diese Frage gebaut ist: Text, Filter und Zähler gleichzeitig. Das Suchfeld auf der Website blieb, wo es war, und wer darin tippt, sieht nichts Neues - außer dass die Ergebnisse schon da sind.
Entscheidend ist die Richtung des Pfeils. Odoo bleibt die Quelle der Wahrheit: Produkte, Preise und Bestände leben und werden dort bearbeitet. Der Index wird aus der Datenbank aufgebaut und bei Änderungen neu aufgebaut - nie umgekehrt. Geht der Index verloren, wirft man ihn weg und baut ihn neu: Es liegt nichts Wertvolles darin.
Woraus das gebaut ist
Nichts davon wurde um des Schreibens willen von Grund auf neu geschrieben. Das Elasticsearch-Modul wurde gekauft und danach überarbeitet, darauf sitzt eine Brücke zum Shop-Theme, damit Suchfeld, Katalogseite und Filter mit dem Index sprechen und nicht mit der Datenbank.
Zwischen Odoo und den Speichern steht ein kleiner Dienst in Go. Er baut die Filterabfrage, fragt Elasticsearch, zählt die Facetten und hält die schweren Teile der Produktseite in Redis - mit einem Timeout von einigen Dutzend Millisekunden: Antwortet er nicht rechtzeitig, wartet niemand auf ihn.
Warum überhaupt ein eigener Dienst: Auf einem gehosteten Odoo lässt sich daneben kein eigener Daemon betreiben, dafür fehlt der Zugriff. Also lebt der Dienst außerhalb und antwortet über HTTP. Auf einem eigenen Server zieht er in dasselbe Subnetz, und dieser Sprung kostet fast nichts.
Und der Shop läuft weiter, wenn der Dienst nicht läuft. Dieselbe Filterlogik gibt es in Odoo in reinem Python: langsamer, aber richtig. Dieser Weg ist kein Überbleibsel - er ist der Grund, warum ein Deploy des Dienstes kein Termin ist, den jemand planen muss.
Was es kostet
Eine ehrliche Antwort nennt den Preis, und das ist nicht nur die Arbeit am Umzug der Suche. Es läuft jetzt ein zweiter Dienst, der betrieben, überwacht und gesichert werden muss. Sein Index muss nach Massenimporten neu aufgebaut werden. Jemand muss merken, wenn er hinterherhinkt, und das System braucht ein sinnvolles Verhalten für die Minute, in der er nicht erreichbar ist.
Das ist der eigentliche Tausch: ein dauerhaftes Stück Infrastruktur gegen eine Suche, die niemanden mehr warten lässt. Für einen Katalog dieser Größe lohnt sich der Tausch offensichtlich. Für einen Katalog mit fünftausend Produkten meistens nicht.
Wann Sie das alles nicht brauchen
Ist die Suche in einem kleinen Katalog langsam, liegt es fast nie an der Datenmenge. Häufiger ist es eine Abfrage, die mehr verbindet als nötig, ein fehlender Index auf einem Feld, nach dem auf jeder Seite gefiltert wird, ein Bild, das die Darstellung blockiert, oder ein Snippet, das bei jedem Tastendruck die ganze Liste neu rendert. Das kostet einen Nachmittag, nicht einen neuen Dienst in der Produktion.
Deshalb ist der erste Schritt immer derselbe: erst messen, dann ändern. Die Messung dauert eine Stunde und spart die Woche, die man sonst an der falschen Hälfte verbringt.
Sie wählen noch das System selbst? Dann kommt die Rechnung vor der Architektur: was ein Zehn-Personen-Team bei Odoo, Salesforce, HubSpot und SAP wirklich zahlt.
Wie verhalten sich dieselben Systeme im Alltag? Odoo Erfahrungen aus dem Produktivbetrieb: was trägt, was bricht.