Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
bahua129043yMaybe this is just the sysadmin in me talking, but why does your instinct seem to be to drop something you know has flaws into your app, as opposed to writing a search function yourself?
-
"Increased latency after bulk inserts"
What do you mean? This is very vague - and it depends on your hardware, too.
Do you mean a merge of segments?
"fast response time for users"
You can. But like any database, Elasticsearch has it's own rules - play by the rules and everything will run smoothly.
"Inability to add synonyms wo closing index"
I guess you mean the synonym analyzer.
This is right - when you change an index definition, e.g. the mapping, existing docs won't be migrated.
But ES has tools to ease the migration, e.g. the internal reindex API.
I said earlier that ES has a fixed set of rules.
First - ES requires design and planning.
You found out by yourself why: once an index is created, it cannot be altered "easily".
The reason for that lies in two fundamental principles of ES:
- multitenant
- Lucene based
Multitenant always requires careful resource planning - doesn't matter if it's ES, a RDBMs with replication, ...
You don't want a single task to take all resources of your cluster - which means you need to design the multitenant application in a way that resources are fixed and don't fluctuate largely during runtime and / or add safeguards to prevent it.
Lucene is the actual search engine - you might want to read up on how a search engine like Lucene works, it will help a lot.
Any full text search (not specifically Lucene - really any) requires to take a string, tokenize and analyse it.
To be fast, any full text search must utilize some form of special storage, in Lucene it is e.g. an inverted index.
The storage format is usually append only - meaning you can't update the inverted index, rather mark an entry as deleted and add a new document to it.
Which makes the rather complicated storage way easier...
The append only structure of Lucene / a full text index is an important factor in designing for Elastic.
Mass deletes / updates should be prevented.
Related Rants
-
thefaketimelord4Manager: let's use elasticsearch for performing relational queries. PostgreSQL performance is not great. Me...
-
C0D46Has anyone installed Elasticsearch on Linux - centos to be specific. Trying to workout why the fucker won't i...
-
BugsBuggy0Around 2 years ago, I had first discovered DevRant. I was an intern in a startup then, and I was working on E...
can you use elastic search as a search engine for your app ?
because i see several weak points in it.
the increased latency after every bulk uploading of docs, meaning u cant ensure fast response time for users
the inability to add synonyms without closing the index ? this is either downtime or ill have to replicate an index to update the original and then switch back to it !!
idk i feel i either must have wrong info or elastic is very inefficient. I might be wrong, not too experienced with it so if I am let me know of some good resources and workarounds that helped you
rant
elasticsearch