Linux下的malloc函数性能问题，想必大部分在Linux下写C的人都深有感受，纷纷利用内存池来改进内存分配效率。
Google开源的tcmalloc则改进了malloc的一些效率问题，在大量malloc和free时，操作系统的内存曲线明显比Linux下malloc函数要平稳，在大并发情况下，提升程序稳定性和性能。
一般网上都是把tcmalloc动态库加到mysqld_safe中启动，但是我们的MySQL都是静态编译的，这时候动态加载是否生效呢？所以还是静态编译入MySQL好。

编译tcmalloc先要编译libunwind：

wget http://download.savannah.gnu.org/releases/libunwind/libunwind-0.99.tar.gz
tar zxvf libunwind-0.99.tar.gz

CHOST=”x86_64-pc-linux-gnu” \
CFLAGS=” -O3 -fPIC \
-fomit-frame-pointer \
-pipe \
-march=nocona \
-mfpmath=sse \
-m128bit-long-double \
-mmmx \
-msse \
-msse2 \
-maccumulate-outgoing-args \
-m64 \
-ftree-loop-linear \
-fprefetch-loop-arrays \
-freg-struct-return \
-fgcse-sm \
-fgcse-las \
-frename-registers \
-fforce-addr \
-fivopts \
-ftree-vectorize \
-ftracer \
-frename-registers \
-minline-all-stringops \
-fbranch-target-load-optimize2″ \
CXXFLAGS=”${CFLAGS}” \
./configure && make && make install

然后编译tcmalloc：

tar zxvf google-perftools-1.6.tar.gz

CHOST=”x86_64-pc-linux-gnu” \
CFLAGS=” -O3 \
-fomit-frame-pointer \
-pipe \
-march=nocona \
-mfpmath=sse \
-m128bit-long-double \
-mmmx \
-msse \
-msse2 \
-maccumulate-outgoing-args \
-m64 \
-ftree-loop-linear \
-fprefetch-loop-arrays \
-freg-struct-return \
-fgcse-sm \
-fgcse-las \
-frename-registers \
-fforce-addr \
-fivopts \
-ftree-vectorize \
-ftracer \
-frename-registers \
-minline-all-stringops \
-fbranch-target-load-optimize2″ \
CXXFLAGS=”${CFLAGS}” \
./configure && make && make install

记得要把libtammloc加入系统路径，否则编译MySQL时找不到：

echo “/usr/local/lib” > /etc/ld.so.conf.d/usr_local_lib.conf
/sbin/ldconfig

最后就是编译MySQL了：

CXX=gcc \
CHOST=”x86_64-pc-linux-gnu” \
CFLAGS=” -O3 \
-fomit-frame-pointer \
-pipe \
-march=nocona \
-mfpmath=sse \
-m128bit-long-double \
-mmmx \
-msse \
-msse2 \
-maccumulate-outgoing-args \
-m64 \
-ftree-loop-linear \
-fprefetch-loop-arrays \
-freg-struct-return \
-fgcse-sm \
-fgcse-las \
-frename-registers \
-fforce-addr \
-fivopts \
-ftree-vectorize \
-ftracer \
-frename-registers \
-minline-all-stringops \
-felide-constructors \
-fno-exceptions \
-fno-rtti \
-fbranch-target-load-optimize2″ \
CXXFLAGS=”${CFLAGS}” \
./configure –prefix=/usr/alibaba/install/mysql-ent-custom-5.1.49sp1 \
–with-server-suffix=-alibaba-edition \
–with-mysqld-user=mysql \
–with-plugins=partition,blackhole,csv,heap,innobase,myisam,myisammrg \
–with-charset=utf8 \
–with-collation=utf8_general_ci \
–with-extra-charsets=gbk,gb2312,utf8,ascii \
–with-big-tables \
–with-fast-mutexes \
–with-zlib-dir=bundled \
–enable-assembler \
–enable-profiling \
–enable-local-infile \
–enable-thread-safe-client \
–with-readline \
–with-pthread \
–with-embedded-server \
–with-client-ldflags=-all-static \
–with-mysqld-ldflags=-all-static \
–with-mysqld-ldflags=-ltcmalloc \
–without-query-cache \
–without-geometry \
–without-debug \
–without-ndb-debug
make && make install

经过试用，大并发下内存分配和释放曲线都比Linux原生的平稳。

类似的文章

• 2009年09月29日 -- 使用tcmalloc优化MySQL (0)
• 2009年12月8日 -- 今天的数据库设计培训 (4)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)

类似的文章

• 2009年12月14日 -- Buffer与Cache (1)
• 2009年10月29日 -- Page Cache和Buffer Cache的区别 (0)
• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)

类似的文章

• 2010年04月10日 -- 数据库算法与数据结构系列——B树相关 (6)
• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)
• 2010年07月5日 -- 李开复——算法的力量 (1)

PostgreSQL提供了一种叫做规则（Rule）的机制，来实现一些与触发器不同的更加自定义的功能。规则系统介于查询编译器和执行优化器之间，根据规则及修改查询。

基本语法：

CREATE RULE 规则名 AS
    ON {SELECT | INSERT | UPDATE | DELETE}
    TO 表名 [WHERE 规则条件]
    DO [INSTEAD] {NOTHING | 命令 | (命令, 命令...)}

PostgreSQL中的视图实际上就是通过RULE来实现的。

例如建立一个视图:

CREATE VIEW view_1 AS SELECT * FROM table_1;

PostgreSQL实际将这个语句翻译为规则：

CREATE TABLE table_view_1 (涉及的列名);
 
CREATE RULE return AS 
    ON SELECT TO table_view_1 DO INSTEAD 
    SELECT * FROM table_1;

这样在查询view_1视图时，PostgreSQL实际上把它转换为对隐含的表table_view_1的查询。

在仅仅需要查询的时候，CREATE VIEW是更合适的语法，但是这这样建立的视图是不能做修改操作的，但是通过规则是可以做到的。

例如我们要更新view_1视图：

CREATE TABLE table_view_1 (涉及的列名);
 
CREATE RULE update_view_1 AS 
    ON UPDATE TO table_view_1
    DO UPDATE table_1 SET col_1 = new.col_1
       WHERE col_2 = new.col_2;

有了这样的规则，我们执行UPDATE view_1 SET col_1=x WHERE　col_2=y;的时候，实际上就更新了table_1，这样就实现了更新视图。对于多表的视图，也可以这样操作。

类似的文章

• 2010年12月27日 -- PostgreSQL和MySQL的对比，第1部分：表组织 (1)
• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)
• 2010年06月22日 -- 数据库算法与数据结构——Cache&Buffer&Lock (1)

后续还会有排序相关，缓存相关，锁相关等内容。

类似的文章

• 2010年05月10日 -- 数据库算法与数据结构系列——排序相关 (0)
• 2010年06月14日 -- B+树实现程序 (2)
• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)

数据库每天都承受着数据量的增长，慢慢的我们发现，对数据库得访问变得非常慢了，这个时候，不外乎两种做法：一是增加单机的配置，升CPU升内存升硬盘；二是“脑裂”，把数据库拆成多份分开存放。
第二个思路必然是最终的方案，因为无论如何单机的承受能力是有限的，业务量的增长必然最终还是要走第二条路。
其实拆分，并不是一个难事，按主键水平拆分，按列垂直拆分，操作上都难，最难的问题是发生在合并的时候，尤其是需要排序的时候（数据库的GROUP/DISTINCT也是先排序做的），合并会变得很麻烦。
一个很糟糕的办法是，设置一台排序专用的机器，访问数据库通过这台机器，发现要排序了就在本地排序，把结果转发给客户端。并发量一大，这台排序用的机器就悲剧了。
第二个方法是，我们希望我们从各个分库中拿出的数据，本身就是按我们所要的方式排序的，数据路由只要组装数据即可，不需要再次排序。
这个如何实现呢，来举个例子，假设我们有个社区系统，有一张用户表U(U_ID,Info,Date)三个字段，分别是主键、信息、注册时间。有一张关系表R(U_ID_1,U_ID_2)，表示U_ID_1和U_ID_2是朋友。我们经常有这样的需求，想知道某个人有哪些朋友。
假设A和B是朋友，我们就在R表插入2条记录R(A,B),(B,A)，为什么要两条呢，数据冗余啦！不错，就是要冗余，冗余可以让后面的工作很Easy。
现在数据量大的惊人，要拆表！
假设业务需求如下：
1. 用户的U.Info查询很少，但是这个部分很长。
2. 经常用U.Date经常被用来排序。
3. 经常要知道某个人有哪些好友。
4. 凡是显示用户都按注册先后排序。

那么怎么拆捏，首先第一个需求，Info查询少，实际中这部分可能包含VARCHAR、TEXT等文本字段，最好需要把它们拆分出去，单独成表，可以提高效率，因为它们不常用。U被拆分为U(U_ID,Date)，U_Info(U_ID,Info)，U_Date(U_ID,Date)。为什么这样拆分？Date不是冗余了嘛，还是为了效率，制造冗余。
然后表怎么拆分呢，当然水平拆分，按ID？那要按Date排序的时候，就悲剧了，所以可以这么分：
U表按Date分区，U_ID建立索引；U_Info/U_Date表按U_ID分区。
这样分区什么好处？为了第2和4个需求，知道了要显示的用户ID列表，到U_Date去拿Date，然后到U表去访问，因为有拆分，所以到所需的时间范围所在的实例去读出新的ID序列，这样拿到的ID就是有序的，原来的ID可以抛弃了，用新的ID序列去拿可能需要的Info，这样取出的数据就是有序的。
然后R表怎么拆呢，很简单，按U_ID_1或者U_ID_2拆都可以，为什么？因为制造了冗余，两边都是对称的，从哪边取都能获得一个人的全部好友，所以就没关系了。
这样还是有一点不方便，拆分可能扩容，怎么办，不能每次都改程序吧？这好办建立1个分区路由表，记录下所有的分区信息，这样查询前先查分区表，再去相应的实例上取数据。

于是得到Schema的设计如下图：

当需要查询A用户的全部好友并且显示列表，再获取第一个好友的详细信息，我们就这么做：
1. 从Route路由表查找A用户所在实例名：SELECT instance FROM Route WHERE Start_ID >= A AND End_ID <=A AND Table = 'R'。
2. 拿到了Instance，就连接到相应的实例去：SELECT U_ID_2 FROM R WHERE U_ID_1 = 'A'。
3. 根据拿到的U_ID，再查所在的Instance，：ELECT instance FROM Route WHERE Start_ID >= u_id_2 AND End_ID <=u_id_2 AND Table = 'U_Date'。
4. 根据拿到的Instance，连接上去，去查U.Date：SELECT Date FROM R WHERE U_ID in (u_id_2)。
5. 有了U.Date，就可以到U去重新查询排序好的ID：SELECT U_ID FROM U WHERE Date in (date)；
6. 然后拿列表中的第一个ID，去取U.Info，查Instance：SELECT instance FROM Route WHERE Start_ID >= u_id AND End_ID <=u_id AND Table = ‘U_Info’。
7. 根据拿到的Instance，连上数据库去取Info：SELECT Info FROM U_Info WHERE U_ID = u_id；
所有任务完成，没有任何的排序产生。

这样大费周折值得吗，我觉得值得，当数据量大的惊人的时候，不可能在中间节点排序，只能是取出的数据就要有序，那么这种拆分思想，就是可以避免排序的。
有了思路，我会自己做一个小实验验证我的方法可行性和效率。

类似的文章

• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)
• 2010年06月22日 -- 数据库算法与数据结构——Cache&Buffer&Lock (1)
• 2010年05月10日 -- 数据库算法与数据结构系列——排序相关 (0)

这些天看数据仓库的内容，发现一个新内容——列式存储。曾经有想过把数据库行列转置作成索引，不过没有深想，没想到列式数据库已经开始发展起来了。
首先看下WIKI上对列式数据库的解释：

列式数据库是以列相关存储架构进行数据存储的数据库，主要适合与批量数据处理和即席查询。相对应的是行式数据库，数据以行相关的存储体系架构进行空间分配，主要适合与小批量的数据处理，常用于联机事务型数据处理。
数据库以行、列的二维表的形式存储数据，但是却以一维字符串的方式存储，例如以下的一个表：
EmpId Lastname Firstname Salary
1 Smith Joe 40000
2 Jones Mary 50000
3 Johnson Cathy 44000
这个简单的表包括员工代码(EmpId), 姓名字段(Lastname and Firstname)及工资(Salary).
这个表存储在电脑的内存(RAM)和存储(硬盘)中。虽然内存和硬盘在机制上不同，电脑的操作系统是以同样的方式存储的。数据库必须把这个二维表存储在一系列一维的“字节”中，又操作系统写到内存或硬盘中。
行式数据库把一行中的数据值串在一起存储起来，然后再存储下一行的数据，以此类推。
1,Smith,Joe,40000;2,Jones,Mary,50000;3,Johnson,Cathy,44000;
列式数据库把一列中的数据值串在一起存储起来，然后再存储下一列的数据，以此类推。
1,2,3;Smith,Jones,Johnson;Joe,Mary,Cathy;40000,50000,44000;
这是一个简化的说法。

昨天装了下两个基于MySQL的数据仓库，infindb和infobright，看了文档发现它们都是列式数据库，把40多M的数据导入infobright，没想到数据文件只有1M多，压缩比令我惊讶！
然后测试了下选择某一列，在列上做计算，都比MyISAM和InnoDB要快，看了一些原理文档，就自己模拟了一下，写了个程序测试。
从内存中读取效率很高，但是从磁盘中读取（假设行式数据库的索引在内存中）比行式数据库要慢（开始在Twitter上说比行式快是程序写错了），不过我觉得还是我设计上的问题，至少Infobright就比MyISAM/InnoDB快，列式应该也有其特殊的索引机制和缓存机制，例如每列分开存在不同的文件，这样文件指针转移会更快。
2010-02-04补充：采用了多个文件指针后，列式存储明显加速，如果给每个列一个文件指针，效率会非常高，也可以肯定，如果每个列单独存储一个文件，效率还会提高。现在文件中列式表读取效率降低了4/5，接近行式表了。继续优化还能提高。

代码请展开：

#include <iostream>
#include <fstream>
#include <cstdlib>
#include <memory>
#include <string>
#include <cstring>
#include <time.h>
#include <map>
 
#define MAXINT RAND_MAX
#define MAXROWS 1000000
#define MINVAL 1
#define MAXVAL 150000000
 
using namespace std;
 
 
/*计时器*/
class Timer {
public :
    //构造函数
    Timer ();
    //析构函数
    ~Timer ();
    //开始计时
    void begin();
    //计时结束
    void end();
    //获取时间,ms
    double get_time();
private :
    clock_t start, finish;
    double time;
};
 
Timer::Timer () {
    start = 0;
    finish = 0;
}
 
Timer::~Timer () {
    start = 0;
    finish = 0;
}
 
void Timer::begin () {
    start = clock();
}
 
void Timer::end () {
    finish = clock();
}
 
double Timer::get_time() {
    time = (double)(finish-start)/CLOCKS_PER_SEC*1000;
    return time;
}
 
//计时器
Timer timer;
 
/*记录各种结构表的空间占用*/
struct Size {
    struct {
        struct {
            int _static;
            int _dynamic;
        } col,row;
    } mem,file;
} size;
 
/*记录各种结构表的文件指针*/
struct File {
    struct {
        struct {
            fstream _static;
            fstream _dynamic;
        } table,index;
    } col,row;
} file;
 
/*静态行式表结构*/
struct StaticRowTable {
    int     id;
    char    name[255];
    int     num;
    double  score;
    bool    flag;
} * static_row_table;
 
/*静态行式表索引*/
struct StaticRowTableIndex {
    multimap<int,int>    id;
    multimap<char*,int>  name;
    multimap<int,int>    num;
    multimap<double,int> score;
    multimap<bool,int>   flag;
} static_row_table_index;
 
/*静态列式表结构*/
struct StaticColTable {
    int*     id;
    char     (*name)[255];
    int*     num;
    double*  score;
    bool*    flag;
} static_col_table;
 
/*动态行式表结构*/
struct DynamicRowTable {
    int    id;
    int    char_len;
    char   *name;
    int    num;
    double score;
    bool   flag;
} * dynamic_row_table;
 
/*动态行式表索引*/
struct DynamicRowTableIndex {
    multimap<int,int>    id;
    multimap<char*,int>  name;
    multimap<int,int>    num;
    multimap<double,int> score;
    multimap<bool,int>   flag;
} dynamic_row_table_index;
 
/*动态列式表结构*/
struct DynamicColTable {
    int*    id;
    int*    char_len;
    char**  name;
    int*    num;
    double* score;
    bool*   flag;
} * dynamic_col_table;
 
/*随机字符*/
char randChar() {
    return rand()%26+'A';
}
 
/*随机字符串*/
void randString(char col[], int len) {
    for(int i=0; i<len; ++i) {
        col[i] = randChar();
    }
}
 
/*初始化表数据*/
void init_StaticTable() {
    double time;
 
    cout << "+-----静态数据-----+" << endl;
 
    //分配空间
    cout << "分配空间中......" << endl;
    timer.begin();
    static_row_table = new StaticRowTable[MAXROWS];
    static_col_table.id = new int[MAXROWS];
    static_col_table.name = new char[MAXROWS][255];
    static_col_table.num = new int[MAXROWS];
    static_col_table.score = new double[MAXROWS];
    static_col_table.flag = new bool[MAXROWS];
    timer.end();
    time = timer.get_time();
    cout << "空间分配完毕!" << endl
         << "分配空间耗时: " 
         << time << "ms" << endl;
 
    //产生随机数据和索引
    cout << "生成数据中......" << endl;
    timer.begin();
    for(int i=0; i<MAXROWS; ++i) {
        static_col_table.id[i] = 
        static_row_table[i].id = i;
        static_row_table_index.id.insert(pair<int,int>(static_row_table[i].id,i));
 
        randString(static_row_table[i].name, rand()%20+1);
        strcpy(static_col_table.name[i],static_row_table[i].name);
        static_row_table_index.name.insert(pair<char*,int>(static_col_table.name[i],i));
 
        static_col_table.num[i] =
        static_row_table[i].num = rand();
        static_row_table_index.num.insert(pair<int,int>(static_row_table[i].num,i));
 
        static_col_table.score[i] = 
        static_row_table[i].score = rand()/rand();
        static_row_table_index.score.insert(pair<double,int>(static_row_table[i].score,i));
 
        static_col_table.flag[i] = 
        static_row_table[i].flag = rand()%2;
        static_row_table_index.flag.insert(pair<bool,int>(static_row_table[i].flag,i));
    }
    timer.end();
    time = timer.get_time();
    cout << "数据生成完毕!" << endl;
    cout << "生成数据耗时: " 
         << time << "ms" << endl;
 
 
    //初始化文件指针
    timer.begin();
    file.row.table._static.open("row_table_static.dat", ios::binary | ios::out);
    file.row.index._static.open("row_index_static.dat", ios::binary | ios::out);
    file.col.table._static.open("col_table_static.dat", ios::binary | ios::out);
 
    if( !file.row.table._static ||
        !file.row.index._static ||
        !file.col.table._static) {
        cout << "打开文件失败" << endl;
    }
 
    cout << "正在将数据写入文件......" << endl;
    for(int i=0; i<MAXROWS; ++i) {
        file.row.table._static.write(reinterpret_cast<char *>(&static_row_table[i]),
                                    sizeof(StaticRowTable));
    }
    file.row.table._static.close();
    for(int i=0; i<MAXROWS; ++i) {
        file.row.index._static.write(reinterpret_cast<char *>(&static_row_table_index),
                                    sizeof(StaticRowTableIndex));
    }
    file.row.index._static.close();
 
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.write(reinterpret_cast<char *>(&static_col_table.id[i]),
                                    sizeof(int));
    }
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.write(reinterpret_cast<char *>(static_col_table.name[i]),
                                    sizeof(char[255]));
    }
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.write(reinterpret_cast<char *>(&static_col_table.num[i]),
                                    sizeof(int));
    }
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.write(reinterpret_cast<char *>(&static_col_table.score[i]),
                                    sizeof(double));
    }
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.write(reinterpret_cast<char *>(&static_col_table.flag[i]),
                                    sizeof(bool));
    }
    file.col.table._static.close();
    timer.end();
    time = timer.get_time();
    cout << "数据写入完毕!" << endl;
    cout << "写入数据耗时: " 
         << time << "ms" << endl;
 
    //计算总占用空间
    size.mem.row._static = sizeof(*static_row_table)*MAXROWS
                    +sizeof(static_row_table_index)*MAXROWS;
    size.mem.col._static = (sizeof(int)*2+sizeof(double)
                    +sizeof(bool)
                    +sizeof(char)*255)*MAXROWS;
 
    cout << "静态行式存储耗费空间: " 
         << size.mem.row._static/1024/1024 << "M" << endl;
    cout << "静态列式存储耗费空间: " 
         << size.mem.col._static/1024/1024 << "M" << endl;
}
 
void init_DynamicTable() {
    double time;
 
    cout << "+-----动态数据-----+" << endl;
}
 
void init() {
    double time1, time2;
 
    srand(time(0));
 
    cout << "======生成数据======" << endl;
 
    init_StaticTable();
    init_DynamicTable();
}
 
/*
SELECT name
FROM table 
WHERE num BETWEEN MINVAL AND MAXVAL;
*/
 
 
/*测试内存中静态行存储*/
int Mem_Static_testRow() {
    double time;
    int count = 0;
    int id;
    multimap<int,int>::iterator it,itlow,itup;
 
    cout << "正在测试内存中读取行式静态表......" << endl;
    timer.begin();
    itlow = static_row_table_index.num.lower_bound (MINVAL);
    itup = static_row_table_index.num.upper_bound (MAXVAL);
 
    for (it=itlow; it!=itup; ++it) {
        id = (*it).second;
        StaticRowTable row = static_row_table[id];
        //结果
        //cout << row.id;
        /*cout << '\t' << */row.name;
        //cout << '\t' << row.num;
        //cout << endl;
        //计数
        ++count;
    }
    timer.end();
    time = timer.get_time();
    cout << "内存中行式静态表读取测试完毕!" << endl;
    cout << "读取耗时:" << time << " ms" << endl;
 
    return count;
}
 
/*测试磁盘中静态行存储*/
int File_Static_testRow() {
    double time;
    int count = 0;
    int id;
    char *name;
    int num;
    int pos;
    StaticRowTable row;
    multimap<int,int>::iterator it,itlow,itup;
 
    //初始化文件指针
    cout << "正在测试磁盘中读取行式静态表......" << endl;
    timer.begin();
    file.row.table._static.open("row_table_static.dat", ios::binary | ios::in);
    //file.row.index._static.open("row_index_static.dat", ios::binary | ios::in);
 
    if(!file.row.table._static) {
        cout << "打开文件失败" << endl;
    }
    //假设索引在内存中
    itlow = static_row_table_index.num.lower_bound (MINVAL);
    itup = static_row_table_index.num.upper_bound (MAXVAL);
 
    for (it=itlow; it!=itup; ++it) {
        id = (*it).second;
        pos = sizeof(StaticRowTable)*id;
        file.row.table._static.seekg(pos);
        file.row.table._static.read(reinterpret_cast<char *>(&row),
                                    sizeof(StaticRowTable));
        //结果
        //cout << row.id;
        /*cout << '\t' << */row.name;
        //cout << '\t' << row.num;
        //cout << endl;
        //计数
        ++count;
    }
    file.row.table._static.close();
    //file.row.index._static.close();
    timer.end();
    time = timer.get_time();
    cout << "磁盘中行式静态表读取测试完毕!" << endl;
    cout << "读取耗时:" << time << " ms" << endl;
 
    return count;
}
 
/*测试磁盘中静态列存储*/
int Mem_Static_testCol() {
    double time;
    int count = 0;
    int id;
    int num;
    char *name;
 
    cout << "正在测试内存中列式静态表读取......" << endl;
    timer.begin();
    for(int i=0; i<MAXROWS; ++i) {
        int num = static_col_table.num[i];
        if(num>MINVAL and num<MAXVAL) {
            //结果
            //cout << i;
            /*cout << '\t' << */static_col_table.name[i];
            //cout << '\t' << static_col_table.num[i];
            //cout << endl;
            //计数
            ++count;
        }
    }
    timer.end();
    time = timer.get_time();
    cout << "内存中列式静态存储表读取测试完毕!" << endl;
    cout << "读取耗时:" << time << " ms" << endl;
 
    return count;
}
 
/*测试磁盘中静态列存储*/
int File_Static_testCol() {
    double time;
    int count = 0;
    int id;
    int num;
    char *name = new char[255];
    int pos_num;
    int pos_name;
    int pos;
 
    cout << "正在测试磁盘中列式静态表读取......" << endl;
    timer.begin();
    file.col.table._static.open("col_table_static.dat", ios::binary | ios::in);
    fstream tmpfile("col_table_static.dat", ios::binary | ios::in);
 
    if(!file.col.table._static || !tmpfile) {
        cout << "打开文件失败" << endl;
    }
 
    pos_name = sizeof(int)*MAXROWS;
    pos_num = (sizeof(int)
            +sizeof(char[255]))*MAXROWS;
    file.col.table._static.seekg(pos_num);
    for(int i=0; i<MAXROWS; ++i) {
        file.col.table._static.read(reinterpret_cast<char *>(&num),
                                    sizeof(int));
        if(num>MINVAL and num<MAXVAL) {
            //结果
            id = i;
            //cout << id;
            pos = pos_name+sizeof(char[255])*id;
            tmpfile.seekg(pos);
            tmpfile.read(reinterpret_cast<char *>(name),
                        sizeof(char[255]));
            /*cout << '\t' << */name;
            //cout << '\t' << num;
            //cout << endl;
            //计数
            ++count;
        }
    }
    file.col.table._static.close();
    timer.end();
    time = timer.get_time();
    cout << "磁盘中列式静态存储表读取测试完毕!" << endl;
    cout << "读取耗时:" << time << " ms" << endl;
 
    return count;
}
 
void test() {
    int count1, count2, count3, count4;
 
    cout << "=====内存存取测试=====" << endl;
    cout << "+----静态表测试中----+" << endl;
    cout << "*行式存储*" << endl;
    //内存中静态行式存储表
    count1 = Mem_Static_testRow();
    //内存中静态列式存储表
    count2 = Mem_Static_testCol();
    cout << "*列式存储*" << endl;
    //磁盘中静态行式存储表
    count3 = File_Static_testRow();
    //磁盘中静态行式存储表
    count4 = File_Static_testCol();
 
    if (count1==count2 and count2==count3 and count3==count4) {
        cout << "共匹配:" << count1 << " 行" << endl;
    } else {
        cout << "错误:每次匹配行数不同" << endl;
    }
 
}
 
int main() {
    init();
    test();
    cout << "All OK!" << endl;
    return 0;
}

2010-02-04测试结果：
======生成数据======
+—–静态数据—–+
分配空间中……
空间分配完毕!
分配空间耗时: 0ms
生成数据中……
数据生成完毕!
生成数据耗时: 4180ms
正在将数据写入文件……
数据写入完毕!
写入数据耗时: 2480ms
静态行式存储耗费空间: 495M
静态列式存储耗费空间: 259M
+—–动态数据—–+
=====内存存取测试=====
+—-静态表测试中—-+
*行式存储*
正在测试内存中读取行式静态表……
内存中行式静态表读取测试完毕!
读取耗时:10 ms
正在测试内存中列式静态表读取……
内存中列式静态存储表读取测试完毕!
读取耗时:0 ms
*列式存储*
正在测试磁盘中读取行式静态表……
磁盘中行式静态表读取测试完毕!
读取耗时:190 ms
正在测试磁盘中列式静态表读取……
磁盘中列式静态存储表读取测试完毕!
读取耗时:210 ms
共匹配:69650 行
All OK!

类似的文章

• 2010年02月2日 -- 数据仓库相关概念 (0)
• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)
• 2010年06月22日 -- 数据库算法与数据结构——Cache&Buffer&Lock (1)

系统由每一个细节组成，我喜欢这句话。
欢迎大牛拍砖，指出错误和不妥之处。

类似的文章

• 2010年10月30日 -- 静态编译TCMalloc到MySQL (6)
• 2012年01月23日 -- 一个InnoDB性能超过Oracle的调优Case (1)
• 2011年12月23日 -- 在Server层实现Kill Idle Transaction (1)

Oracle Developer Tools For .Net (ODT.NET) 和 SQL Server 的数据源一直有些诡异的问题困扰我很久，这几天下了狠心把它们搞定，最终搞定了，并且发现问题的原因是非常简单的。 

首先是ODT.NET的问题，装好ODT以后，在VS2008中配置数据源，总是提示找不到可用的.NET应用程序，这不扯淡么，刚装好，并且在程序中using Oracle.Client是正确的，可以连接数据库的。

网上查了一些资料，全是扯淡，最后只能上OTN了，用灵格斯悲剧的看着老外用英文讨论，终于有个老外貌似解决了，他说是C:\Windows\Microsoft.NET\Framework64\v2.0.50727\CONFIG下的machine.config文件问题，因为

<add name=”Oracle Data Provider for .NET” invariant=”Oracle.DataAccess.Client” description=”Oracle Data Provider for .NET” type=”Oracle.DataAccess.Client.OracleClientFactory, Oracle.DataAccess, Version=2.111.6.0, Culture=neutral, PublicKeyToken=89b483f429c47342″ />
这一列的问题。灰色标出来的就是问题所在，因为装ODT.NET先得装Oracle Client，但是Oracle Client中也有个Provider，版本是2.111.6.0，装了ODT.NET之后，ODAC升级到2.111.6.20了，于是只要把灰色部门改成2.111.6.20，一切都好了，在这个文件中出现的所有关于Oracle Provider的都可以把2.111.6.0改成2.111.6.20，因为全部都升级了。

同时，C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG中的machine.config文件也最好改一下，我是X64系统，所以改Framework64目录就行了，如果是X86系统那就是改Framework目录，不过最好都要修改，这样万无一失。

我改过之后，VS跑起来了。

然后是SQL Server数据源的问题，连接总提示SQL Server没有打开远程连接，怎么可能？我明明打开了，在服务器上都可以连接。

后来突然意识到，在服务器上登录SQL Server数据库引擎时，发现服务器名里面是“VM-WIN2003\VM_WIN2003_MSSQL”，然后在VS中配置数据源时，自动搜索总是显示的服务器名是“VM-WIN2003”，感觉不对，重新写成“VM-WIN2003\VM_WIN2003_MSSQL”，终于在数据库列表中显示出了数据库中的数据库。

原来是个这么简单的问题！

类似的文章

• 2009年07月24日 -- 数据库中的一些概念——集群技术及数据仓库 (0)
• 2009年07月9日 -- Oracle 最近的一些记录 (0)
• 2009年04月12日 -- eBay数据库构架方案分析 (0)

最近学习数据库集群技术，遇到一些新的概念，于是总结一些这些新概念。

数据库与数据仓库的区别

　　简而言之，数据库是面向事务的设计，数据仓库是面向主题设计的。
　　数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。
　　数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。
　　数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表和事实表。维是看问题的角度，比如时间，部门，维表放的就是这些东西的定义，事实表里放着要查询的数据，同时有维的ID。
　　单从概念上讲，有些晦涩。任何技术都是为应用服务的，结合应用可以很容易地理解。以银行业务为例。数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，这里，可以简单地理解为用数据库记帐。数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立ATM了。
　　显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
　　数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。那么，数据仓库与传统数据库比较，有哪些不同呢?让我们先看看W.H.Inmon关于数据仓库的定义:面向主题的、集成的、与时间相关且不可修改的数据集合。
　　“面向主题的”:传统数据库主要是为应用程序进行数据处理，未必按照同一主题存储数据;数据仓库侧重于数据分析工作，是按照主题存储的。这一点，类似于传统农贸市场与超市的区别—市场里面，白菜、萝卜、香菜会在一个摊位上，如果它们是一个小贩卖的;而超市里，白菜、萝卜、香菜则各自一块。也就是说，市场里的菜(数据)是按照小贩(应用程序)归堆(存储)的，超市里面则是按照菜的类型(同主题)归堆的。
　　“与时间相关”:数据库保存信息的时候，并不强调一定有时间信息。数据仓库则不同，出于决策的需要，数据仓库中的数据都要标明时间属性。决策中，时间属性很重要。同样都是累计购买过九车产品的顾客，一位是最近三个月购买九车，一位是最近一年从未买过，这对于决策者意义是不同的。
　　“不可修改”:数据仓库中的数据并不是最新的，而是来源于其它数据源。数据仓库反映的是历史信息，并不是很多数据库处理的那种日常事务数据(有的数据库例如电信计费数据库甚至处理实时信息)。因此，数据仓库中的数据是极少或根本不修改的;当然，向数据仓库添加数据是允许的。
　　数据仓库的出现，并不是要取代数据库。目前，大部分数据仓库还是用关系数据库管理系统来管理的。可以说，数据库、数据仓库相辅相成、各有千秋。

　　补充一下，数据仓库的方案建设的目的，是为前端查询和分析作为基础，由于有较大的冗余，所以需要的存储也较大。为了更好地为前端应用服务，数据仓库必须有如下几点优点，否则是失败的数据仓库方案。
　　1.效率足够高。客户要求的分析数据一般分为日、周、月、季、年等，可以看出，日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，设计不好的数据仓库经常会出问题，延迟1-3日才能给出数据，显然不行的。
　　2.数据质量。客户要看各种信息，肯定要准确的数据，但由于数据仓库流程至少分为3步，2次ETL，复杂的架构会更多层次，那么由于数据源有脏数据或者代码不严谨，都可以导致数据失真，客户看到错误的信息就可能导致分析出错误的决策，造成损失，而不是效益。
　　3.扩展性。之所以有的大型数据仓库系统架构设计复杂，是因为考虑到了未来3-5年的扩展性，这样的话，客户不用太快花钱去重建数据仓库系统，就能很稳定运行。主要体现在数据建模的合理性，数据仓库方案中多出一些中间层，使海量数据流有足够的缓冲，不至于数据量大很多，就运行不起来了。

OLTP与OLAP

　　人们对数据的处理需求可以分为两种类型，操作型处理（OLTP）和分析型处理（OLAP），传统的数据库主要是面向OLTP，注重数据的计算、记录的插入、删除、与修改，以及简单的查询和统计。它的主要任务是进行事务处理，所关注的是事务处理的及时性、完整性和正确性，而在数据的分析处理方面存在着严重的不足，主要表现在以下一些方面。
　　首先是集成性的缺乏。业务数据库系统的条块与部门分割，导致数据分布的分散化与无序化。业务数据库缺乏统一的定义与规划，导致数据的定义存在歧义；其次是主题不明确，建立数据库的目的就是为了满足事务处理的需要，库和表的定义与设计完全以此为基础而进行，对于数据分析而言，这些库和表无疑缺少明确的主题。又是需要分析的数据会分散的存储在不同的表和库甚至不同的数据库服务器中，想要对这些数据进行有效的分析是十分困难的。然后是分析和处理的效率低下，设计基于传统数据库的应用系统的核心准则，是要确保事务得到及时、准确的处理。因此，在业务数据库系统的构建过程中，除了库和表的精心设计之外，索引的建立、存储过程的优化等工作，也均以此为中心展开，这样虽然充分提高了事务处理的效率，但是数据分析处理的效率却无法得到保证。
　　传统数据库由于自身条件的限制，无法担当作为大规模数据综合分析平台的重任，企业的决策迫切需要有一种新的理论与技术来提供支持，这就是数据仓库技术。
　　数据仓库就是面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理层的决策过程，“面向主题、集成、随时间变化和非易失”是它的主要特点。
　　面向主题是数据仓库中数据组织的最基本原则。数据仓库中的所谓“主题”，是一个逻辑概念。在信息管理的层次上，主题就是从管理的角度出发，对数据进行综合分析而抽取的，需要做进一步分析的对象，数据仓库的构造过程首先就是确定主题的过程。数据仓库的设计者必须明确该数据仓库所支持的决策内容，即数据仓库的用途，并将决策内容归纳为若干个具体的易于利用数据进行组织加以分析的主题。
　　数据仓库中数据的集成性是指，在构建数据仓库的过程中，多个外部数据源内格式不同、定义各异的数据，按照既定的策略经过抽取、清洗、转换等一系列处理。最终构成一个有机的整体。传统业务处理程序的侧重点在于迅速、正确地处理所有业务，记录业务内容和处理结果，而不是对决策提供支持。数据仓库直接使用传统业务处理的结果，进行数据分析。
　　数据仓库中数据的非易失性，包括两个方面的含义，其一是指数据仓库内容的更新、追加等操作是不频繁的，一般基于一定的周期或条件阈值进行；其二是指，数据在导入数据仓库后，虽然也有删除更新等操作，但决定这种操作的阈值条件是较难满足的，这种情况的发生是非常罕见的。
　　数据的时变性，是指数据仓库的内容随时间的变化不断得到补充、更新。其实质就是建立业务数据与时间的对应关系，即以时间为坐标轴，对既定时间点的业务数据生成“快照”，各个时间点的快照连接起来，就构成了数据仓库内容的动态连续变化图，为决策者提供有效的依据。
　　从数据库到数据仓库，完成了数据挖掘的最重要一步，为数据挖掘接下来的步骤的顺利进行大好了基础。数据挖掘的各项操作都是在数据仓库的基础上进行的。数据仓库的构建是一门大学问。

        其实这也是很难说，目前数据库厂商中仅有oracle 提供share data模式群集(RAC模式)，而其它数据库厂商的群集均是share nothing的模式，即群集中仅有一个节点处于活动状态，其它节点处于备用状态。Oracle的HA(OFS)其实就是就是采用share- nothing的一种群集模式，对于share-nothing和share-date (share-disk) 两种模式的差别，目前的确是有多种版本的说法。不过，采用share-nothing对于机器的利用率是相当低(如果只采用 active/standby模式)，但如果采用active/active模式，则又会担心在一个节点出现故障时，另外一个节点是否能够承担原来两个节 点所承担的系统负载。对于share-data模式，大家目前比较关心的随着节点的增加，其内部通讯带来的系统开销(即cache同步等)，则又是一个令 人担心的问题，特别是在OLTP系统上，所以，也有人建议，RAC还是用在data warehouse上比较好，而大型OLTP则还是不优先采用RAC，因为OLTP系统带来的内部通讯开销比较令人恐怖。

类似的文章

• 2010年01月9日 -- 在OEL5.4上安装Oracle 10g R2 x64 RAC的一些记录 (1)
• 2009年10月13日 -- 装RAC中libpthread.so.0的问题 (0)
• 2009年10月11日 -- 我组建的Oracle RAC高可用集群 (0)

最近遇到一个比较诡异的问题，一个数据库DROP任何东西的时候都出错，大致错误是“SQL递归在第一层错误，视图、表不存在”。

我网上搜了下，有人说是DUAL里面记录不止一条造成了，把DUAL清空再插入一条记录就OK，如下

DELETE FROM DUAL;
DELETE FROM DUAL;
INSERT INTO DUAL VALUES('X');

我亲自上机尝试，发现这种方法在我们这里并不生效。

经过TRACE，

ALTER SESSION SET sql_trace = true;

我发现是有一张系统表不存在，但是网上找不到这张表的结构，于是我这个悲剧小菜鸟只能选择重装数据库导入数据。

准备今天再详细的跟踪一下DROP语句的解析，看能不能找出其他原因。

SQL>ALTER SESSION SET sql_trace=true;
SQL>ALTER SESSION SET EVENTS '10046 trace name context forever,level 12';
SQL>DROP TABLE p CASCADE CONSTRAINT;
SQL>ALTER SESSION SET EVENTS '10046 trace name context off';
c:\>tkprof $oracle_home\admin\testdb\udump\oracledb_ora_3340.trc  c:\m3_droptable.txt

传说中是可能是MDSYS用户的表不能删除导致的，只要删除MDSYS就可以了。

DROP USER mdsys CASCADE;

也可能是角色引起的，删除角色。

ALTER SESSION SET EVENTS '25475 trace name context forever, level 2';
execute DBMS_RULE_ADM.DROP_RULE('.AQ$WF_DEFERRED_QUEUE_M$1',TRUE);
commit;
execute DBMS_RULE_ADM.DROP_RULE_SET('AQ$WF_DEFERRED_QUEUE_M$1');
commit;

实在不行只能先导出数据库了。
exp m3/m3 owner=m3;

然后导入的时候为了保证导入到自己表空间下，要先设置下用户。

REVOKE UNLIMITED TABLESPACE FROM m3;
ALTER USER m3 DEFAULT TABLESPACE users;
ALTER USER m3 QUOTA UNLIMITED ON users;
ALTER USER m3 QUOTA 0 ON system;

imp m3/m3 fromuser=m3 touser=3;

类似的文章

• 2009年07月26日 -- 对Oracle导出文件错误和DMP文件结构的分析 (0)
• 2009年07月22日 -- 今天为XXX导数据的记录 (0)
• 2009年08月20日 -- 关于VS2008与一些数据源配置的问题 (0)

(荣耀属于Fenng和F5)

一、 eBay的数据量^[]

作为电子商务领头羊的eBay公司，数据量究竟有多大？eWeek的报道中，eBay的存储主管Paul Strong对数据量做了一些介绍，这些数据可以作为参考。

1. 站点处理能力

A. 平均每天的PV超过10亿

B. 每秒钟交易大约1700美元的商品

C. 每分钟卖出一辆车

D. 每秒钟卖出一件汽车饰品或者配件

E. 每两分钟卖出一件钻石首饰

F. 6亿商品，2亿多注册用户

G. 超过130万人把在eBay上做生意看作是生活的一部分

在这样高的压力下，可靠性达到了99.94%，也就是说每年只有5个小时多一点的时间服务不可用。从业界消息来看，核心业务的可用性要比这个还要高。

数据存储工程组控制着 eBay的2PB (1Petabyte=1000Terabytes) 可用空间。这是一个什么概念，对比一下 Google 的存储就知道了。每周就要分配 10T 数据出去，稍微算一下，一分钟大约使用 1G 的数据空间。

2. 计算能力

eBay使用一套传统的网格计算系统。该系统的一些特征数据：

A. 170 台 Win2000/Win2003 服务器；、

B. 170 台 Linux (RHES3) 服务器；、

C. 三个 Solaris 服务器：

为QA构建与部署 eBay.com；、

编译优化 Java / C++ 以及其他 Web 元素；、

D. Build整个站点的时间：

过去是10个小时，现在是30分钟；、

E. 在过去的2年半，有200万次Build，很可怕的数字

3. 存储硬件与软件

每个供货商都必须通过严格的测试才有被选中的可能，这些厂家或产品如下：

A. 交换机：Brocade

B. 网管软件：IBM Tivoli

C. NAS：Netapp（占总数据量的5%，2P*0.05，大约100T）

D. 阵列存储：HDS （95%，EMC在eBay是出局者）

E. 负载均衡与Failover：Resonate

F. 搜索功能：Thunderstone indexing system

G. 数据库软件：Oracle，大多数DB都有4份拷贝

H. 数据库服务器：Sun E10000

I. 数据备份：Share Plex，购买的全球Licence用于数据复制

4. 架构

A. 高分布式

B. 拍卖站点是基于Java的，搜索的架构是用C++写的

C. 数百名工程师进行开发，所有的工作都在同样的代码环境下进行

5. 其他信息

A. 集中化存储应用程序日志

B. 全局计费：实时的与第三方应用集成（eBay的PayPal）

C. 业务事件流：使用统一的高效可靠消息队列，并且使用Cookie-cutter模式用于优化用户体验

二、 eBay 的应用服务器规模

从Oracle的一份白皮书《The eBay Global Platform and Oracle 10g JDBC》^[]中可以了解到，在2004年的时候，eBay的应用服务器采用了IBM Web Sphere，部署在WinNT上，硬件是Intel双CPU奔腾服务器。服务器数量是2400台。在第一部分中可以知道，eBay 的是集中式处理Log的，每天会有2T的Log数据产生，现在只会更多。这些应用服务器分成不同的组，通过一个统一的DAL(Database Access Layer)逻辑层访问135个数据库节点。

这篇白皮书已经发布了两年，相信在这两年的时间里，服务器规模又会扩大了许多。

eBay的SOA架构V3示意图如下：

三、 eBay的数据库分布扩展架构^[]

对于eBay这样超大规模的站点来说，瓶颈往往最容易在数据库服务器上产生，必定有一部分数据（比如交易记录这样不容易水平分割的数据）容易带来大量的读操作，而不管用什么存储，能承担的I/O能力是有限的。所以，如果有效的分散I/O的承载能力就是一个很有意义的事情。

大约为如下结构：

由F5公司设计的方案，通过Quest公司的Share Plex^[]近乎实时的复制数据到其他数据库节点，通过特定的模块检查数据库状态，并进行负载均衡，I/O 成功的做到了分布，读写分离，而且极大的提高了可用性。虽然整个方案技术并无高深之处，但方法巧妙，效果极好。

当然，这个技术架构不算便宜。Quest的Share Plex License很贵，而且对于每个结点来说，都需要数据库License与硬件费用。但优点也很多：节省了维护成本，数据库层面的访问也能做到SOA，高可用性。

国内的一些厂商比较喜欢给客户推存储级别的解决方案。通过存储底层复制来解决数据分布以及灾备问题。这个思路似乎太传统了，对于大型集群多少有点过时。

四、 Share Plex数据库负载均衡方案^[]

1. 需求及挑战

eBay拥有30套生产数据库，全部采用Oracle数据库：

A. 12个数据库支持“live”项目（Sun 480/4500）

B. 1个数据库支持存档项目（Sun 4800）

C. 4个数据库支持客户数据（Sun 4800）

D. 2个数据库支持eBay的反馈系统（Sun 480）

E. 1个数据库支持非正常的 “cache”数据（Sun 4800）

F. 10个其他的数据库（大部分Sun 480 class）

同时，采用Hitachi SAN建立存储架构，建立了两个远程备份数据库，并实施实时复制数据到远程数据库实现冗灾，同时每24小时实施针对数据块的数据备份。

因此，通过eBay数据库读写的比率分析，可以发现，eBay在数据库提供服务时，读和查询的操作达到530亿次，而数据库写和更新的操作达到2亿次。“读和查询”操作与“写和更新”的比率达到265:1。可见查询和数据库读的操作给数据库管理系统带来巨大的压力。而更为严峻的是，eBay年增长率达到50%，这意味着，来自读和查询的操作压力将持续增大，要保证数据库服务的响应能力和效率，稳定性和安全性，eBay 必须采用数据库服务器的负载均衡解决方案。

但是，由于系统庞大，出于投资保护等考虑，eBay对数据库服务器的负载均衡解决方案的需求有如下几个特点：

A. 不改变eBay的数据库体系结构

B. 可用性目标达到99.9%

C. 需承载eBay每年50%的高成长

D. 简单管理等等

这意味着在不对系统大动干戈的同时，却革命性地提高其性能，其挑战不言而喻。

2. 解决方案

针对eBay数据库服务器负载均衡的需求特点，eBay考虑了三种解决方案：

A. 将数据库垂直分割，划分成多层数据库处理，减轻原来单层数据库处理数据而形成的瓶颈与可用性问题。

问题：这种方案很难部署，而且也没有从根本上解决单点故障问题。

B. 采用Oracle OPS/RAC机群解决方案。

问题：要求给便数据库编程代码，非常难以管理与维护。

C. 采用F5与SharePlex 联合解决方案。

优点：简单管理，不需要改变整个体系结构。

在最初，eBay采用Oracle OPS/RAC解决问题。但是后来经过充分论证和探讨，最终eBay采用了基于F5/SharePlex的解决方案。

F5解决方案是应用类似OPS/RAC，但是却相对简单的解决方案，不用改变数据库体系结构，管理和维护简单得多。

F5解决方案得主要思路是：通过应用将数据库“读与查询”的操作与”写和更新”的操作导向到分开的 “逻辑” 数据库，这些数据库服务器都单独配备数据存储，而没有采用共享存储的方式。这样，F5 应用交换机动态的将所有的数据库”读与查询”请求导向到查询数据库服务器群中，并智能负载均衡到最佳的数据库服务器上。所有的”写和更新”请求都指向到一个单一的数据库服务器上，由Share Plex动态实时将数据记录复制到”读与查询”数据库服务器群的数据库中。

这样，一方面，数据库服务器群被F5应用交换机虚拟化和集群，变成了一个“池”；另一方面，“读与查询”的操作，可以根据需要，选择更高效率得数据库服务器，从而使“读与查询”的操作压力得到解决。同时，随着业务的增长，还可以随时根据客户业务的压力在线扩展新的服务器在这个群之中。

由于根据以上分析，数据库读写的比例超过260倍，采用这样的方法，有效解决了数据库性能和高可用性要求。

3. 方案特点

F5解决方案具有以下特点：

A. 运用分离读和写操作，使读和写操作进入分别的逻辑数据库 而不是共享磁盘

B. 数据库服务器均衡可以使所有的读操作交叉分配到Available Hosts，所有的写操作都指定到单一的DOR(Database-Of-Record)

C. 应用类似OPS/RAC，但是却相对简单的的解决方案

D. 发挥F5产品灵敏的量测性和显著的增强可用性。

采用F5的BIG-IP负载均衡器后，对于eBay应用系统有独到的优势：

A. 高可用性：BIG-IP动态分配每一个流量请求到后台的四台Oracle 9i Database数据库服务器，并动态检查各个服务器的健康状态，将下一个请求分配给最有效率的服务器，任何服务起死机时，BIG-IP即刻将流量请求分配给其他的三台服务器，从而达到99.999%系统有效性。特别是针对Oracle 9i 数据库服务器，F5公司专门为Oracle 9i数据库开发了专用的健康检查模块，通过调用F5专有的扩展应用校验（EAV）进程，F5能够随时得到Oracle 9i数据库的应用层服务能力而不是其他的负载均衡设备所采用的ICMP/TCP层进行健康检查。

B. 高安全性： BIG-IP支持地址翻译技术和安全地址翻译，这样一来客户不可能知道真正提供服务的服务器的IP地址与端口，从而保护数据库服务器不受到诸如SYN Flood、DOS及DDOS进攻。

C. 高效率：采用BIG-IP 负载均衡之后。BIG-IP可以智能寻找最佳状态的数据库服务器从而保证客户得到响应最快的数据库服务器以提供最佳的查询数据库服务。

D. 高可扩展性：BIG-IP可以支持动态增加或删除其负载均衡的数据库服务器群组的任何数量的服务器,而不需要对前端或后台做任何改变从而使得系统扩展轻松方便、透明。

E. 高可管理性：BIG-IP有专门的管理软件可以实时监控整个数据库服务器群组的流量状态,并分析发展趋势帮助客户及时根据流量增长增加服务器。

4. 客户价值

F5解决方案具有低成本、低维修，以及保护投资，高效率的特点，并方便在线拓展，面向未来。在2001年第二季度，F5公司与Quest公司合作成功帮助客户实现了以上解决方案，初期布署了两台”读与查询”数据库服务器和一台”写和更新”数据库服务器。在2001年第三季度成功通过了99.9%高可用性。并真正实现了在线高可扩展性，在2002年增加另外两台读与查询”数据库服务器，并于2002年第三季度增加部署了冗灾备份的功能。

F5提供的eBay数据库服务器负载均衡解决方案对行业也具有相当的借鉴意义。电子商务应用同样有着数据库查询的压力，如果能够有效将查询的压力分解到单独的服务器群来处理，将有效提高电子商务的应用效率。 对于电子商务类应用系统数据库扩展解决方案，只需要在Web Portal上将数据库请求分成两个不同模块，问题便迎刃而解。

对于公众服务行业类的数据库服务器的负载均衡，如银行，电信，税务等系统，每月和每季度的都会有报表生成汇总，这些报表既包括用户的月结单数据信息，也需要产生总体业务的业绩报告。这样就必须对数据库系统进行检索和查询。如果这些业务工作与实际生产环境是一个数据库的情况下，将造成系统的巨大压力。采用F5类似方法，同样能够有效达到高可用性预告可扩展性能的需要。

类似的文章

• 2009年08月20日 -- 关于VS2008与一些数据源配置的问题 (0)
• 2009年07月24日 -- 数据库中的一些概念——集群技术及数据仓库 (0)
• 2009年07月9日 -- Oracle 最近的一些记录 (0)