| Subject | Re: [firebird-support] why Blob is so slow ? |
|---|---|
| Author | Tupy... nambá |
| Post date | 2012-04-19T16:34:20Z |
Still something = doesn´t matter if you have the blob field in a separated table. Since they are all together in a same DB file, they may cause defragmentation, no one can ensure where at the DB file they will be written and probably will be written in the middle of others non-blob columns/fields.
If you have an separated DB for the blob-fields-tables, you will not have this problem, but then you will have new ACIDity problems. If Firebird had something like MSSQL Server Linked Servers, than you still could have integration between the two DB´s, having the best of both (no fragmentation at one / blob´s at the other).
...................................................
I had used MSSQL 6.5 (yes it's a long time ago) so can't comment on the
need of defragmentation.
I don't know Postgres, but I think the VACUMM is a similar to FB garbage
collection.
There is a way to defragment FB, make a back-up/restore, but I don't
think it's needed, at least I had never had the need for such operation.
A big blob will be stored in a bunch of pages that tends to be
contiguous at the end of the file (yes, I know unsed page are reused),
so I don't think it's the reason.
A typical NFE would be around 10KB, depending on the page size it could
be stored with the record, or be stored in two blob pages and just the
blob id on the record page, anyway I prefer to have a separate table to
hold the blobs, because in my case the access to blob's are not so
often, so I prefer to have as many records per page as I can, and read a
separate table (and therefore page) to read the blob contents when I
need it.
It's good to read your thougths, I am just arguing about the options :)
see you !
------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !
Also search the knowledgebases at http://www.ibphoenix.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yahoo! Groups Links
[Non-text portions of this message have been removed]
If you have an separated DB for the blob-fields-tables, you will not have this problem, but then you will have new ACIDity problems. If Firebird had something like MSSQL Server Linked Servers, than you still could have integration between the two DB´s, having the best of both (no fragmentation at one / blob´s at the other).
...................................................
I had used MSSQL 6.5 (yes it's a long time ago) so can't comment on the
need of defragmentation.
I don't know Postgres, but I think the VACUMM is a similar to FB garbage
collection.
There is a way to defragment FB, make a back-up/restore, but I don't
think it's needed, at least I had never had the need for such operation.
A big blob will be stored in a bunch of pages that tends to be
contiguous at the end of the file (yes, I know unsed page are reused),
so I don't think it's the reason.
A typical NFE would be around 10KB, depending on the page size it could
be stored with the record, or be stored in two blob pages and just the
blob id on the record page, anyway I prefer to have a separate table to
hold the blobs, because in my case the access to blob's are not so
often, so I prefer to have as many records per page as I can, and read a
separate table (and therefore page) to read the blob contents when I
need it.
It's good to read your thougths, I am just arguing about the options :)
see you !
------------------------------------
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Visit http://www.firebirdsql.org and click the Resources item
on the main (top) menu. Try Knowledgebase and FAQ links !
Also search the knowledgebases at http://www.ibphoenix.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Yahoo! Groups Links
[Non-text portions of this message have been removed]