11 häufige Fehler bei der Suche

Ihr Unternehmen oder Ihre Organisation ist voller Energie. Endlich werden Sie eine unternehmensweite Suchlösung bereitstellen oder das Kundenerlebnis im Online-Handel verbessern! Sie holen alle Beteiligten an Bord, treffen einige technologische Entscheidungen, setzen eine Lösung ein und dumm gelaufen… sie funktioniert nicht. Was haben Sie falsch gemacht? Hier ist, wo andere gescheitert sind. Lernen Sie aus deren Misere.

1. Schlecht Schema-Entwurf – Genau wie bei Ihrer relationalen Datenbank oder einer anderen Nosql-Datenbank müssen Sie sich auch bei Ihrer Suchlösung Gedanken darüber machen, wie Sie einen Eintrag (aka ein Dokument) darstellen. Wenn Sie dies verpfuschen, führt dies zu einer suboptimalen Suchleistung oder zu einem Indexprozess, der zu lange dauert.
2. Unzureichend Ressourcenplanung – Der alte Desktop in der Ecke Ihres Arbeitszimmers eignet sich hervorragend als Fußbank. Sein Itanium-Prozessor war seiner Zeit weit voraus und wurde völlig unterschätzt. Egal, wie gut er Ihre Rückenprobleme oder das Syndrom der ruhelosen Beine lindert, er allein ist wahrscheinlich kein geeigneter Host für eine Enterprise-Suchlösung. Komplizierte Abfragen oder Berechnungen erfordern möglicherweise mehr.
3. Unzureichend Skalierbarkeitstests – Sie haben Hardware gekauft, Daten eingespeist, eine Benutzeroberfläche entworfen und Ihre Benutzer darauf losgelassen… Es ging schief. Die Abfragen kamen innerhalb von Minuten zurück, die Verbindung wurde verweigert und Sie denken, dass Ihr Leben vielleicht einfach nicht so ist, wie Sie es sich wünschen. Mit ein paar Tests hätten Sie festgestellt, dass die Kombination aus Ihrem Schemaentwurf, der Hardwareauswahl und den Anwendungsfällen nicht funktioniert.
4. Rückgabe zu viele Daten – Ganz gleich, ob Sie in Ihr schlechtes Schemadesign eine große Tüte mit allem Möglichen für den Fall der Fälle gepackt haben und es als „Wundertütenmuster“ bezeichnet haben oder ob Sie dumme Abfragen entwickelt haben, die mehr zurückgeben, als Sie brauchen, denken Sie daran, dass weniger mehr ist und dass die Buffet-Regel gilt: Sie können immer wieder zurückgehen und mehr holen. Auf den ersten Blick funktioniert das ganz gut, bis Sie das System mit ein paar mehr Benutzern belasten.
5. Nicht kompatible Index- und Abfragezeit-Analysatoren – Das häufigste Beispiel hierfür ist das Stemming auf der Indexseite, aber nicht auf der Abfrageseite oder umgekehrt, was zu funktionieren scheint…bis es nicht mehr funktioniert. Das bedeutet, dass Sie eine Suche nach Wörtern mit unterschiedlichen Wortstämmen starten und nichts zurückkommt, obwohl es das sollte.
6. Nicht Planung und Prüfung der Relevanz – Ein großer Trugschluss von Big Data ist, dass Sie eine Antwort finden können, ohne zu wissen, wonach Sie suchen. Die Rolling Stones sagten, dass Sie MÖGLICHST bekommen, was Sie brauchen, aber Sie müssen wissen, was Sie wollen! Das bedeutet, dass Sie verstehen müssen, wonach Ihre Nutzer suchen, und dass Sie testen müssen, ob sie es auch bekommen, bevor Sie die ganze Sache ausrollen. Sehen Sie sich an, wie Salesforce dies in den nachfolgenden Versionen umsetzt.
7. Keine Planung für HA und DR – Hochverfügbarkeit und Disaster Recovery sind nicht mehr die heißesten Schlagworte, aber meine Güte, Ihren Service ständig verfügbar zu halten und für einen Glasfaserausfall oder ein verlorenes Rechenzentrum zu planen, ist so, als würden Sie daran denken, Lebensmittel zu kaufen. Sie müssen es einfach tun. (siehe Solr Cloud und rechenzentrumsübergreifende Replikation)
8. Nicht Erfassen von Signalen von Anfang an – Oder unvollständige Signaldaten, z.B. ein Klick-Ereignis, das keine Informationen darüber enthält, wo das angeklickte Dokument in den gerankten Ergebnissen auftaucht. Zu oft wird die Interaktion des Benutzers mit den Suchergebnissen erst im Nachhinein erfasst, und Sie müssen dann eine unvollständige Geschichte aus den Abfrageprotokollen zusammensetzen.
9. Unzureichende KPIs – Egal, ob es um Leistungsoptimierung oder Relevanz geht, Sie müssen Ziele haben. Um zu wissen, wann Sie mit der Optimierung fertig sind, müssen Sie diese Ziele messen. Wenn Sie auf beiden Seiten scheitern, werden Sie nicht einmal wissen, ob Sie scheitern.
10. Verwendung einer Technologie, deren zuverlässige Skalierbarkeit nicht erwiesen ist – Wir haben es verstanden. Sie haben gelesen, dass diese eine Suchtechnologie der letzte Schrei ist. Sie waren auf deren Konferenz und haben sogar von jemandem gehört, der sie bei einem großen Projekt eingesetzt hat. Das ist alles schön und gut, bis Sie ein Problem mit einem gespaltenen Gehirn haben. Vielleicht hat Ihr Unternehmen in der Vergangenheit eine Client-Server-Lösung oder eine auf RDBMS-Technologie basierende Lösung verwendet und nun stellen Sie fest, dass Ihre Daten und Suchanforderungen die Möglichkeiten dieser Lösung übersteigen.
11. Rolling your own – In jedem größeren oder auch in vielen kleineren Suchprojekten gibt es: eine Dateneingabefunktion, die eine Verbindung zu einigen Datenquellen herstellen und die Daten entsprechend umwandeln muss; eine Server-/Suchverwaltung und einen Überwachungsprozess; eine Zugriffskontrolle; eine Benutzeroberfläche; einen Abfrageprozess, der möglicherweise mehr als eine Datenquelle oder Sammlung verwenden muss. Die Entwicklung all dieser Komponenten ist mit viel Arbeit und Kosten verbunden. Hinzu kommen die laufenden Kosten für die Wartung all dieser Komponenten. Es gibt also keinen Grund dafür. Verwenden Sie ein Produkt, das all dies für Sie verwaltet.

Das sind ein Dutzend Möglichkeiten, wie Sie Ihr nächstes Suchprojekt vergeigen können, die nicht auf eine bestimmte Technologie beschränkt sind. Welches ist Ihr Favorit?