The important thing in life is to have a great aim , and the determination

Oracle数据库分区表操作方法(4)

1.3. 分区表索引的使用：

　　分区表和一般表一样可以建立索引，分区表可以创建局部索引和全局索引。当分区中出现许多事务并且要保证所有分区中的数据记录的唯一性时采用全局索引。

　　 1.3.1. 局部索引分区的建立：

以下为引用的内容：
SQL> create index dinya_idx_t on dinya_test(item_id)
2 local
3 (
4 partition idx_1 tablespace dinya_space01,
5 partition idx_2 tablespace dinya_space02,
6 partition idx_3 tablespace dinya_space03
7 );
Index created.
SQL>

　　看查询的执行计划，从下面的执行计划可以看出，系统已经使用了索引：

以下为引用的内容：
SQL> select * from dinya_test partition(part_01) t where t.item_id=12;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=187)
1 0 TABLE ACCESS (BY LOCAL INDEX ROWID) OF ’DINYA_TEST’ (Cost=
2 Card=1 Bytes=187)
2 1 INDEX (RANGE SCAN) OF ’DINYA_IDX_T’ (NON-UNIQUE) (Cost=1
Card=1)
Statistics
----------------------------------------------------------
0 recursive calls
0 db block gets
4 consistent gets
0 physical reads
0 redo size
334 bytes sent via SQL*Net to client
309 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client

1 sorts (memory)
0 sorts (disk)
2 rows processed
SQL>

　　 1.3.2. 全局索引分区的建立

　　全局索引建立时global 子句允许指定索引的范围值，这个范围值为索引字段的范围值：

以下为引用的内容：
SQL> create index dinya_idx_t on dinya_test(item_id)
2 global partition by range(item_id)
3 (
4 partition idx_1 values less than (1000) tablespace dinya_space01,
5 partition idx_2 values less than (10000) tablespace dinya_space02,
6 partition idx_3 values less than (maxvalue) tablespace dinya_space03
7 );
Index created.
SQL>

　　本例中对表的item_id字段建立索引分区，当然也可以不指定索引分区名直接对整个表建立索引，如：

以下为引用的内容：
SQL> create index dinya_idx_t on dinya_test(item_id);
Index created.
SQL>

　　同样的，对全局索引根据执行计划可以看出索引已经可以使用：

以下为引用的内容：
SQL> select * from dinya_test t where t.item_id=12;
Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=3 Bytes=561)
1 0 TABLE ACCESS (BY GLOBAL INDEX ROWID) OF ’DINYA_TEST’ (Cost
=2 Card=3 Bytes=561)
2 1 INDEX (RANGE SCAN) OF ’DINYA_IDX_T’ (NON-UNIQUE) (Cost=1
Card=3)
Statistics
----------------------------------------------------------
5 recursive calls
0 db block gets
10 consistent gets
0 physical reads

0 redo size
420 bytes sent via SQL*Net to client
309 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
3 sorts (memory)
0 sorts (disk)
5 rows processed
SQL>

posted @ 2011-12-12 22:57 鸿雁阅读(313) | 评论 (0) | 编辑收藏

Oracle数据库分区表操作方法(5)

1.4. 分区表的维护：

　　了解了分区表的建立、索引的建立、表和索引的使用后，在应用的还要经常对分区进行维护和管理。日常维护和管理的内容包括：增加一个分区，合并一个分区及删除分区等等。下面以范围分区为例说明增加、合并、删除分区的一般操作：

　　 1.4.1. 增加一个分区:

以下为引用的内容：
SQL> alter table dinya_test
2 add partition part_04 values less than(to_date(’2012-01-01’,’yyyy-mm-dd’))
tablespace dinya_spa
ce03;
Table altered.
SQL>

　　增加一个分区的时候，增加的分区的条件必须大于现有分区的最大值，否则系统将提示ORA-14074 partition bound must collate higher than that of the last partition 错误。

　　 1.4.2. 合并一个分区：

以下为引用的内容：
SQL> alter table dinya_test merge partitions part_01,part_02 into partition part_02;
Table altered.
SQL>

　　在本例中将原有的表的part_01分区和part_02分区进行了合并，合并后的分区为part_02,如果在合并的时候把合并后的分区定为part_01的时候，系统将提示ORA-14275 cannot reuse lower-bound partition as resulting partition 错误。

　　 1.4.3. 删除分区：

以下为引用的内容：
SQL> alter table dinya_test drop partition part_01;
Table altered.
SQL>

　　删除分区表的一个分区后，查询该表的数据时显示，该分区中的数据已全部丢失，所以执行删除分区动作时要慎重，确保先备份数据后再执行，或将分区合并。

　　1.5. 总结：

　　需要说明的是，本文在举例说名分区表事务操作的时候，都指定了分区，因为指定了分区，系统在执行的时候则只操作该分区的记录，提高了数据处理的速度。不要指定分区直接操作数据也是可以的。在分区表上建索引及多索引的使用和非分区表一样。此外，因为在维护分区的时候可能对分区的索引会产生一定的影响，可能需要在维护之后重建索引，相关内容请参考分区表索引部分的文档

posted @ 2011-12-12 22:57 鸿雁阅读(307) | 评论 (0) | 编辑收藏

Oracle数据库分区表操作方法(3)

1.2. 分区表操作

　　以上了解了三种分区表的建表方法，下面将使用实际的数据并针对按日期的范围分区来测试分区表的数据记录的操作。

　　 1.2.1. 插入记录：

以下为引用的内容：
SQL> insert into dinya_test values(1,12,’BOOKS’,sysdate);
1 row created.
SQL> insert into dinya_test values(2,12, ’BOOKS’,sysdate+30);
1 row created.

SQL> insert into dinya_test values(3,12, ’BOOKS’,to_date(’2006-05-30’,’yyyy-mm-dd’));
1 row created.
SQL> insert into dinya_test values(4,12, ’BOOKS’,to_date(’2007-06-23’,’yyyy-mm-dd’));
1 row created.
SQL> insert into dinya_test values(5,12, ’BOOKS’,to_date(’2011-02-26’,’yyyy-mm-dd’));
1 row created.
SQL> insert into dinya_test values(6,12, ’BOOKS’,to_date(’2011-04-30’,’yyyy-mm-dd’));
1 row created.
SQL> commit;
Commit complete.
SQL>
　　按上面的建表结果，2006年前的数据将存储在第一个分区part_01上，而2006年到2010年的交易数据将存储在第二个分区part_02上，2010年以后的记录存储在第三个分区part_03上。

　　 1.2.2. 查询分区表记录：

以下为引用的内容：
SQL> select * from dinya_test partition(part_01);
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
1 12 BOOKS 2005-1-14 14:19:
2 12 BOOKS 2005-2-13 14:19:
SQL>
SQL> select * from dinya_test partition(part_02);
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
3 12 BOOKS 2006-5-30
4 12 BOOKS 2007-6-23
SQL>
SQL> select * from dinya_test partition(part_03);
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
--------------------------------------------------------------------------------
5 12 BOOKS 2011-2-26
6 12 BOOKS 2011-4-30
SQL>

　　从查询的结果可以看出，插入的数据已经根据交易时间范围存储在不同的分区中。这里是指定了分区的查询，当然也可以不指定分区，直接执行select * from dinya_test查询全部记录。

　　在也检索的数据量很大的时候，指定分区会大大提高检索速度。

　　 1.2.3. 更新分区表的记录：

以下为引用的内容：
SQL> update dinya_test partition(part_01) t set t.item_description=’DESK’ where
t.transaction_id=1;
1 row updated.
SQL> commit;
Commit complete.
SQL>

　　这里将第一个分区中的交易ID=1的记录中的item_description字段更新为“DESK”，可以看到已经成功更新了一条记录。但是当更新的时候指定了分区，而根据查询的记录不在该分区中时，将不会更新数据，请看下面的例子：

以下为引用的内容：
SQL> update dinya_test partition(part_01) t set t.item_description=’DESK’ where
t.transaction_id=6;
0 rows updated.
SQL> commit;
Commit complete.
SQL>

　　指定了在第一个分区中更新记录，但是条件中限制交易ID为6，而查询全表，交易ID为6的记录在第三个分区中，这样该条语句将不会更新记录。

　　 1.2.4. 删除分区表记录：

以下为引用的内容：
SQL> delete from dinya_test partition(part_02) t where t.transaction_id=4;
1 row deleted.
SQL> commit;
Commit complete.
SQL>

　　上面例子删除了第二个分区part_02中的交易记录ID为4的一条记录，和更新数据相同，如果指定了分区，而条件中的数据又不在该分区中时，将不会删除任何数据。

posted @ 2011-12-12 22:56 鸿雁阅读(506) | 评论 (0) | 编辑收藏

Oracle数据库分区表操作方法（一）

摘要：在大量业务数据处理的项目中，可以考虑使用分区表来提高应用系统的性能并方便数据管理，本文详细介绍了分区表的使用。

　　在大型的企业应用或企业级的数据库应用中，要处理的数据量通常可以达到几十到几百GB，有的甚至可以到TB级。虽然存储介质和数据处理技术的发展也很快，但是仍然不能满足用户的需求，为了使用户的大量的数据在读写操作和查询中速度更快，Oracle提供了对表和索引进行分区的技术，以改善大型应用系统的性能。

　　使用分区的优点：

　　 ·增强可用性：如果表的某个分区出现故障，表在其他分区的数据仍然可用；

　　 ·维护方便：如果表的某个分区出现故障，需要修复数据，只修复该分区即可；

　　 ·均衡I/O：可以把不同的分区映射到磁盘以平衡I/O，改善整个系统性能；

　　 ·改善查询性能：对分区对象的查询可以仅搜索自己关心的分区，提高检索速度。

　　 Oracle数据库提供对表或索引的分区方法有三种：

　　 ·范围分区

　　 ·Hash分区（散列分区）

　　 ·复合分区

　　下面将以实例的方式分别对这三种分区方法来说明分区表的使用。为了测试方便，我们先建三个表空间。

以下为引用的内容：
create tablespace dinya_space01
datafile ’/test/demo/oracle/demodata/dinya01.dnf’ size 50M
create tablespace dinya_space01
datafile ’/test/demo/oracle/demodata/dinya02.dnf’ size 50M
create tablespace dinya_space01
datafile ’/test/demo/oracle/demodata/dinya03.dnf’ size 50M

　　1.1. 分区表的创建

　　 1.1.1. 范围分区

　　范围分区就是对数据表中的某个值的范围进行分区，根据某个值的范围，决定将该数据存储在哪个分区上。如根据序号分区，根据业务记录的创建日期进行分区等。

　　需求描述：有一个物料交易表，表名：material_transactions。该表将来可能有千万级的数据记录数。要求在建该表的时候使用分区表。这时候我们可以使用序号分区三个区，每个区中预计存储三千万的数据，也可以使用日期分区，如每五年的数据存储在一个分区上。

　　根据交易记录的序号分区建表：

以下为引用的内容：
SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date not null
7 )
8 partition by range (transaction_id)
9 (
10 partition part_01 values less than(30000000) tablespace dinya_space01,
11 partition part_02 values less than(60000000) tablespace dinya_space02,
12 partition part_03 values less than(maxvalue) tablespace dinya_space03
13 );
Table created.

　　　建表成功，根据交易的序号，交易ID在三千万以下的记录将存储在第一个表空间dinya_space01中，分区名为:par_01，在三千万到六千万之间的记录存储在第二个表空间：

　　 dinya_space02中，分区名为：par_02，而交易ID在六千万以上的记录存储在第三个表空间dinya_space03中，分区名为par_03.

　　根据交易日期分区建表：

以下为引用的内容：
SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,

5 item_description varchar2(300),
6 transaction_date date not null
7 )
8 partition by range (transaction_date)
9 (
10 partition part_01 values less than(to_date(’2006-01-01’,’yyyy-mm-dd’))
tablespace dinya_space01,
11 partition part_02 values less than(to_date(’2010-01-01’,’yyyy-mm-dd’))
tablespace dinya_space02,
12 partition part_03 values less than(maxvalue) tablespace dinya_space03
13 );
Table created.

　　这样我们就分别建了以交易序号和交易日期来分区的分区表。每次插入数据的时候，系统将根据指定的字段的值来自动将记录存储到制定的分区（表空间）中。

　　当然，我们还可以根据需求，使用两个字段的范围分布来分区，如partition by range ( transaction_id ,transaction_date), 分区条件中的值也做相应的改变，请读者自行测试。

posted @ 2011-12-12 22:55 鸿雁阅读(281) | 评论 (0) | 编辑收藏

Oracle数据库分区表操作方法（二）

1.1.2. Hash分区（散列分区）

　　散列分区为通过指定分区编号来均匀分布数据的一种分区类型，因为通过在I/O设备上进行散列分区，使得这些分区大小一致。如将物料交易表的数据根据交易ID散列地存放在指定的三个表空间中：

以下为引用的内容：
SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date
7 )
8 partition by hash(transaction_id)
9 (
10 partition part_01 tablespace dinya_space01,
11 partition part_02 tablespace dinya_space02,
12 partition part_03 tablespace dinya_space03
13 );
Table created.

　　建表成功，此时插入数据，系统将按transaction_id将记录散列地插入三个分区中，这里也就是三个不同的表空间中。

　　 1.1.3. 复合分区

　　有时候我们需要根据范围分区后，每个分区内的数据再散列地分布在几个表空间中，这样我们就要使用复合分区。复合分区是先使用范围分区，然后在每个分区内再使用散列分区的一种分区方法，如将物料交易的记录按时间分区，然后每个分区中的数据分三个子分区，将数据散列地存储在三个指定的表空间中：

以下为引用的内容：
SQL> create table dinya_test
2 (
3 transaction_id number primary key,
4 item_id number(8) not null,
5 item_description varchar2(300),
6 transaction_date date
7 )
8 partition by range(transaction_date)subpartition by hash(transaction_id)
9 subpartitions 3 store in (dinya_space01,dinya_space02,dinya_space03)
10 (
11 partition part_01 values less than(to_date(’2006-01-01’,’yyyy-mm-dd’)),
12 partition part_02 values less than(to_date(’2010-01-01’,’yyyy-mm-dd’)),
13 partition part_03 values less than(maxvalue)
14 );
Table created.

　　该例中，先是根据交易日期进行范围分区，然后根据交易的ID将记录散列地存储在三个表空间中。

posted @ 2011-12-12 22:55 鸿雁阅读(236) | 评论 (0) | 编辑收藏

Hibernate继承映射(Inheritance Mappings)

三种策略

Hibernate支持三种基本的继承映射策略：

每个类分层结构一张表(table per class hierarchy)
每个子类一张表(table per subclass)
每个具体类一张表(table per concrete class)

此外，Hibernate还支持第四种稍有不同的多态映射策略：

隐式多态(implicit polymorphism)

对于同一个继承层次内的不同分支，可以采用不同的映射策略，然后用隐式多态来完成跨越整个层次的多态。但是在同一个<class>根元素下，Hibernate不支持混合了元素<subclass>、 <joined-subclass>和<union-subclass> 的映射。在同一个<class>元素下，可以混合使用 “每个类分层结构一张表”（table per hierarchy）和“每个子类一张表”（table per subclass）这两种映射策略，这是通过结合元素<subclass>和 <join>来实现的（见后）。

在多个映射文件中，可以直接在hibernate-mapping根下定义subclass，union-subclass和joined-subclass。也就是说，你可以仅加入一个新的映射文件来扩展类层次。你必须在subclass的映射中指明extends属性，给出一个之前定义的超类的名字。注意，在以前，这一功能对映射文件的顺序有严格的要求，从Hibernate 3开始，使用extends关键字的时侯，对映射文件的顺序不再有要求；但在每个映射文件里，超类必须在子类之前定义。

 <hibernate-mapping>
     <subclass name="DomesticCat" extends="Cat" discriminator-value="D">
          <property name="name" type="string"/>
     </subclass>
 </hibernate-mapping>

9.1.1. 每个类分层结构一张表(Table per class hierarchy)

假设我们有接口Payment和它的几个实现类： CreditCardPayment, CashPayment, 和ChequePayment。则“每个类分层结构一张表”(Table per class hierarchy)的映射代码如下所示：

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        ...
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        ...
    </subclass>
</class>

采用这种策略只需要一张表即可。它有一个很大的限制：要求那些由子类定义的字段，如CCTYPE，不能有非空(NOT NULL)约束。

9.1.2. 每个子类一张表(Table per subclass)

对于上例中的几个类而言，采用“每个子类一张表”的映射策略，代码如下所示：

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="AMOUNT"/>
    ...
    <joined-subclass name="CreditCardPayment" table="CREDIT_PAYMENT">
        <key column="PAYMENT_ID"/>
        ...
    </joined-subclass>
    <joined-subclass name="CashPayment" table="CASH_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </joined-subclass>
    <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        <key column="PAYMENT_ID"/>
        ...
    </joined-subclass>
</class>

需要四张表。三个子类表通过主键关联到超类表(因而关系模型实际上是一对一关联)。

9.1.3. 每个子类一张表(Table per subclass)，使用辨别标志(Discriminator)

注意，对“每个子类一张表”的映射策略，Hibernate的实现不需要辨别字段，而其他的对象/关系映射工具使用了一种不同于Hibernate的实现方法，该方法要求在超类表中有一个类型辨别字段(type discriminator column)。Hibernate采用的方法更难实现，但从关系（数据库）的角度来看，按理说它更正确。若你愿意使用带有辨别字段的“每个子类一张表”的策略，你可以结合使用<subclass> 与<join>，如下所示：

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <join table="CREDIT_PAYMENT">
            <key column="PAYMENT_ID"/>
            <property name="creditCardType" column="CCTYPE"/>
            ...
        </join>
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        <join table="CASH_PAYMENT">
            <key column="PAYMENT_ID"/>
            ...
        </join>
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        <join table="CHEQUE_PAYMENT" fetch="select">
            <key column="PAYMENT_ID"/>
            ...
        </join>
    </subclass>
</class>

可选的声明fetch="select"，是用来告诉Hibernate，在查询超类时，不要使用外部连接(outer join)来抓取子类ChequePayment的数据。

9.1.4. 混合使用“每个类分层结构一张表”和“每个子类一张表”

你甚至可以采取如下方法混和使用“每个类分层结构一张表”和“每个子类一张表”这两种策略：

<class name="Payment" table="PAYMENT">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="PAYMENT_TYPE" type="string"/>
    <property name="amount" column="AMOUNT"/>
    ...
    <subclass name="CreditCardPayment" discriminator-value="CREDIT">
        <join table="CREDIT_PAYMENT">
            <property name="creditCardType" column="CCTYPE"/>
            ...
        </join>
    </subclass>
    <subclass name="CashPayment" discriminator-value="CASH">
        ...
    </subclass>
    <subclass name="ChequePayment" discriminator-value="CHEQUE">
        ...
    </subclass>
</class>

对上述任何一种映射策略而言，指向根类Payment的关联是使用<many-to-one>进行映射的。

<many-to-one name="payment" column="PAYMENT_ID" class="Payment"/>

9.1.5. 每个具体类一张表(Table per concrete class)

对于“每个具体类一张表”的映射策略，可以采用两种方法。第一种方法是使用 <union-subclass>。

<class name="Payment">
    <id name="id" type="long" column="PAYMENT_ID">
        <generator class="sequence"/>
    </id>
    <property name="amount" column="AMOUNT"/>
    ...
    <union-subclass name="CreditCardPayment" table="CREDIT_PAYMENT">
        <property name="creditCardType" column="CCTYPE"/>
        ...
    </union-subclass>
    <union-subclass name="CashPayment" table="CASH_PAYMENT">
        ...
    </union-subclass>
    <union-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        ...
    </union-subclass>
</class>

这里涉及三张与子类相关的表。每张表为对应类的所有属性（包括从超类继承的属性）定义相应字段。

这种方式的局限在于，如果一个属性在超类中做了映射，其字段名必须与所有子类表中定义的相同。(我们可能会在Hibernate的后续发布版本中放宽此限制。) 不允许在联合子类(union subclass)的继承层次中使用标识生成器策略(identity generator strategy), 实际上, 主键的种子(primary key seed)不得不为同一继承层次中的全部被联合子类所共用.

假若超类是抽象类，请使用abstract="true"。当然，假若它不是抽象的，需要一个额外的表（上面的例子中，默认是PAYMENT），来保存超类的实例。

9.1.6. Table per concrete class, using implicit polymorphism

另一种可供选择的方法是采用隐式多态：

<class name="CreditCardPayment" table="CREDIT_PAYMENT">
    <id name="id" type="long" column="CREDIT_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CREDIT_AMOUNT"/>
    ...
</class>

<class name="CashPayment" table="CASH_PAYMENT">
    <id name="id" type="long" column="CASH_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CASH_AMOUNT"/>
    ...
</class>

<class name="ChequePayment" table="CHEQUE_PAYMENT">
    <id name="id" type="long" column="CHEQUE_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <property name="amount" column="CHEQUE_AMOUNT"/>
    ...
</class>

注意，我们没有在任何地方明确的提及接口Payment。同时注意 Payment的属性在每个子类中都进行了映射。如果你想避免重复，可以考虑使用XML实体(例如：位于DOCTYPE声明内的 [ <!ENTITY allproperties SYSTEM "allproperties.xml"> ] 和映射中的&allproperties;)。

这种方法的缺陷在于，在Hibernate执行多态查询时(polymorphic queries)无法生成带 UNION的SQL语句。

对于这种映射策略而言，通常用<any>来实现到 Payment的多态关联映射。

<any name="payment" meta-type="string" id-type="long">
    <meta-value value="CREDIT" class="CreditCardPayment"/>
    <meta-value value="CASH" class="CashPayment"/>
    <meta-value value="CHEQUE" class="ChequePayment"/>
    <column name="PAYMENT_CLASS"/>
    <column name="PAYMENT_ID"/>
</any>

9.1.7. 隐式多态和其他继承映射混合使用

对这一映射还有一点需要注意。因为每个子类都在各自独立的元素<class> 中映射(并且Payment只是一个接口)，每个子类可以很容易的成为另一个继承体系中的一部分！(你仍然可以对接口Payment使用多态查询。)

<class name="CreditCardPayment" table="CREDIT_PAYMENT">
    <id name="id" type="long" column="CREDIT_PAYMENT_ID">
        <generator class="native"/>
    </id>
    <discriminator column="CREDIT_CARD" type="string"/>
    <property name="amount" column="CREDIT_AMOUNT"/>
    ...
    <subclass name="MasterCardPayment" discriminator-value="MDC"/>
    <subclass name="VisaPayment" discriminator-value="VISA"/>
</class>

<class name="NonelectronicTransaction" table="NONELECTRONIC_TXN">
    <id name="id" type="long" column="TXN_ID">
        <generator class="native"/>
    </id>
    ...
    <joined-subclass name="CashPayment" table="CASH_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="amount" column="CASH_AMOUNT"/>
        ...
    </joined-subclass>
    <joined-subclass name="ChequePayment" table="CHEQUE_PAYMENT">
        <key column="PAYMENT_ID"/>
        <property name="amount" column="CHEQUE_AMOUNT"/>
        ...
    </joined-subclass>
</class>

我们还是没有明确的提到Payment。如果我们针对接口Payment执行查询 ——如from Payment—— Hibernate 自动返回CreditCardPayment(和它的子类，因为它们也实现了接口Payment)、 CashPayment和Chequepayment的实例，但不返回NonelectronicTransaction的实例。

posted @ 2011-11-26 23:52 鸿雁阅读(811) | 评论 (0) | 编辑收藏

JVM优化配置

JVM优化配置《一》

OOM这个缩写就是Java程序开发过程中让人最头痛的问题：Out of Memory。在很多开发人员的开发过程中，或多或少的都会遇到这类问题，这类问题定位比较困难，往往需要根据经验来判断可能出现问题的代码。原因主要是两个：对象没有被释放（多种情况引起，往往是比较隐蔽的引用导致被Hold而无法被回收）。另一种就是真的Memory不够用了，需要增加JVM的 Heap来满足应用程序的需求。最近有同事发的关于解决OOM的问题，让我了解了原来OOM除了在JVM Heap不够时会发生，在Native Heap不够的时候也会发生，同时JVM Heap和Native Heap存在着相互影响和平衡的关系，因此就仔细的去看了关于OOM和JVM配置优化的内容。

OOM

在其他语言类似于C,Delphi等等由于内存都是由自己分配和管理，因此内存泄露的问题比较常见，同时也是很头痛的一件事情。而Java的对象生命周期管理都是JVM来做的，简化了开发人员的非业务逻辑的处理，但是这种自动管理回收机制也是基于一些规则的，而违背了这些规则的时候，就会造成所谓的 “Memory Leak”。

OOM(Java Heap)

错误提示：java.lang.OutOfMemoryError。

这类OOM是由于JVM分配的给应用的Heap Memory已经被耗尽，可能是因为应用在高负荷的情况下的却需要很大的内存，因此可以通过修改JVM参数来增加Java Heap Memory（不过也不能无限制增加，后面那种OOM有可能就是因为这个原因而产生）。另一种情况是因为应用程序使用对象或者资源没有释放，导致内存消耗持续增加，最后出现OOM，这类问题引起的原因往往是应用已不需要的对象还被其他有效对象所引用，那么就无法释放，可能是业务代码逻辑造成的（异常处理不够例如IO等资源），也可能是对于第三方开源项目中资源释放了解不够导致使用以后资源没有释放（例如JDBC的ResultSet等）。

几个容易出现问题的场景：

1．应用的缓存或者Collection：如果应用要缓存Java对象或者是在一个Collection中保存对象，那么就要确定是否会有大量的对象存入，要做保护，以防止在大数据量下大量内存被消耗，同时要保证Cache的大小不会无限制增加。

2．生命周期较长的对象：尽量简短对象的生命周期，现在采用对象的创建释放代价已经很低，同时作了很好的优化，要比创建一个对象长期反复使用要好。如果能够设置超时的情景下，尽量设置超时。

3．类似于JDBC的Connection Pool，在使用Pool中的对象以后需要释放并返回，不然就会造成Pool的不断增大，在其他Pool中使用也是一样。同样ResultSet，IO这类资源的释放都需要注意。

解决的方法就是查找错误或者是增加Java Heap Memory。对于此类问题检测工具相当多，这里就不做介绍了。

OOM(Native Heap)

错误提示：requested XXXX bytes for ChunkPool::allocate. Out of swap space。

Native Heap Memory是JVM 内部使用的Memory，这部分的Memory可以通过JDK提供的JNI的方式去访问，这部分Memory效率很高，但是管理需要自己去做，如果没有把握最好不要使用，以防出现内存泄露问题。JVM 使用Native Heap Memory用来优化代码载入（JTI代码生成），临时对象空间申请，以及JVM内部的一些操作。这次同事在压力测试中遇到的问题就是这类OOM，也就是这类Memory耗尽。同样这类OOM产生的问题也是分成正常使用耗尽和无释放资源耗尽两类。无释放资源耗尽很多时候不是程序员自身的原因，可能是引用的第三方包的缺陷，例如很多人遇到的Oracle 9 JDBC驱动在低版本中有内存泄露的问题。要确定这类问题，就需要去观察Native Heap Memory的增长和使用情况，在服务器应用起来以后，运行一段时间后JVM对于Native Heap Memory的使用会达到一个稳定的阶段，此时可以看看什么操作对于Native Heap Memory操作频繁，而且使得Native Heap Memory增长，对于Native Heap Memory的情况我还没有找到办法去检测，现在能够看到的就是为JVM启动时候增加-verbose:jni参数来观察对于Native Heap Memory的操作。另一种情况就是正常消耗Native Heap Memory，对于Native Heap Memory的使用主要取决于JVM代码生成，线程创建，用于优化的临时代码和对象产生。当正常耗尽Native Heap Memory时，那么就需要增加Native Heap Memory，此时就会和我们前面提到增加java Heap Memory的情况出现矛盾。

应用内存组合

对于应用来说，可分配的内存受到OS的限制，不同的OS对进程所能访问虚拟内存地址区间直接影响对于应用内存的分配，32位的操作系统通常最大支持4G的内存寻址，而Linux一般为3G，Windows为2G。然而这些大小的内存并不会全部给JVM的Java Heap使用，它主要会分成三部分：Java Heap，Native Heap，载入资源和类库等所占用的内存。那么由此可见，Native Heap和 Java Heap大小配置是相互制约的，哪一部分分配多了都可能会影响到另外一部分的正常工作，因此如果通过命令行去配置，那么需要确切的了解应用使用情况，否则采用默认配置自动监测会更好的优化应用使用情况。

同样要注意的就是进程的虚拟内存和机器的实际内存还是有区别的，对于机器来说实际内存以及硬盘提供的虚拟内存都是提供给机器上所有进程使用的，因此在设置JVM参数时，它的虚拟内存绝对不应该超过实际内存的大小。
《二》

这里首先要说明的是这里提到的JVM是Sun的HotSpot JVM 5和以上的版本。性能优化在应用方面可以有很多手段，包括Cache，多线程，各种算法等等。通常情况下是不建议在没有任何统计和分析的情况下去手动配置 JVM的参数来调整性能，因为在JVM 5以上已经作了根据机器和OS的情况自动配置合适参数的算法，基本能够满足大部分的情况，当然这种自动适配只是一种通用的方式，如果说真的要达到最优，那么还是需要根据实际的使用情况来手动的配置各种参数设置，提高性能。

JVM能够对性能产生影响的最大部分就是对于内存的管理。从jdk 1.5以后内存管理和分配有了很多的改善和提高。

内存分配以及管理的几个基本概念和参数说明：

Java Hotspot Mode：

server 和 client两种模式，如果不配置，JVM会根据应用服务器硬件配置自动选择模式，server模式启动比较慢，但是运行期速度得到了优化，client启动比较快，但是运行期响应没有server模式的优化，适合于个人PC的服务开发和测试。

Garbage Collector Policy：

在Jdk 1.5的时候已经提供了三种GC，除了原来提供的串行GC（SerialGC）以外，还提供了两种新的GC：ParallelGC和 ConcMarkSweepGC。ParallelGC采用了多线程并行管理和回收垃圾对象，提高了回收效率，提高了服务器的吞吐量，适合于多处理器的服务器。ConcMarkSweepGC采用的是并发方式来管理和回收垃圾对象，降低垃圾回收产生的响应暂停时间。这里说一下并发和并行的区别，并发指的是多个进程并行执行垃圾回收，那么可以很好的利用多处理器，而并行指的是应用程序不需要暂停可以和垃圾回收线程并发工作。串行GC适合小型应用和单处理器系统（无需多线程交互，效率比较高），后两者适合大型系统。

使用方式就是在参数配置中增加-XX:+UseParallelGC等方式来设置。

对于这部分的配置在网上有很多的实例可以参考，不过最终采用哪一种GC还是要根据具体的情况来分析和选择。

Heap：

OOM的各种经历已经让每一个架构师开发人员看到了了解Heap的重要性。OOM已经是Heap的临界点，不得不引起注意，然而Heap对于性能的潜在影响并未被引起重视，不过和GC配置一样，在没有对使用情况作仔细分析和研究的情况下，贸然的去修改Heap配置，可能适得其反，这里就来看一下Heap的一些概念和对于性能的影响。

我们的应用所能够得到的最大的Heap受三部分因素的制约：数据处理模型（32位或者64位操作系统），系统地虚拟内存总数和系统的物理内存总数。首先Heap的大小不能超过不同操作系统的进程寻址范围，当前大部分系统最高限度是4G，Windows通常是2G，Linux通常是3G。系统的虚拟内存也是分配的依据，首先是不能超过，然后由于操作系统支持硬盘来做部分的虚拟内存，如果设置过大，那么对于应用响应来说势必有影响。再则就是要考虑同一台服务器上运行多个Java虚拟机所消耗的资源总合也不能超过可用资源。就和前面OOM分析中的一样，其实由于OS的数据处理模型的限制，机器本身的硬件内存资源和虚拟内存资源并不一定会匹配，那么在有限的资源下如何调整好资源分配，对于应用来说尤为重要。

关于Heap的几个参数设置：

说了Heap的有限资源问题以后，就来看看如何通过配置去改变JVM对于Heap的分配。下面所说的主要是对于Java Heap的分配，那么在申请了Java Heap以后，剩下的可用资源就会被使用到Native Heap。

Xms: java heap初始化时的大小。默认情况是机器物理内存的1/64。这个主要是根据应用启动时消耗的资源决定，分配少了申请起来会降低启动速度，分配多了也浪费。

Xmx:java heap的最大值，默认是机器物理内存的1/4，最大也就到1G。这个值决定了最多可用的Java Heap Memory，分配过少就会在应用需要大量内存作缓存或者零时对象时出现OOM的问题，如果分配过大，那么就会产生上文提到的第二类OOM。所以如何配置还是根据运行过程中的分析和计算来确定，如果不能确定还是采用默认的配置。

Xmn:java heap新生代的空间大小。在GC模型中，根据对象的生命周期的长短，产生了内存分代的设计：青年代（内部也分成三部分，类似于整体划分的作用，可以通过配置来设置比例），老年代，持久代。每一代的管理和回收策略都不相同，最为活跃的就是青年代，同时这部分的内存分配和管理效率也是最高。通常情况下，对于内存的申请优先在新生代中申请，当内存不够时会整理新生代，当整理以后还是不能满足申请的内存，就会向老年代移动一些生命周期较长的对象。这种整理和移动会消耗资源，同时降低系统运行响应能力，因此如果青年代设置的过小，就会频繁的整理和移动，对性能造成影响。那是否把年青代设置的越大越好，其实不然，年青代采用的是复制搜集算法，这种算法必须停止所有应用程序线程，服务器线程切换时间就会成为应用响应的瓶颈（当然永远不用收集那么就不存在这个问题）。老年代采用的是串行标记收集的方式，并发收集可以减少对于应用的影响。

Xss:线程堆栈最大值。允许更多的虚拟内存空间地址被Java Heap使用。

以下是sun公司的性能优化白皮书中提到的几个例子：

1．对于吞吐量的调优。机器配置：4G的内存，32个线程并发能力。

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

-Xmx3800m -Xms3800m 配置了最大Java Heap来充分利用系统内存。

-Xmn2g

创建足够大的青年代（可以并行被回收）充分利用系统内存，防止将短期对象复制到老年代。

-Xss128 减少默认最大的线程栈大小，提供更多的处理虚拟内存地址空间被进程使用。

-XX:+UseParallelGC 采用并行垃圾收集器对年青代的内存进行收集，提高效率。

-XX:ParallelGCThreads=20

减少垃圾收集线程，默认是和服务器可支持的线程最大并发数相同，往往不需要配置到最大值。

2．尝试采用对老年代并行收集

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-Xmx3550m -Xms3550m

内存分配被减小，因为ParallelOldGC会增加对于Native Heap的需求，因此需要减小Java Heap来满足需求。

-XX:+UseParallelOldGC 采用对于老年代并发收集的策略，可以提高收集效率。

3．提高吞吐量，减少应用停顿时间

java

 -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

选择了并发标记交换收集器，它可以并发执行收集操作，降低应用停止时间，同时它也是并行处理模式，可以有效地利用多处理器的系统的多进程处理。

-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31

表示在青年代中Eden和Survivor比例，设置增加了Survivor的大小，越大的survivor空间可以允许短期对象尽量在年青代消亡。

-XX:TargetSurvivorRatio=90 允许90%的空间被占用，超过默认的50%，提高对于survivor的使用率。

类似的例子网上很多，这儿就不在列下来了，最终是否采取自己配置来替换默认配置还是要根据虚拟机的使用情况来分析和配置。

posted @ 2011-10-27 19:32 鸿雁阅读(271) | 评论 (0) | 编辑收藏

Spring事务配置的五种方式

Spring配置文件中关于事务配置总是由三个组成部分，分别是DataSource、TransactionManager和代理机制这三部分，无论哪种配置方式，一般变化的只是代理机制这部分。

DataSource、TransactionManager这两部分只是会根据数据访问方式有所变化，比如使用Hibernate进行数据访问时，DataSource实际为SessionFactory，TransactionManager的实现为HibernateTransactionManager。

具体如下图：

根据代理机制的不同，总结了五种Spring事务的配置方式，配置文件如下：

第一种方式：每个Bean都有一个代理

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
    xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
    xmlns:context=”http://www.springframework.org/schema/context”
    xmlns:aop=”http://www.springframework.org/schema/aop”
    xsi:schemaLocation=”http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd”>

    <!– 定义事务管理器（声明式的事务） –>
    <bean id=”transactionManager”
        class=”org.springframework.orm.hibernate3.HibernateTransactionManager”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>

    <!– 配置DAO –>
    <bean id=”userDaoTarget” class=”com.bluesky.spring.dao.UserDaoImpl”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>

    <bean id=”userDao”
        class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”>
           <!– 配置事务管理器 –>
           <property name=”transactionManager” ref=”transactionManager” />
        <property name=”target” ref=”userDaoTarget” />
         <property name=”proxyInterfaces” value=”com.bluesky.spring.dao.GeneratorDao” />
        <!– 配置事务属性 –>
        <property name=”transactionAttributes”>
            <props>
                <prop key=”*”>PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    </bean>
</beans>

第二种方式：所有Bean共享一个代理基类

    <!– 定义事务管理器（声明式的事务） –>
    <bean id=”transactionManager”
        class=”org.springframework.orm.hibernate3.HibernateTransactionManager”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>

    <bean id=”transactionBase”
            class=”org.springframework.transaction.interceptor.TransactionProxyFactoryBean”
            lazy-init=”true” abstract=”true”>
        <!– 配置事务管理器 –>
        <property name=”transactionManager” ref=”transactionManager” />
        <!– 配置事务属性 –>
        <property name=”transactionAttributes”>
            <props>
                <prop key=”*”>PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    </bean>

    <!– 配置DAO –>
    <bean id=”userDaoTarget” class=”com.bluesky.spring.dao.UserDaoImpl”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>

    <bean id=”userDao” parent=”transactionBase” >
        <property name=”target” ref=”userDaoTarget” />
    </bean>
</beans>

第三种方式：使用拦截器

    <!– 定义事务管理器（声明式的事务） –>
    <bean id=”transactionManager”
        class=”org.springframework.orm.hibernate3.HibernateTransactionManager”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>

    <bean id=”transactionInterceptor”
        class=”org.springframework.transaction.interceptor.TransactionInterceptor”>
        <property name=”transactionManager” ref=”transactionManager” />
        <!– 配置事务属性 –>
        <property name=”transactionAttributes”>
            <props>
                <prop key=”*”>PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    </bean>

    <bean class=”org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator”>
        <property name=”beanNames”>
            <list>
                <value>*Dao</value>
            </list>
        </property>
        <property name=”interceptorNames”>
            <list>
                <value>transactionInterceptor</value>
            </list>
        </property>
    </bean>

    <!– 配置DAO –>
    <bean id=”userDao” class=”com.bluesky.spring.dao.UserDaoImpl”>
        <property name=”sessionFactory” ref=”sessionFactory” />
    </bean>
</beans>

第四种方式：使用tx标签配置的拦截器

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
    xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
    xmlns:context=”http://www.springframework.org/schema/context”
    xmlns:aop=”http://www.springframework.org/schema/aop”
    xmlns:tx=”http://www.springframework.org/schema/tx”
    xsi:schemaLocation=”http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
           http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd”>

<context:annotation-config />
<context:component-scan base-package=”com.bluesky” />

    <tx:advice id=”txAdvice” transaction-manager=”transactionManager”>
        <tx:attributes>
            <tx:method name=”*” propagation=”REQUIRED” />
        </tx:attributes>
    </tx:advice>

    <aop:config>
        <aop:pointcut id=”interceptorPointCuts”
            expression=”execution(* com.bluesky.spring.dao.*.*(..))” />
        <aop:advisor advice-ref=”txAdvice”
            pointcut-ref=”interceptorPointCuts” />
    </aop:config>
</beans>

第五种方式：全注解

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans”
    xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
    xmlns:context=”http://www.springframework.org/schema/context”
    xmlns:aop=”http://www.springframework.org/schema/aop”
    xmlns:tx=”http://www.springframework.org/schema/tx”
    xsi:schemaLocation=”http://www.springframework.org/schema/beans
           http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
           http://www.springframework.org/schema/context
           http://www.springframework.org/schema/context/spring-context-2.5.xsd
           http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
           http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd”>

<context:annotation-config />
<context:component-scan base-package=”com.bluesky” />

<tx:annotation-driven transaction-manager=”transactionManager”/>

此时在DAO上需加上@Transactional注解，如下：

package com.bluesky.spring.dao;

import java.util.List;

import org.hibernate.SessionFactory;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.orm.hibernate3.support.HibernateDaoSupport;
import org.springframework.stereotype.Component;

import com.bluesky.spring.domain.User;

@Transactional
@Component(“userDao”)
public class UserDaoImpl extends HibernateDaoSupport implements UserDao {

    public List<User> listUsers() {
        return this.getSession().createQuery(“from User”).list();
    }


}

posted @ 2011-10-27 19:29 鸿雁阅读(297) | 评论 (0) | 编辑收藏

集群和分布式

集群概念

1. 两大关键特性
集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性：

· 可扩展性－－集群的性能不限于单一的服务实体，新的服务实体可以动态地加入到集群，从而增强集群的性能。

· 高可用性－－集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。

2. 两大能力
为了具有可扩展性和高可用性特点，集群的必须具备以下两大能力：

· 负载均衡－－负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

· 错误恢复－－由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。

负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图（信息上下文）必须是一样的。

3. 两大技术
实现集群务必要有以下两大技术：

· 集群地址－－集群由多个服务实体组成，集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单一集群地址（也叫单一影像）是集群的一个基本特征。维护集群地址的设置被称为负载均衡器。负载均衡器内部负责管理各个服务实体的加入和退出，外部负责集群地址向内部服务实体地址的转换。有的负载均衡器实现真正的负载均衡算法，有的只支持任务的转换。只实现任务转换的负载均衡器适用于支持ACTIVE-STANDBY的集群环境，在那里，集群中只有一个服务实体工作，当正在工作的服务实体发生故障时，负载均衡器把后来的任务转向另外一个服务实体。

· 内部通信－－为了能协同工作、实现负载均衡和错误恢复，集群各实体间必须时常通信，比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。

具有同一个集群地址使得客户端能访问集群提供的计算服务，一个集群地址下隐藏了各个服务实体的内部地址，使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能正常运转的基础，它使得集群具有均衡负载和错误恢复的能力。

集群分类

Linux集群主要分成三大类( 高可用集群，负载均衡集群，科学计算集群)

高可用集群( High Availability Cluster)
负载均衡集群(Load Balance Cluster)
科学计算集群(High Performance Computing Cluster)
================================================

具体包括：

Linux High Availability 高可用集群
(普通两节点双机热备，多节点HA集群，RAC, shared, share-nothing集群等)

Linux Load Balance 负载均衡集群
(LVS等....)

Linux High Performance Computing 高性能科学计算集群
(Beowulf 类集群....)

分布式存储
其他类linux集群
(如Openmosix, rendering farm 等..)

详细介绍

1. 高可用集群(High Availability Cluster)
常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如"双机热备", "双机互备", "双机".
高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。

2. 负载均衡集群(Load Balance Cluster)

负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。

负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。

3. 科学计算集群(High Performance Computing Cluster)

高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

高性能计算分类　　
　高吞吐计算(High-throughput Computing)
　　有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人（ SETI@HOME -- Search for Extraterrestrial Intelligence at Home ）就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照Flynn的分类，高吞吐计算属于SIMD（Single Instruction/Multiple Data）的范畴。

分布计算(Distributed Computing)
　　另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD（Multiple Instruction/Multiple Data）的范畴。

4. 分布式（集群）与集群的联系与区别
分布式是指将不同的业务分布在不同的地方。
而集群指的是将几台服务器集中在一起，实现同一业务。
分布式中的每一个节点，都可以做集群。
而集群并不一定就是分布式的。
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
而分布式，从窄意上理解，也跟集群差不多，但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。
分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。

posted @ 2011-10-27 19:28 鸿雁阅读(389) | 评论 (0) | 编辑收藏

软件设计的七大原则

设计模式遵循的一般原则：

1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。

2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP)
(1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。
(2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型.
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立
(4).<墨子.小取>中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也."
(5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。
(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口.
(7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍:
使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件.

3.依赖倒置原则(Dependence Inversion Principle),要求客户端依赖于抽象耦合.
(1)表述:抽象不应当依赖于细节,细节应当依赖于抽象.(Program to an interface, not an implementaction)
(2)表述二:针对接口编程的意思是说,应当使用接口和抽象类进行变量的类型声明,参量的类型声明,方法的返还类型声明,以及数据类型的转换等.不要针对实现编程的意思就是说,不应当使用具体类进行变量的类型声明,参量类型声明,方法的返还类型声明,以及数据类型的转换等.
   要保证做到这一点,一个具体的类应等只实现接口和抽象类中声明过的方法,而不应当给出多余的方法.
   只要一个被引用的对象存在抽象类型,就应当在任何引用此对象的地方使用抽象类型,包括参量的类型声明,方法返还类型的声明,属性变量的类型声明等.
(3)接口与抽象的区别就在于抽象类可以提供某些方法的部分实现,而接口则不可以,这也大概是抽象类唯一的优点.如果向一个抽象类加入一个新的具体方法,那么所有的子类型一下子就都得到得到了这个新的具体方法,而接口做不到这一点.如果向一个接口加入了一个新的方法的话,所有实现这个接口的类就全部不能通过编译了,因为它们都没有实现这个新声明的方法.这显然是接口的一个缺点.
(4)一个抽象类的实现只能由这个抽象类的子类给出,也就是说,这个实现处在抽象类所定义出的继承的登记结构中,而由于一般语言都限制一个类只能从最多一个超类继承,因此将抽象作为类型定义工具的效能大打折扣.
   反过来,看接口,就会发现任何一个实现了一个接口所规定的方法的类都可以具有这个接口的类型,而一个类可以实现任意多个接口.
(5)从代码重构的角度上讲,将一个单独的具体类重构成一个接口的实现是很容易的,只需要声明一个接口,并将重要的方法添加到接口声明中,然后在具体类定义语句中加上保留字以继承于该接口就行了.
   而作为一个已有的具体类添加一个抽象类作为抽象类型不那么容易,因为这个具体类有可能已经有一个超类.这样一来,这个新定义的抽象类只好继续向上移动,变成这个超类的超类,如此循环,最后这个新的抽象类必定处于整个类型等级结构的最上端,从而使登记结构中的所有成员都会受到影响.
(6)接口是定义混合类型的理想工具,所为混合类型,就是在一个类的主类型之外的次要类型.一个混合类型表明一个类不仅仅具有某个主类型的行为,而且具有其他的次要行为.
(7)联合使用接口和抽象类:
   由于抽象类具有提供缺省实现的优点,而接口具有其他所有优点,所以联合使用两者就是一个很好的选择.
   首先,声明类型的工作仍然接口承担的,但是同时给出的还有一个抽象类,为这个接口给出一个缺省实现.其他同属于这个抽象类型的具体类可以选择实现这个接口,也可以选择继承自这个抽象类.如果一个具体类直接实现这个接口的话,它就必须自行实现所有的接口;相反,如果它继承自抽象类的话,它可以省去一些不必要的的方法,因为它可以从抽象类中自动得到这些方法的缺省实现;如果需要向接口加入一个新的方法的话,那么只要同时向这个抽象类加入这个方法的一个具体实现就可以了,因为所有继承自这个抽象类的子类都会从这个抽象类得到这个具体方法.这其实就是缺省适配器模式(Defaule Adapter).
(8)什么是高层策略呢?它是应用背后的抽象,是那些不随具体细节的改变而改变的真理. 它是系统内部的系统____隐喻.

4.接口隔离原则(Interface Segregation Principle, ISP)
（1）一个类对另外一个类的依赖是建立在最小的接口上。

（2）使用多个专门的接口比使用单一的总接口要好.根据客户需要的不同,而为不同的客户端提供不同的服务是一种应当得到鼓励的做法.就像"看人下菜碟"一样,要看客人是谁,再提供不同档次的饭菜.
（3）胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系.当一个客户程序要求该胖接口进行一个改动时,会影响到所有其他的客户程序.因此客户程序应该仅仅依赖他们实际需要调用的方法.

5.合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.

6.迪米特法则(Law of Demeter LoD)又叫做最少知识原则(Least Knowledge Principle,LKP),就是说,一个对象应当对其他对象有尽可能少的了了解.
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,与1987年秋天由Ian Holland在美国东北大学为一个叫做迪米特(Demeter)的项目设计提出的,因此叫做迪米特法则[LIEB89][LIEB86].这条法则实际上是很多著名系统,比如火星登陆软件系统,木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则.
没有任何一个其他的OO设计原则象迪米特法则这样有如此之多的表述方式,如下几种:
(1)只与你直接的朋友们通信(Only talk to your immediate friends)
(2)不要跟"陌生人"说话(Don't talk to strangers)
(3)每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位.
就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。

7.单一职责原则(Simple responsibility pinciple SRP)
就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责.

另外：常说的OO五大原则就是指其中的：1、单一职责原则；2、开放闭合原则；3、里氏替换原则；4、依赖倒置原则；5、接口隔离原则。

posted @ 2011-10-27 19:27 鸿雁阅读(308) | 评论 (0) | 编辑收藏

仅列出标题

The important thing in life is to have a great aim , and the determination

导航

留言簿(7)

随笔分类

随笔档案

文章档案

相册

阅读排行榜

评论排行榜

常用链接

统计

IT技术链接

保险相关

友情链接

基金知识

生活相关

最新评论

Oracle数据库分区表操作方法(4)

Oracle数据库分区表操作方法(5)

Oracle数据库分区表操作方法(3)

Oracle数据库分区表操作方法（一）

Oracle数据库分区表操作方法（二）

Hibernate继承映射(Inheritance Mappings)

9.1.1. 每个类分层结构一张表(Table per class hierarchy)

9.1.2. 每个子类一张表(Table per subclass)

9.1.3. 每个子类一张表(Table per subclass)，使用辨别标志(Discriminator)

9.1.4. 混合使用“每个类分层结构一张表”和“每个子类一张表”

9.1.5. 每个具体类一张表(Table per concrete class)

9.1.6. Table per concrete class, using implicit polymorphism

9.1.6. Table per concrete class, using implicit polymorphism

9.1.7. 隐式多态和其他继承映射混合使用

JVM优化配置

Spring事务配置的五种方式

集群和分布式

集群概念

集群分类

详细介绍

软件设计的七大原则