81–90 of 95 posts
I think it's not terrible - redis itself is just brilant ! But wow a search-redis ? I think they have a lotttt of ground to make up to compete in the search space. The amount of options/analysis/tokenization/other-search features you get out the box from anything Lucene based (solr,elastic) is just staggering.
Earlier quoted context omitted.
I've recently started using MeiliSearch and quite like it, does anyone have experience with it?
I'm just getting ready to push instant search as a major feature on a client's web application, as both public-facing & admin-side. The MeiliSearch team has been great in terms of communication regarding issues, new features, the roadmap, etc. They're also moving quickly, constantly adding new functionality that has been useful as I've been working on the integration. Depending on what you're planning on using it for…
Earlier quoted context omitted.
It’s amazing that you reached the conclusion that it won’t do the job after reading a benchmark for 2 minutes! The benchmarks are quite realistic (5m docs, 25m products) for document search, and the settings reflect real usage. There is no “memory” storage type for ES, it has “mmapfs” which the documentation explicitly says is dangerous and might be removed. The default `hybridfs` already has the ability to use memor…
The point is not that the benchmarks were setup incorrectly or disputing that RediSearch is faster. It’s thst it’s doing far far less because it’s not ranking, and full text search without ranking is... less than useful.
I am a bit dated but I dont have a high confidence of redis with persistent storage such as a typical ACID database. How does this fit into an architecture? It seems painful to have to write code to reload the search db if it fails. How long is redis search going to exist and be supported? If this is delivered as a module, what guarantees do I have that the module interface wont break and leave redis search in a brok…
Anything that kills redis persistence is also going to corrupt whatever else database you'd have used instead. In fact redis persistence is such a simple model, I'd be surprised if most RDBMs weren't more likely to corrupt data.
I've been running a redis database since 2013 and haven't had a case of lost data once and never even had to restore from a backup.
Earlier quoted context omitted.
> I'm reticent to think that redis search has managed to make them ok at the first try. Your example doesn't really match the reality of Redis. Modules in Redis can bring their own data types and algorithms and don't need to resort to the same kind of hack you mentioned. The ecosystem inside Redis is designed for modularity and clear, minimalistic interfaces between components. RediSearch might not be perfect, but an…
> Modules in Redis can bring their own data types and algorithms and don't need to resort to the same kind of hack you mentioned. To emphasize this: One thing people might misunderstand about Redis is that Redis extension developers aren't expected to fit their data structures to the needs of a storage-engine. It's not like Cassandra, where your data structures must 'boil down' to key-value pairs; nor is it like an R…
From an information retrieval perspective, this is embarrassing, and the benchmarks aren’t close to being apples and oranges—it’s more like apples and Mack trucks. The linked benchmark is for a toy data set of 5.6GB, which we all know Redis will store in RAM; yet they don’t say whether they set “index.storage.type: memory” on ElasticSearch (guessing they didn’t). At the same time, ElasticSearch/Lucene puts considerab…
That's completely untrue, it comes with a few scoring algorithms out of the box (https://oss.redislabs.com/redisearch/Scoring/) and results can also be ranked by the value of arbitrary numeric or short text fields. On top of that, there is a plugin API to provide custom scorers written in C/C++.
BTW It's funny though that in the end most of the use of ElasticSearch is for analyzing logs and all the IR scoring tricks are not even used.
Earlier quoted context omitted.
I mean speed is nice, but it is not the primary thing I am concerned with in a search engine, as long as it is acceptable it is not in the list of requirements - things that would be on my list - not necessarily in this order but close 1. What human languages does it support. 2. In these human languages how does stemming and decompounding work in your implementation. 3. how is word importance determined in your index…
The question in general is "Yes, RediSearch supports all of these features". You can read about it all in the docs https://redisearch.io I also pointed bellow to the specific relevant area in the docs. > 1. What human languages does it support. > 2. In these human languages how does stemming and decompounding work in your implementation. https://oss.redislabs.com/redisearch/Stemming/ > 3. how is word importance deter…
Why would I pay to be off on an island very locked into a proprietary search tech? Even if it is a little faster with the redis brand attached to it? It doesn’t seem quite turnkey as Algolia or as deeply featured like Lucidworks Fusion...
Maybe I just don’t get the pitch yet...
I’m trying to imagine why I would not use existing, mature search tech (Solr/Elastic) with existing mindshare I can hire. Why would I pay to be off on an island very locked into a proprietary search tech? Even if it is a little faster with the redis brand attached to it? It doesn’t seem quite turnkey as Algolia or as deeply featured like Lucidworks Fusion... Maybe I just don’t get the pitch yet...
It attaches to existing redis hash keys and allows you to add an index to your already existing data for example.
Disclaimer - I'm the original author of RediSearch (started in 2016), before the switch to a non FOSS license. I'm not affiliated with it anymore and haven't followed its development for the past couple of years. But I can tell you that our first users were people who couldn't get ES working for their workloads, or had good redis infrastructure in place already and were able to utilize it for this as well.
From an information retrieval perspective, this is embarrassing, and the benchmarks aren’t close to being apples and oranges—it’s more like apples and Mack trucks. The linked benchmark is for a toy data set of 5.6GB, which we all know Redis will store in RAM; yet they don’t say whether they set “index.storage.type: memory” on ElasticSearch (guessing they didn’t). At the same time, ElasticSearch/Lucene puts considerab…