Dmitry, > When we speak about tablespaces, it usually means that the database > consists of multiple files and different database object are stored in > different > files. Each such file is named within a database and called a tablespace. And > each tablespace has its own page set and page numbering.
While I can see possible use cases, I am concerned that implementing tablespaces would only make database management more complicated. The filename/path would become integral to the database and thus cause problems if a device which part of the database was stored was not accessible... With the continuing evolution of disk/storage technology with automatic storage/block tiering (hot block on flash, cold blocks on HDDs) being built into OS/storage devices, I do not think that the database should be concerned about table/storage location management. > A typical usage pattern is that tablespaces are used to separate table data > from indices (and logs from the rest of the database) and thus allow better > concurrent performance due to parallel I/O. Often it's argued that RAIDs now > handle the same job and maybe even better. For many usage cases - maybe. > But I'm pretty sure that the opposite cases are also possible, when a > carefully > designed partitioning could outperform automatic RAID data management. Rather than focus on physical page location management, perhaps Tablespace can be thought of as: - mechanism to set page cache size/rules -- X pages cache for index pages, Y page cache for high activity tables... - mechanism to set garbage collection policy for tables - way to reduce header page/lock contention > Another usage case could be extending the database size beyond the > current limits. The limit is 64TB, the biggest FB database I known is 7TB. Not > that far, I'd say. The limit may be shifted with even larger page sizes, but > it > has its drawbacks as well. I might be alone in thinking this way, but if you have more than 4 to 10 TB of data to store/query, in this day/age, you should be looking to use distributed database/Hadoop type engines. Heck, I have been looking at these technologies for quite some time and my largest database is only 250GB. > (*) My personal opinion is that legacy multi-file databases must die, > preferrably in FB4. They make zero sense in modern filesystems. Completely agree, including database shadows!! Based on your outline/proposal, however, aren't Tablespaces just enabling multi-file databases -- just under a different name? Sean ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
