Besoin d'aide ! Je ne peux pas résoudre le problème, je me heurte à des limitations matérielles. - page 4
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
J'y ai pensé. J'ai demandé un avis :
Quel serait le gain de vitesse par rapport à la lecture d'un fichier et quel serait le ralentissement par rapport au travail en mémoire ?
Le SGBD place ses tables en mémoire dans la mesure du possible.
mais pas dans votre cas, à moins bien sûr que vous ayez 32 GB de RAM
donc comment mettre 20GB dans 4GB est un vrai défi d'optimisation.
Si vous voulez vous simplifier la tâche, faites du disque RAM conventionnel en mémoire.
Si vous ne pouvez pas, optez pour un disque dur.
Combien plus rapide sera-t-il par rapport à la lecture d'un fichier et combien plus lent sera-t-il par rapport au travail en mémoire ?
Eh bien, vous n'avez pas seulement besoin de lire le fichier, vous devez également effectuer des recherches, des calculs, convertir du texte en chiffres, effectuer des tris, etc.
Tout d'abord, si les données ne sont pas mises à jour souvent, vous pouvez créer autant d'index que vous le souhaitez pour les attributs impliqués dans la recherche de données (y compris les attributs agrégés). Ainsi, la recherche sera plus rapide (en utilisant des index), donc le calcul aussi.
Deuxièmement, disons que MySQL, MS SQL, Oracle et d'autres bases de données utilisent la technologie de mise en cache des données pour les requêtes répétitives, ce qui donne également un certain avantage en termes de vitesse de traitement.
Troisièmement, vous pouvez diviser une table en parties (partitions), par exemple par années. Ainsi, les requêtes sélectionnant des données pour une année ne liront pas/rechercheront des données situées dans d'autres partitions.
Quatrièmement, comme vos données sources sont sous forme de texte, lorsque vous les chargez dans la base de données, elles devraient être plus petites en raison de la conversion naturelle des types. Par exemple, le nombre 124.223456221 sous forme de texte prendra 13 octets, dans la base de données selon le type 4-8 ; la date et l'heure "2014-08-17 10:23:35" prendra 19 octets, et dans la base de données 8 octets.
Cinquièmement, si vous utilisez fréquemment des informations agrégées pour certaines périodes, vous pouvez agréger ces données une fois et les stocker dans une autre table.
Bien sûr, s'il s'agit uniquement de lire des données en mémoire, WinApi le fera plus rapidement, mais que faire des données ensuite ? Imaginez, même pour rechercher la bonne partie des données, vous devez lire toutes les données du disque. Ou vous devez écrire la fonctionnalité d'indexation, trier les données dans le fichier, créer des fichiers d'index pour toutes les opérations de recherche et réécrire la moitié de la fonctionnalité du SGBD. Il est nécessaire de traiter une telle quantité de données et de vouloir des performances raisonnables.
Mon avis est sans ambiguïté - un SGBD serveur (les SGBD fichiers comme MS Access, SQLite ne fonctionneront pas ici) sur une machine dédiée. Il sera suffisamment performant et facile à traiter les données (requêtes SQL). Sinon, vous perdrez beaucoup de temps à écrire des "internes" de bas niveau pour traiter le fichier.
J'y ai pensé. J'ai demandé un avis :
Quel serait le gain de vitesse par rapport à la lecture d'un fichier et quel serait le ralentissement par rapport au travail en mémoire ?
(J'ai de l'expérience avec des bases de données de plus de 3TB et des bases de données relativement modestes de 10-100gigs).
mais avec certains matériels ... disons 64gb de RAM et plus avec un bon sous-système de disque.
Dans cette situation, par rapport au travail avec un fichier énorme
SQL accélérera considérablement, mais la vitesse dépendra bien sûr des implémentations de SQL.
- conception correcte de la base de données - index corrects - configuration correcte de la base de données
cela signifie le fractionnement des fichiers (la façon dont elugovoy écrit est vrai)
Une mise en œuvre complète nécessiterait un serveur distinct et un système d'exploitation serveur - base de données SQL
si MS SQL ne doit pas être inférieur à 2008 (sur le logiciel aussi, de préférence, pas inférieur à 64)
Mais à mon avis, il faudra beaucoup de travail et de matériel pour le mettre en œuvre... ( 64 bit est idéal)
--
Si vous n'avez que 16 gigas sur votre machine et qu'elle est utilisée comme une station
Il suffit de mettre un serveur SQL dessus, ce ne sera pas si génial, mais c'est mieux que de s'embêter avec un fichier texte.
Mais si vous n'avez pas d'expérience avec SQL, un certain effort sera nécessaire dans l'implémentation.
Et si ce fichier est compressé avec un archiveur, quelle sera sa taille (car le texte doit être très bien compressé) ?
Le temps qu'il faut pour décompresser chaque passage tue les performances.
le temps qu'il faut pour désarchiver chaque passe va tuer les performances
Je ne parle pas de désarchivage. Si l'archivage permet de réduire considérablement le volume, il est alors logique de comprimer les informations dans un fichier d'index.
était à l'origine
Et si ce fichier est compressé avec un archiveur, quel est le volume (après tout, le texte doit être très bien compressé) ?
d'où la réaction à votre post !
fichier d'index - créer... ? ! c'est un autre sujet
Il est encore plus cool d'écrire son propre serveur (de type SQL) - mais pourquoi ?
dès le début, c'était
d'où la réaction à votre post !
fichier d'index - pour créer... ? ! c'est un autre sujet
Il est encore plus cool d'écrire son propre serveur (comme SQL) - mais pourquoi ?
La question initiale posée à l'auteur était de savoir de combien le fichier est compressé. ....
Puis-je demander pourquoi ?
Il sera compressé de 70-80% et qu'est-ce que cela apportera à l'auteur pour résoudre le problème qu'il a décrit ?