71–80 of 95 posts
Are we pronouncing this Ready-Search, Redis-Search, or Redis-urch? Personally I vote Ready Search but I’m also in the Postgres-Sequel camp :)
EDIT: reh-dih-search, since the "re" is pronounced like in "red" [0] https://redis.io/topics/faq
Are we pronouncing this Ready-Search, Redis-Search, or Redis-urch? Personally I vote Ready Search but I’m also in the Postgres-Sequel camp :)
ree-dih-search EDIT: reh-dih-search, since the "re" is pronounced like in "red" [0] https://redis.io/topics/faq
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…
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…
I rememeber long ago when SQL Server included full text, we thought that our time fiddling with lucene.net had become to an end, but when we tried it failed miserably because the full text engine and the relational one where like 2 different parts, and if you wanted to make a full text search and order by a numeric field, it would have to make a temporal table with all the results of the full text and order that. Those are the things tha lucene solves so well, that I'm reticent to think that redis search has managed to make them ok at the first try. So, not apples to oranges benchmark, but if you have already redis and the search capabilities that you want to add are fullfiled by redis search, it can be a good product.
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…
Well, you have MemoryIndex, which is different proposition (it's used for the percolate feature). I can get that redis search can be faster than Lucene based search engines, but actually running the search is the easiest part, there's a lot of thought and effort on making a decent search engine, and the article doesn't tell me if I can get facets, order by any field, make both fulltext and geospatial queries, and man…
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 any problem will stem from a different set of causes, not because it tries to "emulate" a data model.
The whole point of Redis is not having to emulate data types and algorithms.
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…
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…
I believe that the combination of tmpfs + file access — and especially tmpfs + mmap(2) — results in a fast path that almost resembles direct memory access. (If the file or memory-region is opened read-only, the kernel can expose/share the relevant memory pages directly into the process.)
Earlier quoted context omitted.
ree-dih-search EDIT: reh-dih-search, since the "re" is pronounced like in "red" [0] https://redis.io/topics/faq
The icon is red so I call it red-is ️
Earlier quoted context omitted.
Well, you have MemoryIndex, which is different proposition (it's used for the percolate feature). I can get that redis search can be faster than Lucene based search engines, but actually running the search is the easiest part, there's a lot of thought and effort on making a decent search engine, and the article doesn't tell me if I can get facets, order by any field, make both fulltext and geospatial queries, and man…
> 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…
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 RDBMS, where your data structures must 'boil down' to tuple-sets; nor like a graph DBMS, where your data structures must 'boil down' to EAV triples. Redis data structures aren't "implemented in terms of" any other simpler 'canonical' data structure.
Instead, when you look at something like Redis Streams or the Redis Graph module, the whole complex data structure for each stream/graph is a big opaque in-memory thing dangling off a single key. It doesn't need to be broken down into parts "legible" to Redis. It can just be what it is. "Objects" in the Redis keyspace (the things keys are holding) can't hold pointers to one-another, so the core Redis commands can blindly manipulate them (e.g. deallocate them.) For everything else, you go through the module's commands, which walk the internals of the data-structure as what it is: a plain-old in-memory C struct, defined in your module's header files.
The canonical representation of a data structure in the Redis AOF (WAL log) is just the sequence of commands used to build it; not the data-structure itself. So, as a module developer, to get AOF persistence of your module's types, you don't need to do a thing, other than ensuring that your module's commands are deterministic.
You do need to do a bit of work to get your module's types to serialize into Redis RDB snapshots. But it's completely up to you how to define your types' serializations. Redis just provides an API for writing and reading scalar types from the RDB file stream. How your module uses them to save/load a value of a type is up to you. (And you can just skip this if you like; RDB persistence is used far less often than AOF persistence, so support for RDB persistence it's not even a highly-demanded feature for modules. If you don't bother, then loading your module just disables RDB persistence.)
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 broken state?
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…
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…
Any advantages over Elasticsearch? EDIT: I did read the article, though I overlooked the link to comparison with Elasticsearch.
I've recently started using MeiliSearch and quite like it, does anyone have experience with it?
Depending on what you're planning on using it for, make sure to review the documentation, and check the GitHub issues/discussions. For example, I've had to use workarounds to handle some lacking auth/permissions support, but they're currently working on improving it.
Best part by far is the performance. And memory requirements is completely reasonable, depending on the size of the database.