Calculer Girl
  1. Calculer Girl
  3. meilleur db pour delphi et grandes bases de données
Intereting Posts
comment obtenir les fichiers de programme x86 env variable? Où sont les modules d’installation de Pip3? Différences de performances entre python from package et python compilées à partir des sources Erreur de téléchargement non identifiée sur Apache, serveur Plesk11 Ubuntu Comment supprimer des fichiers sous des sous-répertoires sans supprimer les sous-répertoires eux-mêmes dans Linux PHP htaccess Redirige l’URL avec la chaîne de requête de la majuscule à la minuscule De quelle manière, fork () système appelant le processus enfant? Pourquoi avons-nous besoin de bit COW, quand le bit de référence est suffisant? Comment conserver les variables d’environnement lors de l’utilisation de SUDO Apache Velocity $ vs $! {} Utilisez Tesseract 4 – Docker Container depuis uwsgi-nginx-flask-docker Désactiver show path avec htaccess Comment déployer une application golang avec Apache installé sur Ubuntu 16.04 sur digitalocean? Le HWND de CreateWindow / CreateDialog peut-il être GetMessage’d d’un autre thread? Comment configurer et utiliser Jpegtran avec Windows

meilleur db pour delphi et grandes bases de données

Utilisation de Delphi XE2: J’ai utilisé AbsoluteDB pendant des années avec un bon succès pour les petits besoins, mais il ne s’adapte pas bien aux grands jeux de données. J’ai besoin de recommandations pour un moteur de firebase database pour les conditions suivantes:

  • Grand dataset (plusieurs gigaoctets), peu de tables avec beaucoup de petits enregistrements. Ce sont des données historiques sur les équipements indussortingels; la plupart des tableaux ont de nouveaux enregistrements écrits une fois par minute avec un identifiant de l’appareil, la date, l’heure et le statut; quelques tables ont ces enregistrements avec un seul sharepoint données par enregistrement, trois autres ont 10 à 28 points de données par enregistrement en fonction du type de périphérique. L’une des tables à un seul sharepoint données ajoute des événements de manière asynchrone et peut comporter une douzaine ou plus d’entrées par minute. Tout cela doit être disponible pendant un an. Les données sont généralement accessibles par identifiant de périphérique (s) et fenêtre de date.

  • Multi-utilisateurs. Un service système extrait les données des périphériques, mais l’affichage des tendances est une application distincte et peut se trouver sur un ordinateur distinct.

  • Vite. Capable de tirer toute grappe de données de 48 heures au maximum une demi-douzaine de secondes.

  • Non incorporé

  • Fichier unique si possible. Critique que les sauvegardes et les restaurations peuvent être effectuées par programmation. La prise en charge de la réplication serait bien mais pas obligatoire.

  • Peut être intégré dans nos packages InstallAware existants, sans intervention de l’utilisateur dans le processus d’installation.

  • Critique: pas de licence par installation. Je suis d’accord avec l’achat de licences de développeur par siège, mais nous sums une société d’équipement indussortingel, pas une société de logiciels – nous ne sums pas en mesure de suivre ce genre de choses.

Merci d’avance!

    j’utiliserais

    • soit PostgreSQL (plus éprouvé que MySQL pour de telles données)
    • ou MongoDB

    Le critère principal est ce que vous feriez avec les données. Et vous n’en avez pas beaucoup parlé. Souhaitez-vous faire des requêtes individuelles par sharepoint données? Souhaitez-vous faire des agrégats (sum / moyenne …) sur les points de données par type? Si “Les données sont généralement accédées par ID (s) de périphérique et fenêtre de date”, alors je ne stockerais peut-être pas les données dans des lignes individuelles, une ligne par sharepoint données, mais rassemblerais des données dans des ” agrégats “. colonne “document”.

    Vous pouvez stocker ces agrégats en tant que BLOB, mais cela peut ne pas être efficace. PostgreSQL et MongoDB ont tous deux des fonctions et des objects puissants, y compris des index dans les documents.

    Ne partez pas de la firebase database, mais commencez par votre logique: quelles données collectez-vous? comment est-il acquis? comment est-il plus tard accessible? Concevez ensuite des objects de haut niveau et laissez votre firebase database stocker vos objects de manière efficace.

    Pensez également au modèle CQRS : il est recommandé de stocker vos données à plusieurs endroits, dans plusieurs dispositions, et de distinguer clairement les écritures (commandes) et les lectures (requêtes). Par exemple, vous pouvez envoyer tous les points de données individuels dans une firebase database, mais rassembler les informations, sous une forme prête à l’emploi, dans d’autres bases de données. N’hésitez pas à dupliquer les données! Ne vous fiez pas à une approche centrée sur une firebase database unique! Ceci est la solution IMHO pour les requêtes rapides – et ce que font toutes les entresockets BigData.

    Notre framework Open Source mORMot est idéal pour un tel processus. Je travaille actuellement sur un projet de collecte d’informations en temps réel à partir de milliers d’appareils distants connectés via Internet (panneaux d’alarme, en fait), puis consolidation de ces données dans une batterie de serveurs. Nous utilisons SQLite3 pour le stockage local sur chaque nœud (jusqu’à quelques Go) et consolidons les données sur les serveurs MongoDB . Toute la logique est écrite dans des objects Delphi de haut niveau, et la structure fait tout le nécessaire en matière de plomberie (y compris la réplication en temps réel et les rappels).