> What is a Toshi?<p>> 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.
Does anyone know of any other prod ready elasticsearch alternatives? I'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'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's why Splunk is worth it is you have the budget (I dont)
Neat! I hope this goes far, it'd be great to have a faster/lighterweight Elastcsearch.<p>Something similar I'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://github.com/bluejekyll/pg-extend-rs" rel="nofollow">https://github.com/bluejekyll/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?
There are some real gems among Rust crates. I'm using tantivy[1]. It has been super easy to set up and it's <i>faaast</i>.<p>[1]: <a href="https://crates.rs/crates/tantivy" rel="nofollow">https://crates.rs/crates/tantivy</a>
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/C++ alternative will take over. I was following the development of Apache Lucy (<a href="https://lucy.apache.org/" rel="nofollow">https://lucy.apache.org/</a>) but the project has been retired now.
Love the idea, saw another one in 2018(<a href="https://www.gravwell.io/" rel="nofollow">https://www.gravwell.io/</a>)<p>At least in my experience the web interface is a huge gap. Kibana is ok but Splunk and it's query language and visuals are much better. Anything that competes with Splunk is great imo.
Also check out the roadmap:<p>> <a href="https://github.com/toshi-search/Toshi/blob/master/roadmap.md" rel="nofollow">https://github.com/toshi-search/Toshi/blob/master/roadmap.md</a><p>It seems that the main added functionality of ES, namely clustering, will still take a while to be implemented.
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://austingwalters.com/fast-full-text-search-in-postgresql/" rel="nofollow">https://austingwalters.com/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).
Cool project!<p>But there's an attitude attached which amuses me:<p>> 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's an admirable goal, though the fact that it's stated prominently as one of the first things on the front page gives off somewhat of a "doth protest too much" vibe. It's not like "safety" is rare these days. Any project written in Go, Python, Java, C#, Erlang, JS, and a myriad of others will be "safe" 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's more likely it will be hit by a hardware problem than an inherent language safety / security issue. Luckily, "safety" is for the largest part the default for modern projects.