- Tantivy ist eine schnelle Full-Text-Search-Engine-Bibliothek, die in Rust geschrieben ist; sie ist kein fertiger Suchserver, sondern eher ein Crate, das zum Bau einer Suchmaschine verwendet wird
- Das Design ist stark von Apache Lucene inspiriert; wer nach einem alternativen Server zu Elasticsearch oder Apache Solr sucht, sollte sich die auf Tantivy aufgebaute verteilte Suchmaschine Quickwit ansehen
- Zu den Funktionen gehören Full-Text Search, BM25-Scoring, natürliche Suchanfragen, Phrasensuche, inkrementelle Indexierung, Multithread-Indexierung, mmap-Verzeichnisse, SIMD-Integer-Kompression, Facettensuche, JSON-Felder und Aggregation Collectors
- Läuft mit stabilem Rust und unterstützt Linux, macOS und Windows; mit einer Startzeit von unter 10 ms soll es sich gut für Kommandozeilen-Tools eignen
- Verteilte Suche liegt außerhalb des Scopes von Tantivy; zum Ändern von Dokumenten müssen bestehende Dokumente gelöscht und neu indexiert werden, und neue Dokumente werden erst nach
commit, einem Reload des IndexReader und dem Abrufen eines neuen Searcher suchbar
Positionierung und Design von Tantivy
- Tantivy ist eine schnelle Full-Text-Search-Engine-Bibliothek, die in Rust geschrieben ist
- Es ist kein sofort ausführbarer Suchmaschinen-Server wie Elasticsearch oder Apache Solr, sondern ein Crate, das zum Bau einer solchen Suchmaschine verwendet werden kann
- Vom Design her ist es näher an Apache Lucene und stark von Lucenes Architektur inspiriert
- Wer nach einer Alternative zu Elasticsearch oder Apache Solr sucht, wird auf die verteilte Suchmaschine Quickwit verwiesen, die auf Tantivy aufbaut
Performance und Benchmarks
- Tantivy stellt Benchmarks bereit, die die Performance nach Query- und Collection-Typ aufschlüsseln
- Die Benchmark-Ergebnisse können je nach Art der Query und Last variieren
- Details zu den Benchmarks finden sich im Repository search-benchmark-game
- Laut FAQ ist Tantivy in Benchmarks zur Suchlatenz im Durchschnitt etwa 2-mal schneller als Lucene
Such- und Indexierungsfunktionen
-
Suchfunktionen
- Full-Text Search
- BM25-Scoring wie in Lucene
- Unterstützung natürlicher Suchanfragen:
(michael AND jackson) OR "king of pop"
- Unterstützung für Phrasensuche:
"michael jackson"
- Range Queries
- Facettensuche
- JSON Field
- Aggregation Collector: histogram, range buckets, average, stats metrics
-
Indexierungsfunktionen
- Unterstützung für inkrementelle Indexierung
- Unterstützung für Multithread-Indexierung
- Die Indexierung der englischen Wikipedia soll auf einem Desktop weniger als 3 Minuten dauern
- Indexierung lässt sich über optionale Term Frequency und Position Indexing konfigurieren
- Unterstützung für LogMergePolicy with deletes
- Stellt eine Searcher Warmer API bereit
-
Speicherung und Felder
- Unterstützung für mmap directory
- Unterstützung für single-valued und multivalued fast fields für u64, i64 und f64
- Unterstützung für
&[u8] fast fields
- Unterstützung für text, i64, u64, f64, dates, ip, bool und hierarchical facet fields
- Die Kompression des Dokumentenspeichers unterstützt LZ4, Zstd und None
Tokenizer und Sprachunterstützung
- Tokenizer sind konfigurierbar; für 17 lateinisch basierte Sprachen kann Stemming verwendet werden
- Unterstützung für Third-Party-Tokenizer ist ebenfalls verfügbar
- Beim Implementieren eines Tokenizers für Tantivy muss das Crate
tantivy-tokenizer-api als Abhängigkeit verwendet werden
Laufzeitumgebung und Einstieg
- Tantivy läuft mit stable Rust
- Unterstützte Betriebssysteme sind Linux, macOS und Windows
- Mit einer Startzeit von unter 10 ms eignet es sich für Kommandozeilen-Tools
- Einstiegsmaterial
- Lokales Bauen und Testen erfolgt mit folgenden Befehlen
git clone https://github.com/quickwit-oss/tantivy.git
cd tantivy
cargo test
Funktionen außerhalb des Scopes und Datenänderungsmodell
- Verteilte Suche liegt außerhalb des Scopes von Tantivy
- Wer verteilte Suche benötigt, wird auf Quickwit verwiesen
- Daten in Tantivy sind immutable
- Um ein Dokument zu ändern, muss das bestehende Dokument gelöscht und neu indexiert werden
- Dokumente, die gerade indexiert werden, werden suchbar, nachdem auf dem
IndexWriter commit aufgerufen wurde
- Ein bestehender
IndexReader muss neu geladen werden, um Änderungen zu berücksichtigen
- Änderungen sind nur in einem neu abgerufenen
Searcher sichtbar
Bindings und Anwendungsfälle
- Bindings für andere Sprachen
- Python: tantivy-py
- Ruby: tantiny
- Auf GitHub lassen sich weitere Bindings finden, diese sind aber möglicherweise weniger gepflegt
- Beispiele für die Nutzung von Tantivy
- seshat: Matrix-Nachrichtendatenbank/-Indexer
- tantiny: kleine Full-Text Search für Ruby
- lnx: adaptive, fehlertolerante Suchmaschine mit REST API
- Bichon: leichtgewichtiger, hochperformanter E-Mail-Archivierer in Rust mit WebUI
- Als Unternehmen, die Tantivy nutzen, werden Etsy, ParadeDB, Nuclia, Humanfirst.ai und Element.io genannt
1 Kommentare
Meinungen auf Hacker News
Die Leute, die diese Bibliothek gebaut haben, sind wirklich großartig. Letztes Jahr habe ich beim Ersetzen einer alten, lange vernachlässigten Python2-AppEngine-Codebasis https://progscrape.com [1] darauf neu aufgebaut; es ist eine hervorragende Bibliothek und extrem schnell.
Sie indexiert auf einem Raspberry Pi eine Million Stories in wenigen Sekunden.
Ich betreibe den Full-Text-Search-Dienst auf dem Pi zu Hause; die Spitzenlast liegt nur bei ein paar rps, also nicht viel, aber die CPU schlägt kaum über ein paar Prozent aus. Ich habe die Suche auf dem Pi bis etwa 100 rps lastgetestet, und er hat es ausgehalten. Es war eine sehr nützliche Bibliothek, die sich fast direkt einbauen ließ; das Team hat auf Bug-Reports sehr schnell reagiert, und es gab nur sehr wenige Bugs.
Wenn ihr sehen wollt, wie responsiv die Suche auf so einem kleinen Gerät ist, klickt auf die Labels der einzelnen Stories. Die Abfragen laufen praktisch sofort und treffen bis zu 10 Jahre * 12 Monate an Such-Shards: https://progscrape.com/?search=javascript
Für moderne Projekte würde ich empfehlen, sich das statt Lucene anzusehen. Wenn es schon auf einem kleinen ARM64 so gut skaliert, ist die Erfahrung auf größeren Servern vermutlich noch deutlich besser.
[1] https://github.com/progscrape/progscrape
Ich wollte Nutzern ermöglichen, ihre Backups zu durchsuchen, und da ich Rust verwende, schien Tantivy genau zu passen. Das Indexieren einer einzelnen E-Mail ist so schnell, dass ich es nicht einmal in einen separaten Thread auslagern musste; auch die Suche über Tausende E-Mails scheint kein Problem zu sein.
Wenn ihr in einer Rust-Anwendung Suche braucht, solltet ihr euch Tantivy ansehen.
Error: PersistError(UnexpectedError("Storage fetch panicked")).Im Grunde brauche ich nur Full-Text Search.
Ich habe Tantivy kürzlich in ParadeDB entdeckt. ParadeDB ist eine Postgres-Erweiterung, die Elastic ersetzen will.
https://github.com/paradedb/paradedb/blob/dev/pg_search/Carg...
Darauf gestoßen bin ich über „Extending Postgres for High Performance Analytics (with Philippe Noël)“.
https://www.youtube.com/watch?v=NbOAEJrsbaM
Außerdem steckt es im Kernprojekt Quickwit, einem Projekt für Logs, Traces und bald auch Metriken.
https://github.com/quickwit-oss/quickwit
Ich habe Quickwit zusammen mit ClickHouse in einem persönlichen Projekt für mehrsprachige Suche ausprobiert, und es war überraschend gut. Endlich gibt es eine brauchbare Kombination für Chinesisch, Japanisch und Koreanisch.
https://quickwit.io/docs/guides/add-full-text-search-to-your...
PostgreSQLs
to_tsvectorhat für meinen Anwendungsfall nie wirklich gut gepasst.SELECT * FROM dump WHERE to_tsvector('english'::regconfig, hh_fullname) @@ to_tsquery('english'::regconfig, 'query');Ich hoffe, das läuft gut. Beiträge mit Tantivy als Keyword werde ich wohl automatisch upvoten.
Wir haben kürzlich Quickwit, das auf Tantivy basiert und vom selben Team stammt, in Produktion ausgerollt und Milliarden von Objekten indexiert; wir sind sehr zufrieden. Die Indexierungsgeschwindigkeit ist hervorragend, und die Query-Latenz ist ebenfalls konkurrenzfähig.
Am wichtigsten war, dass die Trennung von Compute und Storage enormen Mehrwert gebracht hat. Ohne für lang laufende, leistungsstarke Server zahlen zu müssen, konnten wir einen neuen Suchdienst über Milliarden von Objekten im Object Storage starten und sogar komplexe Aggregationen durchführen; dadurch wurden neue Use Cases möglich, die sonst ziemlich teuer gewesen wären.
Wenn der Use Case irgendwann leistungsstarke Server rechtfertigt, bietet Quickwit auch die Option, Daten auf den einzelnen Servern zu cachen, um die Performance zu erhöhen.
Als großer Bonus hilft das Team auf Discord sehr schnell und freundlich.
Eine weitere Ressource ist der Go-basierte Trigramm-Suchindex, der in etsy/hound[0] verwendet wird. Er basiert auf Russ Cox’ Artikel und Code „Regular Expression Matching with a Trigram Index“[1].
[0] https://github.com/hound-search/hound
[1] http://swtch.com/~rsc/regexp/regexp4.html
Je nach Bedarf unterscheiden sich auch die Use Cases für Alternativen zu Lucene.
Zu beachten ist, dass Felder hinzufügen/löschen immer noch nicht möglich ist: https://github.com/quickwit-oss/tantivy/issues/470
Die einzige Möglichkeit, ein Feld hinzuzufügen, besteht darin, alle Daten in einen anderen Suchindex neu zu indexieren.
Auf der Suche nach einer Alternative zu Meilisearch, das standardmäßig Telemetriedaten sendet, bin ich auf Tantivy gestoßen. Es ist weniger eine Suchmaschine an sich als vielmehr ein Suchmaschinen-Builder, aber die Konfiguration wirkt ziemlich einfach [0]
[0]: https://github.com/quickwit-oss/tantivy-cli
Das Java-SDK von Meilisearch war ebenfalls gut. Ohne CLI und manuelle Konfiguration konnte man ganze Tabellen indexieren, indem man einfach auf Datenbank-Entities zeigte.
Ich fände es gut, wenn es so etwas auch bei Tantivy gäbe.
Tantivy wird auch in LanceDb, einem interessanten Produkt für Vektordatenbanken, verwendet, um Volltextsuche bereitzustellen: https://lancedb.github.io/lancedb/fts/
Als ich zuletzt nachgesehen habe, war das nur über Python-Bindings möglich, aber meines Wissens wollen sie Rust-Bindings nativ implementieren, um andere Plattformen zu unterstützen.
Vor ein paar Jahren war Elasticsearch so ein ressourcenfressendes Monster, dass ich aus purer Frustration ein privates Projekt gestartet habe. Und das, obwohl selbst mein persönlicher Rechner mehr Ressourcen hatte als das, was mehrere gut ausgestattete Startups ihren Produkten zuweisen.
Ich habe mich aus zwei Gründen für Tantivy entschieden: Zum einen wollte ich alles in Rust bauen, zum anderen wegen Tantivy selbst. Die Performance ist 10/10, die Dokumentation erstklassig, und die Library fühlt sich in der Nutzung sehr gut an.
Leider war der Projektumfang zu groß, um ihn allein in meiner Freizeit zu stemmen, also habe ich aufgegeben. Trotzdem ist Tantivy wirklich hervorragend.
Ich beobachte Tantivy schon seit einiger Zeit. Die Beharrlichkeit der Gründer und die Performance, die Tantivy zuletzt erreicht hat, beeindrucken mich.
Großen Applaus an das gesamte Team. Ich bin fest davon überzeugt, dass sie ihre Ziele erreichen werden.
Als jemand, der Lucene und Solr intensiv genutzt hat, wünsche ich mir vor allem Upgrade-Unterstützung. In der Regel lassen sich Lucene-, Solr- und ES-Indizes nicht auf eine neue Version upgraden. In manchen Fällen geht es zwar, aber der Einfachheit halber lasse ich das hier außen vor.
In großen Projekten ist eine Neuindexierung sehr teuer und manchmal nahezu unmöglich.
Es gibt auch Fälle, in denen sie mit hoher Wahrscheinlichkeit absolut unmöglich ist. Zum Beispiel, wenn sich bei einem verlustbehaftet indexierten Feld der Indexierungsalgorithmus für den Datentyp geändert hat. In vielen Fällen sind jedoch alle Informationen noch vorhanden; es wäre daher wirklich gut, solche Indizes erkennen und upgraden zu können.