Integration von ApacheSolr
Eingetragen von legolas (250)
am 01.10.2009 - 13:06 Uhr in
am 01.10.2009 - 13:06 Uhr in
Hallo,
wir haben eine umfangreiche Site erstellt, aktuell mehr als 5000 Nodes und es werden noch viel mehr. Mit der Standardsuche von Drupal sind wir nicht sehr glücklich. Wer hat sowas schonmal auf einer deutschsprachen Seite gemacht und kann uns ein Angebot für die Integration machen?
Gruß
SW
- Anmelden oder Registrieren um Kommentare zu schreiben
Hallo, Acquia Search schon
am 02.10.2009 - 09:48 Uhr
Hallo,
Acquia Search schon mal getestet?
Steht für die Solr Installation ein eigener Server zur Verfügung?
gruß pebosi
--
http://www.pebosi.net
gruß pebosi
--
https://pebosi.net
Hi, wie immer, wenn es um
am 03.10.2009 - 00:49 Uhr
Hi,
wie immer, wenn es um Drupal geht, mehrere Möglichkeiten existieren :-)
Es stellt sich natürlich erst die Frage, warum Sie mit Drupal Core Search nicht zufrieden sind. Und ob das Problem villeicht nicht irgendwo anders liegt
Wie man es aus der E-Mail auslesen kann, es geht primär um die Geschwindigkeit. Es könnte sich aber auch um die Search- Resultaten handeln: vielleicht sind nicht alle da, die man erwartet – oder es geht um was viel subtileres, wie z.B. die Darstellung von Search- Resultaten.
Ein schnelle Lösung (je nach Budget) findet man auch mit der Integration von Apache Solr & Acquia Search. In kurze: die Site wird remote indexiert (in USA) und jede Search-Anfrage wird auf Acquia Search Web-Service geroutet. Je nach Use Case, Acquia verspricht 3 bis 16x schnellere Search-Results. Daneben bringt Acquia Search mit sich jede Menge andere interessante Features mit, wie z.B. facetted Search. Kosten: $1000/year, für ungf 10,000 - 20,000 nodes, Indexgrosse 100MB. Wenn sie Interesse für diese Option haben, ich kann Sie relativ schnell mit Acquia ins Kontakt bringen (Partner-Status).
Andere Variante ist natürlich selbst den Apache Solr & Co auf Ihren Server(s) zu installieren. Nicht unmöglich, wird aber etwas mehr Zeit und mehr Hardware-Resourcen brauchen (Solr ist ein Java-Produkt).
ABER – es kann auch der MySQL sein. Oder man findet den Bottleneck irgendwo tief im Server selbst, vielleicht auf Hardware-Ebene. Performance-Tuning ist immer eine sehr spannende Geschichte.
Nebenbei: wir haben schon einmal so was wie ein custom search module in Drupal gemacht. So was hat vielleicht einen Sinn, wenn die Data-Models ziemlich heavy angelegt sind (Details unter Quax.at Portal für Familie: Search Upgrade ). Ich persönlich werde so was aber nur dann als eine Lösung auswählen, wenn alle andere Optionen als "nicht brauchbar" eingestuft sind. Und eventuell auch eine Refactoring des Data-Models vorschlagen ;-)
Wie auch immer, eine faire Einschätzung der Kosten kann man erst dann machen, wenn man den Server(s) etwas näher anschaut.
Grüß,
ZP
------
office AT montenasoft DOT com
http://montenasoft.com
www.montenasoft.com
Muss es Solr sein?
am 03.10.2009 - 12:45 Uhr
Ich stimme meinem Vorredner zu. Um eine Kostenaussage treffen zu koennen muss man wissen was die alternative Suche realisieren soll.
Es stellt sich auch die Frage ob es der Overkiller Solr sein muss mit dem Drupals Standardsuche ersetzt werden soll und ob man die vielen Funktionalitaeten benoetigt die Drupals Solr Integration bietet.
Als weitere Alternative moechte ich den Augenmerk auf Sphinx Search lenken. Sphinx macht keine Faxen und Spielereien wie sie Drupals Solr anbietet. Sphinx ist Highspeed Search ohne die Anforderung eines zusaetzlichen Rechner.
------------------------
Quiptime Group
Da geht noch was.
Ich weiß nicht quiptime,
am 03.10.2009 - 12:08 Uhr
Ich weiß nicht quiptime, warum wir an der Stelle immer wieder aneinander geraten, aber deine Aussage, man bräuchte für Solr einen zusätzlichen dedizierten Server wird - so allgemein wie du sie in den Raum stellst - nicht richtiger, wenn du sie nur oft genug wiederholst ;-)
Es kann Sinn machen Solr auf einen eigenen Server auszulagern, ist aber nicht zwingend. Persönlich halte ich die Möglichkeit sogar für einen großen Pluspunkt, weil man so das Drupal-System und die Suchfunktion entkoppeln und getrennt performance-optimieren kann, wenn nötig. Allein die Auslagerung der Suche kann mitunter die Last des Drupal-Systems deutlich verringern.
Man kann es aber "ganz normal" über eine gemeinsame Maschine abdecken und kann später immernoch problemlos trennen.
Einen Solr-Server aufzusetzen ist für einen "normalen" Serveradmin auch kein Hexenwerk und je nach Basissystem schnell erledigt. Mittlerweile scheint auch eine Kinderkrankheit ausgetrieben worden sein, nämlich die Berücksichtigung des Rechtesystems bei den Suchergebnissen. Wenn ich das beim Überfliegen gestern richtig gelesen habe integriert Solr mittlerweile auch korrekt mit Node Access und Organic Groups.
Schön ist an der Stelle natürlich mal wieder zu sehen, dass man die Wahl der Waffen hat und es eine Reihe möglicher praktikabler Lösungsansätze gibt, die man in die engere Wahl nehmen kann.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Suchmaschinenoptimierung (SEO) & Drupal
Wenn man von Alternativen
am 03.10.2009 - 13:06 Uhr
Wenn man von Alternativen spricht meint man in der Regel den Ersatz dessen was man schon hat. Die Alternative macht also das was man schon hat im Ergebnis auf aehnliche Art. In der Regel mit irgendwelchen Verbesserungen - sonst wuerde man sich ja nicht um eine Alternative bemuehen. Fuer meine Betrachtung, ich sage meine, ist Apache Solr nicht als Alternative zu Drupals Standardsuche zu betrachten.
Wenn Solr eine Alternative zu Drupals Standardsuche waere dann koennte man ein entsprechendes Modul aktivieren, den Index erstellen und Solr basiert suchen. Dem ist aber nicht so. Deswegen ja wohl auch die Anfrage hier.
Wenn ich von Overkiller Solr spreche meine ich das eine Ende der Wurst. Am anderen Ende kann man sicher auch ohne extra Rechner Solr verwenden.
PS
Sphinx kann man auch mit extra Rechnern verwenden.
------------------------
Quiptime Group
Da geht noch was.
Use Cases für Acquia Search und Drupal Sphinx
am 05.10.2009 - 14:46 Uhr
Wenn es um die Technologie-Auswahl geht, der Use Case sollte immer das erste sein.
Ich werde jetzt hier versuchen einige Wege zu skizzieren (disclaimer: es geht natürlich darum, was die einzelne Produkte nach meinem letzten Wissenstand leisten können. Und das wird keine algemeinverwendbare Geschichte werden, da die Use Cases nur in groben Zügen beschrieben sind). Wie man es in der USA zu sagen pflegt, „there is no such thing as a free beer“, also…..
1) Faceted Search ist sehr interessant, ich habe keine Geschwindigkeitsprobleme:
http://drupal.org/project/faceted_search
2) Skalierbarkeit & reine Text-Suche sind interessant, Geschwindigkeit ist interessant
Dann könnte man mit Drupal Sphinx etwas anfangen. Der Nachteil diese Variante: Falls man keine Erfahrung mit ähnlichen Systemen hat, Finger weg – das ist nicht was für Anfänger. Know-How ist auch schwerer (als bei Acquia Search & Solr) zu finden, aber die Variante ist durchaus brauchbar - und schnell. Drupal Xapian wäre auch eine andere Text-Search-Variante, aber die Entwicklung von Sphinx-Modul ist viel aktiver. Faceted Search sollte angeblich auch mit Sphinx möglich sein, aber man muss sich ein bisschen anstrengen.
3) Diese neue Search-Feature sollte helfen, dass die Website-Besucher mehr Zeit auf meine Site verbringen. Skalierbarkeit ist interessant, Geschwindigkeit ist interessant
Acquia Search ist (falls man die Features anschaut) mehr oder weniger eine Übermenge der Drupal Sphinx. Diese „Spielereien“ Out-of-the-Box bringen vielleicht gute Verkauf-Argumente mit sich: vor allem könnten Facets bei Resultat-Filtern und Content Recomendation Feature interessant sein. Andere Features sind auch interessant – aber eher für einen kleineren Teil des Web-Site Betreibers, wie z.B. Indexing von PDF & MS Word Dokumenten in Solr.
Zwei Hauptvarianten:
3.a. Es muss schnell gelöst werden und es muss skalierbar sein und ich will leicht Support finden
Dann sollte man einfach auf Acquia Search zugreifen, falls es preislich auch stimmt. Acquia Search ist eine der Zugpferde bei Acquia. Die Menschen die sich schon viel mit Drupal-Optimization (Robert Douglass vor allen) beschäftigt hatten stehen hinter dem Projekt.
3.b. Ich will den Know-How haben/erwerben und alles kontrollieren (keine Indexierung außerhalb Intranet). Falls notwendig, ich will leicht Support in technischen Fragen finden
Apache Solr installieren, Acquia Search Modul installieren. Erfahrene Drupal-Entwicklern brauchen ungf. 1-3 Wochen (ohne Support), um dieses Search-System von der Funktionsseite ins Griff zu kriegen.
4) Keine diese Lösungen ist für mich gut, ich komme nicht an die Daten und nicht auf die Art und Wiese, die ich es gerne hätte
Custom search – Lösung programmieren/programmieren lassen, evtl. auf Basis von Acquia Search (z.B., index/query system kann man beliebig erweitern)
Grüß,
ZP
-------------------
www.montenasoft.com
www.montenasoft.com
Ok, danke für die vielen
am 07.10.2009 - 06:36 Uhr
Ok,
danke für die vielen Hinweise. Dann werden wir erst nochmal in uns gehen und uns die Möglichkeiten genauer ansehen.
Sprache der Webseite
am 09.10.2009 - 10:56 Uhr
Leider habe ich diesen Thread erst jetzt gesehen, möchte aber trotzdem noch meinen Kommentar abgeben.
Apachesolr ist aus meiner Sicht die richtige Wahl, denn neben den hier schon genannten Vorteilen hinsichtlich Skalierbarkeit wie Entkopplung und Performancegewinn bringt diese Integration noch weitere Features mit: Rechtschreibkorrektur, ähnliche Inhalte usw.
Beachten muss man dabei aber, dass es Probleme mit deutschen Inhalten gibt und daher Acquia Search in der momentanen Version als Option für nicht englische Seiten ausscheidet. Siehe dazu den ausführlichen Thread apachesolr für deutschsprachige Webseiten.
Wenn man seinen Solr-Index selbst betreiben kann (was aus meiner Sicht nicht schwerer ist, als Apache, PHP und MySQL aufzusetzen), gibt es für den nicht englischen Sprachraum eine verbesserte Variante zum aktuellen Modul von drupal.org unter http://drupal.cocomore.com/de/project/apachesolr
Natürlich können wir bei Bedarf als Firma das Setup durchführen und Support anbieten.
Markus Kalkbrenner
Cocomore AG
drupal.cocomore.com
Markus Kalkbrenner
bio.logis GmbH