ElasticSearch ou Couchbase ou autre chose

Question

Contexte: J'ai un énorme flux de données - jusqu'à 1000000 enregistrements par heure, ttl est de 3 heures ... Chaque "document" contient environ 20 propriétés, je dois rechercher jusqu'à 15 propriétés en même temps en utilisant "==", "IN" et "BETWEEN" comparaison. Comme il n'y a pour la plupart aucune propriété insondable, il n'y a aucune raison de stocker deux fois le document (dans Couchbase AND dans l'index ElasticSearch), donc je pense que c'est une bonne idée de le stocker uniquement dans ElasticSearch. J'ai raison?

Ou peut-être quelqu'un peut me recommander une meilleure base de données pour une telle tâche? Je besoin d'un facile mise à l'échelle horizontale à l'avenir (sharding personnalisé de MySQL est pas une option) ... Ces données sont une sorte de cache cohérence pour une éventuelle et une mauvaise durabilité est OK ...

Selon le théorème de la PAC I ont besoin la plupart du temps a et P ...

Answer 1

En ce qui concerne la performance, à condition que vous utilisez du matériel de taille appropriée, vous ne devriez pas avoir des problèmes d'indexation des documents 1M par heure. J'ai couru Elasticsearch bien au-dessus de cela sans problèmes. Il y a une writeup détaillée ici que vous trouverez peut-être utiles concernant l'étalonnage et le dimensionnement d'un grand groupe ElasticSearch:

ElasticSearch setup for a large cluster with heavy aggregations

Pour un système de mise en cache éphémère avec un TTL de seulement 3 heures, je suis d'accord que ce serait une perte pour stocker les données dans plusieurs référentiels. Vous pouvez stocker les données dans Couchbase et les répliquer dans Elasticsearch en temps réel ou presque, mais pourquoi s'en soucier? Vous ne savez pas quel avantage vous obtiendriez d'avoir les données dans les deux endroits.

Pour des problèmes de performances concernant votre cas d'utilisation spécifique, je suggère fortement d'effectuer une analyse comparative. Une des forces d'Elasticsearch (et de Solr aussi) que j'ai découvertes est leur (étonnamment forte) performance lors de la recherche sur plusieurs champs non textuels. Vous avez tendance à penser à ES à des fins de recherche de texte (où il excelle), mais c'est aussi une bonne base de données à usage général. J'ai trouvé que, en particulier, il a de bonnes performances lors de la recherche sur plusieurs paramètres par rapport à d'autres solutions NoSQL.

Personnellement quand l'analyse comparative ES dans ce cas d'utilisation je regarde un certain nombre de différentes options d'indexation.ES prend en charge TTL pour les documents afin de purge automatiquement le cache est facile:

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-ttl-field.html

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/docs-index_.html

Cependant, vous pouvez jouer avec ayant des indices pour chaque chaque heure - une chose à propos de ES (en raison de c'est l'utilisation de Lucene en dessous pour l'indexation et le stockage de fichiers) qui supprime le travail différemment de la plupart des bases de données. Les documents sont marqués comme supprimés mais pas supprimés, puis périodiquement les fichiers situés en dessous (appelés segments) seront fusionnés, moment auquel de nouveaux segments seront créés sans les documents supprimés. Cela peut entraîner une bonne quantité d'activité de disque pour les cas d'utilisation intensive à fort volume dans un seul index. Le moyen de contourner cela est de créer un nouvel index pour chaque heure, puis de supprimer l'index dans son intégralité après que les données sont âgées de plus de 3 heures.

Vous pouvez trouver cette discussion précédente sur les TTL par rapport à des indices de séries chronologiques en ElasticSearch utiles: Performance issues using Elasticsearch as a time window storage

Enfin, en ce qui concerne l'échelle horizontale facile ElasticSearch est assez bonne ici - vous ajoutez un nouveau nœud avec le nom du cluster correct et ES s'occupe du reste, en migrant automatiquement les fragments vers le nouveau noeud. Dans votre cas d'utilisation, vous souhaiterez peut-être jouer avec le facteur de réplication, car plus de répliques sur plusieurs noeuds sont un moyen facile d'améliorer les performances des requêtes.

Answer 2

Pour l'utilisation cas d'un cache (système de cache-like), je pense que ElasticSearch vous donnera seulement des problèmes à l'avenir. Je suppose que vous n'avez pas du tout besoin d'indexation car vous ne cherchez pas à rechercher des fonctionnalités.

Je ne l'ai pas utilisé Couchbase mais je l'ai entendu de bonnes choses à ce sujet. J'ai entendu des cas d'utilisation comme utiliser Couchbase pour des fins de filtrage et Elasticsearch pour plus de recherche (et des choses que Couchbase ne peut pas faire).

Pour l'évolutivité, pour autant que je peux dire à la fois se ressemblent d'un point de vue très haut niveau. Les deux prennent en charge la fragmentation et la réplication faciles avec rééquilibrage des fragments et la promotion de réplicas secondaires en mode primaire lorsqu'un noeud du cluster tombe en panne. Les spécificités peuvent être différentes.

Mais en toute honnêteté, vous devrez essayer vous-même et de tester la production comme le trafic. J'ai travaillé avec Elasticsearch et je sais que vous ne pouvez pas toujours dire si c'est le bon choix pour votre cas d'utilisation car son comportement en production peut être différent de celui d'un autre en termes de performances.

Mais je pense que vous êtes sur la bonne voie.