Recommandation pour un système d'entreposage de données à grande échelle

Question

J'ai une grande quantité de données à stocker et à pouvoir générer des rapports, chacun représentant un événement sur un site Web (plus de 50 par seconde, il est donc clair que les données plus anciennes devront être agrégées. ).

J'évalue les méthodes de mise en œuvre. Évidemment, il faut que ce soit fiable et qu'il soit aussi facile à adapter que possible. Il devrait également être possible de générer des rapports à partir des données de manière flexible et efficace.

J'espère que certains propriétaires de réseau ont l'expérience de ce logiciel et qu'ils peuvent faire une recommandation et / ou signaler les pièges.

Idéalement, j'aimerais déployer ceci sur EC2.

Answer 1

Wow. Vous ouvrez un sujet énorme.

Quelques petites choses qui me viennent à l’esprit ...

1. Réfléchissez bien à votre schéma pour les insertions dans la partie transactionnelle et les lectures dans la partie rapport, il est peut-être préférable de les séparer si vous avez de très gros volumes de données
2. examinez attentivement le temps de latence que vous pouvez tolérer entre le reporting en temps réel de vos transactions et le reporting agrégé de vos données historiques. Peut-être devriez-vous avoir un processus qui s'exécute périodiquement et agrège vos transactions.
3. examinez attentivement toute exigence qui vous oblige à générer des rapports sur vos données transactionnelles et agrégées, dans le même rapport ou sous forme d'analyse détaillée de l'une à l'autre
4. prototype avec des requêtes significatives et des volumes de données réalistes
5. procurez-vous une véritable base de données d'entreprise prête à l'emploi, c.-à-d. Oracle / MSSQL
6. pensez à utiliser le code / produit de quelqu'un d'autre pour la création de rapports, par exemple Crystal / BO / Cognos

comme je le dis, sujet énorme. Comme je pense à plus je continuerai à ajouter à ma liste.

HTH et bonne chance

Answer 2

@ Simon a présenté d'excellents arguments, je vais en ajouter quelques-uns et en souligner / souligner quelques-uns autres:

1. Utilisez le bon type de données pour les horodatages - assurez-vous que le SGBD a la précision appropriée.
2. Envisagez de mettre en file d'attente pour la capture d'événements, permettant ainsi à plusieurs threads / processus de gérer le stockage réel des événements.
3. Séparez les schémas de votre entrepôt transactionnel et de votre entrepôt de données
4. Envisagez sérieusement une ETL périodique de la base de données transactionnelle vers l'entrepôt de données.
5. N'oubliez pas que vous n'allez probablement pas avoir 50 transactions / seconde 24x7x365 - transactions de pointe par rapport aux transactions moyennes
6. Recherchez les tables de partitionnement dans le SGBD. Oracle et MSSQL partitionneront tous deux une valeur (comme la date et l'heure).
7. Établissez une stratégie d'archivage / de conservation des données dès le départ. Trop de projets commencent simplement à enregistrer des données sans qu’il soit prévu de les supprimer / archiver.

Answer 3

Je ne suis surpris par aucune des réponses ici couvrent Hadoop et HDFS - je dirais que c'est parce que SO est un programmeur qa et que votre question est en fait une question de science des données.

Si vous êtes confronté à un grand nombre de requêtes et à un temps de traitement important, utilisez HDFS (format de stockage distribué sur EC) pour stocker vos données et exécuter des requêtes par lots (analyse, par exemple) sur du matériel standard.

Vous pouvez alors mettre en place autant d'instances EC2 que nécessaire (des centaines ou des milliers en fonction de la taille de vos exigences en matière de traitement des données) et exécuter map pour réduire les reins contre vos données afin de générer des rapports.

Answer 4

Wow .. C'est un sujet énorme.

Commençons par les bases de données. Commencez par obtenir quelque chose de bien si vous allez avoir des quantités folles de données. J'aime Oracle et Teradata.

Deuxièmement, il existe une différence définitive entre l’enregistrement de données transactionnelles et les rapports / analyses. Placez vos données transactionnelles dans un domaine, puis incorporez-les régulièrement dans un espace de rapport (schéma).

Je pense que vous pouvez aborder ces deux manières

• Jetez de l'argent sur le problème: achetez le meilleur logiciel possible (bases de données, logiciels de reporting) et embauchez quelques personnes astucieuses pour vous aider

• Adoptez l’approche locale: créez uniquement ce dont vous avez besoin pour le moment et développez-le de manière organique. Commencez avec une base de données simple et créez un cadre de reporting Web. Il existe de nombreux outils open source et des agences peu coûteuses qui effectuent ce travail.

En ce qui concerne l’approche EC2, je ne sais pas comment cela s’intégrerait à une stratégie de stockage de données. Le traitement est limité, là où EC2 est puissant. Votre objectif principal est un stockage et une récupération efficaces.