2011-02-09 6 views
2

Je suis curieux de savoir si quelqu'un a fait des tests d'accès aux données dans les bases de données NoSQL par rapport à Oracle (en particulier je parle d'Oracle RAC)? Le projet nécessite de travailler avec au moins 10mil + d'enregistrements, rechercher parmi eux (mais pas nécessairement en temps réel), le lire est très important pour la vitesse, et il est également très important de garantir HA et la fiabilité (peut ' Je peux voir par moi-même comment Cassandra/MongoDB pourrait être mieux adapté (parce que le stockage de valeur de clé fournira des lectures plus rapides que SQL quand vous dépasserez 10mil records), mais je trouve difficile de les articuler tous bien. Des liens? Suggestions? Bullet points? Merci!Oracle (RAC) vs NoSQL

+6

Mon ordinateur portable de 3 ans gère très bien 10 millions de lignes avec une installation standard d'Oracle XE. – Ronnis

+0

En 2012, 10m records n'est pas une grande quantité de données. Comme on le verra ci-dessous, 2,5 Go résideront très facilement dans la mémoire de n'importe quel système contemporain. –

Répondre

4

10 millions d'enregistrements. Supposons 250 octets par enregistrement. C'est environ 2,5 Go de données, ce qui est bien dans la capacité d'un PC de bureau/ordinateur portable de base. Les volumes de données sont insignifiants (sauf si chaque enregistrement est dimensionné en Mo, tel que l'image ou l'audio).

Ce dont vous avez besoin de parler, ce sont les volumes de transactions (séparés en lecture et écriture) et ce que vous considérez comme HA. Lecture seule HA est facile par rapport à "Lecture-écriture HA". Il peut être trivial de répliquer un ensemble de données en lecture seule sur plusieurs serveurs situés à différents emplacements géographiques et de leur distribuer une charge de travail de requête.

Il est beaucoup plus difficile de faire évoluer une lourde charge de travail de mise à jour, c'est pourquoi vous entendez souvent parler de systèmes en cours de fusion lorsque des tickets pour un grand concert sont publiés. Tout simplement, il y a un nombre fixe de sièges et vous ne pouvez pas avoir dix systèmes en double, chacun vendant ce qu'ils pense est disponible. Il doit y avoir une seule source de vérité, ce qui signifie un goulet d'étranglement (et potentiellement un seul point de défaillance). Sur l'aspect HA, RAC est une technologie de stockage partagée qui signifie généralement que vos nœuds RAC sont à proximité. Cela peut les rendre vulnérables à des événements localisés tels qu'un incendie de bâtiment ou une panne de télécommunication. Data Guard est la technologie Oracle associée à la réplication et au basculement hors site.

+2

10 millions de dossiers, mais ils s'attendaient à augmenter de 30 à 50% toutes les deux semaines. Je me demande à quel moment Oracle deviendra plus lent? J'essaie de trouver des repères si nous allons utiliser Oracle RAC comme stockage de valeur-clé par rapport à Cassandra/MongoDB/etc. Qui fournit une meilleure performance? Je suis plus intéressé par les lectures; – alexeypro

+0

Je suis également intéressé par les livres blancs sur ce sujet. Bien que mes exigences sont d'un ordre de grandeur supérieur. Le problème avec les entreprises éloignées d'Oracle réside dans le nom de marque "Oracle."Tous les exemples du monde réel seraient géniaux. –

0

Surtout quand vous venez à la comparaison de NoSQL vs SQL, vous devez comprendre une différence très importante entre eux. Données dans NoSQL peut être incohérent dans l'ordre de coût pour atteindre HA.

Qu'est-ce que je veux dire par incohérence? Cela dépend, mais généralement autour de 3-5 secondes pour propager les données autour des nœuds. La base de données NoSQL fournit un mécanisme pour gérer et éliminer cela, mais si vous voulez que toutes vos données soient cohérentes en temps réel, alors vous utilisez simplement du SQL classique, comme Oracle RAC. Pour en revenir à la comparaison de vitesse: il est simplement incomparable, plus rapide, car elle dépend de facteurs tels que l'infrastructure réseau, la puissance de calcul et le modèle de base de données, etc. Mais il est important de savoir que SQL est économiquement inefficace pour maintenir et vous devez passer à NoSQL.