# Performances ruby/redis vs translate filter

**URL:** https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094
**Category:** Logstash
**Created:** [September 26, 2018, 11:11pm UTC](https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094 "2018-09-26T23:11:38Z")
**Posts on this page:** 4
**Page:** 1

<div class="post-metadata">

### Author: ![drosys](https://avatars.discourse-cdn.com/v4/letter/d/85e7bf/32.png) [@drosys](https://discuss.elastic.co/u/drosys)
#### Post date: [September 26, 2018, 11:11pm UTC](https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094/1 "2018-09-26T23:11:38Z")

</div>

Dear All,  
I have a use case where i need to be able to compare high volume of data (fields like ip addr) to large IP databases.  
I have think about the approach of using ruby filter with redis socket connection (with init =\> to start only once), then request redis DB using mget...  
Pros: - Redis supposed to be high performances  
- No need to restart / send kill -HUP signal to reload a dictionnary file (maybe not necessary ?)  
Cons: Didn t see any config of that kind here... but being the first doesn't mean doing the wrong way 🙂

The other approach would be to use standard translate {} filter with a dictionnary + exact =\> true

I am now wondering if some of you have an idea of impact/performances on large volume for these 2 solutions ?  
Also for the dictionary option is there any "clean" way to reload the yaml dict frequently ?

Kind regards,

---

<div class="post-metadata">

### Author: ![Christian\_Dahlqvist](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/christian_dahlqvist/32/4617_2.png) [@Christian\_Dahlqvist](https://discuss.elastic.co/u/Christian_Dahlqvist)
#### Post date: [September 27, 2018, 5:34am UTC](https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094/2 "2018-09-27T05:34:32Z")

</div>

[This blog post](https://www.elastic.co/blog/elasticsearch-data-enrichment-with-logstash-a-few-security-examples) may be useful to you. It describes a prototype memcached plugin that sounds close to what you are looking for, although it is just available as an early prototype. Maybe this could be used or act as a blueprint for how to create a plugin that interfaces with Redis?

Last time I looked the translate plugin could take some time reloading, so changing the dictionary very frequently might not be a good idea (I am not sure, so need to be tested). You could however also look into the jdbc\_streaming plugin as may work for your use case.

---

<div class="post-metadata">

### Author: ![drosys](https://avatars.discourse-cdn.com/v4/letter/d/85e7bf/32.png) [@drosys](https://discuss.elastic.co/u/drosys)
#### Post date: [September 27, 2018, 10:37pm UTC](https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094/3 "2018-09-27T22:37:28Z")

</div>

Hi Christian,  
Thank you for your answer it is much appreciated !  
I was not aware of this article which seems to be very interesting nad learnt me new approaches..  
It also seems that "translate" would not be suitable for large volumes / dynamic updates...  
The good thing is that I found someone which has does the same as my idea !!! (last year) with what looks like amazing results..

> [@Redis connect to local socket file in Ruby filter?](https://discuss.elastic.co/t/redis-connect-to-local-socket-file-in-ruby-filter/109655/10):
>
> Very good. I will give it a try and let you know if it works, and if so, what effect (if any) it has on the performance of the filter. Thanks for the idea!

I ll try to implement it soon 🙂

---

<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: [October 25, 2018, 10:37pm UTC](https://discuss.elastic.co/t/performances-ruby-redis-vs-translate-filter/150094/4 "2018-10-25T22:37:29Z")

</div>

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.
