Visualizzazione dei risultati da 1 a 5 su 5
  1. #1

    Quale database utilizzare per il data mining?

    Salve a tutti,

    Devo scaricare una gran quantita' di dati da un server e salvarli su disco in maniera opportuna per essere analizzati.


    Ho costruito un database di prova, con microsoft access,
    mi sono successivamente reso conto che ho una particolare tabella che dovrebbe andare a contenere qualche milione di righe... decisamente troppe per excel, considerando che poi dovro' processare questi dati per trovare un pattern e la velocita' delle query essenziale.

    purtroppo sono un po' a digiuno di DB e conosco solo le basi.

    volevo chiedere a chi e' piu' esperto di me, quale tipo di DB dovrei invece utilizzare al posto di access.

    Considerate che , la RAM del computer su cui andro' a processare i dati e' sicuramente sufficiente a contenere per intero il database (12GB) . MySQL permette di mantenere in memoria l'intero DB?

    E considerate poi che devo essere in grado di effettuare query potendo utilizzare ognuna delle colonne della tabella come chiave.

    potrebbe essere utile dividere la tabella piu' grossa in altre tabelle di piu' piccole dimensioni per aumentare le prestazioni?



    Grazie in anticipo.

  2. #2
    Ciao,

    Guarda un po questo documento, qui si parla di partizionamento.

    Adesso tutto dipende di quanti dati hai, come vengono salvati e che operazioni vuoi fare con loro, ma il mio consiglio e usare sia PostgreSQL, sia Oracle se vuoi ottenere performanza.

    Cristiana.

  3. #3
    Utente di HTML.it
    Registrato dal
    Oct 2014
    Messaggi
    539
    capisco poco di questi argomenti, ma credo che marca e modello siano l'ultimo dei pensieri (costi permettendo),
    mentre credo che ci si debba concentrare molto sull'organizzazione dei dati, sulla loro indicizzazione e sul modo con cui leggerli
    indicizzazione comunque legata alle ricerche che si vogliono fare,

    ti riporto il risultato dello stesso programma con un diverso modo di lettura del db a parità di indicizzazione

    tempo di preparazione : 48 sec
    tempo di ottimizzazione : 0 sec
    tempo di memor.risultato : 5 sec
    tempo totale di elab.ne : 53 sec
    FINE DEL PROGRAMMA

    tempo di preparazione : 14 sec
    tempo di ottimizzazione : 0 sec
    tempo di memor.risultato : 3 sec
    tempo totale di elab.ne : 17 sec
    FINE DEL PROGRAMMA

  4. #4
    Quote Originariamente inviata da marino51 Visualizza il messaggio
    capisco poco di questi argomenti, ma credo che marca e modello siano l'ultimo dei pensieri (costi permettendo),
    mentre credo che ci si debba concentrare molto sull'organizzazione dei dati, sulla loro indicizzazione e sul modo con cui leggerli
    indicizzazione comunque legata alle ricerche che si vogliono fare,

    ti riporto il risultato dello stesso programma con un diverso modo di lettura del db a parità di indicizzazione
    molto bene, studiero' bene prima di tutto come organizzare i dati correttamente,
    le guide presenti in questo sito sono sufficienti per arrivare allo scopo?

  5. #5
    Utente di HTML.it L'avatar di MySQL
    Registrato dal
    May 2015
    Messaggi
    729
    La velocità dipende essenzialmente dalla possibilità di usare indici, e dalla selettività degli stessi.
    Supponiamo di avere un milione di righe, delle quali metà marcate con F e metà con M.

    Se vuoi contare quante righe con F ci sono, il tempo che impiegherai non cambierà molto con la presenza di un indice,
    perchè l'indice avrà (circa) la stessa dimensione dei dati.

    Se invece ci sono 100 righe F, il conteggio sarà pressochè immediato, perchè le foglie dell'indice saranno pochissime

    Riguardo poi all'uso degli indici, devi sempre considerare dove sono buoni, e dove no.
    Sono veloci (sto parlando degli indici a foglie di albero, non di quelli hash) per ricerche del tipo =, oppure >= e <=.
    Non servono praticamente a nulla nel caso di ricerche del tipo LIKE %qualcosa%, che essenzialmente non utilizzano indici del tutto.

    Pertanto se devi cercare che so LIKE %rossi% allora cambia poco usare tecniche più o meno sofisticate o database più o meno veloci, la fullscan della tabella è inevitabile (nota: a dir la verità non lo è ma il discorso si complica assai)

    Quindi la primissima domanda è:
    ... devi fare ricerche su dati numerici, e di tipo =, >=, <= ?
    ... devi fare ricerche su dati alfanumerici, di tipo =, >=, <= ?
    ... devi fare ricerche full text (alla google per capirci) con un numero limitato di risultati (es. 1000) ?

    Nel caso 3 ti serve qualcosa che abbia un supporto speciale per questo tipo di ricerche; nel caso di mysql c'è un programma (in realtà ce ne sono tanti, i principali sono sphinx e lucene) che ti consente di fare ricerche molto veloci.
    Per "molto veloci" intendo qualche decina di millisecondo per ricerche su milioni di righe.

    Quindi DOPO aver stabilito esattamente QUALI interrogazioni su QUALI dati potrai iniziare a delineare un progetto sensato.

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.