J'ai un couple de DBS SQLite (je dirais environ 15 Go), avec environ 1 million de rangées au total - donc pas super grand. Je cherchais mongodb et il semblait assez facile de travailler avec, surtout si je veux essayer de faire un traitement de langue naturel de base sur les documents qui composent les bases de données.
Je n'ai jamais travaillé avec Mongo dans le passé, rien n'aurait à apprendre de zéro (travaillera dans Python). Après un peu de googler un peu, je suis tombé sur plusieurs histoires quelque peu horribles sur Mongodb Re. fiabilité. Est-ce encore un problème majeur? Dans une crunch, je vais bien sûr conserver les sauvegardes SQLite, mais je préfère ne pas avoir à reconstruire mes bases de données Mongo constamment.
Je me demande simplement quelles données de données de tri la corruption Les gens ont effectivement été confrontés récemment avec Mongo? Est-ce une grosse préoccupation?
merci!
5 Réponses :
Mongo n'a pas de propriétés acides, spécifiquement durabilité. Vous pouvez donc faire face à des problèmes si le processus ne s'éteint pas proprement ou la machine perd la puissance. Vous êtes censé implémenter des sauvegardes et une redondance pour gérer cela.
"MongoDB prend en charge une architecture au gaz automatisée permettant une échelle horizontale sur plusieurs nœuds." - Source Vous devez donc exécuter de multiples nœuds pour l'équilibrage et le support de basculement. Si vous souhaitez exécuter une seule instance qui n'échouera pas si le courant est soudainement perdu, vous avez besoin de quelque chose qui prend en charge Acide comme Couchdb. Cela étant dit que j'utilise Mongo au travail pendant un mois et que cela ne s'est pas écrasé sur moi, mais nous passons bientôt à un groupe de 6 noeuds bientôt.
durabilité Les produits prennent différentes approches à la durabilité. Couchdb est un "Crash-Seulement" design où la DB peut terminer à tout moment et rester cohérent. Mongodb prend un différent approche de la durabilité. Sur une machine crash, un puis dirigerait un réparationDatabase () opération lorsque démarrer à nouveau (semblable à myisam). MongoDB recommande d'utiliser la réplication - LAN ou WAN - pour une vraie durabilité en tant que serveur donné pourrait être définitivement mort. Résumer: Couchdb est meilleur à la durabilité lorsque en utilisant un seul serveur sans Réplication.
Devis de Mongodb.org Site officiel de '
Oui, la durabilité est un gros problème à Mongo. Vous devez utiliser des ensembles de réplication dans MongoDB pour une durabilité (vous avez besoin d'au moins 2 machines), sinon vous pouvez perdre jusqu'à 1 minute sur une puissance d'échec de l'énergie par exemple. Il n'y a pas de durabilité du serveur unique à Mongo, mais cela sera développé pour 1,7-1,8 comme je le sais. Après un crash, vous devez réparer DB manuellement et l'opération de rapaprise peut avoir pris des heures si vos données sont grandes. Il n'y a pas de transaction ni d'acide, de sorte qu'il ne convient pas à une application de commerce électronique ou de banque.
Vous ne devez pas utiliser les versions de développement de Mongo (numéro de VersionD impair comme 1.3.x, 1.5.x, 1.7.x sont des versions de développement) et vous préférez utiliser des systèmes d'exploitation 64 bits. Si vous DIGG dans des articles de catastrophe sur le Web à propos de Mongo, la source du problème est ces deux deux dans la plupart des cas.
COUCHDB, Cassandra et PostgreSQL Tous ont une forte durabilité (FSYNC est de 10 millisecondes par défaut dans Cassandra et PostgreSQL), ils ont donc toutes une durabilité du serveur unique.
Si vous avez besoin d'une évolutivité facile, de la tolérance aux pannes et de l'équilibrage de la charge; Cassandra est le meilleur, mais avec des options de requête médiocres. Les nœuds défaillants peuvent disparaître et revenir après une période de temps, aucun problème, le système ne se répare pas.
edit: Mongo 1.8 est venu avec la journalisation (permet une durabilité) mais ce n'est pas le paramètre par défaut. Regardez également sur ce http://news.ycomminator.com/item?id=2684423
Cordialement,
Serdar IRMAK
Intéressant - 64 bits et les versions de développement semblent se rendre assez souvent dans les postes que j'ai examinés. Je pense que Mongo m'a rendu assez curieux pour que je vais l'essayer, mais assurez-vous d'avoir une option de sauvegarde DB compatible avec une acide.
Mongo est la solution NOSQL la plus populaire aujourd'hui (une des raisons est que c'est un marketing agile de 10gen). Si vous Digg dans leurs références de site, il est principalement utilisé pour des données de performance hautes de faible valeur telles que Analytics (par exemple: pour la déclaration, la journalisation des erreurs, les comptoirs, les compteurs internes, etc.). Il y a aussi des sites (pas tellement) l'utilisant pour toutes les données.
Il y a beaucoup de sites qui l'utilisent pour des données réelles ces jours-ci. Mongodb.org/display/docs/production+Deploiments a beaucoup de haut déploiements -Profiles; Quelques-uns des sites qui l'utilisent pour "Données réelles" incluent Sourceforge, Foursquare, Wordnik et Insider d'affaires.
@Chris: Foursquare utilise également PostgreSQL. Les propriétaires de l'initié de l'entreprise et 10gen sont AlleyCorp. Et Wordnik est un dictionnaire.
La version 1.8 de MongoDB comprend la journalisation qui permet une durabilité avec un seul noeud.
@ Buttons840: Oui, mais ce n'est pas le paramètre par défaut et il semble que certains problèmes d'évolutivité graves existent (1) schmichael.com/files/schmongodb/... (2) NosqLBenchmarking.com/wp-content/uploads/2011/05/fpest.pdf Je souhaite que cela puisse aller mieux
Hey @sirmak voudriez-vous mettre à jour cette réponse pour refléter 2013? J'aimerais entendre ce que vous avez à dire maintenant que MongoDB a eu des mises à jour.
Je ne vois pas le problème si vous avez les mêmes données également dans les sauvegardes SQLite. Vous pouvez toujours remplir vos bases de données Mongodb. Le remplissage ne prendra que quelques minutes.
+1. Et vous n'aurez pas à faire cela "constamment", mais seulement après une panne de puissance du serveur (ou quelque chose d'autre qui a provoqué l'accident de Mongod dans une minute après la dernière opération de mise à jour). Dans votre cas, vous n'avez pas de mises à jour, n'est-ce pas?
Comme d'autres les ont dit, MongoDB n'a pas de durabilité à un seul serveur en ce moment. Heureusement, il est morts facile pour configurer la réplication multi-nœuds. Vous pouvez même configurer une deuxième machine dans un autre centre de données et avoir des données répliquées automatiquement à Live!
Si une écriture doit réussir , vous pouvez causer que Mongo ne soit pas revenir d'une insertion / mise à jour tant que ces données n'ont pas été répliquées sur n esclaves. Cela garantit que vous avez au moins n copies des données. Les répliques de répliques vous permettent d'ajouter et de supprimer des nœuds de votre cluster à la volée sans aucun travail important; Il suffit d'ajouter un nouveau nœud et il synchra automatiquement une copie des données. Supprimer un nœud et les repères de grappes eux-mêmes. Il est très conçu d'être utilisé sur plusieurs machines, avec de multiples nœuds agissant en parallèle; Ceci est une configuration par défaut préférée, comparée à quelque chose comme MySQL, ce qui s'attend à une machine géante de faire son travail sur lequel vous pouvez ensuite faire une paire d'esclaves contre lorsque vous devez augmenter. C'est une approche différente du stockage et de la mise à l'échelle des données, mais une très confortable si vous prenez le temps de comprendre sa différence d'hypothèses et comment construire une architecture capitalise sur ses forces.
+1 pour la perspicacité détaillée - semble être un paradigme différent, très excitant!