Piotr Woloszyn

Microsoft SQL Server does not allow to replace an existing XSD schema in a straight forward manner. There is a way of extending a schema by adding new schema component to an existing collection but it will not help if we need to replace a schema:

ALTER XML SCHEMA COLLECTION [relational_schema.]sql_identifier ADD 'Schema Component'

We cannot drop the schema collection and recreate it as it might be used by a table. The way forward would be to untype all XML columns using the collection, then drop and recreate the schema collection and as a last step type the XML columns to that new schema collection:

ALTER TABLE my_table ALTER COLUMN my_xml_column XML

DROP XML SCHEMA COLLECTION my_xml_collection

CREATE XML SCHEMA COLLECTION my_xml_collection AS 'content of my XSD'

ALTER TABLE my_table ALTER COLUMN my_xml_column XML(my_xml_collection)

Popularity: 29% [?]

Share This

There are situations when you can’t put all data which you need in a single instance of a relational database. The reasons may differ. Maybe because it is too much of the data itself. Or there is a problem with network latency of a distributed architecture. Scaling? Or one of many other reasons. The answer is: horizontal partitioning. The process of splitting up your data sets that once has been called partitioning, now, it has a new name: sharding. If your data doesn’t fit on one machine you split it up into segments and each segment is called a shard. It is term used initially at Google but now spreading everywhere.

So… There is a new project Hibernate Shards which is a framework that is designed to encapsulate and minimize complexity of accessing multiple databases by adding support for horizontal partitioning on top of Hibernate Core. It was once the 20 percent project at Google but it is open-sourced now and licensed under the LGPL. If you know the Core Hibernate API you know the Shards API as its implementation hasn’t violated the Core API. Basic assumptions and paradigms for using Hibernate are still valid as Configuration, SessionFactory, and Session objects are almost exactly the same. Interfaces from Hibernate Core:

• org.hibernate.Session
• org.hibernate.SessionFactory
• org.hibernate.Criteria
• org.hibernate.Query

have shard-aware extensions:

• org.hibernate.shards.session.ShardedSession
• org.hibernate.shards.ShardedSessionFactory
• org.hibernate.shards.criteria.ShardedCriteria
• org.hibernate.shards.query.ShardedQuery

The implementations for these four interfaces serve as a sharding engine that knows how to apply an application-specific sharding logic. This logic is a set of rules how data is distributed across its shards. To specify this logic we have to implement the interfaces below:

• org.hibernate.shards.strategy.selection.ShardSelectionStrategy
• org.hibernate.shards.strategy.resolution.ShardResolutionStrategy
• org.hibernate.shards.strategy.access.ShardAccessStrategy

Hibernate Shards comes with a couple of simple implementations of these interfaces. For instance for the Shard Selection Strategy we have choice of sequential (load balanced round robin) or parallel access.

To finish the topic of the sharding logic I shall mention the id generation as well. As the standard database sequences can’t be used in distributed environment we have a choice of two primary key generators:

• ShardedUUIDGenerator - that generates a big random number
• ShardedTableHiLoGenerator - that uses a table in one of the shards to generate the primary key. Obviously it is a single point of failure for our system.

Although project is still in its early stage and even the creators warn about possible glitches this nice wrapper for hiding all the complexity of distributing data around multiple relational databases is very much worth looking at, especially if the Hibernate is already used as the ORM tool of choice.

Popularity: 50% [?]

Share This