NoSQL: Qu'est-ce que les données non structurées?

nous fonctionnons actuellement à la limite des ressources avec notre solution basée sur le serveur mssql.

Nous avons maintenant de nombreuses options traditionnelles concernant la prochaine étape pour faire face à la charge:

• acheter des processeurs et des E / S plus rapides
• diviser certains clients sur un serveur séparé
• déplacer la base de données vers le cluster

Tous sont coûteux en termes de licence et de matériel ou de temps. Donc, je veux ajouter une autre option en déplaçant l'ensemble du système vers une solution évolutive que promet la cassandra du moteur nosql.

Pourtant, je ne suis pas sûr et je n'ai pas d'expérience avec les bases de données noSQL, j'ai donc besoin de comprendre la structure des données "non structurées".

Dans notre application, nous stockons essentiellement les données saisies par les utilisateurs de différentes manières sous forme de listes de "valeurs-clés". Il y a une table parent, qui contient l'élément head (comme une commande) et il y a une table enfant avec les paires clé-valeur comprenant le contenu de la commande (comme Order_Lines).

Du point de vue commercial, Order et OrderLines sont une unité. Mais en raison du SGBDR, ils sont stockés dans des tables et doivent être joints en tout temps.

Pendant les opérations, nous choisissons parfois de ne charger que la partie supérieure, mais la plupart du temps, nous chargeons la ligne d'en-tête + quelques KVP pour afficher des informations utiles.

Par exemple, dans une liste de présentation, nous affichons l'identifiant de tête + quelques valeurs dans des colonnes pour chaque ligne.

MISE À JOUR: Nous stockons des formulaires de toute nature. Donc, fondamentalement, nous stockons des "documents". Néanmoins, nous devons préparer et rechercher dans ces formulaires par n'importe quelle valeur, tri, etc. Le contrôle d'accès aux données ajoute une autre couche de compexité sur la base de données.

Comme vous pouvez le deviner, la quantité et la disponibilité de certains KVP varient d'un objet à l'autre. Il n'y a pas de possibilité valide de créer des tables uniques pour chaque type d'objet, car il faudrait créer des milliers de tables pour les différentes combinaisons de données.

Serait-il préférable de stocker ce type de "dictionnaire" comme des ensembles de données dans une base de données noSQL? Et en tirerons-nous des avantages en termes de performances? Cassandra modéliserait-elle ces têtes + KVP comme un seul ensemble de données? En regardant la page Web de cassandra et certains tutoriels, j'ai l'impression qu'il n'y a pas tellement de différence entre notre SGBDR et cassandra en termes d'organisation des données - nous laissant avec la même énorme quantité de jointures si vous vouliez sélectionner 5 KVP pour une liste pour chaque ligne.

L'illumination est la bienvenue, aussi des pointeurs vers des articles expliquant les problèmes sont ok.

Il y a quelques concepts qui doivent être distingués. L'un concerne la structure et l'autre le schéma.

Les données structurées sont celles où l'application connaît à l'avance la signification de chaque octet qu'elle reçoit. Un bon exemple est les mesures d'un capteur. En revanche, un flux Twitter n'est pas structuré. Le schéma concerne la proportion de la structure qui est communiquée au SGBD et la manière dont il est demandé de l'appliquer. Il contrôle la quantité de données analysées par le SGBD. Un SGBD requis par le schéma, tel que SQL Server, peut stocker des données non analysées (varbinary) ou des données éventuellement analysées (xml) et des données entièrement analysées (colonnes).

Les SGBD NoSQL se situent sur un spectre allant de l'absence d'analyse (magasins de valeurs-clés) vers le haut. Cassandra offre une fonctionnalité extrêmement riche à cet égard. Là où ils diffèrent sensiblement des magasins relationnels, c'est dans l'uniformité des données. Une fois qu'une table est définie, seules les données correspondant à cette définition peuvent y être conservées. Dans Cassandra, cependant, même si les colonnes et les familles sont définies, il n'est pas nécessaire que deux lignes de la même table se ressemblent. Il appartient au concepteur de l'application de décider combien va sur une seule ligne (également appelé document) et ce qui est conservé séparément, lié par des pointeurs. En effet, combien de dénormalisation souhaitez-vous.

L'avantage est que vous pouvez récupérer un ensemble complet de données avec une seule lecture séquentielle. C'est rapide. Un inconvénient est que vous, le programmeur d'applications, êtes désormais seul responsable de tous les problèmes d'intégrité des données et de compatibilité descendante, pour toujours, pour chaque bit de code qui touche jamais ce magasin de données. Cela peut être difficile à réaliser correctement. De plus, vous êtes enfermé dans un point de vue sur les données. Si vous saisissez vos lignes par numéro de commande, comment déclarez-vous la vente d'un produit, d'une région ou d'un client particulier?

Malgré le courant dominant des bases de données noSQL à mon humble avis, la décision d'adopter une telle technologie devrait être prise en fonction des réalisations nécessaires en fonction des informations stockées, et pas seulement en fonction des performances que vous avez actuellement. Cela signifie que votre meilleure option est peut-être de vous en tenir à la base de données SQL et d'améliorer votre matériel informatique.

Mais en plus j'ai lu quelque chose dans votre question qui m'a fait réfléchir. Il n'y a pas grand-chose à propos de l'état actuel de votre base de données, mais votre phrase "nous stockons essentiellement les données entrées par les utilisateurs de différentes manières sous forme de listes" de valeurs-clés "" me fait penser si le problème ne serait pas un mauvais modèle de données plutôt que le manque de ressources physiques. J'ai géré de très grandes tables (+10 milliards de lignes) avec des performances incroyables dans des bases de données SQL "traditionnelles".

Je ne dis pas que c'est faux, juste, car bien sûr, je ne peux pas vous évaluer dans le bon modèle de données avec si peu d'informations sur votre solution actuelle, mais pensez simplement à revoir votre modèle de données comme une option supplémentaire avec le reste puisque vous peut y trouver des indices.

Habituellement, les listes de valeurs-clés conviennent comme compromis lorsque vous ne pouvez pas implémenter le modèle dans son état final parce que vous ne connaissez pas les différentes clés auxquelles vous devrez faire face, ou lorsque vous aurez besoin des valeurs de l'une des valeurs possibles clés pour un certain élément. Mais une fois mis en œuvre, j'aime généralement repenser ces décisions après un certain temps lorsque vous avez rassemblé suffisamment d'informations pour identifier le cas d'utilisation courant et décider si la décision du modèle de données est la meilleure. Si vous savez que vous aurez un certain nombre de clés, essayez de faire un benchmark avec la conception d'une table régulière de manière traditionnelle

CREATE TABLE benchmarkTable (
  element INTEGER,
  key1 VARCHAR(xx),
  key2 INTEGER,
  key3 DECIMAL(5,2),
...
);

... et en ajoutant les indices correspondants. Essayez-le et mesurez les plans d'exécution avec les deux approches. Vous pouvez être spécialement surpris si vous collectez plusieurs clés à la fois, car, entre autres avantages, la taille du bloc de données doit être réduite et donc les performances sont améliorées.

J'espère que cela aide, ou au moins élargit les possibilités et ouvre une nouvelle ligne d'enquête.