Have You Heard?
The largest online event for SQL Server, Business Intelligence, SharePoint and .NET is about to happen – it’s just days away! The SSWUG.ORG Ultimate Virtual Conference is next week – it’s easy to register and save your spot – there is even a quick video on the home page of the conference that gives all the details –
But you need to act now – it’s only a few days away. When was the last time you attended a conference (70 sessions, 20 speakers) with a money-back guarantee, no travel, incredible content and full access to presenters? This is the biggest online event, period – check it out!
Watch the video here or Get Registered
(You could even win an Xbox 360 or MSDN subscription!)
Featured Article(s)
Data Access Madness: Choosing the Right Data Strategy for your .NET (Part 2 of 3)
Choosing the right data access technology and strategy for any particular application can be daunting. We have many data access choices to use in our applications and because the best choice is always dependent on each application, we can often feel overwhelmed when selecting a data access technology or crafting a data access strategy. This session will cover an overview of the available data access technologies and how they are used in today’s applications. We’ll also review key differences between ADO.NET Core Libraries, LINQ to SQL, Entity Framework and ADO.NET Data Services and how you can use these differences to your advantage in both existing and new applications.
Distributed Databases – Do You Need Them?
Distributed databases are similar to federated views or partitioned tables, but not in the same physical database. Therefore, a distributed database differs from failover technologies such as log shipping, clustering or mirroring. It also differs from replication in that the data is not necessarily replicated between databases.
The intention of a distributed database is to reduce the load much like a partitioned view or table. The big difference is to also distribute the work of maintaining or querying the data across different resources. If you created a partitioned view with the data stored on two different SQL Servers, this would be more like a distributed database. Two different servers maintain the composite contents of the partitioned view. Then consumer is not aware that the data is stored in a distributed fashion.
In this case, the data is accessed through a view. The view knows the exact location of both databases (if only two are used) and what data is stored on each. If the data supporting a user query is stored on Server B but Server A contains the federated view, then resources from both Server A and Server B are being used to retrieve the desired data. For this reason Federated Views are not a pure distributed database solution.
Partitioned tables physically reside in a single database and therefore do not meet the needs of a distributed database in the pure sense; they can only run within the context of a single SQL Server Instance at any one time.
So how do you create a partitioned database? In this case you need a broker of some sort that has knowledge of where partitioned data is stored. That data needs to be of the kind that can be partitioned. When you send a query to retrieve data, you send the query to the broker. It in turn sends the query to one or more servers concurrently. The results from the different servers are returned to the broker and then unioned. In a sense, this would be like having a single database instance containing nothing but Federated Views accessing data from multiple servers and combining the results for consumption.
Why would you use a distributed database design? Isn’t it more complicated and doesn’t it take a lot of extra resources and effort? Once your partitioning and perhaps replication is in place, then the distribution is not that much of a leap. The biggest thing you gain is scalability. Instead of only having the option to scale up (get bigger and better servers with SAN or SSD storage) you can scale out (get lots of little computers that don’t do much, but the sum of them is quite huge).
This is a big topic…and I have just touched on enough of it to catch your interest. There are many different models supported by other methods not supported by SQL Server natively.
I’d like to hear from you. Are you distributing your databases today or thinking about doing it in the future. Drop a note to me at btaylor@sswug.org.
Cheers,
Ben