Interview mit Ian Holsman von Relegence (AOL)

Grant Ingersoll spricht mit dem Lucene/Solr-Committer Ian Holsman über die Vorteile von Open Source im Unternehmenskontext, Leistungsoptimierungen bei der Extraktion…

Grant Ingersoll spricht mit dem Lucene/Solr-Committer Ian Holsman über die Vorteile von Open Source im Unternehmenskontext, Leistungsoptimierungen bei der Extraktion von Datenbankdaten und eine breite Palette anderer Suchthemen. Ian ist CTO von Relegance, einem Tochterunternehmen von AOL, das sich auf suchgesteuerte Echtzeit-Nachrichtenfeeds spezialisiert hat.

Grant Ingersoll:

Heute spreche ich mit Ian Holsman, dem CTO von Relegence, einer AOL-Tochtergesellschaft und einem begeisterten Lucene- und Solr-Nutzer. Willkommen, Ian.

Ian Holsman:

Hallo, wie geht es Ihnen?

Grant Ingersoll:

Mir geht es gut. Könnten Sie sich zunächst einmal vorstellen und uns ein wenig über Ihren Werdegang erzählen, bevor Sie sich mit Lucene und Solr beschäftigt haben?

Ian Holsman:

Ja. Derzeit bin ich der CTO von Relegence, wie Sie bereits erwähnt haben. Ich bin seit ’98 in der Internetszene tätig, wo ich zunächst bei CNET arbeitete. Ich hatte einen technischen Hintergrund im Bereich Performance und einen Hintergrund als Entwickler. Vor etwa zwei Jahren habe ich meinen MBA gemacht und leite derzeit eine Gruppe von 50 Mitarbeitern bei AOL. Ich bin also nicht mehr wirklich ein praktischer Entwickler, aber sie machen sich immer noch ab und zu die Hände schmutzig, ich bin also eher ein technischer Architekt. Früher habe ich mir die Probleme anderer Leute angesehen und ihnen gesagt, wie sie sie lösen können. Manchmal habe ich auch ein bisschen programmiert, aber damit bin ich seit etwa zehn Jahren fertig. Ich beschäftige mich jetzt eher mit Systemarchitekturen und operativen Dingen und versuche herauszufinden, was schief läuft, und entwerfe einfach Systeme, die schnell und skalierbar sind.Ein großer Teil meines Hintergrunds besteht also darin, große Websites zu betreiben, große Objekte, wie CNET oder news.com. Bei AOL haben wir die AOL Front Door, die sich die Leute ansehen, und einfach andere Websites und Websites. Eine Million bis zehn Millionen bis eine Milliarde Seitenaufrufe pro Tag sind also etwas, womit ich Erfahrung habe.

Grant Ingersoll:

Großartig. Können Sie uns ein wenig mehr darüber erzählen, was Relegence macht und welche Rolle Sie dabei spielen?

Ian Holsman:

Okay. Relegence ist also ein Unternehmen, das 2007 oder 2008 von AOL übernommen wurde. Das Unternehmen bietet Echtzeit-Nachrichten zu einem bestimmten Thema an. Sie haben also in der Finanzdienstleistungsbranche angefangen. Geben Sie mir also alle Nachrichten über Time Warner oder Microsoft und sie werden auf einer Seite angezeigt. Das Programm durchsucht 20 bis 30.000 verschiedene Quellen im Internet, von der New York Times bis hin zu AlleyInsider, und sucht nach den neuesten Dokumenten, um herauszufinden, worum es in dem Dokument geht. Es wird versucht, die Kategorie des Themas und den Ort herauszufinden. Das Ergebnis ist ein Dokument mit einer Menge Metadaten. So könnte es zum Beispiel heißen: „Dieses Dokument handelt von New York. Die Zeitung, aus der es stammt, ist in Michigan ansässig. Obama wurde erwähnt und es ist ein Wahlkampfthema“ und so weiter. Das ist natürlich noch nicht alles, aber im Endeffekt kann Relegence ein Dokument innerhalb von, ich würde sagen, fünf Minuten auf den Bildschirm holen, nachdem es veröffentlicht wurde.

Grant Ingersoll:

Schön.

Ian Holsman:

Ja. Es sind nicht nur alle Dokumente. Sie können sie auch nach verschiedenen Kriterien filtern und so weiter. Offensichtlich war es ein großer Erfolg im Bereich der Finanzdienstleistungen. So konnten wir sehen, dass ein Sturm auf Hawaii die Ananasernte zerstörte, bevor Reuters und Co. die Daten in die Finger bekamen. Die Händler liebten es also. Ich war in Relegence natürlich noch nicht dabei, ich bin ein alter AOL-Typ. Ich kam erst danach dazu. Wir haben es also im Grunde ins Internet verlagert und webifiziert. Sie werden es also auf Money.aol.com sehen: Nachrichten, NewsRunner, Love.com, AOL Musikseiten. Es ist eine nette Ergänzung, denn Sie können auf eine Seite gehen und finden dort Nachrichten von allen anderen Seiten. Es ist ein Aggregator, aber ein ziemlich ausgeklügelter.

Grant Ingersoll:

Schön. Wann sind Sie zum ersten Mal auf Lucene und Solr gestoßen?

Ian Holsman:

Ich stieß auf – nun, damals hieß es noch nicht Solr. Wir kamen zu Lucene in den Tagen von CNET. Ein Typ namens Yonik und Clay Webster bei CNET versuchten, eine Alternative zu AltaVista für unstrukturierte Daten zu entwickeln. Nun hatten wir zwei Probleme. AltaVista wurde auf 64-Bit-Linux-Maschinen nicht unterstützt, also mussten wir uns etwas einfallen lassen. Also haben wir uns zwei verschiedene Lösungen einfallen lassen: Atomics, das ist MySQL über HTTP. Die New York Times hat etwas Ähnliches namens DBSlayer, das jetzt als Open Source verfügbar ist. Und wir haben Solr entwickelt, also Search on Lucene und Resin, unseren damaligen Anwendungsserver. Wir haben also diese beiden Alternativen verwendet, und Sie können anhand vieler Designentscheidungen erkennen, woher Solr stammt. Lucene wurde also hauptsächlich bei shopping.cnet.com für die Facettensuche verwendet. Das war damals die Hauptanwendung. Sie haben also eine Suche durchgeführt und HP hat fünf davon gefunden. Es gibt eine Preisspanne von 300 bis 700 und 700 bis 900 und so weiter, und dort wurde es intensiv genutzt.

Sie hatten auch drei stündliche Batch-Updates. Sie sehen also, dass Solr die – die Replikation von Solr war für rsync eingerichtet, denn das passte zu dieser Zeit in die Umgebung. Vieles von dem, was CNET verwendet hat, wurde also in Solr weitergeführt.

Ich war also nicht so sehr in die tägliche Entwicklung involviert. Ich habe mich mehr um das Benchmarking und die Leistungsanalyse gekümmert, um sicherzustellen, dass es reibungslos läuft und so weiter, damit es auch funktioniert.

Grant Ingersoll:

Erinnern Sie sich noch daran, ob es von geschäftlicher Seite Bedenken gegen die Einführung von Open Source gab, oder ob die Leute bei CNET damit einverstanden waren?

Ian Holsman:

Es war nicht das erste Open-Source-Produkt, das wir gemacht haben, aber es war das erste Open-Source-Produkt, das wir, glaube ich, tatsächlich veröffentlicht haben. Das war also ein großer Schritt. Ich meine, CNET war ein großer Nutzer von Open Source. Das war im Jahr 2000, 2001, und wir hatten eine Kostenbegründung dafür. Wir verwendeten damals WebLogic oder BEA WebLogic, und es kostete etwa zehntausend Dollar pro CPU oder so, um einen WebLogic-Anwendungsserver zum Laufen zu bringen, und wir sahen uns Resin an und es kostete 500,00 Dollar pro Maschine. Das war die erste Rechtfertigung, die zwar nicht 100 Prozent Open Source war, aber sehr nahe daran. Also haben wir für 500 Dollar pro Server gesagt: „Wir machen es einfach so.“

Wir haben auch mit der Entwicklung des Apache 2-Webservers begonnen, von dem ich zu Apache gekommen bin. Ich bin ein Apache 2-Entwickler oder war es zumindest einmal. Wir haben einige der Webserver entwickelt, und das hat uns in die Open Source-Welt eingeführt.

Ich habe das Unternehmen damals vor allem damit überzeugt, dass wir vier Entwickler hatten, die mit einer alten Apache-Version arbeiteten, und dass sie mit der Entwicklung und den neuen Anfragen nicht Schritt halten konnten, weil wir all diese maßgeschneiderten Module selbst entwickelt hatten. Der Business Case war also, dass es hier nichts proprietäres oder maßgeschneidertes gibt, das uns einen strategischen Vorteil verschafft. Lassen Sie uns einfach die Module als Open Source zur Verfügung stellen und dazu beitragen, dass wir hier kein Team von fünf Entwicklern haben müssen. Wir können ein Team von zwei Personen haben, die sich um unsere Interessen an dem Projekt kümmern und dafür sorgen, dass wir weiterhin über das Wissen darüber verfügen, aber alles andere wird von anderen Leuten gepflegt.

Sie war einfach. Es war eine einfache Gleichung. Und das war zu der Zeit, als die Dot-Com-Blase platzte und es für niemanden mehr genug Geld gab. Der Aktienkurs lag bei 0,50 Dollar und wir waren nicht sicher, ob das Unternehmen ein weiteres Quartal überleben würde. Es waren wirklich interessante Zeiten, wenn Sie dabei waren. Sie erinnern sich.

Alles, was Geld sparte, war also willkommen. Wir betrachteten Open Source also einfach als eine Möglichkeit, Kosten zu sparen. Es war nicht das schnellste. Es war nicht der größte Funktionsumfang und vielleicht auch nicht die einfachste Bedienung, aber es sparte uns verdammt viel Geld und sorgte dafür, dass das Unternehmen in vielen Fällen über Wasser gehalten werden konnte.

Grant Ingersoll:

Richtig.

Ian Holsman:

Also, ich meine, CNET ist jetzt ein sehr, sehr starker Nutzer von Open Source. Wir haben den größten Teil der Daten auf MySQL umgestellt. Ich glaube, sie haben damals Sybase verwendet. Schließlich sind sie von BEA und Resin auf Tomcat umgestiegen, was es ihnen ermöglichte, Architekturentscheidungen auf andere Art und Weise zu treffen. Während wir vorher im Wesentlichen Lizenzkosten in Kauf nehmen mussten, die die Anzahl der Rechner begrenzten, und wir diese großen, schweren Eisen brauchten, weil die Lizenzkosten so hoch waren, konnten wir, sobald wir das abschafften und zu Open Source übergingen, auf billige Linux-Boxen umsteigen.

Grant Ingersoll:

Richtig.

Ian Holsman:

Und als wir aufhörten, sind wir von vier 280Rs, dem damaligen Spitzenprodukt von Sun, auf 100 Linux-Rechner umgestiegen, auf denen Tomcat und Solr und so weiter laufen. Das hat das Modell von Open Source einfach verändert. Das veränderte die Gleichung so sehr, dass wir auf billige Hardware zurückgreifen konnten, was damals eine enorme Ersparnis darstellte.

Grant Ingersoll:

Wow. Ja, ich glaube, das sehe ich oft. Alle stellen um. Ich habe mit einer Reihe von Kunden gesprochen, die auf Open Source umgestiegen sind. Danach haben Sie Ihren Weg zu AOL gefunden und waren dort Teil der AOL Search Group. Wurde dort bereits Solr verwendet, als Sie dort ankamen, oder haben Sie es eingeführt, und wie hat das alles funktioniert?

Ian Holsman:

Okay. Ich glaube, ich kam im Februar 2008, vielleicht auch erst im März. Ich kam zwei Monate nach Ted Cahall, dem EVP für Plattformen und Technologien, zu uns. Er ist derjenige, der mich eingestellt hat. Er war der ehemalige CIO von CNET. Ich bin also in seinem Kielwasser gekommen. Er brachte also Solr und MySQL und Java ein und begann, uns in diese Richtung zu drängen. Eines der Probleme, die wir bei AOL hatten, und dafür werde ich wahrscheinlich von den Insidern kritisiert, war, dass die Technologiegruppe nicht genügend auf die Geschäftsanwender einging. Das lag nicht an ihnen selbst. Wenn sie eine neue Funktion einführen wollten, mussten sie in ihre eigene Suchmaschine gehen und den Code ändern, und es gab Releases, QA-Releases, und das war einfach nur teuer, weil sie zu sehr damit beschäftigt waren, die Eingeweide zu reparieren, als sich um die Funktionen zu kümmern, die die Leute wollten. Wir kamen zu ihnen und stellten Solr vor. Natürlich war es ein neues Produkt und es war anders, und die Leute hatten Einwände dagegen, denn das passiert nun einmal.

Zu dieser Zeit war das aktuelle Suchprodukt, das sie hatten, in gewisser Hinsicht besser und in anderer Hinsicht schlechter, aber die Kosten dafür waren einfach unerschwinglich. Wir konnten es nicht aufrechterhalten und kommerziell überlebensfähig sein. Es war zwar für bestimmte Dinge gut, aber es konnte einfach nicht mit der Zeit gehen, sozusagen. Es konnte keine Facettensuche durchführen. Es war einfach schwer zu implementieren und nur zwei Leute in der Firma kannten es, was das andere Risiko war.

Grant Ingersoll:

Das stimmt. Oft sage ich den Leuten, dass es wirklich nicht viel Sinn macht, eine Low-Level-TF-IDF-Implementierung oder eine Vektorraummodell-Implementierung einer Suchmaschine zu schreiben, weil Lucene das macht und die Probleme löst, so dass Sie sich dann auf Ihre Anwendung konzentrieren können.

Ian Holsman:

Ja, genau. Und genau zu diesem Punkt, ich meine, wir hatten einige Jungs, die Hälfte meines Teams, die Mehrheit meiner Entwickler bei Relegence sitzen tatsächlich in Tel Aviv, Israel. Sie haben Lucene verwendet. Sie hatten ihr eigenes internes Material, und sie fanden Lucene und Solr und sahen sich die TF-IDF an und verwenden sie nun in ihren Algorithmen. Das sind also Leute, die einen Doktortitel haben und diese Art von Dingen im Schlaf schreiben können, wenn sie es wirklich wollen, und das tun sie wahrscheinlich auch, auf eine gute Art und Weise, Leute, auf eine gute Art und Weise.

Grant Ingersoll:

Auf jeden Fall.

Ian Holsman:

Aber sie haben sich das Zeug angesehen und es war für sie einfach nicht machbar. Sie würden ihre Zeit lieber damit verbringen, die neuronalen Netze zu schreiben, die darauf aufbauen, und die höheren Aufgaben zu erledigen, als sich um diese grundlegenden Dinge zu kümmern. Sie haben Lucene und sagen: Ja, sicher, sie haben wahrscheinlich ein wenig am Code herumgeschraubt und es gefällt ihnen nicht, wie es in bestimmten Bereichen funktioniert, aber es ist gut genug.

Grant Ingersoll:

Richtig. Das Schöne an Open Source ist, dass Sie es ändern können, wenn Sie es brauchen. Und wenn Sie Leute haben, die diese Fähigkeiten haben, dann ist es umso einfacher.

Ian Holsman:

Ja. Ich meine, ich habe eine Weile gebraucht, um herauszufinden, wofür IDF eigentlich steht. In Israel bedeutet IDF die Armee, das ist also ein kleiner Unterschied.

Grant Ingersoll:

Okay.

Ian Holsman:

Ja. Ich habe gerade herausgefunden, dass Solr für die Konzepterkennung verwendet wird. So ist mir zum Beispiel gerade aufgefallen, dass sie es so machen. Sie nehmen die Wörter aus einem Dokument heraus oder kreisen hochwertige Wörter ein und verwenden eine Solr-Suche, um herauszufinden, welche Konzepte am besten dazu passen. Wir nennen das dann ein Thema, ein übergeordnetes Thema, z.B. Verbrechen, Mode, ich weiß nicht, Softball. Wir haben also etwa eine Million dieser Dinge, und was sie getan haben, ist, dass sie diese bestimmten Schlüsselwörter in die Solr-Abfrage einfügen und sagen: „Nun, das passt am besten zu diesen Dingen.“ Solr wird also auf unzählige verschiedene Arten verwendet. Aber auch dafür setzen wir es ein.

Grant Ingersoll:

Genau. Können Sie also einige der Objekte beschreiben, die Solr bei AOL und Relegence nutzen, und vielleicht ein wenig darüber sprechen, wie Solr diese Websites betreibt?

Ian Holsman:

Sicher. Wenn Sie also eines der Suchfelder in einer der AOL-Eigenschaften aufrufen, ist die Wahrscheinlichkeit 90 Prozent, dass ein Teil davon auf eine Solr-Suchmaschine trifft. Das könnte zum Beispiel so aussehen, dass Sie music.aol.com aufrufen und eine Suche eingeben. Die Suchmaschine greift auf Solr zu, um die Ergebnisse zu erhalten. Für die eigentliche AOL-Suche selbst wird Solr im Hintergrund verwendet, und zwar für die Google-Ergebnisse und die so genannten organischen Links, aber alles andere auf der Seite berührt Solr. Wir verwenden es nur, um herauszufinden, was Sie eingegeben haben, um Ihnen das Beste zu zeigen – die Anzeigen auf der Seite. Wir haben also oben etwas, das sich Webangebote nennt, um Ihnen einen Wiederholungslink zu zeigen. Wenn Sie also Madonna eingeben, möchten wir, dass Sie auf die Seite von AOL über Madonna gelangen, oder wenn Sie Pizza in Denver eingeben, möchten wir, dass Sie auf unsere lokale Seite gelangen. Wenn Sie einen Query-String eingeben, können wir außerdem versuchen, herauszufinden, um welche Website oder Kategorie es sich handelt, und auch das geschieht mit Solr, ohne dass Sie es merken. Natürlich kommen noch andere Dinge hinzu, aber alles basiert auf Solr, weil es einfach flexibel genug ist, um diese Dinge zu tun.

Einige der interessanten Dinge, für die wir Solr verwenden und die über das hinausgehen, was ich in Relegence beschrieben habe, sind eine Website namens Love.com, die zu 100 Prozent von Solr betrieben wird. Wenn Sie ein Thema wie Madonna.love.com oder Prince.love.com eingeben, gehen wir zuerst zu MySQL, um die Abfrage für Prince zu finden, was Sie damit meinen, und dann erweitern wir das in eine Solr-Suche. Und dann werden alle Ergebnisse aus dieser Datenbank auf der Seite angezeigt. Das ist also eine Datenbank mit Nachrichtenartikeln von Relegence, die wir haben.

Wir haben eine weitere Datenbank mit Fotos. Wenn Sie also einen Blick darauf werfen, werden Sie sehen, dass es eine Fotogalerie gibt. Das meiste davon wird ebenfalls von Solr unterstützt.

Wir haben eine föderierte Suchmaschine, ich glaube, das war die Version 1.3, bei der wir eine Datenbank haben, die zu groß ist, um auf einen einzigen Rechner zu passen. Also müssen wir sie aufteilen. Ich glaube, sie befindet sich im Moment auf zehn Rechnern, und sie wird einfach abgefragt. Auf jedem dieser Rechner befindet sich ein so genannter Shard oder ein Teil der Datenbank, mit dem wir die Nachrichtenartikel von drei Monaten abfragen können. Das ist der Antrieb für NewsRunner.

Wir verwenden auch etwas namens Local Lucene, das von einem gewissen Patrick O’Leary geschrieben wurde, der jetzt Committer in der Apache-Gruppe ist, um geografisch basierte oder geobasierte Suchvorgänge für Lokales durchzuführen. Wir suchen also zuerst nach Denver, z.B. nach der Postleitzahl. Wir können uns den Längen- und Breitengrad ansehen, eine Bounding Box erstellen und die Local Lucene Algorithmen verwenden, die jetzt Teil davon sind, um uns alle Pizzerien in dieser Bounding Box oder dem Fünf-Meilen-Radius anzuzeigen, was ziemlich cool ist.

Ich habe einmal eine Anwendung geschrieben, bei der wir das in MySQL machen mussten. Das war einfach nur lästig, weil wir die richtige Bounding-Box-Berechnung vornehmen mussten. Sie mussten all diese vorberechneten Dinge in MySQL speichern, und die Abfrage war im Vergleich zu dem, was heute in der Suche zur Verfügung steht, einfach verdammt langsam.

Es ist einfach unglaublich, wie einfach es jetzt ist, eine lokale Suche durchzuführen. Sie geben einfach den Breiten- und Längengrad in bestimmte Felder ein und fügen das Dokument ein – das war’s. Sie müssen sich nicht um die Berechnungen der Bounding Box kümmern. Es gibt keine Sinus- und Kosinusberechnungen mehr in Ihrem Code. Es ist einfach getan und es funktioniert.

Grant Ingersoll:

Ja, das stimmt. Ich habe gerade ein weiteres Podcast-Interview mit Patrick O’Leary geführt. Es ist nicht auf unserer Website zu finden, aber die Hörer dieses Podcasts können es sich ansehen oder anhören. Es dürfte also interessant sein, das in Beziehung zu setzen. Um noch einmal auf all diese Objekte zurückzukommen, welche Art von Datenverkehr wird von Solr bedient? Ich meine, AOL ist offensichtlich ein riesiges Unternehmen mit einem enormen Verkehrsaufkommen. Können Sie uns ein wenig darüber sagen, wie viel Solr tatsächlich genutzt wird?

Ian Holsman:

Die genauen Zahlen habe ich nicht. Ich kann Ihnen die genauen Zahlen nicht direkt nennen, weil ich dafür wahrscheinlich Ärger bekommen würde, aber wir erreichen definitiv – ich würde sagen, über 20 bis 40 Millionen Suchanfragen pro Tag, und das schließt Bebo nicht mit ein, denn wenn wir Bebo mit einbeziehen, könnten Sie wahrscheinlich – ich glaube, sie verwenden Solr. AOL ist ein sehr großes Unternehmen und es gibt nicht nur eine Person, die für alles verantwortlich ist. Ich glaube nicht, dass sie Solr verwenden, aber ich denke, 20 Millionen Suchanfragen sind eine ungefähre Zahl, und das ist nur eine Suche. Da wird keine normale Seite angezeigt. Das sind Leute, die einfach nur Suchen durchführen.

Grant Ingersoll:

Und viele davon beinhalten wahrscheinlich auch Facetten und die lokale Suche, richtig.

Ian Holsman:

Ja. Die lokale Suche besteht aus Facetten, und wir haben mit Ihnen gesprochen, um Ihren Algorithmus zu bekommen. Sie hatten eine schnellere Version der Facettierung. Ich glaube, das hat uns gespart – ich glaube, wir wollten ursprünglich 18 Maschinen einsetzen. Wir haben mit Ihnen gesprochen und konnten es auf fünf reduzieren, weil es einfach so viel schneller ging.

Grant Ingersoll:

Das stimmt. Und tatsächlich wird dieser Algorithmus jetzt in Solr 1.4 enthalten sein. Das war also eine schöne Verbesserung, die wir wieder in Solr aufgenommen haben.

Ian Holsman:

Ja.

Grant Ingersoll:

Wow! Das ist eine ziemlich große Solr-Installation. Sie haben 20 bis 40 Millionen Abfragen pro Tag und ich vermute, dass Sie auch mehrere Millionen oder mehr Dokumente in all diesen Objekten haben.

Ian Holsman:

Ja. Ich meine, Sie dürfen nicht vergessen, dass AOL nicht nur eine große Immobilie ist. Es sind viele kleine. Love.com hat zum Beispiel eine Dokumentengröße von, ich glaube, fünf Millionen Dokumenten, das sind die Nachrichten eines ganzen Monats. Ich werde das mal überprüfen. Wir schalten also eine der Suchfunktionen einfach aus, und zwar mit einer ganz einfachen Suche. Ich überprüfe nur, wie viele Dokumente es genau sind. Das kann ich Ihnen sagen, aber das ist nur eine einzelne Maschine, die nur Facettensuchen und normale Suchen durchführt. Es basiert auf einer Dokumentengröße von 5,5 Millionen.

Grant Ingersoll:

Alles auf einem einzigen Rechner. Ich meine, natürlich haben Sie eine Ausfallsicherung und all das, richtig.

Ian Holsman:

Ja. Ich meine, wir haben natürlich den Replikator für den Verkehr.

Grant Ingersoll:

Richtig.

Ian Holsman:

Wir haben also ein paar Maschinen als Sklaven, die das tun. Aber ja, es handelt sich um eine Dokumentendatenbank mit 5,5 Millionen Einträgen, und die Antwortzeit für eine einzelne Anfrage wird in Millisekunden angegeben.

Grant Ingersoll:

Schön.

Ian Holsman:

Natürlich haben wir auch eine Zwischenspeicherung eingebaut, denn Sie wollen ja nicht, dass jeder Benutzer auf dieselbe Suche im System zugreift und CPU verschwendet.

Grant Ingersoll:

Sicher.

Ian Holsman:

Aber ja, ich meine, indem ich sie einfach in eine Solr-Engine einfüge. Wir hatten also, wie ich schon sagte, 5,5 Millionen Dokumente in einer Solr-Datenbank oder in einer Solr-Engine. Dadurch konnten wir sagen: „Was wäre, wenn wir einfach diese Art von Abfragen durchführen oder diese Art von Facettensuche und diese Art von Dingen tun würden? Und auf dieser Grundlage werden wir – wenn ich meinen armen Finger raushole – das kann ich in einem Podcast sagen – im Grunde eine Reihe verschiedener Websites starten, ich würde sagen 10 oder 15 verschiedene Websites, die auf diesen Daten basieren, basierend auf facettierten Suchen.

Grant Ingersoll:

Schön.

Ian Holsman:

Es ist einfach zu einfach. Wir kombinieren das. Jetzt ist jedes dieser Dokumente mit einem Standort-Tag versehen. Wir können dann Local Lucene verwenden, um darüber hinaus auch noch eine Umkreissuche durchzuführen, wenn wir das möchten. So können wir z.B. eine Art Lokalnachrichten erstellen. Es ist also wirklich sehr einfach, diese Funktionen hinzuzufügen. Ich meine, wenn Love.com, wie Sie es sehen, im Dezember letzten Jahres eine Idee war.

Grant Ingersoll:

Ist das Ihr Ernst?

Ian Holsman:

Ja, das stimmt. Bill Wilson kam auf uns zu und sagte: „Wir wollen so etwas machen“, und wir haben, glaube ich, drei Monate gebraucht, um das Frontend zu schreiben. Der größte Teil der Arbeit entfiel auf das Frontend, weil wir es genau richtig machen wollten und es einige Probleme mit der Skalierbarkeit gab, aber ja, es begann im Dezember. Wir haben darüber gearbeitet. Und das sind nur ein oder zwei Entwickler. Wir haben nur die Ingestion-Engine bekommen, denn wir haben den Dokumentenstrom, der durchkommt, und haben ihn einfach in Solr eingefügt.

Grant Ingersoll:

Und das Problem mit der Skalierbarkeit, nur um das klarzustellen, betraf das Frontend und nicht Solr, richtig.

Ian Holsman:

Es gab einige Probleme mit Solr.

Grant Ingersoll:

Einige, ein bisschen.

Ian Holsman:

Ja. Ich meine, es ist keine perfekte Sache. Es funktioniert nicht auf Anhieb, aber das war auch das Problem, mit dem wir zu kämpfen hatten. Weil wir in Echtzeit arbeiten, haben wir zum Beispiel eine Zeit lang bei jedem Dokument ein Commit durchgeführt, und wenn Sie mit diesen Leuten sprechen, werden sie Ihnen sagen, dass Sie das nicht tun sollten. Also änderten wir es auf Commit für jeden Tausender und ließen die Abfragen nicht mehr vom Master, sondern von den Slaves laufen, und die Dinge wurden schneller.

Grant Ingersoll:

Ja.

Ian Holsman:

Und genau hier kommen Optimierer ins Spiel. Bei den meisten Abfragen haben wir festgestellt, dass wir zunächst Solr für alles verantwortlich gemacht haben, weil es eine neue Sache war und nicht unser Code, und dann haben wir einen Optimierer eingesetzt und uns das angesehen. Es lag nicht an Solr. Es lag daran, dass wir bei jedem Dokument 50 Mal auf die MySQL-Datenbank zugegriffen haben.

Grant Ingersoll:

Ja, das habe ich schon mal gehört, ja.

Ian Holsman:

Ja, das stimmt. Ein guter Optimierer ist also sein Gewicht in Gold wert. Aber ich komme ja aus dem Bereich Performance, also bin ich voreingenommen. Aber ja, ich glaube, eine Seite auf Love.com bestand aus einer Solr-Anfrage und etwa 15 MySQL-Anfragen, weil wir andere Daten hatten, die wir nicht in Solr speichern wollten. Wenn ich etwas Zeit hätte, würde ich gerne einige Dinge in Solr integrieren.

Grant Ingersoll:

Wie bitte?

Ian Holsman:

Eines der Probleme, die wir haben, ist, dass vieles, was wir tun, zeitbasiert ist. Wir möchten also eine Suche mit Relevanz durchführen, aber die Inhalte in zeitlicher Reihenfolge anzeigen, weil wir eine Nachrichtenseite sind und die meisten Leute sich für die neuesten Dinge interessieren. Es ist schwierig, sich vorzustellen, wie man das machen soll.

Grant Ingersoll:

Es geht also nicht nur um die Sortierung, sondern auch darum, dass die Zeit ein Faktor für die Relevanz ist.

Ian Holsman:

Ganz genau.

Grant Ingersoll:

Ja, das stimmt. Ich meine, Sie könnten so etwas wie Funktionsabfragen machen. Ich meine, das ist es, was die Leute normalerweise tun, eine über die Zeit. Aber Sie wollen wahrscheinlich etwas Ausgefeilteres als nur eine über die Zeit, oder?

Ian Holsman:

Ja. Und dann haben wir noch die Popularität. Wir wissen also, dass viele der Seiten, die wir uns ansehen, bei den Künstlern beliebt sind. Für die Musikseiten verwenden wir zum Beispiel einen Daten-Feed von AMG. Es gibt eine Menge Daten und eine Menge Musiker. Einige haben die gleichen Namen. Das ist auch bei Sportteams der Fall. Wenn Sie also – ich bleibe mal bei der Musik – Madonna eingeben, wollen Sie die Madonna, die Sie kennen und lieben. Es gibt wahrscheinlich zwei weitere Madonnas, die den Namen Madonna tragen. Wenn wir nun die Popularität in die Suche einbeziehen könnten, wäre das eine weitere tolle Sache, denn wir wissen, dass diese Madonna-Seite diejenige ist, die die meisten Treffer erzielt. Es geht nur darum, dies in den Bewertungsalgorithmus einzubeziehen, damit er es berücksichtigt. Es ist nur schwer zu machen. Es ist machbar. Es ist nur eines der Dinge, die nicht so einfach zu machen sind
wie Sie es gerne hätten, wenn Sie einfach die Kiste aufmachen würden und schon ist es erledigt.

Grant Ingersoll:

Das stimmt. Ich habe das also in Solr gemacht. Jetzt gibt es etwas, das sich – ich habe den genauen Namen vergessen – nennt. Es handelt sich dabei um eine externe Dateiquelle oder so etwas Ähnliches, bei der Sie eine externe Quelle als Teil einer Funktionsabfrage verwenden können. Sie können also eine Liste von Dokument-IDs und Boost-Werten pflegen, und Solr kann dann bei einer Funktionsabfrage nachsehen, wie diese Dokument-IDs lauten und wie hoch der Boost-Wert ist, und dies dann in die Bewertung einbeziehen. Und da diese Datei nicht Teil des Index ist, ist sie viel einfacher zu aktualisieren. Sie können die Aktualisierung auf verschiedene Weise vornehmen.

Ian Holsman:

Sie können also Memcache statt einer Datei dafür verwenden?

Grant Ingersoll:

Ich habe es nicht mit Memcache gemacht, aber ich könnte mir vorstellen, dass Sie es könnten. Ich meine, das wäre eine interessante Frage, die man auf einer der Solr-Mailinglisten oder so ähnlich stellen könnte. Soweit ich weiß, habe nicht ich diesen Code geschrieben, sondern Yonik, aber wenn wir externe Dateien nutzen können, warum nicht auch andere externe Dinge, oder?

Ian Holsman:

Ganz genau. Ich meine, ja, wenn Sie Memcache nutzen können, dann können Sie Ihre Bewertungen und Ihre Popularität in Echtzeit aktualisieren und plötzlich fragt dieses Ding diese Dinge in Echtzeit ab. Das wäre also großartig. Ich werde mir das mal ansehen müssen.

Grant Ingersoll:

Ja, das stimmt. Und auch unter der Haube von Lucene wird es mehr Echtzeitfunktionen geben. Das wird natürlich auch auf Solr durchschlagen. Ich meine, wir haben bereits gesehen, dass Solr und Lucene viel schneller geworden sind, wenn es darum geht, Suchanfragen neu zu öffnen. Wenn Sie also mit einer neueren Version von Lucene und Solr arbeiten, geht das jetzt viel schneller als früher, also ja.

Ian Holsman:

Und es gibt Projekte von LinkedIn, die das in Echtzeit mit Lucene gemacht haben. Ich meine, wir haben jetzt unsere Aktualisierungen. Früher war es einmal pro Minute und ich glaube, sie haben es auf einmal pro Sekunde heruntergeschraubt. Sie replizieren es also einmal pro Sekunde. Das ist zwar nicht in Echtzeit, aber für die meisten Leute reicht das aus.

Grant Ingersoll:

Sie haben also eine Aktualisierung in Ihrem Master und replizieren diese jede Sekunde an alle Ihre Worker.

Ian Holsman:

Wir können.

Grant Ingersoll:

Und haben Sie einen benutzerdefinierten Solr-Code, der Ihnen dabei hilft, oder machen Sie das nur über die Hardware?

Ian Holsman:

Ja, gut. Jetzt werden Sie ein bisschen zu technisch. Nein, das war nur ein Scherz. Das ist nicht mein Team. Das ist ein Typ namens Vineet in der AOL-Suchgruppe, der sich um diese Dinge kümmert. Ich mache mir das im Grunde nur zunutze.

Grant Ingersoll:

Sicher.

Ian Holsman:

So wie AOL strukturiert ist, haben wir kein Suchteam, das für Solr an sich zuständig ist. Wir haben Anwendungsentwickler, die in verschiedenen Geschäftsbereichen arbeiten und miteinander kommunizieren. Ich bin zum Beispiel bei Relegence und wir arbeiten zusammen. Venite ist bei AOL Search. Wir haben Jungs namens Shalin und Noble, die in Bangalore arbeiten und sich hauptsächlich mit dem Thema Shopping beschäftigen. Diese beiden Jungs sind jetzt Committer bei Solr. Eine der anderen Anwendungen, die wir ins Auge fassen, ist die Multicore-Funktionalität. Wir planen also, diese für E-Mails zu verwenden. Auch hier bin ich nicht zuständig, das ist Nobles und Shalins Gebiet, aber jeder Benutzer einer E-Mail hat seine eigene kleine Solr-Suche. Alle E-Mails sind also nur in diesem kleinen Kern enthalten. Eines der Probleme, die wir mit Solr hatten, war, dass es nicht sehr schnell beim Hochladen und Entladen von Millionen dieser Daten war, und Shaylen und Noble haben daran gearbeitet, dies zu beheben.

Grant Ingersoll:

Schön.

Ian Holsman:

Ja, und sie haben Benchmarks durchgeführt. Dabei haben wir festgestellt, dass es nützlich ist, etwas beizusteuern. Um auf das anfängliche Gespräch über den Grund für Open Source zurückzukommen: Wir sind ein großes Unternehmen. Ich glaube, wir haben – laut Presseberichten – zwischen 5.000 und 8.000 Mitarbeiter bei AOL, was riesig ist, und wir haben Mitarbeiter in mehreren Ländern. Und wenn wir unsere eigene Version von Solr behalten wollten, müssten wir irgendwo eine zentralisierte Gruppe haben, die sich darum kümmert. Jetzt brauchen wir das nicht mehr, denn es gibt eine zentralisierte Gruppe bei Apache, die das für uns erledigt. Und letztendlich gibt es nichts, was proprietär oder so genannt ist, was uns den Schlaf rauben würde, wenn Sie es sich schnappen und zu einem Konkurrenten von uns werden, denn darin liegt nicht unser strategischer Vorteil. Es geht nicht darum, etwas schnellere Solr-Abfragen zu schreiben. Es geht darum, die Websites dort aufzubauen, wo die Daten herkommen, und das ist viel wettbewerbsfähiger. Es gibt also keinen Wettbewerbsvorteil, wenn wir diese Änderungen für uns behalten, ganz im Gegenteil. Ich meine, wir haben Local Lucene vor sechs Monaten in den Solr-Hauptbaum aufgenommen, Patrick hat das getan, und dann haben sich Yonik, Chris und viele der anderen Kernentwickler von Solr und Lucene das Ganze angeschaut und ein paar Dinge korrigiert und Alternativen vorgeschlagen. Und wenn wir das in der Open Source nicht hätten, würden wir nicht die klügsten Köpfe der Suchbranche dazu bringen, sich unsere Probleme anzuschauen und darüber nachzudenken.

Das ist der andere Vorteil: Wir müssen nicht alle Raketenwissenschaftler einstellen. Sie arbeiten alle für ihre eigenen Unternehmen, machen ihr eigenes Ding und verbringen etwas Zeit damit, weil sie sich für diese Dinge interessieren. Das hilft ihnen.

Grant Ingersoll:

Ja. Ich sage oft, dass Open Source einfach ein sehr effektiver Weg ist, um Partnerschaften mit anderen Unternehmen einzugehen, ohne dass man mit jedem einzelnen von ihnen rechtliche Vereinbarungen treffen muss.

Ian Holsman:

Ganz genau. Wir sind alle dazu da, Geld zu verdienen, und das tun wir alle auf unterschiedliche Weise. Aber es ist so, als würden Sie Linux oder ein Betriebssystem herunterladen. Solr ist in vielerlei Hinsicht zu einem Gerät geworden. Ich halte nichts davon, eine freigegebene Version herunterzuladen. Ich bin immer noch etwas skeptisch, wenn es darum geht, den Stamm herunterzuladen und in die Produktion zu bringen, aber einige Leute in unserem Unternehmen tun das nicht. Es gibt eine Menge Politik.

Grant Ingersoll:

Richtig.

Ian Holsman:

Wir haben eine freigegebene Version. Wir testen sie. Wir prüfen sie und sie kommt in eine Schachtel. Und das Einzige, worüber wir uns wirklich Gedanken machen müssen, ist das Schema. Sie legen das Schema an und legen eine Version 1 an, die dann irgendwie funktioniert und Sie aktualisieren das Schema. Einer der weiteren Vorteile von Solr ist, dass Sie Änderungen am Schema vornehmen können, neue Felder hinzufügen, Felder löschen und all diese Dinge, ohne dass Sie eine mehrstündige Reorganisation durchführen müssen.

Grant Ingersoll:

Und oft ist es so, dass Menschen, vor allem wenn sie aus dem Datenbankland kommen, wo sie in dieser normalisierten Weltanschauung leben, mit der Suche beginnen und alles entnormalisieren, und das macht den Kopf frei, um über viele andere Dinge nachzudenken und Dinge viel schneller zu erledigen.

Ian Holsman:

Ja. Demos, zum Beispiel, Demos.org, existiert immer noch. Wir sind dabei, sie neu zu schreiben, und wir haben Solr verwendet, um viele der mengenbasierten Operationen durchzuführen. Wenn Sie sich Demos ansehen, ist es ein hierarchischer Baum. Wir haben also recherchiert und festgestellt, dass es einfacher ist, das mit Solr zu schreiben, weil die Abfragen so viel einfacher sind. Anstatt eine Art von verschachtelten Algorithmen zu verwenden, die zwar cool sind und viel Spaß machen, aber bei denen es schwierig ist, sie richtig zu machen, weil es so viele Grenzfälle gibt. Mit Solr ist es nur eine ganz einfache Solr-Abfrage auf einem Pfad, und sie war schnell genug, um das zu tun.

Grant Ingersoll:

Schön.

Ian Holsman:

Eine andere Sache, die ich gerne in Solr einrichten würde, sind benannte Wertepaare und ein Mehrwertsystem. Wenn Sie zum Beispiel ein Dokument und Attribute haben, könnten Sie interne IDs haben, die auf etwas anderes verweisen, z.B. ID5 ist Madonna, ID7 ist Prince usw. Es gibt keinen einfachen Weg. Das geht nicht, wenn Sie einen Code schreiben, der ein Name-Wert-Paar für ein Dokument speichert und mit der Suche beginnt, den Wert und so weiter, aber die damit verbundenen Schlüssel behält. Sie müssen zwei Listen haben. Das ist also eine der anderen kleinen Dinge, die ich gerne sehen würde.

Grant Ingersoll:

Denn Sie würden nicht einfach – Sie wissen schon, ein Feld enthält den Wert. Ich meine, es ist ein Namenswert. Aber Sie möchten nach dem Wert suchen können, aber auch den Namen oder die Schlüsselwerte zurückerhalten. Habe ich das richtig verstanden?

Ian Holsman:

Ja, das stimmt. Ich habe also zum Beispiel ein Dokument, das viele Personen enthält. Nun hat jede dieser Personen eine ID. Stellen Sie sich vor, dass wir auf der Rechnung Lagerartikel haben. Sie haben also einen Lagernamen und die Artikel. Ich brauche diese Produkt-ID und alle Personen-IDs in einem Dokument, das mit diesem Namen verknüpft ist. Ich könnte also eine Rechnung für fünf Widgets mit der Produkt-ID 75 bestellen. Ich möchte das Widget mit der Produkt-ID75 in derselben Zeile haben, damit ich nicht eine Liste von ID-Nummern und eine Liste von Produktnamen in separaten Feldern speichern muss. Das ist nur eine Kleinigkeit. Es ist eher eine dieser Sachen, für die ich eine Klasse in Solr schreiben könnte, aber es ist einfach eine dieser Sachen, die nicht in der Box enthalten sind. Es ist definitiv leicht machbar. Es ist nur eine Frage der Ausführung.

Grant Ingersoll:

Auch hier klingt es so, als ob eine Art von Funktionsabfrage das wahrscheinlich erledigen könnte. Aber Sie haben Recht. Es würde etwas Code erfordern.

Ian Holsman:

Ja, ja. Ich meine, ich versuche, das so zu formulieren. Ich meine, vieles, was Solr macht, ist sofort einsatzbereit. Sie brauchen keine Leute, die daran beteiligt sind. Sie schieben es einfach da rein und es funktioniert. Sie brauchen Menschen, wenn es um die Relevanz geht. Sie wollen, dass dieses Dokument weiter oben erscheint als das andere Dokument. So erhalten Sie eine bessere Punktzahl. Und dann fangen Sie an, mit Boost-Werten und Scoring und solchen Dingen zu spielen. Das ist das, was ich als Rattenloch bezeichne, denn es ist sehr schwer, in allen Fällen gut zu sein.

Grant Ingersoll:

Ja.

Ian Holsman:

Ich glaube, dass viele Leute bei Solr vergessen, dass es sehr einfach ist, einen Index zu erstellen und eine Suche zu starten. In den meisten Fällen ist das auch in Ordnung, aber Sie müssen sich einige Randfälle ansehen, und wenn Sie zu einem Randfall kommen, kann es manchmal sehr schwierig sein, diese Art von Dingen zum Laufen zu bringen, weil es nicht dasselbe ist, sie algorithmisch zum Laufen zu bringen. Ich denke, es gibt Boosts auf Dokumentenebene und solche Dinge, die Sie tun können.

Grant Ingersoll:

Und ich meine tatsächlich, dass Sie auf etwas gestoßen sind. Dieses Problem geht weit über Solr hinaus. Ich meine, das ist ein allgemeines Suchproblem und alle Anbieter haben dasselbe Problem. Einer der Vorteile von Solr ist, dass Sie sehen können, was unter der Haube passiert. Sie können also zumindest wissen, warum ein Dokument auf diese Art und Weise gefunden wurde, anstatt dass es sich um eine geheime Soße handelt, mit der Sie möglicherweise das Reverse Engineering der Engine durchführen könnten.

Ian Holsman:

Ja.

Grant Ingersoll:

Ja, ja. Das sind alles tolle Sachen, Ian. Ich denke, das war’s. Ich habe jetzt definitiv mehr als genug von Ihrer Zeit in Anspruch genommen. Warum beenden wir es also nicht hier? Ich möchte Ihnen für Ihre Zeit danken und freue mich auf weitere gute Nachrichten von Love.com, Relegence und AOL.

Ian Holsman:

Großartig. Ich bin sicher, dass wir es schaffen werden. Wir haben einen neuen CEO, und er feuert aus allen Rohren. Er wird den Laden auf jeden Fall umkrempeln. Das steht fest.

Grant Ingersoll:

In Ordnung, sehr gut.

Ian Holsman:

Vielen Dank für Ihre Zeit, Grant.

Grant Ingersoll:

Vielen Dank, Ian.