# Real-time Response Time

**URL:** <https://discuss.elastic.co/t/real-time-response-time/8505>\
**Category:** Elasticsearch\
**Created:** [July 24, 2012, 5:20pm UTC](https://discuss.elastic.co/t/real-time-response-time/8505 "2012-07-24T17:20:51Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Behrad\_Zari](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/behrad_zari/32/1002_2.png) [@Behrad\_Zari](https://discuss.elastic.co/u/Behrad_Zari)\
**Post date:** [July 24, 2012, 5:20pm UTC](https://discuss.elastic.co/t/real-time-response-time/8505/1 "2012-07-24T17:20:51Z")

</div>

Howdy,  
We have a Couchdb database of 10million documents (6GB in size), on which  
we do realtime search by map/reduce views.  
I installed ES with couchdb river to see if I can acheive realtime response  
time (\<500 ms) in searching our dataset.  
with a default configuration, indexes grow to 7GB in ES, and response time  
of a query like f1:v1\* AND f2:v2\* was more than  
1.5 secs, and around 2, 3 secs in some cases!  
I want to know if I can use a configuration, or tweak my indexes  
(ignore unnecessary fields or optimize for a subset of searches)  
to achieve \<0.5 sec response time!!?

---

<div class="post-metadata">

**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\
**Post date:** [July 24, 2012, 5:42pm UTC](https://discuss.elastic.co/t/real-time-response-time/8505/2 "2012-07-24T17:42:13Z")

</div>

Wildcard searches are not the most performant ones.  
You should think of building an efficient mapping for your documents.

Plus, you should ask yourself what are your users looking for.  
If you need full text search (like Google), you probably don't want to use wildcards.

Could you post a sample of your documents ?

David 😉  
Twitter : @dadoonet / @elasticsearchfr

Le 24 juil. 2012 à 19:20, Behrad Zari [behradz@gmail.com](mailto:behradz@gmail.com) a écrit :

> Howdy,  
> We have a Couchdb database of 10million documents (6GB in size), on which we do realtime search by map/reduce views.  
> I installed ES with couchdb river to see if I can acheive realtime response time (\<500 ms) in searching our dataset.  
> with a default configuration, indexes grow to 7GB in ES, and response time of a query like f1:v1\* AND f2:v2\* was more than  
> 1.5 secs, and around 2, 3 secs in some cases!  
> I want to know if I can use a configuration, or tweak my indexes (ignore unnecessary fields or optimize for a subset of searches)  
> to achieve \<0.5 sec response time!!?

---

<div class="post-metadata">

**Author:** ![Behrad\_Zari](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/behrad_zari/32/1002_2.png) [@Behrad\_Zari](https://discuss.elastic.co/u/Behrad_Zari)\
**Post date:** [July 24, 2012, 10:40pm UTC](https://discuss.elastic.co/t/real-time-response-time/8505/3 "2012-07-24T22:40:43Z")

</div>

David,  
Consider a business directory which queries are patterns (wildcards are  
crucial to us) on 2, 3 fields that can be AND-ed together! fields are  
Strings like, names, addresses, phones, tags, ... in a simple structured  
json.

I also have an off-topic question: Can we change the default lucene indexer  
to enable homophonic characters in Arabic/Persian (too support mis-spelling  
of words)? forexample searching for صلام also contains results like سلام!  
(In English it means searching foto results in photo...)

On Tuesday, July 24, 2012 9:50:51 PM UTC+4:30, Behrad Zari wrote:

> Howdy,  
> We have a Couchdb database of 10million documents (6GB in size), on which  
> we do realtime search by map/reduce views.  
> I installed ES with couchdb river to see if I can acheive realtime  
> response time (\<500 ms) in searching our dataset.  
> with a default configuration, indexes grow to 7GB in ES, and response time  
> of a query like f1:v1\* AND f2:v2\* was more than  
> 1.5 secs, and around 2, 3 secs in some cases!  
> I want to know if I can use a configuration, or tweak my indexes  
> (ignore unnecessary fields or optimize for a subset of searches)  
> to achieve \<0.5 sec response time!!?

---

<div class="post-metadata">

**Author:** ![Clinton\_Gormley](https://avatars.discourse-cdn.com/v4/letter/c/50afbb/32.png) [@Clinton\_Gormley](https://discuss.elastic.co/u/Clinton_Gormley)\
**Post date:** [July 25, 2012, 8:04am UTC](https://discuss.elastic.co/t/real-time-response-time/8505/4 "2012-07-25T08:04:30Z")

</div>

Hi Behrad

> Consider a business directory which queries are patterns (wildcards  
> are crucial to us)

You can achieve the same effect as wildcards but without using wildcard  
queries, which are inefficient. You need to analyze the strings you  
want to be searchable as wildcards using either the edge ngram  
tokenizer, or the ngram tokenizer (depending on whether you want to  
match from the beginning of the word, or anywhere within a word)

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

See this post for an example of using edge ngrams:

> <https://stackoverflow.com/questions/9421358/filename-search-with-elasticsearch>

> on 2, 3 fields that can be AND-ed together! fields are Strings like,  
> names, addresses, phones, tags, ... in a simple structured json.

Doing AND queries is fine, either by changing the default\_operator for a  
query string query or a text query to 'AND', or using bool or dismax  
query clauses to join multiple queries.

> I also have an off-topic question: Can we change the default lucene  
> indexer to enable homophonic characters in Arabic/Persian (too support  
> mis-spelling of words)? forexample searching for صلام also contains  
> results like سلام!  
> (In English it means searching foto results in photo...)

I'm not sure what is available in Lucene for Arabic homophones, but the  
mapping character filter and the synonyms token filter may be useful:

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

Possibly also the pattern replace filter:

> **[Elasticsearch Platform — Find real-time answers at scale](https://www.elastic.co)**
>
> Power insights and outcomes with the Elasticsearch Platform and AI. See into your data and find answers that matter with enterprise solutions designed to help you build, observe, and protect. Try Elasticsearch free today.

clint

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [July 6, 2017, 3:19am UTC](https://discuss.elastic.co/t/real-time-response-time/8505/5 "2017-07-06T03:19:07Z")

</div>