Release of Interbase Beta For Linux 67
Baudtender was one of the folks who wrote to say that Interbase has been released for public testing. This is the open source release, with the code and more information available at
Interbase.com
Other databases (Score:2)
CPM? (Score:1)
Maybe I have my head in the cyber-sand, but is this the same CPM from the 1970's? I find that hard to believe, but then I find it hard to believe that people still use Basic and Cobol. =B)
Well behaved (Score:4)
The real kicker for Interbase is the fact it's so bloody small - it hardly eats any resources. OK, it does lack some features, but you can get around these with a little effort.
As Linux gets ported to more and more embedded devices, there will be situations when a database will be useful. Interbase would plug that gap admirably.
Inprise are to be congratulated on this bold move - I am hoping to see a resurgence of Borland as a market leader in compiler technology. They already are, IMHO, except in market share...
Strong data typing is for those with weak minds.
Familiar Surroundings (Score:1)
As someone who is just switching from Windooze to a far superiour product *Crowd goes wild at the meer suggestion of Linux* it's good to have some familiar stuff around to buffer my transition.
I shall be looking back in here to check the reviews and comments.
Will InterBase get shipped with the Linux versions of Borland DEs?
Cheers,Captain SpankMunki
Re:Other databases (Score:1)
I remember seeing an article in PC Week not too long ago that put several of these head-to-head. Unfortunately, I can't find anything on the PC Week website, and the hard copy magazine is long gone.
Any pack rat geeks out there still have theirs?
Try here (Score:2)
Re:Other databases (Score:1)
Does not even come close. mySQL grills it as speed. PostgreSQL grills it as features.
This release has other importance IMHO, it is the step before Delphy. Deplphy first learns to work with Interbase than someone teaches it to work with the other guys ;-)
Open Sores? (Score:2)
Watch carefully -- it's libel to be free beer only. (Not that I'm complaining. It still beats the heck out of MySQL for what I do, and I'm not an Open Source zealot) I just wish they would not call it open source until it is open source.
Did I just miss the source code on the web site? Anybody from Inprise care to comment?
--
Faster than MySQL? (Score:2)
Retraction (Score:2)
--
Mozilla Public License (Score:2)
Re:Open Sores? (Score:1)
I believe they are releasing it under the Mozilla Licence.
Re:Faster than MySQL? (Score:2)
The Linux code still uses the old architecture. The NT code uses the new.
Interbase and Others (Score:5)
MySQL
Good Stuff
Very fast for read heavy or low user-load apps.
Good Security
Good Support with web publishing systems
Not So Good Stuff
No Transaction Support
Table locking system behaves poorly with many connections
Noy SQL-92 Compliant.
Okay a little about interbase and PostgreSQL now. PostgreSQL has a shared cache, something interbase DOES not have in the Linux version as of yet. Interbase blows PostgreSQL out of the water for single user queries.
Interbase TPS on OLTP Single Read test was over 150
The same test for PostgreSQL was at the 50 mark. for transactions per second.
But if you are expecting many concurrent connections interbase does not have the *best* setup and PostgreSQL will actually outperform Interbase under lots of connection/high-load.
Without the shared cache PostgreSQL was like three times faster than interbase. Go PostgreSQL. Another nice thing about Interbase is that it IS SQL-92 compliant. Okay Enjoy and I hope this was a litle useful.
Oh BTW Interbase is under the Mozilla License
(lol I was asked to check out the two database like last eek
Jeremy
Re:Other databases (Score:1)
Yes, mySQL is faster, but at the cost of no transaction control. And PostgrSQL does not even fully conform to the entry level SQL92 standard. Interbase does, and more. It also has one of the most advanced Multi-Generational engines around. It is a great RDBMS for OLTP applications.
Interbase scalability vs. Postgres scalability (Score:5)
Though the released version of Interbase is the non-threaded one, apparently the source for the treaded version WILL be released, and I've seen a quote from one of the Interbase folks stating his hope that folks in the Linux community will port over the threaded version, too.
In that case, scalability shouldn't really be an issue for Interbase, because the threaded version does implement cache sharing between threads.
Postgres reached its maximum throughput on the artificial benchmark at 50 users on a dual P450 with (I think) 512MB RAM, according to the PC Week guy.
Also, note that Postgres v7.0, now in beta, implements some of the missing SQL features mentioned in the article. In particular, referential integrity complete with "on cascade/update delete/set null/default" referential actions is included.
Regarding mySQL, yes, it is very fast for simple queries. For high-volume use it is less than ideal, though, as it implements concurrency control by locking entire tables. Postgres, Interbase and Oracle all implement concurrency control such that readers NEVER wait for writers, and writers only lock affected rows during a transaction (unless the user does a "select for update" or otherwise imposes a more stringent lock ).
Table locking is evil for high-volume sites. This is one reason for Oracle's popularity at high-end e-commerce sites.
Re:Other databases (Score:3)
Now to balance things. Interbase server side User defined functions are not threaded in the current Linux release (5.x). This can cause slow downs if lots of users are setting them off.
On the windows side where IB is truly and fully threaded, UDFs can't make calls to external programs/DLLs (ala SQL Server). Has poor support for temporary tables, though that can be easily overcome with good design and programming.
Overall though, IB is truly multiplatform and very easy to setup and maintain. You don't need a high priced Oracle style DBA to manage it.
Re:Faster than MySQL? (Score:2)
Faster databases are faster databases; whether or not they are open source is pretty much orthogonal to this issue. If you're referring to the claim that open source software is faster, better and more stable, you should be aware that this is a statement about generalities, not specific software. For example, Microsoft Office is indisputably more feature-complete than AbiWord. Now this isn't bashing AbiWord - it just hasn't got to the point of being complete yet. The point is that claims about the superior performance of open-source solutions can only be made in general; if you try to claim that it is true in *every* specific case, there will always be counterexamples (although they will be increasingly hard to find as more open source projects get more and more complete).
Stuart.
Table locking issues. (Score:1)
The price is that if you leave a lot of transactions open, it's multgenerational architecture can eat up a lot of ram per user. The key is to finish and commit as quickly as possible, and put some code in to automatically rollback after a predetermined timeout period. (yes I have been using it for over 3 years).
Also check out www.interbase2000.org (Score:2)
Re:Interbase scalability vs. Postgres scalability (Score:2)
This is incorrect. Readers must wait when a page (the usual locking granularity AFAIK) is write locked or they could use data that is later rolled back. That would be an unrepeatable read and is bad.
Oh yes, the joys of two phase locking...
Anyone know why PostgreSQL is so slow (relatively) for single users? I heard that the default setting always flushed the cache after a write, but I don't know if this the problem or even if it is true.
Re:Interbase and Others (Score:1)
Re:Thoughts on the Interbase Demo (Score:2)
What they hell did he say?
Re:Interbase and Others (Score:1)
PostgreSQL is BSD License
Interbase is gonna be Mozilla
MySQL is GPL/Pseudo Free
Re:Interbase scalability vs. Postgres scalability (Score:2)
Sorry, I am absolutely correct. Readers don't see the uncommitted data being written by another transaction, but rather previously committed data, and therefore aren't blocked by writers. It's all done on a row-level locking basis. Postgres and Interbase implement a very similar tuple-storing scheme which makes this (relatively) easy. This scheme is expensive in space, though - in Postgres, at least, you have to manually garbage collect your database with "vacuum" to reclaim space occupied by obsolete tuples. I run it automatically once a night.
Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.
I might be slightly wrong about Oracle, it may block readers of rows being written, anyone know for sure? I know this isn't true for Postgres, though - I've read the source. Writers don't block readers.
You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.
Those of us who support Open Source should be pleased that we have TWO Open Source databases that support write-locking on a row-level rather than block level basis, and that both never block readers when writing.
Postgres was slow for single users on one large benchmark run by PC Week. It's not been investigated thus far. I have some personal theories, though.
Postgres doesn't flush the cache after a write - but it DOES fsynch a table's file at each transaction commit, which in effect ends up being about the same thing. Plans are to implement a full-blown write-ahead log later this year, which will remove the necessity of fsynch'ing data files at commit time. Only the write-ahead log need by fsynch'd. The current fsynch'ing behavior is necessary to ensure that data is flushed to the disk before the separate transaction log is written marking the transaction complete. Again, a full write-ahead log will speed things up by removing the need to do that.
/. (Score:1)
One other thing. (Score:1)
New Licenses available.... (Score:1)
News Server: forums.borland.com
I think the news group was: interbase.public.kinobi.
Thoughts on Interbase, PostGressSQL and MySQL (Score:1)
With open source and the combined talent of these three orgs, it would be possible to create the "definitive" database for Linux, much like what was done on the DEC Vax systems, and make it a powerful and intregal part of Linux. It would be the ultimate counter to SQLServer on Wintel.
If only all involved could set aside egos and personal agendas this could actually happen.
Maybe I will get flamed for this, but the idea keeps cropping up in my thick head, and I had to get it out.
Relational Databases Considered Harmful (Score:2)
(*) Note that Netcom, which hosts Mr Baker's archive, is under a large load, and may take a few attempts to be accessed.
Familiar Surroundings (Score:1)
-Effendi
Re:Other databases (Score:1)
You check your facts.
PostgreSQL has a nice little procedural language called PL/pgSQL that works great, and lets you add procedures written in SQL, Perl, TCL and C if you feel the need.
Postgres also supports triggers.
Interbase is a great little database system. So are recent versions of postgres.
And there are partial ports of Philip Greenspun's web development toolkit for each, though the Postgres version's far more complete and up-to-date. It can be found here [benadida.com].
A Poll? (Score:1)
( ) I know all the tricks, and willing to contribute, gimme the code
( ) I know !@#$, but can probably draw yet another WISQL in Delphi
( ) there's a community, you know, they do things
( ) also by Hemos
Re:Interbase and Others (Score:2)
Now they did release an older version (3.20.32a) under the GPL, but that is not nearly the same as releasing the latest versions. This has already been discussed extensively in this [slashdot.org] slashdot article.
---
Not Open Source. (Score:1)
INTERBASE 6.0 BETA TEST FOR LINUX
LICENSE STATEMENT AND LIMITED WARRANTY
...
You acknowledge that the Software in source code form remains a confidential trade secret of Inprise and/or its suppliers and therefore you agree not to modify the Software or attempt to reverse engineer, decompile, or disassemble the Software, except and only to the extent that such
activity is expressly permitted by applicable law notwithstanding this limitation.
Doesn't sound like Open Source to me.
good... (Score:1)
rbf aka pulsar
Poll Update (Score:1)
( ) Free beer!
Re:Not Open Source. (Score:1)
My understanding is that the Open Source release will come Q3.
Re:umm... (Score:1)
Re:Interbase scalability vs. Postgres scalability (Score:2)
I guess my background in DBs is overly academic
Rollback doesn't affect committed data - read the definition of "commit" in any text on transaction processing if you don't understand.
Of course rollback doesn't effect committed transactions, which is why I questioned letting dirty pages get read before commiting.
You are right that many commercial dbs do lock on a page basis. You are wrong in insisting that all do, and that row-level locking can not implement transaction semantics.
I don't know what post you read, but I never insisted that all DBs use page-level locking or that it is necessary for proper serialization. I just stated that in my experience, it is very common, because it provides good transaction throughput. What are the benefits from row-level locking?
My I'm feeling defensive this afternoon....
Re:Mozilla Public License (Score:1)
Re:Not Open Source. (Score:1)
step. You should have seen the NDA that went
with the earlier beta.
Ann
Re:Interbase scalability vs. Postgres scalability (Score:1)
The benefits of row-level locking vs. page-level locking? Same as the benefits of page-level vs. table-level, or table-level vs. locking an entire disk drive, etc.
Finer granularity means fewer backends are blocked for any given write operation that affects data occupying the same or less space than the granule.
Pure row-level locking would mean that only readers reading the particular rows being updated would block on a write operations. As opposed to the reading of any row within a table if you only implement table locking. Etc etc. Surely the benefit of this is obvious in a high-concurrency environment. For the single user running PSQL there is, of course, no benefit.
Postgres (and AFAIK Interbase) can go a step further. Since you worked with Stonebreaker, you probably know that writing a new version of a tuple in a table in Postgres doesn't overwrite the old tuple in the table. A new tuple is made which is associated with the current transaction. That means the old, previously-committed tuple is available for other readers, which means they don't have to be blocked until the transaction writing the table has committed or rolled back.
Writers don't block readers. Conceptually easy, harder than it sounds in practice, but much easier with a tuple-storage scheme such as is implemented by Postgres than it is with certain other schemes. Let me hasten to add that there are drawbacks to the Postgres tuple-storage scheme, as well! But the high degree of concurrency made possible by MVCC is a huge win in certain application spaces, such as high-traffic web sites.
Re:Interbase scalability vs. Postgres scalability (Score:1)
-
V6 has the shared cache. (Score:2)
Interbase 6 (the one just released as beta) is available with the shared cache under Linux.
That's despite what it says in the article about it not being ready - it seems they finished it after all did. (I'll try and find a link for this)
That should make quite a difference as demonstated by this (from teh PC Week article)
Also, see this quote:
I'm just looking forward to them getting it up on Sourceforge!
It's coming, apparently! (Score:1)
Christian R. Conrad
MY opinions, not my employer's - Hedengren, Finland.
Anyone w/ points reading the above, pls MOD IT UP! (Score:1)
Christian R. Conrad
MY opinions, not my employer's - Hedengren, Finland.
Anyone w/ points reading the above, pls MOD IT UP! (Score:1)
(And she's pretty goddarn funny too, in this post! Wild, you say? Aah, too sad I was too young to have been there with you and the rest of those "wild women"... Oh well, you were probably all married anyway.
Christian R. Conrad
MY opinions, not my employer's - Hedengren, Finland.
Anyone w/ points reading the above, pls MOD IT UP! (Score:1)
Christian R. Conrad
MY opinions, not my employer's - Hedengren, Finland.
Re:CPM? (Score:1)