Re: OLAP

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