Hello I'm planning to write an OLAP server for PostgreSQL, in Lisp.
I did something similar before, a slow (in the cube generation part)
PHP MySQL version, but it still works for a client. (It only has to
generate aggregates every two months so speed is not an issue.)
I already have some lisp code, and CVS access in common-lisp.net. I
have a web site for the project too.
The intended license will be BSD. (Or MIT, if it's more lisp friendly).
Here I'm just soliciting help from anyone who likes to help this
project. If nobody likes to help right now it doesn't matter, however
even some discussion or rants about it would be useful (it's nice to
know if I'm doing something in a really wrong way).
Hello Nicolay,
<·········@gmail.com> wrote:
NGc> Hello I'm planning to write an OLAP server for PostgreSQL, in
NGc> Lisp.
Strange, but I've got a similar idea a couple of weeks ago.
NGc> I did something similar before, a slow (in the cube generation
NGc> part) PHP MySQL version, but it still works for a client. (It only
NGc> has to generate aggregates every two months so speed is not an
NGc> issue.)
NGc>
NGc> I already have some lisp code, and CVS access in common-lisp.net.
NGc> I have a web site for the project too.
I have not dealt with OLAP in its nutshell but I have been doing tons of
adhoc reporting. I realize that many of those reports should have been
grounded on a more general paradigm.
NGc> The intended license will be BSD. (Or MIT, if it's more lisp
NGc> friendly).
NGc>
NGc> Here I'm just soliciting help from anyone who likes to help this
NGc> project. If nobody likes to help right now it doesn't matter,
NGc> however even some discussion or rants about it would be useful
NGc> (it's nice to know if I'm doing something in a really wrong way).
It can pay not delineating yourself by PosterSQL but basing on a general
Lisp-to-DBMS library, e.g. CLSQL or YSQL (my personal choice - follow the
link below :-)). As both are CommonSQL-compatible, a large audience could
benefit from the project.
Please count me as a volunteer.
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru
The OLAP server is modelled after MS SQLServer Analysis Services.
So it will use a MOLAP data store, will respond queries in the MDX
language and will have a "pivot table" client for the end user. And a
friendly cube editor.
Hello Nicolay,
<·········@gmail.com> wrote:
NGc> The OLAP server is modelled after MS SQLServer Analysis Services.
Have you taken a look at other projects around? Open source http://mondrian.sourceforge.net/
could be interesting.
NGc> So it will use a MOLAP data store, will respond queries in the MDX
NGc> language and will have a "pivot table" client for the end user.
NGc> And a friendly cube editor.
All these is a usual bunch. It is quite ambitious to have them all keeping
in mind that you are just starting up :-) In my understanding, a client
could be rather different (sub)project.
NGc> I already have some lisp code, and CVS access in common-lisp.net.
NGc> I have a web site for the project too.
What do you mean mentioning CVS in common-list.net? What is the project
name? Have you got a mailing list there?
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru
> Have you taken a look at other projects around? Open source http://mondrian.sourceforge.net/ could be interesting.
Of course, yes, for several years by now. Mondrian is a ROLAP server
and AFAIR it does not store the aggregates but generates SQL
underneath. Wich is, apart from the caching that Java provides, as slow
as my homebrew PHP SQL generator.
A MOLAP approach should be several orders of magnitude faster for the
aggregates stored, having into account not all of them could be
reasonably stored unless the number of dimensions is small.
> All these is a usual bunch. It is quite ambitious to have them all keeping in mind that you are just starting up :-) In my understanding, a client could be rather different (sub)project.
Yes it is ambitious, but this is better than rewriting reddit to show
lisp power. I have several years procastinating the start of the
project, it was initially planed to be in C++. I found lisp more
powerful for this kind of software (and later adding decision trees and
rule generators) than C++. You are quite right about the subproject. It
is not a bad idea to make the server compatible with JPivot.
In fact, the OLAP server can be separated in subprojects too:
- A cube processor: reads data from SQL and generate the aggregates.
- A MDX parser: reads a MDX expression and converts it to a
s-expression.
- A MDX interpreter: uses the s-expression to build the
multidimensional representation of the data. It could be as simply as
running the s-expression from last step.
> What do you mean mentioning CVS in common-list.net? What is the project name? Have you got a mailing list there?
The project name in both sourceforge and common-lisp.net is
macondoolap. The project homepage will be somewhere in
www.macondobits.com. There is nothing in the CVS yet.
Yes I should start using the mailing list:
http://common-lisp.net/cgi-bin/mailman/listinfo/macondoolap-devel
Any confusion generated by this posts is solely my fault.
·········@gmail.com wrote:
>> Have you taken a look at other projects around? Open source
>> http://mondrian.sourceforge.net/ could be interesting.
>
> Of course, yes, for several years by now. Mondrian is a ROLAP server
> and AFAIR it does not store the aggregates but generates SQL
> underneath.
Mondrian can do aggregate tables, at least if you spell them out in
small words to it anyway, yeah, and you have to rebuild the aggregates
nightly or whatever:
http://mondrian.sourceforge.net/aggregate_tables.html
Hello Nicolay,
<·········@gmail.com> wrote:
NGc>> What do you mean mentioning CVS in common-list.net? What is the
NGc>> project name? Have you got a mailing list there?
NGc>
NGc> The project name in both sourceforge and common-lisp.net is
NGc> macondoolap. The project homepage will be somewhere in
NGc> www.macondobits.com. There is nothing in the CVS yet.
NGc>
NGc> Yes I should start using the mailing list:
NGc> http://common-lisp.net/cgi-bin/mailman/listinfo/macondoolap-devel
NGc>
NGc> Any confusion generated by this posts is solely my fault.
The name looks a bit long and does not sound as loud as the project
prospects. As 'cl-olap' has not been occupied yet, why not to use it to
better match the ambitions? Never mind :-)
--
Sincerely,
Dmitriy Ivanov
lisp.ystok.ru