Quels problèmes d'évolutivité avez-vous rencontrés lors de l'utilisation d'un magasin de données NoSQL? [fermé]

NoSQL fait référence aux magasins de données non relationnels qui rompent avec l'historique des bases de données relationnelles et des garanties ACID. Les magasins de données NoSQL open source populaires incluent:

• Cassandra (tabulaire, écrit en Java, utilisé par Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit et Twitter)
• CouchDB (document, écrit en Erlang, utilisé par la 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)
• Projet 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)
• Tokyo Cabinet / 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 les 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 passer à un magasin de données NoSQL?

Je recherche des expériences de première main, alors s'il vous plaît ne répondez pas à moins que vous ayez cela.

J'ai basculé un petit sous-projet de MySQL vers CouchDB, pour 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é Linux allemande). Le site est écrit en Python et nous avons ajouté un middleware WSGI qui a pu capturer toutes les exceptions et les envoyer à un autre petit site Web alimenté par MySQL. Ce petit site Web utilisait un hachage pour déterminer différents bogues et stockait également le nombre d'occurrences et la dernière occurrence.

Malheureusement, peu de temps après la publication, le site Web de traceback-logger ne répondait plus. Nous avons eu des problèmes de verrouillage avec la base de données de production de notre site principal qui lançait des exceptions à presque toutes les requêtes, ainsi que plusieurs autres bogues, que nous n'avons pas explorés pendant la phase de test. Le cluster de serveurs de notre site principal, appelé la page d'envoi de traceback-logger plusieurs k fois par seconde. Et c'était beaucoup trop pour le petit serveur qui hébergeait le journal de trace (c'était déjà un ancien serveur, qui n'était utilisé qu'à des fins de développement).

À cette époque, CouchDB était plutôt populaire, et j'ai donc décidé de l'essayer et d'écrire un petit enregistreur de trace avec. Le nouvel enregistreur ne consistait qu'en un seul fichier python, qui fournissait une liste de bogues avec des options de tri et de filtrage et une page de soumission. 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 voir l'énorme quantité de rapports de bogues automatiques.

Une chose intéressante est que la solution avant, fonctionnait sur un ancien serveur dédié, où le nouveau site basé sur CouchDB, par contre, ne fonctionnait que sur une instance xen partagée 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 à gérer les demandes simultanées sans rien verrouiller était déjà suffisante pour répondre aux besoins.

Maintenant, 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 volumineuse et le processus CouchDB est tué. Mais alors, la commande compact-db de CouchDB réduit à nouveau la taille de plusieurs Go à quelques Ko et la base de données est à nouveau opérationnelle (peut-être que je devrais envisager d'ajouter un cronjob là-bas ... 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 sur 8 tables différentes. Il a fallu 1 minute pour les récupérer et les mapper à notre modèle d'objet Java, c'est avec tout correctement indexé, etc.

Les stocker sous forme de paires clé / valeur à l'aide d'une représentation textuelle légère: 1 table, 18 000 lignes, 3 secondes pour les récupérer toutes 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: fonctionne sur MySQL pour SQL et NoSQL! S'en tenir à MySQL pour une bonne prise en charge des transactions, des performances et des antécédents éprouvés pour ne pas corrompre les données, une mise à l'échelle assez bonne, la prise en charge du clustering, etc.

Notre modèle de données dans MySQL est maintenant juste des champs clés (entiers) et le grand champ «valeur»: juste un gros champ TEXTE en gros.

Nous n'avons choisi aucun des nouveaux lecteurs (CouchDB, Cassandra, MongoDB, etc.) car bien qu'ils offrent chacun d'excellentes fonctionnalités / performances à part entière, il y avait toujours des inconvénients pour notre situation (par exemple, support Java manquant / immature).

Avantage supplémentaire de (ab) en utilisant MySQL - les bits de notre modèle qui font le travail peut être facilement relationnellement liée à nos données de stockage de clés / valeur.

Mise à jour: voici un exemple de la façon dont nous avons représenté le contenu du texte, pas notre domaine d'activité réel (nous ne travaillons pas avec des "produits") pendant que mon patron me tirait dessus, mais transmet l'idée, y compris l'aspect récursif (une entité, ici un produit, "contenant" d'autres). Espérons qu'il est clair que dans une structure normalisée, cela pourrait être un certain nombre de tables, par exemple, joindre 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}
]

Le site highscalability.com de Todd Hoff a une grande couverture de NoSQL, y compris des études de cas.

Le SGBD commercial en colonnes Vertica peut convenir à vos objectifs (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 le récent article du CACM de Stonebraker et al. Opposant Vertica à map-Reduce.

Mise à jour: Et Twitter a sélectionné Cassandra parmi plusieurs autres, notamment HBase, Voldemort, MongoDB, MemcacheDB, Redis et HyperTable.

Mise à jour 2: Rick Cattell vient de publier une comparaison de plusieurs systèmes NoSQL dans des magasins de données hautes performances . Et le point de vue de highscalability.com sur l'article de Rick est ici .

Nous avons déplacé une partie de nos données de mysql vers mongodb, pas tant pour l'évolutivité mais plus parce que c'est un meilleur ajustement pour les fichiers et les 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 (6x450GB sas raid10) avec des clients apache / wsgi / python utilisant l'api mongodb python (pymongo). La configuration du disque est probablement exagérée, mais c'est ce que nous utilisons pour mysql.

Mis à part quelques problèmes avec les threadpools pymongo et la nature bloquante du serveur mongodb, cela a été une bonne expérience.

Je m'excuse d'aller à l'encontre de votre texte en gras, car je n'ai aucune expérience de première main, mais cet ensemble d'articles de blog est un bon exemple de résolution d'un problème avec CouchDB.

CouchDB: une étude de cas

Essentiellement, l' application textme a utilisé CouchDB pour gérer leur problème de données explosives. Ils ont trouvé que SQL était trop lent pour traiter de grandes quantités de données d'archives et l'ont transféré vers CouchDB. C'est une excellente lecture, et il discute de l'ensemble du processus pour déterminer quels problèmes CouchDB pourrait résoudre et comment ils ont fini par les résoudre.

Nous avons déplacé certaines de nos données que nous avions l'habitude de stocker dans Postgresql et Memcached vers Redis . Les magasins de valeurs clés sont bien mieux adaptés au stockage de données d'objets hiérarchiques. Vous pouvez stocker les données 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 à un SGBDR.

J'ai un client open source c # redis qui vous permet de stocker et de récupérer tous les 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 à «monter en puissance» car vous pouvez ajouter un nouveau serveur, puis partitionner votre charge de manière égale 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 requêtes).

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, donc tout ce que j'avais l'habitude d'utiliser un fichier texte ou une base de données intégrée pour j'utilise maintenant Redis. Par exemple, pour obtenir un journal d'erreurs glissantes combiné en temps réel pour tous nos services (ce qui a été notoirement une tâche difficile pour nous), est maintenant accompli avec seulement quelques lignes en pré-attendant simplement l'erreur sur une liste côté serveur Redis et puis découper 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 aucune 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 bidimensionnelle (lignes et colonnes) prend 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 un enregistrement client.

Nous sommes passés aux systèmes de gestion de base de données d'objets (ODBMS). Ils dépassent les capacités des systèmes noSQL répertoriés. Le GemStone / S (pour Smalltalk) en est un 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 est automatiquement votre schéma de base de données, vos sous-classes et tout. 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 qu'il fonctionnerait également dans les systèmes financiers.

Je suis passé de MySQL (InnoDB) à cassandra pour un système M2M, qui stocke essentiellement des séries chronologiques de capteurs pour chaque appareil. Chaque donnée est indexée par (device_id, date) et (device_id, type_of_sensor, date). La version MySQL contenait 20 millions de lignes.

MySQL:

• Configuration en synchronisation maître-maître. Peu de problèmes sont apparus autour de la perte de synchronisation . C'était stressant et surtout au début pouvait prendre des heures à réparer.
• 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 comme un tout. Dans mon cas, je n'utilisais que des parties très minces des index qui étaient nécessaires pour charger en mémoire (seuls quelques pour cent des appareils étaient fréquemment surveillés et c'était sur les données les plus récentes).
• 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 clair qu'il n'était pas possible de mettre à jour le schéma des tables lourdes , car cela prenait beaucoup trop de temps (heures).
• L'importation des données a pris des heures (même lorsque l'indexation a été faite à la fin). Le meilleur plan de sauvetage était de toujours conserver quelques copies de la base de données (fichier de données + journaux).
• Passer d'une société d'hébergement à une autre était vraiment un gros problème . La réplication a dû être manipulée très soigneusement.

Cassandra:

• Encore plus facile à installer que MySQL.
• Nécessite beaucoup de RAM. Une instance de 2 Go ne pouvait pas la faire fonctionner dans les premières versions, maintenant elle peut fonctionner sur une instance de 1 Go mais ce n'est pas une idée (beaucoup trop de vidages de données). Lui donner 8 Go était suffisant dans notre cas.
• Une fois que vous comprenez comment vous organisez vos données, le stockage est facile. La demande est un peu plus complexe. Mais une fois que vous l'avez contourné, c'est vraiment rapide (vous ne pouvez pas vraiment vous tromper sauf si vous le voulez vraiment).
• Si l'étape précédente a été bien exécutée, elle l'est et reste ultra-rapide.
• Il semble presque que les données soient organisées pour être sauvegardées. Toutes les nouvelles données sont ajoutées en tant que nouveaux fichiers. Personnellement, mais ce n'est pas une bonne chose, vider les données tous les soirs et avant chaque arrêt (généralement pour la 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 s'ils sont compactés.
• L'importation de données est rapide comme l'enfer. Et plus vous avez d'hôtes, plus vite. Exporter et importer des 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 suivre vos besoins. Cela peut signifier 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 (pas rapide cependant) mais je ne l'ai pas fait sur une configuration multi-datacenter.

Remarque: j'ai également utilisé elasticsearch (orienté document basé sur lucene) et je pense qu'il devrait être considéré comme une base de données NoSQL. Il est distribué, fiable et souvent rapide (certaines requêtes complexes peuvent très mal fonctionner).

Je ne. Je voudrais utiliser un magasin de valeurs-clés simple et gratuit que je peux appeler en cours, mais une telle chose n'existe pas sur la plate-forme Windows. J'utilise maintenant Sqlite mais j'aimerais utiliser quelque chose comme Tokyo Cabinet. BerkeleyDB a des "problèmes" de licence.

Cependant, 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 de processus simple.

J'ai utilisé redis pour stocker les messages de journalisation sur les machines. C'était très facile à mettre en œuvre et très utile. Redis vraiment rock

Nous avons remplacé une base de données postgres par une base de données de documents CouchDB car ne pas avoir de schéma fixe était un gros avantage pour nous. Chaque document a un nombre variable d'index utilisés pour accéder à ce document.

J'ai utilisé Couchbase dans le passé et nous avons rencontré des problèmes de rééquilibrage et une foule d'autres problèmes. Actuellement, j'utilise Redis dans plusieurs projets de production. J'utilise redislabs.com, un service géré pour Redis qui s'occupe de 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'encourage tous ceux qui liront ceci à essayer Couchbase une fois de plus maintenant que la version 3.0 est disponible. Il y a plus de 200 nouvelles fonctionnalités pour les débutants. Les performances, la disponibilité, l'évolutivité et les fonctionnalités de gestion faciles 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écouvrent automatiquement les nœuds du cluster, de sorte qu'il n'est pas nécessaire d'installer un équilibreur de charge entre l'application et la base de données. Bien que nous n'ayons pas de service géré pour le moment, vous pouvez exécuter couchbase sur des éléments tels que AWS, RedHat Gears, Cloudera, Rackspace, des conteneurs Docker comme CloudSoft, et bien plus encore. En ce qui concerne le rééquilibrage, cela dépend de ce à quoi vous faites spécifiquement référence, mais Couchbase ne rééquilibre pas automatiquement après une panne de nœud, comme prévu, mais un administrateur peut configurer le basculement automatique pour le premier échec de nœud et en utilisant nos API, vous pouvez également accéder aux répliques de vbuckets pour les lire avant de les rendre actifs ou en utilisant RestAPI, vous pouvez imposer un basculement par un outil de surveillance. C'est un cas particulier mais il est possible de le faire.

Nous avons tendance à ne pas rééquilibrer à peu près n'importe quel mode à moins que le nœud ne soit complètement hors ligne et ne revienne jamais ou qu'un nouveau nœud soit prêt à être équilibré automatiquement. Voici quelques guides pour aider tous ceux qui souhaitent découvrir en quoi consiste l'une des bases de données NoSQL les plus performantes.

1. Couchbase Server 3.0
2. Guide d'administration
3. API REST
4. Guides du développeur

Enfin, je vous encourage également à consulter N1QL pour les requêtes distribuées:

1. Tutoriel N1QL
2. Guide N1QL

Merci d'avoir lu et faites-moi savoir ou à d'autres si vous avez besoin de plus d'aide!

Austin

J'ai utilisé Vertica dans le passé.Il repose sur la compression en colonnes, accélère les lectures de disque et réduit les besoins de stockage pour tirer le meilleur parti de votre matériel. Des charges de données plus rapides et une plus grande simultanéité vous permettent de fournir des données analytiques à davantage d'utilisateurs avec une latence minimale.

Auparavant, nous interrogions la base de données Oracle contenant des milliards d'enregistrements et les performances étaient très sous-optimales. Les requêtes ont pris 8 à 12 secondes pour s'exécuter, même après optimisation avec SSD. Par conséquent, nous avons ressenti le besoin d'utiliser une base de données plus rapide, optimisée et orientée analytique. Avec Vertica Clusters derrière la couche de service allégée, nous pourrions exécuter des API avec des performances inférieures à la seconde.

Vertica stocke les données dans des projections dans un format qui optimise l'exécution des requêtes. À l'instar des vues matérialisées, les projections stockent les ensembles de résultats sur disque OU SSD plutôt que de les calculer à chaque fois qu'ils sont utilisés dans une requête.

1. Compressez et encodez les données pour réduire l'espace de stockage.
2. Simplifiez la distribution dans le cluster de bases de données.
3. Fournit une haute disponibilité et une récupération.

Vertica optimise la base de données en distribuant les données à travers le cluster à l'aide de la segmentation.

1. La segmentation place une partie des données sur un nœud.
2. Il distribue uniformément les données sur tous les nœuds. Ainsi, chaque nœud effectue une partie du processus d'interrogation.
3. La requête s'exécute sur le cluster et chaque nœud reçoit le plan de requête.
4. Les résultats des requêtes sont agrégés et utilisés pour créer la sortie.

Pour en savoir plus, veuillez consulter la documentation Vertica @ https://www.vertica.com/knowledgebase/