Ein regionales Portal steigert die Anzeigenzahl in 18 Monaten von 800 auf 12.000. SEO macht Fortschritte, ebenso wie der Traffic – insgesamt ist das Volumen bescheiden, aber jeder Besucher startet eine Suche. Ein Filter „drei Zimmer, Balkon, weniger als 350.000 €, Umkreis fünf Kilometer“ löst eine umfangreiche Abfrage, zehn Fotos im Lazy Loading, eine Kartenkachel und manchmal eine E-Mail-Benachrichtigung aus. Die Freigabe enthält weiterhin den HTML-Code. MySQL beschleunigt bei beliebten Suchanfragen von 200 ms auf acht Sekunden.
Ein Immobilienportal ist kein Immobilienblog. Die Einschränkung besteht nicht darin, „10.000 Seitenaufrufe pro Tag beizubehalten“, sondern darin, 10.000 Filterkombinationen in einem lebenden Katalog beizubehalten, mit umfangreichen Medien und Referenzen, die jede Datei indizieren.
Drei Säulen: Indexierung, Medien, Suche
| Säule | Symptom bei unzureichender Größe | Hebel |
|---|---|---|
| Grundlegende Indizierung | Suchvorgänge > 2 s, MySQL-Prozessor bei 100 % | Zusammengesetzte Indizes, EXPLAIN, Replikatlesung |
| Bilder | Festplatte voll, TTFB hoch | Objekt + CDN, Miniaturansichten, Komprimierung |
| Suchen | Zeitüberschreitungen auf Karte/Filtern | Elasticsearch, Meilisearch, PostGIS |
Auf einem Immobilienportal ist die Listenseite eine als Webseite getarnte analytische Abfrage. Behandle es als solches.
Indizierung: Die Abfrage, die vor dem Verkehr tötet
Die klassischen Fehler treten immer wieder auf: fehlender Index für „(Stadt, Typ, Preis, Fläche)“, obwohl die Schnittstelle genau danach filtert; „ORDER BY date DESC“ ohne abdeckenden Index führt zu einer Sortierung nach 50.000 Zeilen; Agentur tritt bei → Anzeige → Foto ohne Begrenzung der Anzahl der geladenen Bilder.
Führen Sie vor der Live-Schaltung EXPLAIN für die zehn häufigsten Abfragen aus (Analyse-Dashboard oder langsames Abfrageprotokoll). Erstellen Sie einen zusammengesetzten Index, der an der Reihenfolge der Schnittstellenfilter ausgerichtet ist. Legen Sie eine Paginierung fest (maximal 24 bis 48 Anzeigen pro Seite). Redis-Cache „Top“-Suchen (Zweizimmerwohnung im Stadtzentrum usw.) mit einer kurzen TTL.
Weitere Informationen finden Sie unter Fehlender MySQL-Index: Erkennen Sie die Abfrage, die die Site zum Absturz bringt.
Fotos: das unsichtbare Gewicht des Katalogs
Eine „Standard“-Anzeige: zwölf Fotos × 1,5 MB = 18 MB gespeichert. Mit 12.000 Anzeigen multiplizieren – Festplattenmathematik erklärt Notfallmigrationen.
Die gesunde Architektur umfasst einen Upload in den Objektspeicher (Scaleway, OVH, Infomaniak Object Storage), eine asynchrone Verarbeitung zur Erstellung von 800-Pixel-WebP-Thumbnails, ein CDN mit langem Cache auf den Medien und wenig HTML des Formulars (der Preis ändert sich) und eine sofortige Löschung, wenn eine Anzeige entfernt wird.
Stellen Sie niemals das Originalformat 4000 x 3000 in der Liste bereit. Das Google Page Experience und Ihre Fahrt werden es Ihnen danken.
Facettierte und geografische Suche: Wenn MySQL allein ausreicht
| Anzeigenvolumen | Suchen | Empfehlung |
|---|---|---|
| <2000 | Text + Stadt | MySQL oder PostgreSQL gut indiziert |
| 2.000 – 20.000 | Multifilter + Karte | PostGIS oder Meilisearch |
| > 20.000 | Facetten + Aggregationen | Dedizierte Elasticsearch oder OpenSearch |
Die interaktive Karte vervielfacht die Anforderungen: Jeder Zoom entspricht einem neuen geografischen Gebiet. Kacheln und Cluster serverseitig ausblenden oder nach Zone vorberechnen.
Hosting: mehr als „WordPress mit Cache“
Die Präsentationsfront der Agentur kann geteilt werden. Benutzerdefinierte Anzeigen-Engine, Elasticsearch, 500 GB Fotos und umfangreiche CSV-Importe erfordern einen VPS oder eine Cloud mit Objektspeicher, Warteschlangenarbeitern und Lesereplikat, wenn die Suche dominiert.
Ein nächtlicher Import von Anzeigen aus einem CRM kann die E/A überlasten, während Benutzer morgens suchen. Isolieren Sie Importe in einer Celery-Warteschlange oder einem dedizierten Worker-Server.
Der Gipfel: SEO bringt Traffic, den Ihre Datenbank nicht erhalten sollte
Das Marketing will „mehr indexierte Anzeigen“. Der Betrieb muss antworten: „Jedes Suchmodell hat einen Leistungsplan“ – andernfalls gewinnen Sie Traffic und verlieren gleichzeitig Conversions.
Entscheide dich und gehe ohne blinden Fleck voran
Listen Sie zunächst die zehn langsamsten Suchanfragen über das Slow-Query-Log auf. Lagern Sie die Medien aus, bevor Sie 100 GB oder 80 % der Festplatte erreichen. Testen Sie einen massiven Import kombiniert mit gleichzeitigem Suchverkehr beim Staging. Aktivieren Sie CDN und Komprimierung für alle Listenminiaturansichten. Legen Sie einen Schwellenwert fest: Wenn die Latenz beim 95. Perzentil der Suchvorgänge 1,5 Sekunden überschreitet, wechseln Sie zu einer dedizierten Engine oder einem Lesereplikat.
Vergleichen Sie Hosts mit Objektspeicher über das Verzeichnis und den Komparator. Informationen zur Lesereplikation finden Sie unter Datenbankreplikation: Verfügbarkeit oder schnelleres Lesen?.
Häufig gestellte Fragen
Warum ist ein Immobilienportal beim Teilen so schnell gesättigt?
Jede Suche mit mehreren Kriterien kann Tausende von Zeilen ohne einen geeigneten Index durchsuchen. Jedes Blatt lädt zehn bis zwanzig Fotos. Prozessor, Speicher und Festplatten-I/O steigen alle gemeinsam – nicht nur der Seitenaufrufverkehr.
Ist Elasticsearch für ein Immobilienportal notwendig?
Ab ein paar Tausend aktiven Anzeigen mit Facettensuche ist eine dedizierte Engine oder PostgreSQL mit PostGIS stabiler als nicht indizierte LIKE-Abfragen auf MySQL.
Wo werden Anzeigenfotos gehostet?
Objektspeicher und CDN; WebP- oder AVIF-Miniaturansichten beim Import, niemals das Original in der Liste.
Wie dimensioniere ich die geografische Suche?
Räumlicher Index, Cache für häufige Abfragen, striktes Paging – kein vollständiger Scan für eine Karte.
Ein Immobilienportal wird in den SQL-Indizes und Fotodateien ausgespielt – nicht in der Anzahl der auf dem Host-Sheet angezeigten Kerne.