Quels problèmes d'évolutivité avez-vous rencontrés lors de l'utilisation d'un magasin de données NoSQL?
NoSQL fait référence aux magasins de données non relationnels qui rompent avec l'historique des bases de données relationnelles et les garanties ACID. Les magasins de données NoSQL Open Source populaires incluent:
- Cassandra (tableau, écrit en Java, utilisé par Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit et Twitter)
- CouchDB (document, écrit en Erlang, utilisé par BBC et Engine Yard)
- Dynomite (valeur-clé, écrite en Erlang, utilisée par Powerset)
- HBase (valeur-clé, écrite en Java, utilisée par Bing)
- Hypertable (tabulaire, écrit en C++, utilisé par Baidu)
- Kai (valeur-clé, écrite en Erlang)
- MemcacheDB (valeur-clé, écrite en C, utilisée par Reddit)
- MongoDB (document, écrit en C++, utilisé par Electronic Arts, Github, NY Times et Sourceforge)
- Neo4j (graphique, écrit en Java, utilisé par certaines universités suédoises)
- Project Voldemort (valeur-clé, écrite en Java, utilisée par LinkedIn)
- Redis (valeur-clé, écrite en C, utilisée par Craigslist, Engine Yard et Github)
- Riak (valeur-clé, écrite en erlang, utilisée par Comcast et Mochi Media)
- Ringo (valeur-clé, écrite en erlang, utilisée par Nokia)
- Scalaris (valeur-clé, écrite en Erlang, utilisée par OnScale)
- Terrastore (document, écrit en Java)
- ThruDB (document, écrit en C++, utilisé par JunkDepot.com)
- Cabinet de Tokyo/Tokyo Tyrant (valeur-clé, écrite en C, utilisée par Mixi.jp (site de réseau social japonais))
J'aimerais connaître les problèmes spécifiques que vous - le lecteur SO - avez résolus en utilisant des magasins de données et le magasin de données NoSQL que vous avez utilisé.
Des questions:
- Quels problèmes d'évolutivité avez-vous utilisé pour résoudre les magasins de données NoSQL?
- Quel magasin de données NoSQL avez-vous utilisé?
- Quelle base de données avez-vous utilisée avant de basculer vers un magasin de données NoSQL?
Je cherche des expériences de première main, alors s'il vous plaît, ne répondez que si vous en avez.
J'ai remplacé un petit sous-projet de MySQL par CouchDB afin de pouvoir gérer la charge. Le résultat était incroyable.
Il y a environ 2 ans, nous avons publié un logiciel auto-écrit sur http://www.ubuntuusers.de/ (qui est probablement le plus grand site Web de la communauté allemande Linux). Le site est écrit en Python et nous avons ajouté un middleware WSGI qui a été capable de récupérer toutes les exceptions et de les envoyer vers un autre petit site Web géré par MySQL. Ce petit site Web a utilisé un hachage pour déterminer différents bogues et a également stocké le nombre d'occurrences et la dernière.
Malheureusement, peu de temps après sa publication, le site Web de traceback-logger ne répondait plus. Nous avons eu quelques problèmes de verrouillage avec la base de production de notre site principal qui lançait des exceptions à chaque demande, ainsi que plusieurs autres bogues, que nous n’avons pas explorés au cours de la phase de test. Le groupe de serveurs de notre site principal, appelé la page de soumission de traceback-logger plusieurs fois par seconde. Et c’était beaucoup trop pour le petit serveur qui hébergeait le journal de suivi (c’était déjà un ancien serveur, qui n’était utilisé que pour le développement).
A cette époque, CouchDB était plutôt populaire et j'ai donc décidé de l'essayer et d'écrire un petit enregistreur de suivi avec lui. Le nouvel enregistreur consistait uniquement en un seul fichier python, qui fournissait une liste de bogues avec des options de tri et de filtrage et une page d'envoi. Et en arrière-plan, j'ai lancé un processus CouchDB. Le nouveau logiciel a répondu extrêmement rapidement à toutes les demandes et nous avons pu visualiser la quantité énorme de rapports de bogues automatiques.
Une chose intéressante est que la solution fonctionnait auparavant sur un ancien serveur dédié, tandis que le nouveau site basé sur CouchDB ne fonctionnait que sur une instance partagée xen avec des ressources très limitées. Et je n'ai même pas utilisé la force des magasins de valeurs-clés pour évoluer horizontalement. La capacité de CouchDB/Erlang OTP de traiter des demandes simultanées sans rien verrouiller était déjà suffisante pour répondre aux besoins.
Le journal CouchDB-traceback, rapidement écrit, est toujours en cours d’exécution et constitue un moyen utile d’explorer les bogues sur le site Web principal. Quoi qu'il en soit, environ une fois par mois, la base de données devient trop grosse et le processus CouchDB est tué. Mais ensuite, la commande compact-db de CouchDB réduit la taille de plusieurs Go à quelques Ko et la base de données est à nouveau opérationnelle (peut-être devrais-je envisager d’ajouter un cronjob ici ... 0o).
En résumé, CouchDB était sûrement le meilleur choix (ou du moins un meilleur choix que MySQL) pour ce sous-projet et il fait bien son travail.
Mon projet actuel en fait.
Stockage de 18 000 objets dans une structure normalisée: 90 000 lignes réparties sur 8 tables différentes. Il a fallu 1 minute pour les récupérer et les mapper sur notre modèle d'objet Java, c'est-à-dire que tout est correctement indexé, etc.
Les stocker sous forme de paires clé/valeur en utilisant une représentation textuelle légère: 1 table, 18 000 lignes, 3 secondes pour toutes les récupérer et reconstruire les objets Java.
En termes commerciaux: la première option n’était pas réalisable. La deuxième option signifie que notre application fonctionne.
Détails de la technologie: fonctionnant sur MySQL pour SQL et NoSQL! Rester avec MySQL pour un bon support des transactions, des performances et des antécédents prouvés pour ne pas corrompre les données, évoluer assez bien, supporter le clustering etc.
Notre modèle de données dans MySQL est maintenant constitué de champs clés (nombres entiers) et du grand champ "valeur": en gros, un champ TEXT.
Nous ne sommes allés avec aucun des nouveaux joueurs (CouchDB, Cassandra, MongoDB, etc.) car, bien qu’ils offrent chacun des fonctionnalités/performances exceptionnelles, il existait toujours des inconvénients pour notre situation (support Java manquant/immature, par exemple).
Avantage supplémentaire de (ab) utilisation de MySQL - les éléments de notre modèle que do travaillent en relation peuvent être facilement liés à nos données de magasin clé/valeur.
Mise à jour: voici un exemple de la manière dont nous avons représenté le contenu textuel, et non notre domaine commercial actuel (nous ne travaillons pas avec des "produits") car mon patron m'avait tiré dessus, mais transmet l'idée, y compris l'aspect récursif (une entité, ici un produit, "contenant" d'autres). Espérons qu'il soit clair que dans une structure normalisée, il pourrait s'agir de plusieurs tables, par exemple. joignant un produit à sa gamme de saveurs, quels autres produits sont contenus, etc.
Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={Nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]
Todd Hoff highscalability.com a une excellente couverture de NoSQL, y compris des études de cas.
Le SGBD commercial Vertica columnar peut convenir à vos besoins (même s’il prend en charge SQL): il est très rapide par rapport aux SGBD relationnels traditionnels pour les requêtes analytiques. Voir Stonebraker, et al./ article récent du CACM contrastant Vertica avec map-réduire.
Mise à jour: Et Cassandra sélectionnée par Twitter par rapport à plusieurs autres, dont HBase, Voldemort, MongoDB, MemcacheDB, Redis et HyperTable.
Mise à jour 2: Rick Cattell vient de publier une comparaison de plusieurs systèmes NoSQL dans Magasins de données à haute performance . Et le rapport de Rick sur highscalability.com est ici .
Nous avons déplacé une partie de nos données de mysql vers mongodb, non pas tant pour l'évolutivité que pour l'évolutivité, car elle convient mieux aux fichiers et aux données non tabulaires.
En production, nous stockons actuellement:
- 25 mille fichiers (60 Go)
- 130 millions d'autres "documents" (350 Go)
avec un chiffre d'affaires quotidien d'environ 10 Go.
La base de données est déployée dans une configuration "appariée" sur deux nœuds (6x450 Go sas raid10) avec des clients Apache/wsgi/python utilisant l’application mongodb python api (pymongo). La configuration du disque est probablement excessive, mais c’est ce que nous utilisons pour mysql.
Mis à part quelques problèmes avec les pools de threads pymongo et la nature bloquante du serveur mongodb, ce fut une bonne expérience.
Je m'excuse de m'être opposé à votre texte en caractères gras, car je n'ai aucune expérience pratique, mais cet ensemble d'articles de blog est un bon exemple de la résolution d'un problème avec CouchDB.
Pour l’essentiel, l’application textme a utilisé CouchDB pour traiter le problème de l’explosion de ses données. Ils ont constaté que SQL était trop lent pour traiter de grandes quantités de données archivistiques et les ont transférés vers CouchDB. C'est une excellente lecture, et il discute de tout le processus de détermination des problèmes que CouchDB pourrait résoudre et de la manière dont ils ont finalement été résolus.
Nous avons déplacé certaines de nos données que nous avions l'habitude de stocker dans Postgresql et Memcached dans Redis . Les magasins de valeurs de clés conviennent beaucoup mieux au stockage de données d'objets hiérarchiques. Vous pouvez stocker des données de blob beaucoup plus rapidement et avec beaucoup moins de temps et d’efforts de développement que d’utiliser un ORM pour mapper votre blob sur un SGBDR.
J'ai un client open source c # redis qui vous permet de stocker et de récupérer des objets POCO avec 1 ligne:
var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });
Les magasins de valeurs clés sont également beaucoup plus faciles à «déployer», car vous pouvez ajouter un nouveau serveur, puis partitionner votre charge de manière uniforme pour inclure le nouveau serveur. Il est important de noter qu’aucun serveur central ne limitera votre évolutivité. (bien que vous ayez toujours besoin d’une stratégie de hachage cohérente pour distribuer vos demandes).
Je considère Redis comme un "fichier texte géré" sur les stéroïdes, qui fournit un accès rapide, simultané et atomique à plusieurs clients. Par conséquent, tout ce que j’utilisais auparavant pour utiliser un fichier texte ou une base de données incorporée pour Redis est maintenant. par exemple. Pour obtenir un journal des erreurs de roulement combinées en temps réel pour tous nos services (ce qui a été notoirement une tâche difficile pour nous), il suffit maintenant de quelques lignes en pré-attendant l'erreur sur une liste côté serveur Redis, puis coupez la liste pour ne conserver que les 1000 derniers, par exemple:
var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);
Je n’ai pas d’expérience de première main, mais j’ai trouvé cette entrée de blog assez intéressante.
Je trouve que l'effort de mapper des objets de domaine logiciel (par exemple aSalesOrder, aCustomer ...) à une base de données relationnelle à deux dimensions (lignes et colonnes) nécessite beaucoup de code pour enregistrer/mettre à jour, puis à nouveau pour instancier une instance d'objet de domaine à partir de plusieurs tables . Sans parler de l'impact sur les performances d'avoir toutes ces jointures, toutes ces lectures de disque ... juste pour afficher/manipuler un objet de domaine tel qu'une commande client ou une fiche client.
Nous sommes passés à ODBMS (Object Database Management Systems). Ils vont au-delà des capacités des systèmes noSQL répertoriés. Le GemStone/S (pour Smalltalk) est un tel exemple. Il existe d'autres solutions ODBMS qui ont des pilotes pour de nombreuses langues. Un avantage clé pour les développeurs, votre hiérarchie de classes correspond automatiquement à votre schéma de base de données, à vos sous-classes et à tous. Utilisez simplement votre langage orienté objet pour rendre les objets persistants dans la base de données. Les systèmes ODBMS fournissent une intégrité de transaction de niveau ACID, de sorte que cela fonctionnerait également dans les systèmes financiers.
Je ne. J'aimerais utiliser un magasin simple et gratuit de valeurs-clés que je peux appeler en cours de traitement, mais une telle chose n'existe pas sur la plate-forme Windows. Maintenant, j'utilise Sqlite, mais j'aimerais utiliser quelque chose comme Cabinet Tokyo. BerkeleyDB a une licence "problèmes".
Toutefois, si vous souhaitez utiliser le système d'exploitation Windows, votre choix de bases de données NoSQL est limité. Et il n'y a pas toujours de fournisseur C #
J'ai essayé MongoDB et c'était 40 fois plus rapide que Sqlite, alors je devrais peut-être l'utiliser. Mais j'espère toujours une solution simple en processus.
J'ai utilisé redis pour stocker les messages de journalisation sur les ordinateurs. C'était très facile à mettre en œuvre et très utile. Redis vraiment des rochers
Nous avons remplacé une base de données postgres par une base de données de documents CouchDB car le fait de ne pas avoir de schéma fixe était un avantage important pour nous. Chaque document a un nombre variable d'index utilisés pour accéder à ce document.
Je suis passé de MySQL (InnoDB) à cassandra pour un système M2M, qui stocke essentiellement des séries temporelles de capteurs pour chaque périphérique. Chaque donnée est indexée par (device_id, date) et (device_id, type_of_sensor, date). La version de MySQL contenait 20 millions de lignes.
MySQL:
- Configuration dans la synchronisation maître-maître. Peu de problèmes sont apparus autour de perte de synchronisation. C'était stressant et cela pouvait prendre des heures, surtout au début.
- Le temps d’insertion n’était pas un problème mais les requêtes nécessitaient de plus en plus de mémoire à mesure que les données augmentaient. Le problème est que les index sont considérés dans leur ensemble. Dans mon cas, je n'utilisais que des parties très minces des index nécessaires au chargement en mémoire (seuls quelques pour cent des périphériques étaient fréquemment surveillés et les données les plus récentes étaient utilisées).
- C'était difficile à sauvegarder. Rsync n'est pas capable de faire des sauvegardes rapides sur de gros fichiers de table InnoDB.
- Il est rapidement devenu évident que il n'était pas possible de mettre à jour le schéma de tables lourdes}, car cela prenait beaucoup trop de temps (heures).
- L'importation de données a pris des heures} (même lorsque l'indexation a été effectuée à la fin). Le meilleur plan de sauvetage consistait à toujours conserver quelques copies de la base de données (fichier de données + journaux).
- Déplacement d'une société d'hébergement à une autre c'était vraiment un gros problème. La réplication devait être traitée avec beaucoup de soin.
Cassandra:
- Encore plus facile à installer que MySQL.
- Nécessite beaucoup de RAM. Une instance de 2 Go ne pouvait pas le faire fonctionner dans les premières versions, elle peut désormais fonctionner sur une instance de 1 Go mais ce n’est pas une idée (beaucoup trop de vidages de données). Donner 8 Go suffisait dans notre cas.
- Une fois que vous comprenez comment vous organisez vos données, le stockage est facile. Demander est un peu plus complexe. Mais une fois que vous avez compris, c'est vraiment rapide (vous ne pouvez pas vous tromper sauf si vous voulez vraiment).
- Si l'étape précédente a été bien faite, elle est et reste ultra-rapide.
- Il semble presque que les données sont organisées pour être sauvegardées. Chaque nouvelle donnée est ajoutée en tant que nouveau fichier. Personnellement, mais ce n’est pas une bonne chose, vider les données toutes les nuits et avant chaque arrêt (généralement pour une mise à niveau) afin que la restauration prenne moins de temps, car nous avons moins de journaux à lire. Cela ne crée pas beaucoup de fichiers car ils sont compactés.
- Importer des données est rapide comme l'enfer. Et plus vous avez d'hôtes plus vite. L'exportation et l'importation de gigaoctets de données n'est plus un problème.
- Ne pas avoir de schéma est une chose très intéressante car vous pouvez faire évoluer vos données pour répondre à vos besoins. Ce qui peut vouloir dire avoir différentes versions de vos données en même temps sur la même famille de colonnes.
- L'ajout d'un hôte était facile (mais pas rapide) mais je ne l'ai pas fait sur une configuration multi-centre de données.
Note: J'ai aussi utilisé elasticsearch (orienté document basé sur lucene) et je pense que cela devrait être considéré comme une base de données NoSQL. Il est distribué, fiable et souvent rapide (certaines requêtes complexes peuvent donner de très mauvais résultats).
J'encourage tous ceux qui liront ceci à essayer Couchbase une fois de plus maintenant que la version 3.0 est en vente. Il y a plus de 200 nouvelles fonctionnalités pour les débutants. Les fonctions de performance, de disponibilité, d'évolutivité et de gestion simple de Couchbase Server en font une base de données extrêmement flexible et hautement disponible. L'interface utilisateur de gestion est intégrée et les API détectent automatiquement les nœuds de cluster, ce qui évite de recourir à un équilibreur de charge de l'application à la base de données. Bien que nous n’ayons pas de service géré pour le moment, vous pouvez utiliser Couchbase sur des éléments tels que AWS, RedHat Gears, Cloudera, Rackspace, Docker Containers comme CloudSoft, etc. En ce qui concerne le rééquilibrage, cela dépend de ce dont vous parlez, mais Couchbase ne rééquilibre pas automatiquement après une défaillance de nœud, mais un administrateur peut configurer le basculement automatique pour le premier nœud en panne et utiliser nos API pour accéder au réplica vbuckets à lire avant de les rendre actifs ou à l'aide de RestAPI, vous pouvez imposer un basculement via un outil de surveillance. C'est un cas particulier mais il est possible de le faire.
Nous avons tendance à ne rééquilibrer à peu près aucun mode sauf si le nœud est complètement déconnecté et ne revient jamais ou si un nouveau nœud est prêt à être équilibré automatiquement. Voici quelques guides pour aider les personnes intéressées à découvrir l’une des bases de données NoSQL les plus performantes.
Enfin, je vous encourage également à consulter N1QL pour les requêtes distribuées:
Merci d'avoir lu et laissez moi ou d'autres savoir si vous avez besoin de plus d'aide!
Austin
J'ai utilisé Couchbase dans le passé et nous avons rencontré des problèmes de rééquilibrage et d'autres problèmes. Actuellement, j'utilise Redis dans plusieurs projets de production. J'utilise redislabs.com , un service géré pour Redis qui prend en charge la mise à l'échelle de vos clusters Redis. J'ai publié une vidéo sur la persistance des objets sur mon blog à l'adresse http://thomasjaeger.wordpress.com qui montre comment utiliser Redis dans un modèle de fournisseur et comment stocker vos objets C # dans Redis. Regarde.
J'ai utilisé Vertica dans le passé. Il repose sur la compression en colonnes et accélère les lectures de disque et réduit les besoins en stockage pour tirer le meilleur parti de votre matériel. Des charges de données plus rapides et une concurrence accrue permettent de transmettre des données d'analyse à davantage d'utilisateurs avec un temps de latence minimal.
Plus tôt, nous interrogions une base de données Oracle contenant des milliards d’enregistrements et les performances étaient très sous-optimales. L'exécution des requêtes a pris 8 à 12 secondes, même après optimisation avec SSD. Nous avons donc ressenti le besoin d’utiliser une base de données orientée analytique optimisée pour la lecture. Avec les clusters Vertica derrière la couche de services lean, nous pourrions exécuter des API avec des performances inférieures à une seconde.
Vertica stocke les données dans des projections dans un format optimisant l'exécution des requêtes. Semblables aux vues matérialisées, les projections stockent les ensembles de résultats sur un disque SSD OR plutôt que de les calculer chaque fois qu'ils sont utilisés dans une requête. Les projets présentent les avantages suivants:
- Compressez et encodez les données pour réduire l'espace de stockage.
- Simplifiez la distribution sur le cluster de bases de données.
- Fournir une haute disponibilité et une récupération.
Vertica optimise la base de données en répartissant les données sur le cluster à l'aide de la segmentation.
- La segmentation place une partie des données sur un nœud.
- Il distribue les données de manière égale sur tous les nœuds. Ainsi, chaque nœud effectue une partie du processus d’interrogation
- La requête s'exécute sur le cluster et chaque nœud reçoit la requête Plan.
- Les résultats des requêtes sont agrégés et utilisés pour créer la sortie
Pour plus d'informations, consultez la documentation Vertica @ https://www.vertica.com/knowledgebase/