Today, we are proud to release guzz 1.2.9 with the table-distribute feature 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 or 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 1.2.9 build20110209 updates:

 

 VirtualDB:

 

VirtualDB is based on the technology of guzz’s ShadowTable. If you have already spilt your big table into small ones with ShadowTable, you only to have to write a new rule to route the databases, and make a few changes in guzz.xml configuration file to distribute them in different (database) machines.

 

Read for more details: http://code.google.com/p/guzz/wiki/TutorialVirtualDB

 

Now, with this release, guzz finally achieves our database solution in 6 opinions.

 

  1. You have too many tables in a database, or they took too much resource for a database. Distribute them in different database machines with dbgroup in chapeter 3:  http://code.google.com/p/guzz/wiki/TutorialGuzzXml

 

  1. Some table is too big. Spit them into small ones with ShadowTable in chapter 15: http://code.google.com/p/guzz/wiki/TutorialShadowTable

 

  1. 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

 

  1. 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

 

  1. 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

 

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

 

Record SQL execution time in nano-seconds:

 

Two more options are introduced in DebugService to print out the nano-seconds a sql took to execute. Read more: http://code.google.com/p/guzz/wiki/AppendCoreService

 

Others?

 

  1. A new attribute “package” is supported in hbm.xml.
  2. LogService is changed to InsertQueueService
  3. Fix some bugs.

 

 

What is guzz?

 

Guzz is a framework for large-scaled system and rapid development.

 

With ORM, multi-datasources, shard, general data processing, object-oriented database taglib, guzz provides a full-stack solution for data-layer architecture. It can be a good complement or another choice for hibernate and ibatis.

 

Guzz's aim is to simplify the design of large-scaled system, clearing the division of team jobs, lessen mistakes in using frameworks.

 

Guzz's features:

 

  1. Modern design, experienced on ibatis and hibernate's great favors.
  2. For simple situation, you can persist, mapping and query data in a object-oriented way like hibernate (80%).
  3. For some complicated operations, you can store complicated sqls in a xml configuration file, and let dbas involved in, like ibatis (20%).
  4. Over ibatis, you can also store and load sqls from anywhere (or any system), and use it on fly. Add/delete/test/tune sqls online without a restart. (We call this "Dynamic SQL")
  5. Better batch API. Easy use and easy control.
  6. Support your system to use many database machines without extra codes, and separate read-write between those machines.
  7. Support your system to store different tables in different machines, and maintain a distributed transaction automatically (Shard).
  8. Support your system to split a big table into many small ones on your rules (Shadow), and even allow each table owns its special columns (Custom).
  9. Support the split small tables distributed in different database groups (VirtualDB).
  10. Support unified POJO styled usage for data with very special conjunction (over "Normal Form"), or between unstructured data (such as from other systems). For example, you call book.getPrice(), and the price can actually be read from a third part system like Amazon, while other properties like book name, ISBN, author are read from your own database.
  11. Support Service-oriented architecture; help you accumulate a fundamental services system. (Yes, not build a fundamental system from scratch, but accumulate one from more and more projects.)
  12. Object-oriented database JSP Taglib, fast view-layer's development, maintaining and deployment. You can build pages without writing any java codes. Very very fast! It is also nice for building a custom-featured system on a production.
  13. Support for Configuration System. You can manage all configurations among different systems in a central system online.

 

Project Home: http://code.google.com/p/guzz/