guzz 1.2.9 英文版发布新闻，求好心人转发

guzz 1.2.9 released--split & distribute big tables into many databases to solve the db bottleneck in large systems.

 

Table-distribute feature is released in guzz1.2.9 named VirtualDB. In VirtualDB, you can split a big table into many small ones, and distribute them in several machines on your own rules.

 

For a busy system or a large-scaled system, distributed table cutting is a very efficient solution to solve the problems of storing, querying, archiving and other maintaining stuffs for huge operations of data. But in the real world, almost no general-purpose framework did this for developers. Guzz designed this feature in 1.2.9, and now release it to commit a big step of our promise “full stack data-layer solution”.

 

guzz’s database layer solution:

 

With the release of VirtualDB, guzz finally achieves her database solution in 6 opinions.

 

1.     You have too many tables in a database, or they took too much resource for a single database. Distribute them in different database machines with dbgroup in chapeter 3:  

  http://code.google.com/p/guzz/wiki/TutorialGuzzXml

 

2.     Some table is too big. Spit them into small ones with ShadowTable in chapter 15: 

  http://code.google.com/p/guzz/wiki/TutorialShadowTable

 

3.    Your business is special, for example a shopping site; each table may/should own its special columns. Ok, split them with CustomTable in chapter 16:  

  http://code.google.com/p/guzz/wiki/TutorialCustomTable

 

4.    Big tables are split, but the split small tables are too many or too big in total to store together. Distribute the small tables in different database machines with VirtualDB in chapter 17:

  http://code.google.com/p/guzz/wiki/TutorialVirtualDB

 

5.    Some column is too big to store in the database, or should be treated very special. Store it in File System, in memcached, or in anything you like with CustomColumnLoader in chapter 11:

  http://code.google.com/p/guzz/wiki/TutorialLazyLoad

 

6.   The system is really very very busy, a single database is absolutely impossible to achieve your mission. Ok, deploy more READ machines with the native read-write separation support in guzz.

 

Guzz can work with hibernate and ibatis, and can also work alone. If your system meets something of lacking database-scale ability, deploy more database machines and introduce guzz to upgrade database-scale related modules. It’s simple to write, easy to understand, and future-oriented.

 

Read more about us: http://code.google.com/p/guzz/