Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 8 reacties
Bron: Apache

De Apache Software Foundation heeft een nieuwe versie van Solr uitgebracht, met 5.3.0 als versienummer. Solr kan worden ingezet als een zoekmachine. Het maakt op de achtergrond gebruik van Lucene en draait als een Java Servlet binnen bijvoorbeeld Tomcat. Voor meer informatie verwijzen we jullie door naar deze pagina. De aankondiging van deze uitgave ziet er als volgt uit:

Apache Solr 5.3.0 and Reference Guide for 5.3 available

Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project. Its major features include powerful full-text search, hit highlighting, faceted search, dynamic clustering, database integration, rich document (e.g., Word, PDF) handling, and geospatial search. Solr is highly scalable, providing fault tolerant distributed search and indexing, and powers the search and navigation features of many of the world's largest internet sites.

Solr 5.3.0 is available for immediate download at: http://lucene.apache.org/solr/mirrors-solr-latest-redir.html.

Solr 5.3 Release Highlights:
  • In addition to many other improvements in the security framework, Solr now includes an AuthenticationPlugin implementing HTTP Basic Auth that stores credentials securely in ZooKeeper. This is a simple way to require a username and password for anyone accessing Solr’s admin screen or APIs.
  • In built AuthorizationPlugin that provides fine grained control over implementing ACLs for various resources with permisssion rules which are stored in ZooKeeper.
  • The JSON Facet API can now change the domain for facet commands, essentially doing a block join and moving from parents to children, or children to parents before calculating the facet data.
  • Major improvements in performance of the new Facet Module / JSON Facet API.
  • Query and Range Facets under Pivot Facets. Just like the JSON Facet API, pivot facets can how nest other facet types such as range and query facets.
  • More Like This Query Parser options. The MoreLikeThis QParser now supports all options provided by the MLT Handler. The query parser is much more versatile than the handler as it works in cloud mode as well as anywhere a normal query can be specified.
  • Added Schema API support in SolrJ
  • Added Scoring mode for query-time join and block join.
  • Added Smile response format
See the CHANGES.txt file included with the release for a full list of details.

Please report any feedback to the mailing lists
Versienummer:5.3.0
Releasestatus:Final
Besturingssystemen:Java
Website:Apache
Download:http://lucene.apache.org/solr/mirrors-solr-latest-redir.html
Licentietype:Voorwaarden (GNU/BSD/etc.)
Moderatie-faq Wijzig weergave

Reacties (8)

Solr is the popular, blazing fast, open source NoSQL search platform from the Apache Lucene project.
Oh jee, is SOLR ook al gevallen voor de verleidingen van gehypte termen? NoSQL (Not Only SQL) heeft betrekking op databases, en een zoekindex wat SOLR biedt is per definitie niét een database. Er zijn mensen die SOLR misbruiken als database, maar dat is een zeer slecht idee. SOLR blinkt uit in hele andere zaken, zoals full text search, facetting en allerlei zaken die met een relationele database moeizaam gaan. Data-integriteit is daar niet een van. Een SOLR-index zou altijd gebackt moeten worden door een volwaardige database, zij het SQL, zij het NoSQL.

De term daargelaten, mooie software, echt een aanrader. Ben hier inmiddels alweer 2 jaar flink mee aan de slag voor een medium-sized zoekindex en het werkt echt heel goed. Volop configureerbaar, snel, modificeerbaar en een goede community. En mede met dank aan de Web-API eenvoudig vanuit zo goed als elke programmeertaal te benaderen.

Niet direct highlights die in mijn use case helpen, maar er zijn ongetwijfeld ook weer voldoende verbeteringen achter de schermen gedaan dus zal binnenkort weer eens updaten.
Een 'database' is niets meer dan een gegevensbank. Jij doelt op een relationele database denk ik.

Een van de veelgestelde eisen aan een database is dat deze aan ACID voldoet; sinds 2012 (http://blog.mikemccandles...transactional-lucene.html) doet Lucene dit al.
Een SOLR-index zou altijd gebackt moeten worden door een volwaardige database, zij het SQL, zij het NoSQL.
Dit is natuurlijk totaal afhankelijke van je doel.

Lucene, de onderliggende search engine, heeft anders genoeg mechanismes om data-integreteit te bewaken. Operaties op documenten zijn kunnen gecommit en gerollbacked worden. De segmenten van de index worden sinds versie 5.2 ook nog eens geCRCd zodat je corruptie kan herkennen.
Een 'database' is niets meer dan een gegevensbank. Jij doelt op een relationele database denk ik.
Ik doel zeker niet specifiek op een relationele database. Een database kan relationeel zijn, het kan ook Key-Value-based zijn, of document based. En er zijn ongetwijfeld ook nog andere vormen beschikbaar. Echter, er is een groot verschil tussen een index en een database: een database is gericht op de betrouwbare en exacte opslag en retrieval van gegevens op basis van soms complexe, doch absolute criteria. Denk aan joins, aggregates en dergelijke.

Een index is bedoeld voor het snel kunnen zoeken op bepaalde gegevens. Indices spelen ook een rol binnen databases, je kunt op basis van eenvoudige of complexe constraints indices bouwen om daarbinnen snel te kunnen zoeken. Op andere gegevens kun je óók zoeken, maar dat gaat aanzienlijk minder efficiënt.
Een van de veelgestelde eisen aan een database is dat deze aan ACID voldoet; sinds 2012 (http://blog.mikemccandles...transactional-lucene.html) doet Lucene dit al.
ACID is juist voor "NoSQL" waar ze op hinten in de omschrijving vaak niét een eis, heel vaak wordt iig de C gedropt ten behoeve van schalingsmogelijkheden.

Maar dan nog kun je niet aan van de juistheid van de data. Lucene is een index, niet een database. SOLR is een zoekmachine die gebruik maakt van deze index. De gegevens die erin opgeslagen zijn, kunnen dan wel ACID zijn, maar ze zijn geoptimaliseerd om de gegevens te vinden, en niet om overal accuraat en compleet te zijn.
Dit is natuurlijk totaal afhankelijke van je doel.

Lucene, de onderliggende search engine, heeft anders genoeg mechanismes om data-integreteit te bewaken. Operaties op documenten zijn kunnen gecommit en gerollbacked worden. De segmenten van de index worden sinds versie 5.2 ook nog eens geCRCd zodat je corruptie kan herkennen.
Natuurlijk hangt het af van je doel. Het is ook zeker niet dat je bij het gebruik van SOLR / Lucene bang moet zijn voor het verliezen van je gegevens. Het gaat erom dat de informatie vrijwel altijd niet overeenkomt met de daadwerkelijke data, omdat het getransformeerd wordt om beter doorzoekbaar te zijn.
SOLR is op zich een prima product, alleen een groot deel van de doelgroep is ondertussen over gegaan op Elastic Search (ook gebaseerd op Lucene). Ik moet ook zeggen dat ik ES een fijner product vind om te configureren. Maar goed, beiden hebben hun voor- en nadelen.
Ik ken SOLR alleen van naam maar Elasticsearch vanuit de praktijk. En dat is toch erg fijn en elegant product. Voordeel van ES is dat het zonder (voorgedefineerde) schema's werkt! Dat is een groot pluspunt op SOLR.

https://www.elastic.co/gu.../mapping-object-type.html
Helemaal mee eens, een belachelijk goed en eenvoudig product, hier gebruikt in een log management omgeving.

SOLR vs Elastisearch. (oudere versies)
http://solr-vs-elasticsearch.com
De manier waarop die website geformuleerd is geeft wel een lichte bias richting ElasticSearch. De gegevens kloppen. Maar arbitrair kleine features die ElasticSearch in het voordeel hebben worden als apart punt benoemd terwijl ze bij SOLR op grote schaal samengeraapt worden. Bijvoorbeeld met betrekking tot interoperabiliteit en bestandsformaten.

Terwijl "Self-contained cluster" nadelig wordt beschouwd dat SOLR niet zelf de cluster managed maar dat ZooKeeper dat doet. Dat ZooKeeper wel gewoon direct met solr meegeleverd wordt zodat het in het gebruik weinig uitmaakt wordt dan voor het gemak maar even vergeten.

SOLR doet wat dat betreft meer eer aan de Unix philisophy: doe goed waar je voor bedoelt bent en laat randfunctionaliteiten over aan systemen die daar goed in zijn. Door het gebruik van Tomcat of Jetty voor het het webserver-gebeuren of ZooKeeper voor het managen van de cluster bijvoorbeeld.

ElasticSearch is ongetwijfeld een goed product, ik heb er zelf weinig ervaring mee, maar SOLR doet op basis van de features in die lijst niet onder voor ES.
SOLR werkt sinds versie 4.4 zonder schema. Nu vind ik dat persoonlijk geen pluspunt; het schema in SOLR stelt mij in staat om diverse aangepaste types te definiëren met andere workflows mbt indexing en queries, wat het immens krachtig maakt.

Ook voor versie 4.4 was het mogelijk om nagenoeg schemaless te werken door het gebruik van dynamische velden en een wildcard. Bv, een definitie van txt_* maakt alle velden die beginnen met txt_ een text-veld (op de juiste manier). Hierdoor heb je natuurlijk nog steeds wel configuratie maar niet een vaststaand aantal velden per document. Werkt prima voor uitzonderlijke situaties / user-input fields, maar voor de meeste overige velden in de data waar ik mee werk heb ik een custom workflow toegespitst op de betreffende data.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True