Subject | Re: [ib-support] Re: Maximum Capacity |
---|---|
Author | Paul Schmidt |
Post date | 2003-02-26T14:46:15Z |
On February 26, 2003 07:15 am, "Frank Emser wrote:
are mathematical limits, technical limits and practical limits, and the three
are not related to one another.
Mathematical limits, are limits like how many rows can a table have, how many
pages, etc. These are largely theoretical in nature, but are unlikely to be
tested because the other limits are much lower. 32TB seems to be reasonable
these days.
Technical Limits, currently the largest hard drives are around 250GB, meaning
to attain 32TB you would need around 130 hard drives connected together,
which isn't currently obtainable, except maybe through NAS, and currently FB
doesn't work with NAS. This may change in the future.... Using SCSI with 6
drives on the same chain, and 4 controllers/chains would make 6TB a more
reasonable technical limit.
Then there are practical limits, like how long does it take for Gbak to
backup a certain sized database, for example if it takes 8 hours per TB, then
a 32TB backup would be almost 11 days (ouch), if it's a really important
database then 11 days to backup would not be reasonable, and the down-time
for a restore would not be reasonable either. In this case 1-3 TB would be a
more reasonable limit.
Now the real issue, technical and practical limits apply for all of the
engines, not just Firebird. The numbers may be a little different, but would
be close.
> --- In ib-support@yahoogroups.com, Marco Bommeljé <mbommelj@x> wrote:The problem is that there are several limits that you can bump into, there
> > Read this list carefully. The topic is discussed frequently.
>
> Looks like a good idea to put this question (or even better: the
> answer) into an easily reachable faq.
> At least I did not find such one.
>
> > Yesterday, Sean Leyne mentioned in one of his postings that the
> > (current) theoretical limit is 32TB.
>
> Well, to be precise:
> He only said that he *believes* the (current) theoretical limit is
> 32 TB.
> This is exactly the amount mentioned in the IB6 techspecs quoted
> at
> http://firebird.sourceforge.net/index.php?op=guide&id=ib6_techspec.
> But then, this was before the 64-bit version of firebird.
>
are mathematical limits, technical limits and practical limits, and the three
are not related to one another.
Mathematical limits, are limits like how many rows can a table have, how many
pages, etc. These are largely theoretical in nature, but are unlikely to be
tested because the other limits are much lower. 32TB seems to be reasonable
these days.
Technical Limits, currently the largest hard drives are around 250GB, meaning
to attain 32TB you would need around 130 hard drives connected together,
which isn't currently obtainable, except maybe through NAS, and currently FB
doesn't work with NAS. This may change in the future.... Using SCSI with 6
drives on the same chain, and 4 controllers/chains would make 6TB a more
reasonable technical limit.
Then there are practical limits, like how long does it take for Gbak to
backup a certain sized database, for example if it takes 8 hours per TB, then
a 32TB backup would be almost 11 days (ouch), if it's a really important
database then 11 days to backup would not be reasonable, and the down-time
for a restore would not be reasonable either. In this case 1-3 TB would be a
more reasonable limit.
Now the real issue, technical and practical limits apply for all of the
engines, not just Firebird. The numbers may be a little different, but would
be close.
> It would be a nice if anyone could provide some *reliable*
> information about the actual firebird limits.
> I just intended to send a note to the author of a comparison of
> several open-source-databases (mysql, postgresql, firebird, sap db)
> which was just recently published in a German computer magazine (c't
> 5/2003, p.142).
> He stated
> => a. that firebird can handle 2^64 colums per table
> (this simply makes no sense if the maximum row size is still 64
> Kbytes as with IB6)
>
> => b. that firebird can handle 16 columns / index
> (if the 256-bytes limit still applies, then these 16 columns might
> be too much as well as too few ... depending of the (size of) the
> datatypes of the columns.
>
> => c. that the maximum database size with firebird is "only" 980
> GBytes
> I consider a *real* existing database of 980 GBytes to be huge (
> especially compared for example to the maximum "real" size of about
> 60 GB
> for Postgresql-databases (http://www.postgresql.org/users-
> lounge/limitations.html))
>
> but compared to the theoretical limits given for the other databases
> (SAP DB: 32 TByte, Postgresql: 64 TByte and MySQL's: "unlimited")
> this 980 GB-limit just sounds like a child's toy.
>
> I just intended to reply to him that Firebird maximum database size
> calculates as the maximum number of files per database times the
> maximum file size.
> According to the Firebird 1.0 release notes, p.5&6, this would mean
> for Windows NT a maximum of about 2040 files per database times
> a maximum of about 16384 GBytes per file and therefore result in
> about 32000 TBytes per database; => a quite impressive number !
> (Well, to be true, not quite as impressive as MySQL's "unlimited",
> but "good enough" anyway ? ).
>
> Now I read that you assume Firebirds theoretical limit to be about
> a factor of thousand below that so I am quite lucky that I have not
> yet mentioned my numbers.
>
> Any idea what went wrong with my calculation or what else is the
> reason for this theoretical limit of 32 TB (if it really still
> exists with 64-bit-firebird) ?
>
> => d. that firebird's maximum table size is only limited by the
> database size.
> Of course, this statement of that author sounds good.
> But is it really valid ?
> In case the maximum database indeed goes to the thousands of
> terabytes, the maximum number of rows (if this is still 2^32 like in
> IB6) would quite probably become very fast the limiting factor for a
> maximum table size (for example when inserting small samples of
> measuring data every few milliseconds)
>
> By the way, just in case that someone of you really happen to read
> this twice: I have posted a very similar reply in the max-table-size
> thread but even after many hours, it has not yet appeared there , so
> I assume that it got lost.
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/