© Excellent backgrounds/Shutterstock.com
Java Magazin
Ist Solr 4.3 reif für Cloud und agile Entwicklung?

Ist Solr 4.3 reif für Cloud und agile Entwicklung?

Eine gut funktionierende Suche ist unverzichtbar für jeden erfolgreichen Onlineshop, sei es Amazon, Etsy oder Zalando. Um eine skalierbare Suche mit vertretbarem Aufwand zu bauen, gab es lange Zeit nur eine Antwort: die Verwendung von Apache Solr als Suchserver im Hintergrund. Solr ist schon lange mehr als nur ein einfacher HTTP-Wrapper um Apache-Lucene-basierte Indizes. Es kann als eine NoSQL-Datenbank verstanden werden, die für die Suche in großen Datenmengen optimiert ist. Solr wird gerne als sekundärer Index für große, relationale Datenbanken eingesetzt, auf denen sich in der Regel schlecht über beliebige Attributkombinationen suchen lässt. Seit 2010 existiert mit ElasticSearch eine würdige Alternative, und glaubt man Vergleichsseiten [1], Blogs [2], [3], [4] und Konferenzbeiträgen, so ist Solr pauschal unterlegen, insbesondere, wenn es um den Einsatz in der Cloud und agiles Entwickeln geht. Konkurrenz belebt aber häufig das Geschäft, und mit Solr 4.3 meldet sich der Platzhirsch eindrucksvoll zurück.

Martin Breest, Jens Hadlich


Ist Solr reif für die Cloud und agile Entwicklung? Diese Frage mussten wir uns in den letzten Wochen beruflich stellen, da die Suchfunktionalität unserer Plattform, an der verschiedenste Onlineshops und Anwendungen hängen, deutlich erweitert werden soll. Wir haben momentan noch eine ältere Solr-Version (3.1) im Betrieb, die in den letzten Jahren gute Dienste geleistet hat und in einem Master-/Slave-Set-up mit der ständig steigenden Anzahl von Suchanfragen und Vergrößerung des Suchindexes mitwachsen konnte.

Bisher war allerdings nur eine Teilmenge der Entitäten durchsuchbar. In Zukunft werden es aber im Prinzip alle und damit weit über 100 Millionen Items sein. In der Vergangenheit war uns allerdings die Handhabung der Schemata viel zu statisch. Änderungen daran waren in der Praxis eher zeitaufwändig und wurden gerne vermieden. In unserem agilen Umfeld ist dies sehr hinderlich. Im Hinblick auf die bevorstehende Erweiterung ist Einfachheit nunmehr ein K.-o.-Kriterium. Wir wären gerne in der Lage, tägliche Änderungen an unserer Suche ohne Downtimes durchzuführen. Weiterhin sollen von Benutzern neu angelegte oder geänderte Entitäten in Echtzeit verfügbar sein und nicht erst nach 15 Minuten und einer Synchronisierung über unser Master-/Slave-Set-up. Bei Spitzenlast, z. B. im Weihnachtsgeschäft oder bei Marketingaktionen, wollen wir Suchindizes einfach temporär horizontal skalieren können, indem wir mehr Ressourcen zur Verfügung stellen.

Ob Solr in diesem Sinne reif für die Cloud und agile Entwicklung ist, soll anhand folgender Punkte und damit verbundenen Fragen betrachtet werden:

Skalierbarkeit: Wie einfach kann man Suchindizes skalieren, sowohl, was die Indexgröße in GB betrifft als auch die Anzahl der Suchanfragen pro Sekunde? Wie einfach kann man neue Master-/Slave-Set-ups bzw. Shards und Shard-Replikationen aufsetzen? Kann man die Verteilung von Daten auf Shards beeinflussen?Echtzeitfähigkeit: Wie lange dauert es, bis Änderungen am Suchindex in Suchanfragen sichtbar werden? Ist der Suchindex mit (fast) aktuellen Daten als sekundärer Index zu einer relationalen Datenbank einsetzbar?Administrierbarkeit: Mit welchem Aufwand ist es verbunden, neue Suchindizes aufzusetzen, neue Replikationen oder Shards anzulegen oder Suchindexkonfigurationen zu verändern? Können Änderungen programmatisch vorgenommen und z. B. für Releases automatisiert werden? Mit welchen Downtimes ist das verbunden?Anpassbarkeit: Kann ich das Schema des Suchin­dexes ändern? Kann ich Einfluss ...

Java Magazin
Ist Solr 4.3 reif für Cloud und agile Entwicklung?

Ist Solr 4.3 reif für Cloud und agile Entwicklung?

Eine gut funktionierende Suche ist unverzichtbar für jeden erfolgreichen Onlineshop, sei es Amazon, Etsy oder Zalando. Um eine skalierbare Suche mit vertretbarem Aufwand zu bauen, gab es lange Zeit nur eine Antwort: die Verwendung von Apache Solr als Suchserver im Hintergrund. Solr ist schon lange mehr als nur ein einfacher HTTP-Wrapper um Apache-Lucene-basierte Indizes. Es kann als eine NoSQL-Datenbank verstanden werden, die für die Suche in großen Datenmengen optimiert ist. Solr wird gerne als sekundärer Index für große, relationale Datenbanken eingesetzt, auf denen sich in der Regel schlecht über beliebige Attributkombinationen suchen lässt. Seit 2010 existiert mit ElasticSearch eine würdige Alternative, und glaubt man Vergleichsseiten [1], Blogs [2], [3], [4] und Konferenzbeiträgen, so ist Solr pauschal unterlegen, insbesondere, wenn es um den Einsatz in der Cloud und agiles Entwickeln geht. Konkurrenz belebt aber häufig das Geschäft, und mit Solr 4.3 meldet sich der Platzhirsch eindrucksvoll zurück.

Martin Breest, Jens Hadlich


Ist Solr reif für die Cloud und agile Entwicklung? Diese Frage mussten wir uns in den letzten Wochen beruflich stellen, da die Suchfunktionalität unserer Plattform, an der verschiedenste Onlineshops und Anwendungen hängen, deutlich erweitert werden soll. Wir haben momentan noch eine ältere Solr-Version (3.1) im Betrieb, die in den letzten Jahren gute Dienste geleistet hat und in einem Master-/Slave-Set-up mit der ständig steigenden Anzahl von Suchanfragen und Vergrößerung des Suchindexes mitwachsen konnte.

Bisher war allerdings nur eine Teilmenge der Entitäten durchsuchbar. In Zukunft werden es aber im Prinzip alle und damit weit über 100 Millionen Items sein. In der Vergangenheit war uns allerdings die Handhabung der Schemata viel zu statisch. Änderungen daran waren in der Praxis eher zeitaufwändig und wurden gerne vermieden. In unserem agilen Umfeld ist dies sehr hinderlich. Im Hinblick auf die bevorstehende Erweiterung ist Einfachheit nunmehr ein K.-o.-Kriterium. Wir wären gerne in der Lage, tägliche Änderungen an unserer Suche ohne Downtimes durchzuführen. Weiterhin sollen von Benutzern neu angelegte oder geänderte Entitäten in Echtzeit verfügbar sein und nicht erst nach 15 Minuten und einer Synchronisierung über unser Master-/Slave-Set-up. Bei Spitzenlast, z. B. im Weihnachtsgeschäft oder bei Marketingaktionen, wollen wir Suchindizes einfach temporär horizontal skalieren können, indem wir mehr Ressourcen zur Verfügung stellen.

Ob Solr in diesem Sinne reif für die Cloud und agile Entwicklung ist, soll anhand folgender Punkte und damit verbundenen Fragen betrachtet werden:

Skalierbarkeit: Wie einfach kann man Suchindizes skalieren, sowohl, was die Indexgröße in GB betrifft als auch die Anzahl der Suchanfragen pro Sekunde? Wie einfach kann man neue Master-/Slave-Set-ups bzw. Shards und Shard-Replikationen aufsetzen? Kann man die Verteilung von Daten auf Shards beeinflussen?Echtzeitfähigkeit: Wie lange dauert es, bis Änderungen am Suchindex in Suchanfragen sichtbar werden? Ist der Suchindex mit (fast) aktuellen Daten als sekundärer Index zu einer relationalen Datenbank einsetzbar?Administrierbarkeit: Mit welchem Aufwand ist es verbunden, neue Suchindizes aufzusetzen, neue Replikationen oder Shards anzulegen oder Suchindexkonfigurationen zu verändern? Können Änderungen programmatisch vorgenommen und z. B. für Releases automatisiert werden? Mit welchen Downtimes ist das verbunden?Anpassbarkeit: Kann ich das Schema des Suchin­dexes ändern? Kann ich Einfluss ...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang