数据库文件组织结构

dbHeader(4096).......

| index(默认512*1024) ....... | shadowIndex(默认512*1024) ........

| bitmap page (默认计算出来是9个，4*4096，占用的置1，表示已占用）.........

| page(4096) | page(4096) | ............

 

fastdb只有一个数据文件，所有数据库信息全存在里面，默认的数据文件是8M

 

 

dbHeader 的结构如下，主要存储全局的数据库信息，

class dbHeader {
public:
    offs_t size; // database file size
    int4   curr; // current root
    int4   dirty; // database was not closed normally
    int4   initialized; // database is initilaized
#if (dbDatabaseOffsetBits > 32 && defined(ALIGN_HEADER)) || defined(PAD_HEADER)
    int4   pad;
#endif
    struct {
        offs_t index;           // offset to object index
        offs_t shadowIndex;     // offset to shadow index
        oid_t indexSize;       // size of object index
        oid_t shadowIndexSize; // size of object index
        oid_t indexUsed;       // used part of the index  
        oid_t freeList;        // L1 list of free descriptors
    } root[2];
   
    int4 majorVersion;
    int4 minorVersion;
    int4 mode;

    enum {
        MODE_OID_64        = 0x01,
        MODE_OFFS_64       = 0x02,
        MODE_AUTOINCREMENT = 0x04,
        MODE_RECTANGLE_DIM = 0x08
    };   

    int getVersion() {
        return majorVersion*100 + minorVersion;
    }
   
    bool isCompatible();
    static int getCurrentMode();
};

 

index 和 shadowIndex 非常重要，它就是影子算法的实现部分，也就是自带文档里面的object index

当事务提交后，会把index中的内容拷贝到shadowIndex 里面，这样它们的内容就一致了

每个对象，包括表或者列，全有一个全局的oid，这个oid是不重复的，通过oid就能找到对应的对象在数据文件中的偏移地址，这个地址就存储在index 和 shadowIndex 里面，

oid的起始从0开始，在32的系统中，有8192个bitmap的页面，所以可用的从8194开始，如下面的定义：

 

 

enum dbPredefinedIds {
    dbInvalidId,
    dbMetaTableId,
    dbBitmapId,
    dbFirstUserId = dbBitmapId + dbBitmapPages
};

index 和 shadowIndex 的初始位置是这样的，当增大时，一般是增大一倍，并移动到别的地方，原空间释放

 

bitmap page 表示的是前面已使用的存储空间，这就是已使用的dbHeader，index，shadowIndex 的总和

 

 

这之后就是一个一个连续的普通page了，bitmap页面的分配都是以4096为单位的