Burak,
When I said extremely large, I didn't mean at the very extreme of
extreme. I've created Oracle applications that had to deal with 10's of
millions of rows, but it only amounted to GBs of storage. Maybe I
should have used a less extreme word than extreme in my post, eh?
See other comments below...
On Mon, 2009-06-22 at 07:27 +0300, Burak Arslan wrote:
> Gene Amtower wrote:
> >>
> >> The real power of Oracle is that it handles extremely large datasets
> >> with ease and aplomb.
>
> oracle (or any off-the-shelf rdbms, for that matter) sucks big time at
> handling "extremely large datasets", because the fundamental ideas (the
> acid requirements) are inherently non-scalable. according to [1],
> turkcell is oracle's second biggest deployment world-wide, and it's just
> 50 terabytes [2]. the real power of oracle is its sales and support people.
>
> [3] is a read about the most famous "extremely large dataset". look at
> sep'07 figures from table 1 in the acm paper where google reports to
> have processed 400000 terabytes in a month.
I don't know how Google's complex set of servers compares to a single
application on one database, as I know they wield a lot of horsepower.
You did mention that Oracle deployed a 50TB database at turkcell -
imagine how well it would have run under MySQL. What I was referring to
in my post is that Oracle has done a great deal of work at optimizing
the performance of a typical Oracle database instance, and I've had
pretty good performance with application screen delivery to the client
browser when working with millions of rows of data. If someone knows
how to write appropriate queries with the necessary indexes in place,
Oracle is tops.
I'm not putting down any other databases (I do a fair amount of MySQL
work), but Oracle is a powerful force in the database world. I just
want to be able to harness that power with the elegance of a Qooxdoo
front-end.
> >> The PL/SQL code is actually compiled on first use, and all later
> >> calls to the compiled code packages runs it in native Oracle code, as
> >> compared to a raw interpreted language.
>
> there's no such thing as "native oracle code". pl/sql is yet another
> interpreted language.
I know that Oracle code goes through a compile process whenever the
database detects that the code text has changed, but they don't explain
the format of the compiled code. It might not be compiled down to
machine assembly code, but Oracle has a special compiled format that
runs faster than plain interpreted text. Whatever you call this, I
don't think it's completely interpreted at run-time. Maybe it's similar
to the optimizations that the Qooxdoo build system performs, but I'm not
making any claims about exactly what it does, as Oracle doesn't give us
any details.
For the record, I hereby coin the name YAIL for "yet another interpreted
language" in case I ever want to write a new programming language in the
future. ;-)
> >>
> >> For large-scale application development, the performance just can't
> >> be beat. But I really want to be able to leverage the Qooxdoo
> >> framework within my Oracle projects, which is the reason for my
> >> interest in an RPC server in Oracle.
> >>
>
> well, i had to roll my own solution, and it seems that you're going to
> have to do the same. i wish you luck with your endeavor.
Thanks for the encouragement - at least I hope you're not suggesting by
your comment that I should be discouraged.
>
> >
> > Oracle can support reading and writing of XML strings, so it would
> > conceivably be easy to add both xmlrpc and soap support at some later
> > point in time. I don't know how much demand there is for XML formats
> > over JSON within the current Qooxdoo community. I also think SOAP
> > might be too heavy for a standalone application. I think it's more
> > appropriate where several existing applications need to be able to
> > query each other to minimize re-development effort.
> >
> > I see that your SOAP contribution uses Python on the server. So does
> > it just add another layer into the request/response process that would
> > call Oracle via HTTP through mod_plsql or would it connect to the
> > Oracle database through an Oracle client driver within Python,
> > providing all of the RPC processing internally?
>
> i think the latter would be the optimal solution.
I agree with you in the context of a Python-based SOAP client; I just
wasn't sure which approach your solution took in order to manage
different transmission protocols. I haven't seen anything on a python-
based Oracle client, but maybe you know of something out there. I'm
also not experienced at all in Python development, using it solely for
the Qooxdoo tools at the present time.
>
> > Do you provide for more than HTTP transport protocols? That sounds
> > too complicated to me when I can include GET/POST support right in the
> > database itself, so it might be easier to try to write something in
> > Oracle to implement the SOAP protocols by reading and writing the XML
> > for the appropriate SOAP message formats. Again, I think it's more
> > than I need right now, but it might be something nice to leave on the
> > table for discussion.
> >
>
> why not use the oracle soa suite? see [4]. they have it all implemented
> and ready for use.
Thanks for the tip - I hadn't really looked at that yet.
>From what the Oracle docs say, I think this is a Java solution (it
includes JDeveloper, which is Java-focused). Oracle allows Java code to
be stored in the database much like PL/SQL modules, so I suspect the SOA
suite loads some additional Java-based modules into an existing database
environment that provide all of the SOAP functionality. I know much of
the recent work in Oracle has been focused on increasing the use of
Java, so this is no surprise to me. (This is part of the reason I'm
confused by concerns regarding Oracle buying Sun - Oracle LIKES Java.)
Of course, running Java modules in Oracle is fine, as any Oracle
installation requires an appropriate JRE to support many of the default
packages in the database. I don't know yet if this suite requires the
client generation to also be java-based, but I personally limit my Java
efforts for client browsers so that I don't force clients to install a
specific JRE to get apps to work.
That's one of the reasons I like Qooxdoo, as it supports a thin client
environment that doesn't require special runtime add-ons like a JRE.
Again, I appreciate the heads-up, but I'm still keen on creating a
JSONRPC to enable my use of Qooxdoo rather than using a SOAP solution at
this time. I was just hoping that someone else out there had already
been down that road - now it appears that I'm in uncharted waters!!!
Again thanks,
Gene
>
> best regards,
> burak
>
>
> [1]: http://www.turk.internet.com/haber/yazigoster.php3?yaziid=20029
> [2]:
> http://www.oracle.com/customers/snapshots/turkcell-telecommunications-services-snapshot.pdf
> [3]: http://www.niallkennedy.com/blog/2008/01/google-mapreduce-stats.html
> [4]: http://www.oracle.com/technologies/soa/index.html
------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
