Pentaho sembra essere abbastanza solido, offrendo l'intera suite di strumenti di BI, con un'integrazione migliorata secondo quanto riferito sulla strada. Ma ... è probabile che le aziende che vogliono seguire il percorso open source per la loro soluzione di BI abbiano anche più probabilità di utilizzare la tecnologia di database open source ... e in che il "database agnostico" di può facilmente essere un doppio a due punte Ad esempio, è possibile sviluppare un cubo nei servizi di analisi di Microsoft nella comoda consapevolezza che tutto ciò che MDX/XMLA il cubo invia al database verrà interpretato in modo coerente, con pochissime sorprese.
Confrontalo con lo stack Pentaho, che in genere termina l'interazione con Postgresql o Mysql. Non posso garantire come Postgresql funzioni nel regno OLAP, ma so per esperienza che Mysql - per tutti i suoi indubbi punti di forza - ha "problemi" con i tipi di SQL che tipicamente spuntano dappertutto in una soluzione OLAP (non è possibile andare lontano in un cubo senza usare GROUP BY o COUNT DISTINCT). Quindi parte di ciò che risparmi nei costi di licenza sarà quasi certamente usato per risolvere i problemi derivanti dal fatto che il Pentaho non sempre sa a quale database si sta parlando - rubando a Peter (almeno in parte) pagare Paul, per così dire.
In realtà sembra che ci sia sempre più utenti Pentaho a partire da utilizzare (ad esempio Lucid) mysql vari open source colonna di db invece di e quindi è possibile ottenere prestazioni accecante dalle query di tipo OLAP. anche l'analisi fa fare un buon lavoro di caching - quindi, anche se le query sono lenti nel db sottostante, è solo un'una tantum colpito. Infine; Supporta le tabelle aggregate - ancora un altro modo per evitare quelle query lente - e il designer di aggregazione ordina tutto questo per te: è uno strumento molto utile. – Codek