Gérer les gigaoctets de données

Question

Je vais commencer avec un nouveau projet. J'ai besoin de traiter des centaines de données dans une application .NET. Il est très tôt pour donner beaucoup de détails sur ce projet. Certains aperçu est suit:

1. Beaucoup d'écritures et beaucoup de lectures sur mêmes tables, très en temps réel
2. Mise à l'échelle est très important que le client insiste sur l'expansion des serveurs de bases de données très souvent, donc, les serveurs d'applications et
3. , prévoyant lots et beaucoup d'utilisation en termes de requêtes globales pourraient être mises en œuvre
4. Chaque ligne de données peut contenir des nombreux attributs pour traiter

Je suggère/ha Ving suivant comme solution:

1. utilisation distribuée tri de la table de hachage de persistance (pas S3, mais un inhouse un)
2. Utiliser Hadoop/Ruche aime (tout remplacement dans .NET?) pour tout processus d'analyse à travers les nœuds
3. GUI Impelement dans ASP.NET/Silverlight (avec beaucoup de ajaxification, où cela est nécessaire)

Qu'est-ce que vous en pensez? Ai-je un sens ici?

Answer 1

Vos objectifs sont-ils la performance, la maintenabilité, l'amélioration des chances de succès, l'avant-garde?

N'abandonnez pas les bases de données relationnelles trop tôt. Avec un disque dur externe de 100 $ et un générateur de données échantillon (RedGate's est bon), vous pouvez simuler ce type de charge de travail assez facilement.

Simuler cette charge de travail sur une base de données non relationnelle et en nuage et vous pourriez écrire vos propres outils.

Answer 2

« Anticiper, beaucoup, beaucoup d'utilisation en termes de requêtes globales pourraient être mises en œuvre »

C'est la marque d'un entrepôt de données.

Voici l'astuce avec le traitement DW.

1. Les données sont FLAT. Faits et dimensions Structure minimale, car elle est principalement chargée et non mise à jour. Pour effectuer l'agrégation, chaque requête doit être un SELECT SUM() or COUNT() FROM fact JOIN dimension GROUP BY dimension attribute simple. Si vous le faites correctement pour que chaque requête ait cette forme, les performances peuvent être très, très bonnes.

2. Les données peuvent être stockées dans des fichiers plats jusqu'à ce que vous vouliez agréger. Vous chargez ensuite les données que les utilisateurs ont réellement l'intention d'utiliser et créez un "datamart" à partir du jeu de données principal.

Rien est plus rapide que de simples fichiers plats. Vous n'avez pas besoin de complexité pour gérer des téraoctets de fichiers plats qui sont (au besoin) chargés dans des datamarts RDBMS pour l'agrégation et la création de rapports.

Les charges en vrac simples de tableaux de dimensions et de faits simples peuvent être TRES rapides en utilisant les outils du SGBDR.

Vous pouvez pré-assigner de manière triviale tous les PK et FK en utilisant le traitement de fichiers plats à ultra-haute vitesse. Cela rend les charges en vrac d'autant plus simples.

Obtenez les livres de Ralph Kimball Data Warehouse Toolkit.

Answer 3

"beaucoup de lectures et d'écritures sur les mêmes tables, très en temps réel" - L'intégrité est-elle importante? Certaines de ces écritures sont-elles transactionnelles? Si oui, respectez le SGBDR.

La mise à l'échelle peut être difficile, mais cela ne signifie pas que vous devez utiliser le cloud computing. La réplication dans le SGBD fera généralement l'affaire, avec les clusters d'applications Web, les équilibreurs de charge, etc.

Answer 4

Les bases de données modernes fonctionnent très bien avec des gigaoctets. C'est lorsque vous obtenez des téraoctets et pétaoctets que les RDBMS ont tendance à tomber en panne. Si vous prévoyez ce genre de charge, quelque chose comme HBase ou Cassandra peut être ce que le médecin a ordonné. Si ce n'est pas le cas, passez du temps de qualité à régler votre base de données, en insérant des couches de mise en cache (en mémoire), etc.

Answer 5

Donnez au SGBDR la responsabilité de conserver l'intégrité. Et traiter ce projet comme s'il s'agissait d'un entrepôt de données. Gardez tout propre, vous n'avez pas besoin d'utiliser beaucoup d'outils tiers: utilisez plutôt les outils RDBMS. Je veux dire, utiliser tous les outils que le SGBDR a, et écrire une interface graphique qui extrait toutes les données de la base de données en utilisant des procédures stockées bien écrites d'un modèle de données physique bien conçu (index, partitions, etc.).

Teradata peut gérer un grand nombre de données et est évolutif.