Je recherche des idées d'architecture sur un problème au travail que j'ai peut-être à résoudre.
Le problème.
1) Notre entreprise LDAP est devenue une "maîtrise de contact" remplie d'années de données rassis et d'attributs inutilisés et non utilisés.
2) La direction a décidé que LDAP ne servira plus de livre téléphonique de la société. C'est à des fins d'autorisation seulement.
3) La société dispose de données de type de contact sur les personnes dans des centaines de sources différentes. Nous devons nettoyer toutes les indicoles de la LDAP et donner aux autres applications un représentant central pour stocker toutes ces données sur une personne.
L'objectif idéal
1) avoir une source unique pour stocker tous les différents attributs sur une personne de
2) La société a probablement des informations sur 500k People (Lire 500k Rows)
3) J'estime qu'il pourrait y avoir 500 à 1000 attributs facultatifs sur ces personnes. (lire plus de 500 colonnes)
4) Les données seront principalement définies / obtiendraient via XML sur JMS (cette infrastructure est déjà en place)
5) Les groupes individuels au sein de l'entreprise pourraient "posséder" des colonnes. Seuls ils seraient autorisés à écrire sur leurs colonnes, ils seraient responsables de garder les données propres.
6) Une recherche d'enregistrement unique doit être retournée en sous-secondes
7) Le système devrait prendre en charge 1 million de demandes par heure au maximum.
8) L'objectif principal est de servir des données en temps réel à l'entreprise, le rapport est un objectif secondaire.
9) Nous sommes une boutique Java, Oracle, Terradata. Nous sommes votre gros magasin informatique typique.
Mes pensées:
1) À l'origine, je pensais que LDAP pourrait fonctionner, mais cela n'a pas été ajouté lorsque de nouvelles colonnes sont ajoutées.
2) Ma prochaine pensée était une sorte de solution no-SQL, mais d'après ce que j'ai lu, je ne pense pas que je ne puisse pas obtenir la performance dont j'ai besoin et que c'est encore relativement nouveau. Je ne suis pas sûr que je puisse obtenir mon manager de signer quelque chose comme ça pour un projet aussi critique.
3) Je pense qu'il y aura une composante méta-données à la solution qui doit suivre qui possède les colonnes et la représentation de chaque colonne et le système source d'origine.
Merci de la lecture et merci d'avance pour toutes les pensées.
3 Réponses :
Vous voudrez peut-être examiner le modèle de parti de Len Silverston. Voici un lien vers son livre: http://www.amazon .Com / Data-Model-Resource-Book-Vol / DP / 0471380237 .
Je n'ai aucune expérience construisant quelque chose à cette échelle, bien que je pense que penser à cela comme des rangées 500k x 500 - 1000 colonnes sonne un peu ridicule.
Merci pour la recommandation du livre, je vais vérifier ce soir. Pouvez-vous élaborer un peu sur vos lignes 500K par 500 colonnes commentaire? Si je comprends la portée de mes données à l'avance, pourquoi ne voudriez-je pas construire avec ces chiffres en tête?
500 colonnes impliquent une structure physique (une table) qui peut ne pas être une solution optimale à votre problème. De plus, lorsque vous avez que beaucoup de données facultatives, n'épuise pas les données «requises» deviennent une douleur?
Dans ma tête, je suppose que je vois la solution comme une grande table ratase. Chaque rangée aurait une UUID. si une colonne est requise ou non au propriétaire de la colonne et à tous les consommateurs de cette colonne. Idéalement, le système l'appliquerait à l'écriture de l'écriture.
Je le vois davantage comme un système de tables qui mettent fortement la mise en œuvre du modèle de héritage. Cela empêcherait également le schéma dur change la plupart des temps. J'ai trouvé que le livre de Silverson soit un véritable ouvre-yeux (lisez certains des commentaires sur Amazon).
Quelques pensées:
1) Notre entreprise LDAP est devenue une "maîtrise de contact" remplie d'années de données rassis et d'attributs inutilisés et non utilisés.
Ce n'est pas vraiment un problème technologique. Vous aurez également ce problème avec un nouveau système, LDAP ou non.
"LDAP ... n'éduit pas"
Il y a beaucoup d'énormes systèmes LDAP énormes . LDAP est sûrement un art sombre, mais je serais prêt à parier que cela échoue mieux que n'importe quel équivalent SQL dans cette situation. Sans parler que LDAP est une norme pour ce type d'informations et, en tant que tel, il est accessible à partir de zillions de différents types de systèmes.
Peut-être que ce que vous recherchez est un nouveau système LDAP qui est plus facile à gérer / a de meilleurs outils d'administration?
J'espère "résoudre" la question de données fade en donnant la propriété des colonnes aux groupes qui possèdent les données. Ils devraient s'authentifier avant de pouvoir écrire dans le magasin de données. Les données pourraient toujours devenir obsolètes, mais avec des métadonnées sur toutes les colonnes que nous savons qui possède les données et la dernière fois qu'il a été mis à jour.
En ce qui concerne la mise à l'échelle LDAP, je pense que j'étais un peu peu claire dans mon post original. Notre LDAP est extrêmement rapide et très bien pour récupérer un seul enregistrement étant donné une valeur clé. La partie sur LDAP qui ne fait pas échouer est le nombre d'attributs dont nous avons besoin. Pour ajouter un attribut dans LDAP nécessite un changement de schéma. Je voudrais une solution qui est un peu plus dynamique. Où nous pouvons créer des colonnes et des groupes de colonnes et d'attribuer la propriété des groupes de colonnes. Peut-être que la réponse est LDAP. J'espère juste trouver quelque chose d'un peu plus dynamique.
avec des outils de grade TERADATA Une solution à base de SQL peut être réalisable. Je suis tombé sur un Article sur la base de données Design il y a quelque temps qui a discuté " Modélisation d'ancrage ".
Fondamentalement, l'idée est de créer une table de clé primaire synthétique unique, muette et synthétique, tandis que toutes les données réelles ou métadonnées viennent dans d'autres tables (sous-ensembles) et sont attachées à titre d'une clé étrangère + Joindre.
Je vois que le bénéfice de cette conception soit deux fois. Premièrement, vous pouvez plus facilement compartimenter le stockage de données pour des raisons organisationnelles ou performantes. Deuxièmement, vous ne créez que des lignes supplémentaires pour des enregistrements que ont des données dans un sous-ensemble donné, de sorte que vous utilisez moins d'espace et d'indexation et de recherche sont plus rapides.
Les sous-ensembles peuvent être basés sur le mainteneur ou dans d'autres critères. XML Ensemble / Get serait per-sous-ensemble / enregistrement (plutôt que le disque mondial). Tous les sous-ensembles pour un enregistrement donné peuvent être composés et mis en cache. Des sous-sols supplémentaires peuvent être créés pour des métadonnées, des index de recherche, etc., et celles-ci peuvent être interrogées indépendamment.
NOSQL semble semblable au LDAP (en théorie, au moins) mais le bénéfice d'un bon outil NOSQL inclurait une plus grande abstraction des métadonnées, des versions et de l'organisation. En fait, de ce que j'ai lu, il semble que les données de données NOSQL soient conçues pour répondre à certaines des problèmes que vous avez soulevés en ce qui concerne la mise à l'échelle et les données de manière lâchée. Il y a une bonne question sur SO sur les données de données . < / p>
Hors de la main, il y a une poignée de grandes entreprises utilisant NOSQL dans des environnements réduits massivement mis à l'échelle, tels que Bigtable de Google . Il semble que l'outil parfait pour:
Bigtable est uniquement disponible (à mes connaissances) via appengine . D'autres technologies similaires sont des technologies similaires sont ICI ICI .
La vue d'image plus grande semble plus ou moins la même quelle que soit la technologie que vous décidez d'utiliser. Par exemple. Compôt sur le stockage, les vues composites, les vues de cache, Stick Metadata quelque part pour que vous puissiez trouver des choses.
Les caractéristiques de performance que vous ciblez deviennent besoin d'une sorte de mise en cache et / ou d'optimisation basée sur des modèles d'utilisation du monde réel. Quelle que soit la solution que vous choisissez, vous ne pouvez probablement pas résoudre que dans la phase de conception. NOSQL
Production NOSQL
6) Une recherche d'enregistrement unique doit être renvoyée en secondes
7) Le système devrait prendre en charge 1 million de demandes par heure au maximum.
Autres pensées
Wow, merci pour le lien sur la modélisation d'Anchor, je me sens comme si je vous dois des frais de consultation maintenant :) Big Table était ma pensée originale et cela m'a conduit à HBase et à Hypertable, avec une hypertable prenant une légère plomb. Je pense que je vais devoir prendre un pas en arrière et creuser dans ce nouveau sujet. Merci encore.
@bostonbob content de pouvoir partager de nouvelles idées. :) J'ai mis à jour pour inclure un lien concernant les datastores, cela peut être utile. Acclamations!
+1 problème très intéressant. Intrigué dans ce que vous venez avec.
Intéressant en effet. Cependant, en tant que question d'opérations, je m'attends à ce qu'il soit assez difficile de faire en sorte que les gens soient suffisamment prêts à garder cette quantité d'informations actuelle et exacte. (Maintenant, je dois aller essayer d'imaginer ce que 500+ données sur moi pourraient éventuellement intéresser quelqu'un d'autre;)
Deux questions: 1. Le système est-il lu lourd, écrit lourd ou mélangé? 2. Est-ce que vous accédez principalement à des enregistrements individuels ou à des gammes?
BanzaimonKey: Le système actuel voit environ 1 million de lectures par heure à son apogée et un faible pourcentage de ceux-ci sont écrits. Ce système offrirait une nouvelle façon de faire des choses ici, alors j'ai du mal à estimer la quantité d'écritures. Je pense que ce serait mieux si j'ai offert la possibilité d'autoriser des mises à jour en temps réel ainsi que des mises à jour par lots aux données. MSW: Je conviens qu'il est difficile d'amener les gens à se soucier de leurs données, c'est là que la composante Meta Data s'inscrit. I en tant qu'administrateur peut pointer le doigt sur le propriétaire de données. Tous les groupes de Col auraient quelque chose comme des horodatages «Dernière mise à jour».