The future of Java
Qu0ll
http://infoworld.com/d/developer-world/java-what-does-its-future-hold-978?page=0,0
--
And loving it,
-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>http://infoworld.com/d/developer-world/java-what-does-its-future-hold-978?page=0,0
Sun has been an unusually generous company. I have often puzzled why a
corporation would give away so much.
Oracle has a much more rapacious philosophy -- lock the customers in
then apply the screws upping annual fees.
There is bound to be some friction between these two philosophies.
I hope the deal falls through. Mergers are almost never good for
customers.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Finding a bug is a sign you were asleep a the switch when coding. Stop debugging, and go back over your code line by line.
Tom Anderson
> On Fri, 20 Nov 2009 23:34:11 +1100, "Qu0ll" <Qu0llS...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> http://infoworld.com/d/developer-world/java-what-does-its-future-hold-978?page=0,0
>
> Sun has been an unusually generous company. I have often puzzled why a
> corporation would give away so much.
>
> Oracle has a much more rapacious philosophy -- lock the customers in
> then apply the screws upping annual fees.
Although they're good to developers - developer licenses for their
products (the ones we use, which includes the big database, anyway) are
free. It's a sensible strategy: make it easy for developers to get
involved and build loads of stuff, then charge people who actually need to
use it.
This is exactly why Sun pushed java in the first place: they wanted
developers to write software in a language that would run on their
servers. Presumably, because they thought there was a threat that
Microsoft would get in with some proprietary language and lock them out,
or because they wanted to invade the space then held by IBM.
> There is bound to be some friction between these two philosophies.
Yes. Sun were happy to give away the software for the production side -
you could get a production-quality software stack from Sun for free,
including OS, JVM and app server. If Sunacle applied their model to java,
then we'd see a free JVM and app server suitable for development, but not
for deployment - for that, you'd have to pay. Perhaps we'll see Sunacle
switch resources away from OpenJDK, and start maintaining a for-pay branch
which gets all the new performance goodies. Or just refuse to support the
free JDK in production environments; often, that's enough to persuade a
corporate user to stump up for a paid version.
tom
--
If it ain't broke, open it up and see what makes it so bloody special.
Arne Vajhøj
> On Fri, 20 Nov 2009 23:34:11 +1100, "Qu0ll" <Qu0llS...@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> http://infoworld.com/d/developer-world/java-what-does-its-future-hold-978?page=0,0
>
> Sun has been an unusually generous company. I have often puzzled why a
> corporation would give away so much.
Mostly because they could not make money from it.
> Oracle has a much more rapacious philosophy -- lock the customers in
> then apply the screws upping annual fees.
Oracle has lots of free stuff as well.
Oracle makes money from highend software.
SUN makes money from hardware.
Neither gives away what they make money on.
> There is bound to be some friction between these two philosophies.
Not different philosophies just different business areas.
I will not rule out conflicts between SW and HW parts of the
new combined company though.
> I hope the deal falls through.
That would be extremely bad for Java.
SUN would be toast if the merger falls.
Their finances were not that good before (else they would
not have been put up for sale!) and now IBM and HP has lured
away a slice of customers.
Arne
Arne Vajhøj
> Interesting article on the future of Java:
>
> http://infoworld.com/d/developer-world/java-what-does-its-future-hold-978?page=0,0
I think it is more of a summary of what is known than actually
providing new angles.
Arne
Qu0ll
news:4b073951$0$277$1472...@news.sunsite.dk...
Perhaps, but I still found it interesting.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Their finances were not that good before (else they would
>not have been put up for sale!) and now IBM and HP has lured
>away a slice of customers.
Just a short while ago Sun was cash rich. Are you just assuming it was
put up for sale, or did you read somewhere they did that? I guess it
is not like putting it up on Craig's List. Possible buyers are well
aware of when Sun was financially vulnerable to takeover.
Years ago I read that computer companies often do well in recessions.
Companies try to save money by firing people and replacing them with
computers. I figured Sun should weather the recession.
On the other paw, I have read the Internet as a whole has had a
slowdown which would hurt Sun. They pretty well need constant
expansion to keep the server sales going.
Sun now sends me at least one email a day hoping to drum up sales.
That is much more aggressive than before.
Sun's behaviour over the years has been exemplary. They have been
honest with customers. They have not betrayed them the way
corporations often do. They have been generous. Their products are
good quality. I hope there is some way they can continue much as
before.
Even if they are swallowed in the blender, I would like to publicly
thank them their part in providing me Java, MySQL and Open Office.
Others would add to that list, particularly NetBeans.
Arne Vajhøj
> On Fri, 20 Nov 2009 19:48:47 -0500, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> Their finances were not that good before (else they would
>> not have been put up for sale!) and now IBM and HP has lured
>> away a slice of customers.
>
> Just a short while ago Sun was cash rich. Are you just assuming it was
> put up for sale, or did you read somewhere they did that? I guess it
> is not like putting it up on Craig's List. Possible buyers are well
> aware of when Sun was financially vulnerable to takeover.
SUN's had a loss of 2.2 billion dollar in FY 2009.
It is public that SUN negotiated with both IBM and Oracle. According
to gossip then HP were also approached.
> Years ago I read that computer companies often do well in recessions.
> Companies try to save money by firing people and replacing them with
> computers.
Sure. Those making money from cheap Linux and Windows system may do
fine.
But the market for high end systems and storage are not that well. And
IBM and HP seems to be doing better than SUN in that market.
> Sun's behaviour over the years has been exemplary. They have been
> honest with customers. They have not betrayed them the way
> corporations often do. They have been generous. Their products are
> good quality. I hope there is some way they can continue much as
> before.
There are still people that will never forgive SUN for the
SunOS 4->5 isuues.
> Even if they are swallowed in the blender, I would like to publicly
> thank them their part in providing me Java, MySQL and Open Office.
SUN did not provide you MySQL. SUN just acquired the company
not long ago. And have lost most of the original people since then.
Arne
Lew
>> Even if they are swallowed in the blender, I would like to publicly
>> thank them their part in providing me Java, MySQL and Open Office.
Arne Vajhøj wrote:
> SUN did not provide you MySQL. SUN just acquired the company
> not long ago. And have lost most of the original people since then.
Small loss.
I rate MySQL far, far below Postgres, Derby and the free versions of Oracle DB
and IBM DB2.
--
Lew
Martin Gregorie
>
> I rate MySQL far, far below Postgres, Derby and the free versions of
> Oracle DB and IBM DB2.
>
How do you rate H2 against Derby and HSQL? I see that it can use
PostgreSQL JDBJ drivers, so how close are the Postgres and H2 dialects of
SQL?
--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |
Arved Sandstrom
Server or Oracle XE for my local work on Windows/Linux/Mac OS X lets me
do everything I need to do to support my company's clients. In fact I
use SQL Server on the odd .NET project only to keep acquainted;
otherwise I'd pare my choices down to Postgres and Oracle XE. Nothing
against Derby - I just haven't had occasion to use it now for some years.
AHS
Stefan Lotties
> which gets all the new performance goodies. Or just refuse to support the
> free JDK in production environments; often, that's enough to persuade a
> corporate user to stump up for a paid version.
Oracle already got a for-pay JVM with lots of performance (and
management) goodies when they bought Bea. Well, at least I've heard
JRockit were *that* good, but I haven't tried out yet. Therefore it's
much more interesting what'll happen to both of the JVM's. Will they
be kept separate? Will Oracle try to combine them?
We'll see...
John B. Matthews
Martin Gregorie <mar...@address-in-sig.invalid> wrote:
> On Sat, 21 Nov 2009 13:08:32 -0500, Lew wrote:
>
> > I rate MySQL far, far below Postgres, Derby and the free versions
> > of Oracle DB and IBM DB2.
> >
> How do you rate H2 against Derby and HSQL? I see that it can use
> PostgreSQL JDBJ drivers, so how close are the Postgres and H2
> dialects of SQL?
In embedded mode, H2 starts up and runs queries more quickly than Derby;
I haven't used HSQLDB. My testing is limited, but I haven't found any
counter-examples to the author's claims:
<http://www.h2database.com/html/performance.html>
H2 client-server performance is good, and portability is no worse than
most. In a JDBC application developed with H2 and intended to be
portable, PostgreSQL proved to be easiest target, while MySQL was the
hardest; Oracle and Firebird were in between.
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Qu0ll
news:9CXNm.54457$PH1.35011@edtnps82...
The beauty of using Derby of course is that it just installs as part of your
application. No separate or specialised installers required.
Arved Sandstrom
> "Arved Sandstrom" <dce...@hotmail.com> wrote in message
> news:9CXNm.54457$PH1.35011@edtnps82...
>> Lew wrote:
>>> Roedy Green wrote:
>>>>> Even if they are swallowed in the blender, I would like to publicly
>>>>> thank them their part in providing me Java, MySQL and Open Office.
>>>
>>> Arne Vajhøj wrote:
>>>> SUN did not provide you MySQL. SUN just acquired the company
>>>> not long ago. And have lost most of the original people since then.
>>>
>>> Small loss.
>>>
>>> I rate MySQL far, far below Postgres, Derby and the free versions of
>>> Oracle DB and IBM DB2.
>>>
>> That's roughly my take on it as well. Choosing from PostgreSQL, SQL
>> Server or Oracle XE for my local work on Windows/Linux/Mac OS X lets
>> me do everything I need to do to support my company's clients. In fact
>> I use SQL Server on the odd .NET project only to keep acquainted;
>> otherwise I'd pare my choices down to Postgres and Oracle XE. Nothing
>> against Derby - I just haven't had occasion to use it now for some years.
>
> The beauty of using Derby of course is that it just installs as part of
> your application. No separate or specialised installers required.
>
lot, has embedded Derby by default.
AHS
Tom Anderson
> "Arved Sandstrom" <dce...@hotmail.com> wrote in message
> news:9CXNm.54457$PH1.35011@edtnps82...
>> Lew wrote:
>>> Roedy Green wrote:
>>>>> Even if they are swallowed in the blender, I would like to publicly
>>>>> thank them their part in providing me Java, MySQL and Open Office.
>>>
>>> Arne Vajh?j wrote:
>>>> SUN did not provide you MySQL. SUN just acquired the company
>>>> not long ago. And have lost most of the original people since then.
>>>
>>> Small loss.
>>>
>>> I rate MySQL far, far below Postgres, Derby and the free versions of
>>> Oracle DB and IBM DB2.
>>>
>> That's roughly my take on it as well. Choosing from PostgreSQL, SQL Server
>> or Oracle XE for my local work on Windows/Linux/Mac OS X lets me do
>> everything I need to do to support my company's clients. In fact I use SQL
>> Server on the odd .NET project only to keep acquainted; otherwise I'd pare
>> my choices down to Postgres and Oracle XE. Nothing against Derby - I just
>> haven't had occasion to use it now for some years.
>
> The beauty of using Derby of course is that it just installs as part of your
> application. No separate or specialised installers required.
This is also true of H2 and HSQL, no? You just add their JARs to your
application, and it gains the ability to make and use their databases
wherever it goes. Of course, with Derby you don't even need to add a JAR,
but that's such a trivial thing to do that it hardly seems like a
significant advantage.
tom
--
The revolving disc of plagues is particularly fun. -- greengolux
Qu0ll
news:alpine.DEB.1.10.0...@urchin.earth.li...
True, but I was comparing Derby to Postgres and Oracle XE as Arved had
indicated his choice was narrowed down to those two.
Arved Sandstrom
AHS
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>SUN did not provide you MySQL. SUN just acquired the company
>not long ago. And have lost most of the original people since then.
You can thank Oracle for continuing to provide Java free in the same
sense you can thank Sun for continuing to provide MySQL free.
Roedy Green
<mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :
>How do you rate H2 against Derby and HSQL?
For a comparison of PosGreSQL and MySQL see
http://mindprod.com/jgloss/postgresql.html
The information is a few years old.
I understand that Derby is fast, but ram resident only. It is for
small databases only.
Martin Gregorie
> On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
> <mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>How do you rate H2 against Derby and HSQL?
>
> For a comparison of PosGreSQL and MySQL see
> http://mindprod.com/jgloss/postgresql.html
>
> The information is a few years old.
>
> I understand that Derby is fast, but ram resident only. It is for small
> databases only.
>
I'm interested finding out if Derby, H2 or HSQL could be used as a
lighter weight, portable alternative to PostgreSQL, i.e. minimal changes
to SQL queries and schema, full ACID capability, capable of dealing with
fairly large tables on disk.
From what you say it looks like Derby wouldn't fit the bill.
Lew
>> How do you rate H2 against Derby and HSQL?
Roedy Green wrote:
> For a comparison of PosGreSQL [sic] and MySQL see
> http://mindprod.com/jgloss/postgresql.html
>
> The information is a few years old.
And mentions nothing about Derby or HSQL.
<http://troels.arvin.dk/db/rdbms/>
has a fairly comprehensive comparison of various RDBMSes, but also fails to
mention Derby and HSQL. It has a rather more comprehensive comparison between
PG and MySQL than the mindprod site.
I dispute mindprod's claims that MySQL is "easier to set up" than PG, and
while there may be more books and tutorials on MySQL than PostgreSQL, there is
plenty of information available about the latter so one will not feel the lack.
> I understand that Derby is fast, but ram [sic] resident only. It is for
> small databases only.
Derby is not RAM resident only.
<http://db.apache.org/derby/papers/pageformats.html>
"Derby stores table and index data in Containers, which currently map to files
in the seg0 directory of the database. In the current Derby implementation
there is a 1 to 1 mapping of containers to files."
<http://db.apache.org/derby/docs/10.5/devguide/>
"A Derby database is stored in files that live in a directory of the same name
as the database. "
As for the size of the database, that is shown in the Developer's Guide at the
above link also:
> rows in each table No limit.
> size of table No limit.
> Some operating systems impose a limit on the size of a single file.
> size of row No limit.
> Rows can span pages. Rows cannot span tables so some operating systems
> impose a limit on the size of a single file, which results in limiting the
> size of a table and size of a row in that table.
How well Derby performs at larger sizes is a whole 'nother question, natch.
The documentation has a lot of advice on how to tune Derby performance.
--
Lew
Lew
>> I understand that Derby is fast, but ram resident only. It is for small
>> databases only.
Martin Gregorie wrote:
> I'm interested finding out if Derby, H2 or HSQL could be used as a
> lighter weight, portable alternative to PostgreSQL, i.e. minimal changes
> to SQL queries and schema, full ACID capability, capable of dealing with
> fairly large tables on disk.
>
> From what you say it looks like Derby wouldn't fit the bill.
What he says is wrong.
Derby is highly SQL compliant, not RAM resident, and ACID compliant.
<http://db.apache.org/derby/docs/10.5/devguide/cdevconcepts15366.html>
Table size is limited only by the OS's file-size limit.
Check the facts.
--
Lew
Arne Vajhøj
> On Sat, 21 Nov 2009 12:10:06 -0500, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>> SUN did not provide you MySQL. SUN just acquired the company
>> not long ago. And have lost most of the original people since then.
>
> You can thank Oracle for continuing to provide Java free in the same
> sense you can thank Sun for continuing to provide MySQL free.
They are about equivalent in that.
Neither have much of a choice.
MySQL is GPL. Java specs are JCP and Java RI is GPL and
GPL with classpath exception.
Arne
Arne Vajhøj
> On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
> <mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
> someone who said :
>> How do you rate H2 against Derby and HSQL?
>
> For a comparison of PosGreSQL and MySQL see
> http://mindprod.com/jgloss/postgresql.html
>
> The information is a few years old.
#PostGres has many data types.
Most databases has.
#You can write triggers in Oracle stored procedure language PL/SQL or in
other languages such as Java.
http://www.postgresql.org/docs/8.2/interactive/triggers.html
does not list Java but several other languages.
And even though PL/pgSQL is very similar to Oracle PL/SQL, then
I assume that Oracle prefer it not to be called Oracle PL/SQL.
> I understand that Derby is fast, but ram resident only.
Not true.
> It is for
> small databases only.
Probably.
Arne
Arne Vajhøj
I forgot:
#PostGres does not crash under heavy loads.
No databases are supposed to do that.
Arne
Arne Vajhøj
They are relative similar in target usage.
I would go for Derby (Java DB), because:
- it comes with newer Java
- Informix/IBM/ASF some indicates a certain quality
Arne
Arne Vajhøj
We do know that there is a "cult" of people that believe that
PostgreSQL is "enterprise" and MySQL is "toy", but given that
MySQL dominates the highend over PostgreSQL the reality seems
to be the exact opposite.
Arne
Arne Vajhøj
> <http://troels.arvin.dk/db/rdbms/>
> has a fairly comprehensive comparison of various RDBMSes, but also fails
> to mention Derby and HSQL.
He compares all the big ones.
Derby and HSQL are not widely used in production and in reality
Java only.
Arne
Lew
>> http://www.postgresql.org/docs/8.2/interactive/triggers.html
For reference, Postgres 8.2 is an old version. The current version is 8.4.
Naturally that does not change your main point.
As for PG PL/pgSQL's similarity to Oracle PL/SQL, there is a chapter:
<http://www.postgresql.org/docs/8.4/interactive/plpgsql-porting.html>
that discusses that.
--
Lew
Lew
>> I rate MySQL far, far below Postgres, Derby and the free versions of
>> Oracle DB and IBM DB2.
Arne Vajhøj wrote:
> We do know that there is a "cult" of people that believe that
> PostgreSQL is "enterprise" and MySQL is "toy", but given that
> MySQL dominates the highend over PostgreSQL the reality seems
> to be the exact opposite.
My comments are based on my experience with the platforms, and that of
colleagues who've used them, and are my own personal assessment. YMMV.
What evidence do you have that MySQL "dominates" the high end over PG?
Performance charts that I've seen, hardly to be taken as gospel but perhaps
indicative, show PG maintaining faster performance over MySQL for larger
databases that need referential integrity and other features not available in
the MyISAM engine. Anecdotes told me by colleagues speak of data corruption
and other problems with MySQL that I have not heard about PG. Other anecdotes
from colleagues compare Postgres's performance favorably to Oracle DB in some
circumstances. I've not encountered anyone who's found MySQL superior to
Postgres in their actual work, but I have encountered the contrary.
The relational databases I've used professionally that have done well on the
high end have included Oracle DB, IBM DB2 and Red Brick. I use Postgres in my
personal development projects but that does not represent any sort of "high
end". MySQL has only annoyed me, even at the low end, to the point where I
simply will not consider it for anything serious.
My major complaint with MySQL is its weakness in the implementation of SQL.
It's so far out of standard as to make it a real PITA to use. I detest it.
Extrapolate as you will from this single data point.
--
Lew
Arved Sandstrom
I'm prepared to accept that all of the above is true, namely that there
does exist such a cult, and also that for some definition of the word
"dominate" that MySQL dominates the high-end over PostgreSQL.
In fact there's little argument that MySQL "dominates" PostgreSQL,
period, in the sense of downloads, installations and numbers of
supporters. In a similar fashion, all flavours of Internet Explorer
dominate all other web browsers, and Windows dominates Mac OS X and Linux.
In the technical sense of "dominate" I'm not prepared to accept that
MySQL dominates PostgreSQL. Not for a "high-end" situation. Of course
we'd need to sit down and first define what "high-end" actually means.
To me a high-end database concentrates on features like data integrity,
scalability, reliability, solid procedural language support,
constraints, serious transactional support etc etc, all of which are
things that PostgreSQL has been working on since the beginning, and all
of which are MySQL after-thoughts.
MySQL has storage engines out the ying-yang, and PostgreSQL has *one*.
This allows the Postgres developers to concentrate on quality, IMHO. And
by all accounts, the recent decrease in quality and reliability of MySQL
products is enough reason to stay away, even before comparing technical
features.
Ultimately it boils down to benchmarking your own application in
realistic field conditions. To me high-end also means that you've got a
person or people who qualify as DBAs - it's their #1 job to administer
the database of choice. I'll bet a lot of the benchmarks that highlight
MySQL over PostgreSQL are set up by folks who don't class as DBAs for
either, or just for MySQL. In any case I'm willing to bet that for a
"real" high-end app in realistic conditions that Postgres will win out.
AHS
David Segall
>On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
><mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
>someone who said :
>
>>How do you rate H2 against Derby and HSQL?
>
>For a comparison of PosGreSQL and MySQL see
>http://mindprod.com/jgloss/postgresql.html
>
>The information is a few years old.
And it ignores the gulf between the license conditions of the two
products. MySQL is GPL but the drivers are not LGPL so you can only
incorporate a MySQL driver into your application and distribute the
MySQL database if your software is open source. Even if you have some
weird objection to open source there is a genuinely, freely
distributable, version of all the commercial heavyweight databases
although they may restrict the number of processors, RAM or disk size.
Why risk contravening MySQL's deliberately confusing license
conditions?
I have a list of freely distributable, heavy duty databases at
<http://database.profectus.com.au>. The page also includes a list of
open source, relational databases that will run in the same JVM as
your application. The page is intended to be comprehensive so I would
appreciate it if you have any additions or corrections.
John B. Matthews
David Segall <da...@address.invalid> wrote:
> Roedy Green <see_w...@mindprod.com.invalid> wrote:
>
> >On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
> ><mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
> >someone who said :
> >
> >>How do you rate H2 against Derby and HSQL?
> >
> >For a comparison of PosGreSQL and MySQL see
> >http://mindprod.com/jgloss/postgresql.html
> >
> >The information is a few years old.
>
> And it ignores the gulf between the license conditions of the two
> products. MySQL is GPL but the drivers are not LGPL so you can only
> incorporate a MySQL driver into your application and distribute the
> MySQL database if your software is open source. Even if you have some
> weird objection to open source there is a genuinely, freely
> distributable, version of all the commercial heavyweight databases
> although they may restrict the number of processors, RAM or disk
> size. Why risk contravening MySQL's deliberately confusing license
> conditions?
Thank you for clearly stating some implications of the MySQL license
terms. Here's a discussion of the linking exception offered by many
competitors:
<http://en.wikipedia.org/wiki/GPL_linking_exception>
> I have a list of freely distributable, heavy duty databases at
> <http://database.profectus.com.au>. The page also includes a list of
> open source, relational databases that will run in the same JVM as
> your application. The page is intended to be comprehensive so I would
> appreciate it if you have any additions or corrections.
I would add that Derby and H2 can function as stand-alone servers, in
addition to working in embedded mode. I'm not familiar with the other
embedded offerings mentioned.
Mark
<see_w...@mindprod.com.invalid> wrote:
>Years ago I read that computer companies often do well in recessions.
>Companies try to save money by firing people and replacing them with
>computers.
Or they cancel new IT projects to save money and cut back on
maintenance.
--
(\__/) M.
(='.'=) Due to the amount of spam posted via googlegroups and
(")_(") their inaction to the problem. I am blocking most articles
posted from there. If you wish your postings to be seen by
everyone you will need use a different method of posting.
[Reply-to address valid until it is spammed.]
Lew
>> Years ago I read that computer companies often do well in recessions.
>> Companies try to save money by firing people and replacing them with
>> computers.
Mark wrote:
> Or they cancel new IT projects to save money and cut back on
> maintenance.
Penny wise, pound foolish.
--
Lew
Tom Anderson
Aha, my mistake.
tom
--
1 p4WN 3v3Ry+h1n G!!!
Tom Anderson
> On Sun, 22 Nov 2009 15:10:32 -0800, Roedy Green wrote:
>
>> On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
>> <mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> How do you rate H2 against Derby and HSQL?
>>
>> For a comparison of PosGreSQL and MySQL see
>> http://mindprod.com/jgloss/postgresql.html
>>
>> The information is a few years old.
>>
>> I understand that Derby is fast, but ram resident only. It is for small
>> databases only.
>
> I'm interested finding out if Derby, H2 or HSQL could be used as a
> lighter weight, portable alternative to PostgreSQL, i.e. minimal changes
> to SQL queries and schema, full ACID capability, capable of dealing with
> fairly large tables on disk.
One thing that leaped out at me when reading the H2 docs is that it uses
table-level rather than row-level locking. For read-heavy tables, this is
fine, because read locks can be shared, but it means that if you have
multiple threads writing to a single table, even if they're touching
entirely different rows, they'll serialise, which will kill concurrency
and throw its body in a ditch.
I have had serious problems with table-level locking in real systems. We
have an app which occasionally loads huge (well, moderate) amounts of data
into a database, doing so via a process with quite a bit of CPU overhead.
The machines running the app and databases have multiple cores, and
there's fast disk (actually a SAN) at the backend, so we use multiple
threads to get the most out of the hardware. We developed with Oracle as
our RDBMS, and it all went swimmingly. We ran it up on a client's test
farm with MS SQL Server as the database, and it fell flat on its face.
Turns out that unlike Oracle, MSSQL uses table-level locking by default.
The work around was to drop the number of threads used to one, and endure
amazingly long load times. A later solution was to enable row-level
locking in MSSQL, although to be honest, even then it crawled compared to
Oracle. We never (or haven't yet, more optimistically) got to the bottom
of that.
Hmm. A bit of googling suggests that MSSQL uses row-level locking by
default, which doesn't fit this story. It's possible an overenthusiastic
DBA had changed this somehow. Or that we were running into lock escalation
- each transaction inserted many rows, so it's possible each one started
out with row locks, but then decided to escalate to a whole-table lock.
As an aside, part of the moral here is to develop or at least
integration-test on the same infrastructure as you'll be deploying to. My
defence here is that we originally developed the app for client A, who
used Oracle, and only got involved with client B's MSSQL setup, where the
above story happened, later.
Coming back to H2, it does also support an entirely lock-free concurrency
strategy in the shape of multi-version concurrency control (as made famous
by Interbase/Firebird), but this is experimental, and currently
single-threaded, which means it's not a solution in situations like the
above.
A bit of reading reveals that other databases which use MVCC, beside H2
and Firebird, are Oracle (which explains why it worked where MSSQL
didn't!), PostgreSQL, MS SQL Server since 2005 (as an option, though?),
and even MySQL with the right storage engine. I've seen Sybase mentioned
as having MVCC, but googling turned up strong indications that it uses
orthodox locking. So, MVCC is used by everything except that, the
lightweight java databases, and, er, DB2!
A final caveat on that postscript to a caveat: MVCC is not a cure-all,
because it introduces certain kinds of overhead that lock-based systems
don't have. For instance, i have read that SELECT COUNT(*) FROM SOME_TABLE
is O(n) in an MVCC system, because it has to look at version numbers on
the rows, whereas a locking system can do it in O(1) by looking at the
metadata.
Martin Gregorie
>
> One thing that leaped out at me when reading the H2 docs is that it uses
> table-level rather than row-level locking. For read-heavy tables, this
> is fine, because read locks can be shared, but it means that if you have
> multiple threads writing to a single table, even if they're touching
> entirely different rows, they'll serialise, which will kill concurrency
> and throw its body in a ditch.
>
That's good to know.
However, for my immediate application, table locking is probably not a
problem since during normal processing DB updating is a single threaded
bulk load that can be done overnight and/or in a quiet time. The only
other accesses are read-only apart from occasional bouts of data
cleansing.
> I have had serious problems with table-level locking in real systems.
>
I've been bitten by that in the past too.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>#PostGres does not crash under heavy loads.
>
>No databases are supposed to do that.
Under heavy loads a system can have can a variety of behaviours:
in increasing desirability
1. the system crashes outright.
2. the throughput drops precipitously. (e.g. virtual ram thrashing).
3. the throughput maintains a plateau, no matter what the load.
--
Roedy Green Canadian Mind Products
http://mindprod.com
I mean the word proof not in the sense of the lawyers, who set two half proofs equal to a whole one, but in the sense of a mathematician, where half proof = 0, and it is demanded for proof that every doubt becomes impossible.
~ Carl Friedrich Gauss
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>
>Neither have much of a choice.
I have seen vendors wriggle out of these sorts of promise by creating
a new product and just letting the old one languish. The wording of
the GPL licence may make that difficult for Sun and Oracle. Does the
licence apply to them too? Surely a vendor has the legal right to
change the terms of a licence. They can always create new aux products
that become indispensable. I am glad to see both Sun and Oracle have
shown any sign of wriggling.
--
Roedy Green Canadian Mind Products
http://mindprod.com
RedGrittyBrick
Roedy Green wrote:
> On Sun, 22 Nov 2009 21:56:54 -0500, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Neither have much of a choice.
>
> I have seen vendors wriggle out of these sorts of promise by creating
> a new product and just letting the old one languish. The wording of
> the GPL licence may make that difficult for Sun and Oracle. Does the
> licence apply to them too?
Yes it does, AIUI a company that wholly acquires another as a going
concern also acquires all of it's legal obligations, including those
prescribed in licence terms. If MySQL gave you a licence to use MySQl,
that licence is still valid after MySQL are taken over by Sun or Oracle.
> Surely a vendor has the legal right to change the terms of a licence.
Not retroactively. As copyright owners they can cease making available
the product under the GPL and offer it to new customers using a
different licence.
They can't legally stop people with existing GPL licences from using the
source code to fork the product and make it available under the GPL with
a different product name.
> They can always create new aux products that become indispensable.
They can try.
http://www.linuxtoday.com/developer/2001080201120NWGM.
http://en.wikipedia.org/wiki/Tux_Racer#History
There must be better examples :-)
--
RGB
Arne Vajhøj
> Lew wrote:
>>> I rate MySQL far, far below Postgres, Derby and the free versions of
>>> Oracle DB and IBM DB2.
>
> Arne Vajhøj wrote:
>> We do know that there is a "cult" of people that believe that
>> PostgreSQL is "enterprise" and MySQL is "toy", but given that
>> MySQL dominates the highend over PostgreSQL the reality seems
>> to be the exact opposite.
>
> My comments are based on my experience with the platforms, and that of
> colleagues who've used them, and are my own personal assessment. YMMV.
>
> What evidence do you have that MySQL "dominates" the high end over PG?
Look at the reference customers they have.
And the discussion we had a month ago.
MySQL power some of the highest volume web sites in the world.
> The relational databases I've used professionally that have done well on
> the high end have included Oracle DB, IBM DB2 and Red Brick. I use
> Postgres in my personal development projects but that does not represent
> any sort of "high end". MySQL has only annoyed me, even at the low end,
> to the point where I simply will not consider it for anything serious.
If you don't like it, then don't use it.
But please distinguish between don't like and not good.
> My major complaint with MySQL is its weakness in the implementation of
> SQL. It's so far out of standard as to make it a real PITA to use. I
> detest it.
Oracle and MySQL are two of the worst when it comes to standard
SQL compliance.
Arne
Arne Vajhøj
> To me a high-end database concentrates on features like data integrity,
> scalability, reliability, solid procedural language support,
> constraints, serious transactional support etc etc, all of which are
> things that PostgreSQL has been working on since the beginning, and all
> of which are MySQL after-thoughts.
data integrity - InnoDB is from 1995 and has been part of MySQL since 2000
scalablity - largest public known MySQL customers are bigger
than largest known PostgreSQL customers
reliability - I have never seen any trustworthy analysis comparing
reliability of databases
procedural language support - InnoDB support several, MySQL only SQL
constraints - same as under integrity
transactions - same as under integrity
Based on what yoy say it seems as if the distrust of MySQL is
based on 3 things:
- what MySQL were missing 10 years ago
- the ability to use Tcl, Perl and Python for USP's/UDF's/triggers
- lack of understanding of where MySQL is used
Not convincing.
> MySQL has storage engines out the ying-yang, and PostgreSQL has *one*.
> This allows the Postgres developers to concentrate on quality, IMHO.
That does not make any sense.
It is not the same people that does MyISAM and InnODB. It is not
even the same company.
(not at least until EU approves Oravle buying SUN)
> Ultimately it boils down to benchmarking your own application in
> realistic field conditions. To me high-end also means that you've got a
> person or people who qualify as DBAs - it's their #1 job to administer
> the database of choice. I'll bet a lot of the benchmarks that highlight
> MySQL over PostgreSQL are set up by folks who don't class as DBAs for
> either, or just for MySQL. In any case I'm willing to bet that for a
> "real" high-end app in realistic conditions that Postgres will win out.
The CIO's of the big internet companies seems to bet differently.
Arne
Lew
>> The relational databases I've used professionally that have done well
>> on the high end have included Oracle DB, IBM DB2 and Red Brick. I use
>> Postgres in my personal development projects but that does not
>> represent any sort of "high end". MySQL has only annoyed me, even at
>> the low end, to the point where I simply will not consider it for
>> anything serious.
Arne Vajhøj wrote:
> If you don't like it, then don't use it.
I just said I wouldn't, didn't I?
> But please distinguish between don't like and not good.
Since my opinion is based on professional experience and utility in real-world
projects, my "don't like" is equivalent to "not good". I didn't even mention
the effed-up open-source licensing scheme alluded to elsethread. MySQL is not
good. It rather sucks, actually.
Lew:
>> My major complaint with MySQL is its weakness in the implementation of
>> SQL. It's so far out of standard as to make it a real PITA to use. I
>> detest it.
Arne:
> Oracle and MySQL are two of the worst when it comes to standard
> SQL compliance.
And Postgres is one of the best. Even so, Oracle is miles better than MySQL
for compliance.
--
Lew
Arne Vajhøj
> Roedy Green <see_w...@mindprod.com.invalid> wrote:
>
>> On Sat, 21 Nov 2009 18:59:04 +0000 (UTC), Martin Gregorie
>> <mar...@address-in-sig.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>> How do you rate H2 against Derby and HSQL?
>> For a comparison of PosGreSQL and MySQL see
>> http://mindprod.com/jgloss/postgresql.html
>>
>> The information is a few years old.
>
> And it ignores the gulf between the license conditions of the two
> products. MySQL is GPL but the drivers are not LGPL so you can only
> incorporate a MySQL driver into your application and distribute the
> MySQL database if your software is open source. Even if you have some
> weird objection to open source there is a genuinely, freely
> distributable, version of all the commercial heavyweight databases
> although they may restrict the number of processors, RAM or disk size.
> Why risk contravening MySQL's deliberately confusing license
> conditions?
MySQL gives you the choice of free via a GPL license or
paying for a license on commercial terms.
If you want something free under Apache/BSD/similar license,
then MySQL is not a good choice.
But a lot of people can live with GPL and a lot of people
can live with commercial terms.
Arne
Arne Vajhøj
> On Sun, 22 Nov 2009 21:56:54 -0500, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> Neither have much of a choice.
>
> I have seen vendors wriggle out of these sorts of promise by creating
> a new product and just letting the old one languish. The wording of
> the GPL licence may make that difficult for Sun and Oracle. Does the
> licence apply to them too? Surely a vendor has the legal right to
> change the terms of a licence.
Oracle own the copyright and could make MySQL 7.x closed source,
but the source code for 3.x/4.x/5.x/6.x would still be open source.
And with almost certainty that code would be forked if Oracle
tried something like that.
But Oracle would not do it, because it does not make any business
sense. Oracle already have a closed source database.
Arne
Arne Vajhøj
> On Sun, 22 Nov 2009 22:05:05 -0500, Arne Vajh�j <ar...@vajhoej.dk>
> wrote, quoted or indirectly quoted someone who said :
>
>> #PostGres does not crash under heavy loads.
>>
>> No databases are supposed to do that.
>
> Under heavy loads a system can have can a variety of behaviours:
>
> in increasing desirability
>
> 1. the system crashes outright.
>
> 2. the throughput drops precipitously. (e.g. virtual ram thrashing).
>
> 3. the throughput maintains a plateau, no matter what the load.
That does not justify your claim on that page of it being
an advantage of PostgreSQL.
Arne
Arne Vajhøj
SQLServer has never used table level locking as basic locking.
It inherited page level locking from Sybase.
And row level locking was added in SQLServer 6.5 in 1996.
> Coming back to H2, it does also support an entirely lock-free
> concurrency strategy in the shape of multi-version concurrency control
> (as made famous by Interbase/Firebird), but this is experimental, and
> currently single-threaded, which means it's not a solution in situations
> like the above.
>
> A bit of reading reveals that other databases which use MVCC, beside H2
> and Firebird, are Oracle (which explains why it worked where MSSQL
> didn't!), PostgreSQL, MS SQL Server since 2005 (as an option, though?),
> and even MySQL with the right storage engine. I've seen Sybase mentioned
> as having MVCC, but googling turned up strong indications that it uses
> orthodox locking. So, MVCC is used by everything except that, the
> lightweight java databases, and, er, DB2!
IBM DB2 + Sybase ASE + MS SQLServer in default config +
Informix + SQLite + MySQL with MyISAM seems to me to be
something like 1/2-2/3 of all the worlds databases.
Arne
Lew
> scalablity - largest public known MySQL customers are bigger
> than largest known PostgreSQL customers
As of May, 2008, supposedly the largest database installation in the world was
on Postgres.
<http://it.toolbox.com/blogs/oracle-guide/worlds-largest-database-runs-on-postgres-24979>
--
Lew
Arne Vajhøj
Read the fine print.
That database is not really a PostgreSQL database.
It it is a custom database backend.
They only use PostgreSQL as frontend.
So if we can agree that the scalability is in getting the
data on and off the disk and not in parsing SQL statements,
then that does not say anything about PostgreSQL's scalability.
Well it does say that PostgreSQL backend is not suited for
PB data sizes. But then neither are any other relational
databases. Various big table & map reduce concept exists
to handle those data sizes. Interesting from a Java perspective
is that HDFS & Hadoop are by far the most widely used
technologies for this.
BTW, accidentally Yahoo is a big MySQL customer.
One can wonder whether they picked PostgreSQL for the above just to
get the SQL frontend or because even though MySQL comes with multiple
storage engines, then they really did consider the API for those
to be good.
Arne
Arved Sandstrom
> Arved Sandstrom wrote:
>> To me a high-end database concentrates on features like data
>> integrity, scalability, reliability, solid procedural language
>> support, constraints, serious transactional support etc etc, all of
>> which are things that PostgreSQL has been working on since the
>> beginning, and all of which are MySQL after-thoughts.
>
> Based on what yoy say it seems as if the distrust of MySQL is
> based on 3 things:
> - what MySQL were missing 10 years ago
> - the ability to use Tcl, Perl and Python for USP's/UDF's/triggers
> - lack of understanding of where MySQL is used
>
> Not convincing.
I daresay the distrust of MySQL doesn't go back as far as 10 years.
There are simply too many reports of problems, right across the board,
with releases prior to 5.0 (2005). In fact 5.0 is probably the MySQL
high point; 5.1 last year under the auspices of Sun was accompanied by
reports of poor quality control and these reports have not gone away.
>> MySQL has storage engines out the ying-yang, and PostgreSQL has *one*.
>> This allows the Postgres developers to concentrate on quality, IMHO.
>
> That does not make any sense.
Focus on one thing and do it well. Makes sense to me.
> It is not the same people that does MyISAM and InnODB. It is not
> even the same company.
>
> (not at least until EU approves Oravle buying SUN)
>
>> Ultimately it boils down to benchmarking your own application in
>> realistic field conditions. To me high-end also means that you've got
>> a person or people who qualify as DBAs - it's their #1 job to
>> administer the database of choice. I'll bet a lot of the benchmarks
>> that highlight MySQL over PostgreSQL are set up by folks who don't
>> class as DBAs for either, or just for MySQL. In any case I'm willing
>> to bet that for a "real" high-end app in realistic conditions that
>> Postgres will win out.
>
> The CIO's of the big internet companies seems to bet differently.
>
> Arne
MySQL took off and PostgreSQL and Firebird (to highlight 2 competitors)
did not. There is no rhyme or reason as to why the market, especially
users of free stuff, and especially hundreds and thousands and tens of
thousands of non-professional DBA users, tends to pick one database over
another. The LAMP notion however had a great deal to do with it in this
case - this was marketing genius, and ten or so years ago that stack was
something that every hacker in a single room could get a website up and
running with...right around the time of the bubble. MySQL has never
looked back - they got lifted right up on that rising tide.
Once you generate that kind of user base, a large percentage of your
"DBAs" and "system architects" and "CIOs" are people who grew up with
(and I mean that literally) MySQL. They for the most part haven't
seriously used other databases. They are so used to the workarounds for
MySQL warts, of which there are still many, that they forget how many
there are. There are so many MySQL users out there that there are also
more MySQL experts than there are, say, PostgreSQL or Firebird experts
[1]; this in and of itself is a selling point, because even if MySQL
does need a lot of help in order to develop a large installation,
there's no shortage of relatively inexpensive people to help you do it.
I can fully understand why CIOs of big Internet companies go with MySQL.
And few of the reasons for why they do so necessarily have anything to
do with MySQL being the best database for the job (except for human
resourcing).
AHS
[1[ For all I know there are more MySQL experts than there are Postgres
users.