Journal Index secondaire Elasticsearch pour Cassandra

Posté par  . Licence CC By‑SA.
9
16
jan.
2020

Index secondaire Elasticsearch pour Cassandra

Cassandra et Elasticsearch en une seule connexion

Cet index permet de faire des requêtes de type « Full Text Search » en utilisant la syntaxe CQL, par l’intermédiaire du pilote DataStax par exemple.

En créant une table avec une colonne qui ne contiendra pas de données et un index associé à cette colonne, des requêtes peuvent être envoyées vers Elasticsearch et les ids Cassandra correspondants sont retournés
Il n’y a pas besoin d’une connexion supplémentaire vers Elasticsearch, ni de faire de recoupements compliqués entre les données Cassandra et Elasticsearch. La réplication se fait automatiquement de Cassandra vers Elasticsearch. Il est possible de spécifier les types de données des champs qui seront indexés, pour permettre des requêtes plus complexes avec des range, match, etc.

Exemple de requête

Prenons une table définie comme ceci :

CREATE TABLE genesys.emails (
   id UUID PRIMARY KEY,
   subject text,
   body text,
   userid int,
   query text
);

Et un index comme ceci :

CREATE CUSTOM INDEX ON genesys.emails(query)
USING 'com.genesyslab.webme.commons.index.EsSecondaryIndex'
WITH OPTIONS = {
    'unicast-hosts': 'localhost:9200',
    'mapping-emails': '
        {
           "emails":{
              "date_detection":false,
              "numeric_detection":false,
              "properties":{
                 "id":{
                    "type":"keyword"
                 },
                 "userid":{
                    "type":"long"
                 },
                 "subject":{
                    "type":"text",
                    "fields":{
                       "keyword":{
                          "type":"keyword",
                          "ignore_above":256
                       }
                    }
                 },
                 "body":{
                    "type":"text"
                 },
                 "IndexationDate":{
                    "type":"date",
                    "format":"yyyy-MM-dd''T''HH:mm:ss.SSS''Z''"
                 },
                 "_cassandraTtl":{
                    "type":"long"
                 }
              }
           }
        }
    '};

Nous pouvons faire des requêtes :

select id, subject, body, userid, query  from emails where query='body:cassan*';
select id, subject, body, userid from genesys.emails
where query='{"query":{"range":{"userid":{"gte":10,"lte":50}}}}';

Cet index a été écrit par un collègue, et j’assure pour l’instant la partie intégration Open Source (disponibilité dans Maven Central, GitHub, etc.). Un conteneur Docker est disponible pour faciliter les tests. C’est une installation de Cassandra avec le greffon déjà présent.

Liens

  • # Sonic

    Posté par  . Évalué à -1. Dernière modification le 16 janvier 2020 à 17:24.

    Vu que le billet parle d'elastic search, j'en profite pour faire de la pub pour une chouette alternative libre françaaiiise (cocorico) : https://github.com/valeriansaliou/sonic (pas de grand rapport avec le billet du journal, je vous l'accorde)

    Je suis pas un pro d'elastic search mais pour mon petit usage perso de recherche ça suffit je trouve, ça tient bien sur un petit serveur.

    • [^] # Re: Sonic

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      AH ? Voilà qui est intéressant. Je cherchais justement un backend de recherche textuelle alternatif à ES (qui est, évidemment, beaucoup trop lourd pour mon usage). Merci pour le lien !

      • [^] # Re: Sonic

        Posté par  . Évalué à 2.

        Il existe apache solr comme alternative, bon je suis pas sur pour le cote moins lourd du coup :)

    • [^] # Re: Sonic

      Posté par  . Évalué à 3.

      Du coup, ça se compare plutôt à Lucene (bibliothèque sous-jacente à ES) ou à Xapian ; d'ailleurs, je n'invente rien, c'est marqué .

      • [^] # Re: Sonic

        Posté par  . Évalué à -3. Dernière modification le 18 janvier 2020 à 07:00.

        En effet l'API n'est pas REST ce qui a ses inconvenients! Mais d'un autre cote la plupart des gens qui utilisent ES utilisent un wrapper dessus le REST je crois ;)

        • [^] # Re: Sonic

          Posté par  . Évalué à 1. Dernière modification le 18 janvier 2020 à 08:48.

          Pour en production oui. Lors des phases de développement ou d'expérimentation c'est confort de pouvoir manipuler ton index à la main. Après ce n'est pas bloquant non plus.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Sonic

            Posté par  . Évalué à -3.

            Par curiosité, a la main = curl ? Ou tu penses a autre chose ?

            • [^] # Re: Sonic

              Posté par  . Évalué à 1.

              Oui curl, httpie ou n'importe quel client http.

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

        • [^] # Re: Sonic

          Posté par  . Évalué à 2.

          ce qui a ses inconvenients

          Mon commentaire ne portait aucune préférence sur un outil ou un autre ; seulement une différence d'approche : bibliothèque logiciel ou client/serveur.

          • [^] # Re: Sonic

            Posté par  . Évalué à -2.

            Et le mien une manière polie de dire que c'est bien un serveur ;)

            • [^] # Re: Sonic

              Posté par  . Évalué à 2.

              Ah, au temps pour moi. La page WP m'a induit en erreur.

    • [^] # Re: Sonic

      Posté par  (site web personnel) . Évalué à 3.

      Quels sont les avantages sur un Postgresql avec un index foule texte?

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.