according to what you write pentaho best fits your needs
On Tue, Aug 27, 2013 at 5:52 PM, Pavel Stehule <pavel.steh...@gmail.com>wrote: > > Dne 28. 8. 2013 0:05 "Jerry Sievers" <gsiever...@comcast.net> napsal(a): > > > > > Alban Hertroys <haram...@gmail.com> writes: > > > > > On Aug 27, 2013, at 19:07, Paul Jungwirth <p...@illuminatedcomputing.com> > wrote: > > > > > >> Hi Alban, > > >> > > >> I think Postgres works great for OLAP work > > > > > > What do you base that on? > > > I don't really doubt that the database layer is up to the task, I'm > much more worried about maintaining the model and the cube data and all > that typical OLAP stuff that I've mostly just heard about. > > > > > >> , and Amazon's Red Shift is > > >> even based on Postgres. 100 million sales should be not problem at > > >> all. My understanding is Greenplum also builds on top of Postgres, so > > >> if you ever do outgrow your Postgres installation, that would be an > > >> easy migration path. > > > > > > What's the benefit of GreenPlum for OLAP? Isn't it a columnar > database? And a pretty old fork of Postgres at that? > > > GreenPlum has a pretty steep price-tag too. > > > > Vertica is another case of an analytics focused platform that dirived > > from Postgres, version 8.0 IIR > > vertica use a similar interface, but internally use nothing from pg. it > was written from zero. > > > It was, by the time I first looked at it back about 4 years ago, only > > superficially resembling Postgres. Performance was absolutely > > shocking in terms of how quickly it processed queries over certain > > kinds of data... and for which the set of expected queries to be run > > over same was identifiable in advance. > > > > Sample queries are given to a moddeler which in turn creates a set of > > "projections" which are physical manifestations of the backend storage > > intended to optimize for this specialized workload. > > > > Vertica and I presume Green Plumb are *not* well suited for an OLTP > > role so it takes a fair amount of learning to make good use of them. > > > > Just FWIW. > > > > > I didn't really look into Red Shift, perhaps I should… > > > > > > Anyway, I'm not at all sure I want to use some product that's heavily > modified from Postgres. If it is, it has to be really really good. > > > > > >> One Postgres OLAP tool to consider is Pentaho. > > >> That will save you lots of time around ETL, ad-hoc reporting, and > > >> other standard OLAP functionality. > > > > > > How is Pentaho an OLAP tool? Aren't you mixing up a few things? > > > We already use Pentaho for ETL, so I'm a bit familiar with it. Why do > you consider it suitable for managing an OLAP database? > > > > > > How would Pentaho manage cube rollup triggers, business models, > dimensions and stuff like that? > > > We don't want to hand code those, that's far too error-prone and far > too much work to keep track of. That stuff needs to be automated, > preferably similar to what we're used to from Gentia (well, not me - I > can't make heads or tails of Gentia, but the person who asked me about PG's > suitability has been developing with it for years). That's what we're > comparing to. > > > > > > Unfortunately, I can't find any decent information about Gentia for > reference. Apparently these days they're all about NoSQL databases and > such. That's not what we have - I guess the clunky GUI is a hint that it's > something of the past... > > > > > > > > > BTW, please don't top-post. > > > > > > > > >> On Tue, Aug 27, 2013 at 8:12 AM, Alban Hertroys <haram...@gmail.com> > wrote: > > >>> Hi all, > > >>> > > >>> At work we have a system that's built on top of a proprietary OLAP > database > > >>> system (Rocket Gentia). We're looking into replacing that system with > > >>> something that's still supported and in such a way that we can also > access > > >>> the data from our reporting software (WebFOCUS by information > builders). > > >>> > > >>> Because I'm always advocating PG, I was asked whether PG would be > suitable > > >>> for this, but I'm not really familiar enough with OLAP databases to > be able > > >>> to comment on that. > > >>> > > >>> I got three prerequisites for a solution, namely: > > >>> 1. It must contain correct information, > > >>> 2. It must be fast and > > >>> 3. It must be easy to maintain the data and the models; that's a > task for a > > >>> 3rd party back-end application, but it would be helpful to be able > to name > > >>> something to the higher-ups. > > >>> > > >>> Next to that, because we're also going to access the system using our > > >>> reporting software (which is read-only access), it would be best if > the > > >>> entire data model and all the business rules are stored inside the > database > > >>> so that we're looking at the data in the same way that the > "back-end" sees > > >>> it. > > >>> > > >>> For size, we're looking at about 20 years of sales and shipment data > all > > >>> over the world (although mostly in Europe) for about 5mln sold > products per > > >>> year. > > >>> > > >>> I suspect there might be some "middleware" that handles the models > and > > >>> dimensions and stuff and manages triggers on relational tables in PG > or a > > >>> setup like that. > > >>> I've seen an old reference to "Cybertec OLAP", but they don't seem > to carry > > >>> a product like that if I watch their site. > > >>> > > >>> I'm looking for suggestions for something that would be able to do > this. > > >>> > > >>> Cheers, > > >>> Alban. > > >>> -- > > >>> If you can't see the forest for the trees, > > >>> Cut the trees and you'll see there is no forest. > > >> > > >> > > >> > > >> -- > > >> _________________________________ > > >> Pulchritudo splendor veritatis. > > > > > > Alban Hertroys > > > -- > > > If you can't see the forest for the trees, > > > cut the trees and you'll find there is no forest. > > > > > > > > > > > > -- > > > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > > > To make changes to your subscription: > > > http://www.postgresql.org/mailpref/pgsql-general > > > > > > > -- > > Jerry Sievers > > Postgres DBA/Development Consulting > > e: postgres.consult...@comcast.net > > p: 312.241.7800 > > > > > > -- > > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > > To make changes to your subscription: > > http://www.postgresql.org/mailpref/pgsql-general >
