Re: OLAP

according to what you write pentaho best fits your needs

On Tue, Aug 27, 2013 at 5:52 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>wrote:

>
> Dne 28. 8. 2013 0:05 "Jerry Sievers" <gsievers19(at)comcast(dot)net> napsal(a):
>
> >
> > Alban Hertroys <haramrae(at)gmail(dot)com> writes:
> >
> > > On Aug 27, 2013, at 19:07, Paul Jungwirth <pj(at)illuminatedcomputing(dot)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 <haramrae(at)gmail(dot)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(at)postgresql(dot)org)
> > > To make changes to your subscription:
> > > http://www.postgresql.org/mailpref/pgsql-general
> > >
> >
> > --
> > Jerry Sievers
> > Postgres DBA/Development Consulting
> > e: postgres(dot)consulting(at)comcast(dot)net
> > p: 312.241.7800
> >
> >
> > --
> > Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-general
>