Finally the day arrives! The year end update to SQL Azure is live and you can now use federations across all geographies of SQL Azure. There also a great new surprise we have been working on; we are making Federations available through open specification promise. OSP (open specification promise) is a promise not to assert patents against you for making, using, selling, offering for sale, importing or distributing any implementation that conforms to a Covered Specification. You can find the full definition here. This simply means that anyone in the open source community or in commercial development business can freely utilize the federations model in your libraries and utilize the same runtime model for representing distribution of data in your partitioning implementations. OSP for federations bring great interoperability and openness to the federations model. You can find more details on Ram’s blog here about details of the SQL Database Federations OSP.
Well, if you would like to get started, there are many how-tos and walk-throughs. here are a few links that will help;
There are also a few chats and demos I have recorded over the last few weeks to help get you started on federations;
We are obviously not done yet with federations. There will be more content, updates to the technology and other exciting news. Simply look for #sqlfederations in twitter or come to my blog regularly for updates.
Cihan Biyikoglu - Program Manager SQL Azure
Congrates on the RTW of SQL Azure Federations. Great work from your entire team.
Cihan, thanks for keeping us all posted all the way until the D-day the 12th.
Having followed your posts and some Azure documentation (so far limited), there is 1 simple but key question that keeps bugging me, my team and quite likely many other developers - so far I have not found any reasonable explanation and I fail to understand on HOW and WHY having ALL(!) federation member requests go ALWAYS(!) through ONE(!) Federation Root DB would eliminate the SQL performance bottleneck problem that we are trying to get away with???
Unless I am missing something (and hopefully I am so please help me with your detailed explanation) would not the Federation Root DB have the same physical restraints as the regular SQL Azure(max threads, max connections per pool, timeouts, Azure multi-tenant black-box internal resource management considerations/terminations, etc.)?? Aren't we just substituting one bottleneck for another?
In a traditional sharding approach (as you rightfully mentioned in your Jan. 18th post) typically the data access layer will cache the shard directory (distribution of the data to the databases) at the application tier and will construct a connection string based on the shard key instance – and it is DIRECTLY to a Specific DB.
It seems that with Federations the necessity of always routing the federation member requests through the Federation Root DB just DOES NOT solve the physical constraints problems and limitations of having to always deal through the Single SQL db. IF it is not the case, can you please provide a detailed explanation and proof on why and how. Your help is greatly appreciated!
This is great feature, but pricing model seems to be broken from what I can see making it not very useful for SAAS.
Question - Having issues with having federation and aspnet_Membership in the same database? Getting errors that you can't have Identity in a federated database? Also in Azure it is creating items in a system-unique identifier database and not in the regular database when scripting tables with federation. Any pointers?
Is this still true: ALTER TABLE does not provide a way to alter tables created with the FEDERATED ON clause.
If so, how in the world are we supposed to deploy schema changes?
Hi Gunnar, We do support ALTER TABLE on all tables however we do not support a FEDERATED ON clause in the ALTER TABLE statement. So you cannot demote and promote a table to be federated or reference table with a single ALTER TABLE statement but we did not find that type of change to be very common among our users. What is your use case for doing ALTER TABLE with FEDERATED ON?
Hi Craig, would love to hear what you'd like to see changed with federation billing model. You can email me at firstname.lastname@example.org.
Hi DE, we do not support identity property in federation members right now. We are looking at relaxing that in future. Now sure about the second question; could you expand on the details? you can email me at email@example.com.