Quelles stratégies de Recherche avec Cassandra ?
•Télécharger en tant que PPTX, PDF•
4 j'aime•1,676 vues
Webinar avec Ippon et DataStax sur les stratégies de recherches possibles avec Cassandra
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à Quelles stratégies de Recherche avec Cassandra ?
Similaire à Quelles stratégies de Recherche avec Cassandra ? (20)
Plus de Victor Coustenoble
Plus de Victor Coustenoble (8)
Quelles stratégies de Recherche avec Cassandra ?
- 1. Quelles stratégies de Recherche avec Cassandra ? Webinar 17 septembre 2015 Jérôme Mainaud – Victor Coustenoble
- 2. Agenda 1.Recherche multi-critères avec Cassandra 2.Recherche avec DataStax Enterprise Search
- 3. Ippon Technologies © 2015 Présentation Recherche multi-critères avec Cassandra Jérôme Mainaud ➔@jxerome ➔Architecte logiciel chez Ippon Technologies ➔DataStax Solution Architect Certifié
- 5. Ippon Technologies © 2015 Contexte Application de facturation en mode SAAS ➔Tous les utilisateurs partagent la même base de données ➔Les données sont isolées par utilisateur Application volumineuse ➔un an de stockage ➔500 millions de factures ➔2 milliards de lignes de facturation
- 6. Ippon Technologies © 2015 Contexte
- 7. Ippon Technologies © 2015 Evolution du back-end
- 8. Modélisation
- 9. Ippon Technologies © 2015 Modèle conceptuel
- 10. Ippon Technologies © 2015 Modèle physique
- 11. Ippon Technologies © 2015 Recherche multi-critères Critères obligatoires ➔User (implicite) ➔Date de la facture (plage de dates) Critères supplémentaires ➔Nom du client ➔Prénom du client ➔Ville ➔Code postal
- 12. Ippon Technologies © 2015 Utiliser Solr ? ● Intégré dans DataStax Enterprise ● Mise à jour atomique et automatique ● Recherche documentaire
- 13. Ippon Technologies © 2015 Utiliser Solr ? ● On cherche sur des colonnes statiques ➔Solr ne les gère pas ● On cherche des partitions ➔Solr retourne des lignes
- 14. Ippon Technologies © 2015 Tables d’index Utilisation de tables d’index ➔Clé de partition : Les critères primaire et un critère secondaire ○ user_id ○ date de facturation (tronqué à la date) ○ le critère secondaire ➔Clustering columns : l’identifiant de la facture
- 15. Ippon Technologies © 2015 Tables d’index
- 16. Ippon Technologies © 2015 Vue dématérialisée CREATE MATERIALIZED VIEW invoice_by_firstname AS SELECT invoice_id FROM invoice WHERE firstname IS NOT NULL PRIMARY KEY ((user_id, invoice_day, firstname), invoice_id) WITH CLUSTERING ORDER BY (invoice_id DESC)
- 17. Ippon Technologies © 2015 Recherches sur les index en parallèle Fusion par application en mémoire
- 18. Ippon Technologies © 2015 Recherches unitaires en parallèle Une page de résultat (id)
- 19. Ippon Technologies © 2015 Recherche Recherche sur une plage de dates ➔boucle sur les jours en s’arrêtant dès qu’on a une page de résultat
- 20. Ippon Technologies © 2015 Complexité de la recherche Nombre de requêtes ➔Pour chaque jour dans la plage de dates ○ 1 requête par critère secondaire (partition by query) ➔1 requête par élément trouvé (partition by query) Complexité de la recherche ➔partitions by query Exemple: 3 critères, 7 jours, 100 par page ➔nombre de requêtes ≤ 3 × 7 + 100 = 121
- 21. Résultats
- 22. Ippon Technologies © 2015 Limitations ● C’est une recherche exacte ➔Pas de recherche plein texte ➔Pas de recherche « commence par » ➔Pas de recherche sur un pattern ● Nécessite des critères obligatoires fortement discriminants ➔user_id & invoice_day ● La pagination ne donne pas le nombre total de pages de résultats ➔Réalisable moyen coût de lecture plus important ● Pas de tri possible
- 23. Ippon Technologies © 2015 Matériel ● Hébergement chez Ippon Hosting ● 8 noeuds équivalents ➔16 Go de RAM ➔Deux disques durs SSD de 256 Go en RAID 0 ● 6 noeuds pour le cluster Cassandra ● 2 noeuds pour l’application
- 24. Ippon Technologies © 2015 Résultats ● 5000 utilisateurs simultanés ● 9 mois de données ➔Ancien système : 3 mois ➔Objectif : 3 ans ● Résultats en « temps réel » ➔Les données sont immédiatement disponibles ➔Ancien système : 24h de retard ● Réduction importante des coûts
- 25. Ippon Technologies © 2015 Présentation DataStax Enterprise Search Victor Coustenoble ➔@vizanalytics ➔Ingénieur Solutions chez DataStax
- 26. Plan 1.Qu’est-ce que la Recherche ? 2.DataStax Enterprise Search ? 3.Apache Solr ? 4.Pourquoi avec Cassandra ? 5.Comment ça fonctionne ?
- 27. Ippon Technologies © 2015Confidential Qu’est ce que la Recherche ? 27
- 28. Ippon Technologies © 2015 DataStax Enterprise Search ? DataStax Enterprise Search = Apache Solr complétement et finement intégré au dessus de Apache Cassandra = Un moteur de recherche d’entreprise sur des données Cassandra à travers le moteur Lucene et une intégration de Apache Solr
- 29. Ippon Technologies © 2015Confidential 29 Apache Solr ? • La base de presque tous les moteurs de recherches (comme Elastic search) • Rapide, haute performance et scalable • Indexation et Recherche • Options de recherche avancée comme full text, facet, geospatial, synonymes, proximités … • http://lucene.apache.org • Système de recherche d’entreprise Open Source • Enveloppe au dessus du moteur Lucene • Possibilité de customisation • Indexation et requêtes de recherche via une API HTTP
- 30. Ippon Technologies © 2015Confidential Indexation Solr – Efficace et rapide ! 30 Credit: https://developer.apple.com/library/mac/documentation/userexperience/conceptual/SearchKitConcepts/searchKit_basics/searchKit_basics.html Terms
- 31. Ippon Technologies © 2015Confidential Solr ne peut pas être tout seul 31
- 32. Ippon Technologies © 2015Confidential 32 Haute disponibilité Scalabilité Linaire Requêtes OLTP avec une faible latence C * Apache Cassandra
- 33. Ippon Technologies © 2015Confidential 33 + =
- 34. Ippon Technologies © 2015 Comment Solr est intégré à cassandra ? ● Même JVM entre Cassandra et Solr sur chaque nœud Cassandra ● Index Lucene stockés et répliqués sur les nœuds du cluster Cassandra
- 35. Ippon Technologies © 2015Confidential 35 • Cassandra stocke les données • Solr stocke les indexes pour une recherche rapide • Les données sont indéxés localement sur les noeuds • Vous pouvez oublier que Solr existe • Vous pouvez faire des requêtes Solr à travers Cassandra Comment Solr est intégré à cassandra ?
- 36. Ippon Technologies © 2015Confidential 36 C * / S o l r Comment Solr est intégré à cassandra ? 1 seul Data Center
- 37. Ippon Technologies © 2015Confidential 37 C * C * / S o l r Comment Solr est intégré à cassandra ? 2 Data Center : 1 OLTP + 1 Recherche (sans ETL) Replication automatique
- 38. Ippon Technologies © 2015 Par rapport à Solr tout seul • Pas de goulot d’étranglement • Le client peut lire/écrire sur tous les noeuds Solr • Partionnement et réplication des index de recherche pour la montée en charge et la disponibilité • Support Multi-Data Center • Durabilité de la donnée (Solr manque de log, les données peuvent être perdues) Architecture SolrCloud
- 39. Ippon Technologies © 2015Confidential Indexation temps réel avec DSE Search 39 Standard Solr Indexing DSE Search Live Indexing
- 40. Ippon Technologies © 2015Confidential 40 Terme Cassandra Terme Solr Column Family / Table Core Row Document Column Field SSTable Index Vocabulaire
- 41. Ippon Technologies © 2015Confidential Interface d’administration Solr 41
- 42. Ippon Technologies © 2015Confidential 42 Requêtage Solr – Indexation et Recherche API HTTP de Solr API CQL de Cassandraou • Select * from demo.users_product where solr_query='{"q":"product_name:livre","facet":{"field":"product_attrib"}}'; • Select title,body from wiki.solr where solr_query='(title:foot* AND body:Arthur*) OR title:sport*'; • select * from amazon.metadata where solr_query='{"q":"title:Maltese~","fq":"categories:book"}';
- 43. Ippon Technologies © 2015 // Videos by id CREATE TABLE videos ( videoid uuid, userid uuid, name text, description text, location text, location_type int, preview_image_location text, tags set<text>, added_date timestamp, PRIMARY KEY (videoid) ); Confidential 43 // Index for tag keywords CREATE TABLE videos_by_tag ( tag text, videoid uuid, added_date timestamp, userid uuid, name text, preview_image_location text, tagged_date timestamp, PRIMARY KEY (tag, videoid) ); Solution classique Cassandra • Maintenance manuelle des tables “d’index” ! • Attention aux index secondaires !
- 44. Ippon Technologies © 2015Confidential 44 // Videos by id CREATE TABLE videos ( videoid uuid, userid uuid, name text, description text, location text, location_type int, preview_image_location text, tags set<text>, added_date timestamp, PRIMARY KEY (videoid ); Solution Solr
- 45. Ippon Technologies © 2015Confidential 45
- 46. Ippon Technologies © 2015Confidential 46 1. Démarrer un cluster Cassandra avec la recherche activées en utilisant l’installeur de DSE. $ sudo service dse cassandra -s 2. Création du keyspace et de la table Cassandra en CQL. 3. Execution de dse_tool sur la table videos $ dsetool create_core killrvideo.videos generateResources=true 4. Utilisation de l’interface d’administration de Solr afin de vérifier la création du core Solr. 5. Ecriture d’une requête CQL avec une recherche Solr. select* from videos where solr_query='description:cassandra*'; Mise en place
- 47. Ippon Technologies © 2015 DataStax Enterprise • Support • Sécurité • Production ready • Administration • Supervision • Analytique • Recherche • In-Memory
- 48. Ippon Technologies © 2015 Plus sur DataStax et Cassandra DataStax: http://www.datastax.com Downloads: http://www.datastax.com/download Documentation: http://www.datastax.com/docs Developer Blog: http://www.datastax.com/dev/blog Academy: https://academy.datastax.com/ Community Site: http://planetcassandra.org
- 49. Ippon Technologies © 2015 Merci Questions & Réponses
- 50. PARIS BORDEAUX NANTES WASHINGTON NEW-YORK RICHMOND contact@ippon.fr www.ippon.fr - www.ippon-hosting.com - www.ippon-digital.fr @ippontech - 01 46 12 48 48
Notes de l'éditeur
- Search is eveywhere. Tell story about kids with search and recommendations. Properly written queries, on the other hand, are completely precise. A query will give you exactly the result you ask for. Exactly what you asked for, which may or not be exactly what you want. The hardest part of a query is asking the right question. Search, on the other hand, is not precise. A dumb search just gives you a randomly ordered list of items in which your search term occurs. A smart search will provide you a ranked list of items that are strongly related to the search terms you entered, even if they do not match the exactly. This means that even though some of the results will doubtless be unrelated, and sometimes absurd, there is a very good chance that there is data you can use pretty high up in those results, even if you didn’t ask quite the right question. And there may well be relevant data you didn’t even think to ask for. Being smart in this way is a key benefit of search. Queries cannot be smart. Queries must always give you exactly what you asked for. There can be no tolerance for serendipity in query results. Search can be smart, but query must be dumb and strictly obedient. “Find me all webpages that contain “Cassandra” and “Optimization”” “Recommend artists who are “like” “Taylor Swift”” “Highlight the keywords “Awesome,” “Good,” and “Amazing.”” Find me all shoes with: Size: 12 Price: $15 - $60 Brand: Nike
- Lucene is the base to nearly every popular search engine out there, including elastic search (which is more a of fried taco shell) Fast, high performance, scalable search/IR library Open source Initially developed by Doug Cutting (Also author of Hadoop) Indexing and Searching Inverted Index of documents Provides advanced Search options like synonyms, stopwords, based on similarity, proximity. http://lucene.apache.org/ Created by Yonik Seeley for CNET Enterprise Search platform for Apache Lucene Open source Highly reliable, scalable, fault tolerant Support distributed Indexing (SolrCloud), Replication, and load balanced querying http://lucene.apache.org/solr To search! (duh) Note: Not the same as querying. Querying implies you are searching with a specific value in mind. Search is fuzzier, about finding likeness. Full text search and highlighting Faceted search (search by price, size, manufacturer, etc.) Geospatial search (combining location information, filtering by distance, and more) Solr is an open source enterprise search system Solr “wraps” the Lucene open source information retrieval engine You customize Solr via configuration & plug-ins Free-form text search includes wildcards and phrases Query support includes filtering (ranges, geo-spatial) and sorting You can run Solr as a webapp, or in stand-alone (embedded) mode You make search requests using HTTP GET requests Documents are added and deleted via HTTP POST requests Document updates work the same way (internally as delete+add) ----- Meeting Notes (6/5/15 14:33) ----- Lucene is assembly to Solr's Java
- These are extremely efficient and fast structures that live on disk. Simple queries are typically fulfilled in < 1ms. More complex ones, < 10ms
- no built in datastore, it is a just a jar file that runs in a servlet container like Jetty and Tomcat Give me some documents and let me index them for you! But how does that solve your scaling problem? Your uptime problem? It doesn’t. data is stored completely on disk No built in way to shard or distribute Even with SolrCloud or ElasticSearch, you will need to move your data around SolrCloud = zookeeper makes Solr clusterable. Just like mysql sharding… not transparent
- SolrCloud = zookeeper makes Solr clusterable. Just like mysql sharding… not transparent
- Cassandra is storing your data, solr is storing the indexes for fast search. Again, no ETLs and your data model doesn’t change. Data is indexed locally. You could completely forgot that solr exists. You could just write your queries through Cassandra.
- You get a lot of the benefits from using Solr on top of C* - No ETL! Just load the data in cassandra and it’s automatically replicated to Solr! Data is automatically replicated from the Cassandra DC to the Solr DC No single point of failure No ETL
- You get a lot of the benefits from using Solr on top of C* - No ETL! Just load the data in cassandra and it’s automatically replicated to Solr! Data is automatically replicated from the Cassandra DC to the Solr DC No single point of failure No ETL
- Real time indexing!! Push down predicates Locality awareness with the sharding Netty vs HTTP communication Using docvalues all the time lockless agortithms on accessing ram buffer to provide linear scalability, each thread can search a different portion of a segment, so you can have larger ram buffers All this plus some other enhancements means indexing twice as fast as OSS lucene
- Solr is an enterprise search solution meaning you have access to many API’s, there’s an administrative UI, support for importing data from different sources, and customizations (Solr is a bunch of JARS!) It was built on top of the Lucene information retrieval engine and was developed by Cnet as a product search engine.
- Solr is an enterprise search solution meaning you have access to many API’s, there’s an administrative UI, support for importing data from different sources, and customizations (Solr is a bunch of JARS!) It was built on top of the Lucene information retrieval engine and was developed by Cnet as a product search engine.
- This ONLY allows search on tags, and the “index” table needs to be maintained manually. This is fine if this is all you want to do, and is very common. Location_type, currently ith only 2 values, will work with a2i, name on the other hand, would not. So how do you search by name? Secondary indexes will allow you to search on the whole field, but those aren’t efficient for higher cardinality values, like email address Secondary index creates additional data structures on each node that hold table partitions Each ‘local index’ indexes values in rows stored locally Query on an indexed column requires accessing ‘local indexes’ on all nodes Expensive Query on a partition key and an indexed column requires accessing a ‘local index’ on one (or a few) nodes Efficient But say you want to search the text in description or title? What now?