TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Toshi: An Elasticsearch competitor written in Rust

255 点作者 whoisnnamdi超过 6 年前

13 条评论

georgecalm超过 6 年前
&gt; What is a Toshi?<p>&gt; Toshi is a three year old Shiba Inu. He is a very good boy and is the official mascot of this project. Toshi personally reviews all code before it is commited to this repository and is dedicated to only accepting the highest quality contributions from his human. He will though accept treats for easier code reviews.
arminiusreturns超过 6 年前
Does anyone know of any other prod ready elasticsearch alternatives? I&#x27;m working on a logging infrastructure project for shipping syslog, and it seems no one these days just uses plain central syslog and ES is the standard, but it seems bloated.<p>I&#x27;ve been tempted to just ship straight to a dB and skip all these crazy shippers and parsers and all the other middle men in the equation.<p>Also, why has no product unified monitoring and logging? AFAIK that&#x27;s why Splunk is worth it is you have the budget (I dont)
评论 #18897984 未加载
评论 #18905337 未加载
评论 #18897967 未加载
评论 #18898569 未加载
评论 #18899171 未加载
评论 #18897947 未加载
评论 #18899303 未加载
评论 #18898048 未加载
评论 #18898513 未加载
评论 #18911502 未加载
评论 #18897970 未加载
评论 #18902702 未加载
评论 #18898818 未加载
评论 #18898429 未加载
评论 #18898361 未加载
nathcd超过 6 年前
Neat! I hope this goes far, it&#x27;d be great to have a faster&#x2F;lighterweight Elastcsearch.<p>Something similar I&#x27;m really hoping to see is Tantivy in a Postgres extension, so I can stop playing the game of trying to keep my search engine and database in sync. Seeing pg-extend-rs (<a href="https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;pg-extend-rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;pg-extend-rs</a>) on HN the other week got me thinking about it again. Does anyone know whether this is feasible or if anyone is working on something in this vein?
评论 #18897130 未加载
评论 #18897167 未加载
评论 #18897012 未加载
评论 #18898657 未加载
评论 #18902709 未加载
pornel超过 6 年前
There are some real gems among Rust crates. I&#x27;m using tantivy[1]. It has been super easy to set up and it&#x27;s <i>faaast</i>.<p>[1]: <a href="https:&#x2F;&#x2F;crates.rs&#x2F;crates&#x2F;tantivy" rel="nofollow">https:&#x2F;&#x2F;crates.rs&#x2F;crates&#x2F;tantivy</a>
评论 #18897588 未加载
评论 #18900656 未加载
latenightcoding超过 6 年前
I love these type of projects. I am a big fan of Elasticsearch, but sometimes it feels overly complex, bloated and memory-hungry. I hope someday a decent Rust&#x2F;C++ alternative will take over. I was following the development of Apache Lucy (<a href="https:&#x2F;&#x2F;lucy.apache.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lucy.apache.org&#x2F;</a>) but the project has been retired now.
评论 #18898723 未加载
评论 #18907679 未加载
评论 #18898501 未加载
CSDude超过 6 年前
Tantivy does not allow schema evolution, but Lucene does, this is a major blocker for dynamic indices
评论 #18900663 未加载
评论 #18920112 未加载
markhenderson超过 6 年前
It would be great if this achieved API parity with ES. Being able to swap out parts of the ELK stack would make tools like kibana even more powerful.
评论 #18898030 未加载
badrabbit超过 6 年前
Love the idea, saw another one in 2018(<a href="https:&#x2F;&#x2F;www.gravwell.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.gravwell.io&#x2F;</a>)<p>At least in my experience the web interface is a huge gap. Kibana is ok but Splunk and it&#x27;s query language and visuals are much better. Anything that competes with Splunk is great imo.
评论 #18904959 未加载
amelius超过 6 年前
Also check out the roadmap:<p>&gt; <a href="https:&#x2F;&#x2F;github.com&#x2F;toshi-search&#x2F;Toshi&#x2F;blob&#x2F;master&#x2F;roadmap.md" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;toshi-search&#x2F;Toshi&#x2F;blob&#x2F;master&#x2F;roadmap.md</a><p>It seems that the main added functionality of ES, namely clustering, will still take a while to be implemented.
lettergram超过 6 年前
Nice! I’m going to have to check it out.<p>At the same time, I’m curious on the performance differences with postgres. I’ve been able to get very quick queries from Postgres:<p><a href="https:&#x2F;&#x2F;austingwalters.com&#x2F;fast-full-text-search-in-postgresql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;austingwalters.com&#x2F;fast-full-text-search-in-postgres...</a><p>The only time it’s slower to the point of using elasticsearch (for my usecases) is something like log search (so far).
评论 #18899217 未加载
ivoras超过 6 年前
Cool project!<p>But there&#x27;s an attitude attached which amuses me:<p>&gt; Toshi will always target stable Rust and will try our best to never make any use of unsafe Rust. While underlying libraries may make some use of unsafe, Toshi will make a concerted effort to vet these libraries in an effort to be completely free of unsafe Rust usage. The reason I chose this was because I felt that for this to actually become an attractive option for people to consider it would have to have be safe, stable and consistent. This was why stable Rust was chosen because of the guarantees and safety it provides.<p>It&#x27;s an admirable goal, though the fact that it&#x27;s stated prominently as one of the first things on the front page gives off somewhat of a &quot;doth protest too much&quot; vibe. It&#x27;s not like &quot;safety&quot; is rare these days. Any project written in Go, Python, Java, C#, Erlang, JS, and a myriad of others will be &quot;safe&quot; as far as memory access is concerned, and in many cases this safety will be easier to achieve than in Rust. As far as error handling safety, so far exceptions seem to be more expressive, though the jury is out there.<p>Basically, if a project stays away from C and C++ and libraries written in them, it&#x27;s more likely it will be hit by a hardware problem than an inherent language safety &#x2F; security issue. Luckily, &quot;safety&quot; is for the largest part the default for modern projects.
评论 #18898157 未加载
评论 #18898459 未加载
supernintendo超过 6 年前
Cute!
评论 #18904300 未加载
zozbot123超过 6 年前
Yet another great piece of work by the Rewrite-It-In-Rust Task Force (a sister organization to the Rust Evangelism Strike Force)!