Différence de performance ES/Solr

[Nicolas Labrot]

Bonjour à tous,

Je suis en train d'évaluer ES 0.90.0 et Solr 4.3 sur un volume de données assez faible : 5 millions de documents, 10 fields par doc de petite taille. Le tout sur 2 shards, 0 replicas, avec 1.2Gb de mémoire allouée à la JVM.

La config de Solr et d'ES est celle de base, pas de customization du mapping.
L'index est optimisé.
Je ne retourne que 25 résultats


Je lance une requête que je pense simple : clientId:valeur_numérique1 AND docTypeId:valeur_numérique2

Elle retourne les documents par type associés à un client.
valeur_numerique1 et valeur_numérique2 sont pris au hasard parmis la liste de ceux présents dans l'index. Il y a toujours un résultat associé à ces requêtes.

Résultats:

• Solr 100 users simultannés : 500 req/s
• ES 100 users simultannés : 200 req/s

Le nombre de résultat retourné par Solr et ES est identique. La différence de perf me semble trop importante pour être honnête. Ce qui est interessant de noter c'est que la requete seule "clientId:valeur_numérique1" monte à 800 req/s et la requete seule "docTypeId:valeur_numérique2" monte à 150 req/s. Le nombre de résultats de la seconde est 10x plus important que la première.

Je suis également passé par une filter query plutot que par une query standard et j'obtiens le même résultat. Un vmstat pendant les queries ne montre quasiment aucune activité des IO et aucune du swap.


Je suis à cours d'idée pour tenter de trouver une solution et j'en viens à penser que Solr est plus performant qu'ES (en tous cas dans ce cas de figure).

Avez vous des idées?


Nicolas

[Nicolas Labrot]

Je me demande si ce n'est pas lié à https://issues.apache.org/jira/browse/LUCENE-4571

2013/5/17 Nicolas Labrot <nit...@gmail.com>

--
--
---
Vous pouvez également poster et consulter les réponses en anglais sur le groupe Elasticsearch https://groups.google.com/group/elasticsearch
 
Si vous avez également posté votre question sur la mailing list elasti...@googlegroups.com, merci d'indiquer ici le lien vers cette discussion pour faciliter le suivi.
 
Twitter : @ElasticsearchFR https://twitter.com/#!/ElasticsearchFR
Site web (English) : http://www.elasticsearch.org/
 
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Elasticsearch FR.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse elasticsearch-...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
 
 

[David Pilato]

Tu peux poster tes queries ES?

Sinon, 1.2 gb de RAM c'est faible. Est ce que la seconde exécution est aussi lente ?

Pour améliorer le thoughput dans ES l'idée est d'augmenter le nombre de replica.

Ce qui serait sympa c'est d'indexer massivement en même temps pour voir ce que cela donne.

Il est possible que sur un cluster qui ne subit pas de mise à jour, tu puisses observer ici ou là de meilleures perfs avec SOLR, mais je dirai que ce type de test brut mériterait ensuite d'être rejoué avec du tuning de part et d'autre.

--

David ;-)

Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

--

[David Pilato]

Oublie ma seconde question. Elle est stupide...

--

David ;-)

Twitter : @dadoonet / @elasticsearchfr / @scrutmydocs

[Nicolas Labrot]

Voici la requête (désolé, pas de gist possible, github est ... bloqué à mon taf) :

{
    "from": 0,
    "size": 25,
    "query": {"constant_score": {"query": {"bool": {"must": [
        {"field": {"docType_i": 1005}},
        {"field": {"docClientId_l": 12000001000001}}
    ]}}}},
    "fields": []
}

Si j'utilise un filtre dans la query je monte à 1400 req/s
{
    "from": 0,
    "size": 25,
    "query": {"constant_score": {"filter": {"bool": {"must": [
        {"term": {"docType_i": 1039}},
        {"term": {"docClientId_l": 11000001000014}}
    ]}}}},
    "fields": []
}

Ce qui est après reflexion tres logique, mais je n'aurais pas pensé que le cout etait aussi important

2013/5/17 David Pilato <da...@pilato.fr>