Per prima cosa, non dare per scontato che un RDMS non abbia una scala. Potrebbe non essere la soluzione giusta, ma dire che non si ridimensionerà non ha senso se non hai considerato come i tuoi dati entreranno nel sistema, come verrà interrogato e cosa vorresti vedere da quelle domande.
La registrazione di hit di pagine non elaborate può essere o meno un set di dati di grandi dimensioni. Se lo fai in modo semplice e ingenuo, registrando una riga per ogni singolo hit, potrebbe non essere scalabile, ma questo non è necessariamente il modo più intelligente per registrare queste cose. Probabilmente lavorerai dai log del server, che poi li distilleremo in una forma aggregata.
Probabilmente il tracciamento dei percorsi è il set di dati più grande da quando avrai bisogno dei breadcrumb di ogni singolo utente, ma la parte di query è importante qui. Per fare ciò in modo sofisticato, probabilmente utilizzerai una certa logica applicativa, non una query non elaborata.
Se non si dispone di un numero elevato di utenti, un singolo RDMS dovrebbe essere in grado di gestire queste query. L'idea generale è di mantenere sia i dati aggregati che i dati grezzi a livello di grana fine in diverse tabelle. Gli aggregati forniscono query veloci con indici, ecc. E i dati a grana fine possono essere utilizzati per creare nuove metriche.
Alcuni database e alcune soluzioni di BI forniscono modalità automatizzate per farlo. Ad esempio, Oracle ha una persistenza aggregata, ma nel mio lavoro mi sono ritrovato a scrivere lavori batch per creare aggregati.
A lungo termine, ti consigliamo di imparare a modellare i tuoi dati in modo dimensionale piuttosto che relazionale. I modelli dimensionali e gli schemi a stella sono più estensibili di un modello relazionale che si replica da un sistema di produzione e forniscono un modo migliore per gestire la granularità dei dati e degli aggregati memorizzati nella cache.
Se hai veramente set di dati di grandi dimensioni, allora dovrai iniziare a pensare all'utilizzo dell'elaborazione distribuita, della mappatura / riduzione, ecc. Ma ti potrai risparmiare molto tempo se riuscirai a gestire utilizzare un database tradizionale in modo efficiente. L'esecuzione di analisi complesse (vale a dire, più che semplici aggregati come SUM o AVE) richiede molte più conoscenze e competenze nella mappa / riduzione del framework rispetto a SQL.