StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>From a certain size (number of databases) up, you have to change the paradigm. Are you at that size?</p> <p>When you deploy what ultimately is a distributed application and yet try to controll it as an ordinary local application you are going to run into a set of fundamental issues around availability, scalability and correctness. If you use concepts like 'distributed transactions', 'linked servers' and 'ORM', your are down the wrong path. True distributed applications will use terms like 'message', 'queue' and and 'service'. Terms like Linq, EF, nHibernate are all fine and good, but <strong>none</strong> will bring you anything extra from what a simple Transact-SQL <code>SELECT</code> statement brings. In other words, if a SELECT solves your issues, then the client side various ORM will work. If not, they won't add any miraculos value.</p> <p>I recommend you go over the slides on the <a href="http://www.softconference.com/pass/sessionDetail.asp?SID=174551" rel="nofollow noreferrer">SQLCAT: High Performance Distributed Applications in Real World Deployments</a> which explain how a site like MySpace manages to read and write into a store of nearly 500 servers and thousands of databases.</p> <p>Ultimately what you need to internalize is this: one database can have 95% availability (uptime <strong>and</strong> acceptable service response time). A system consiting of 10 databases with 95% availability has 59% availability. And a system of 100 databases each with 99.5% availability has 60% availability. 1000 databases with 99.95% availability (5 min downtime per week) have 60% availability. And this is for an <em>ideal</em> situation. In reality there is always a snowball effect caused by resource consumption (eg. threads blocked on trying to access an unavailable or slow resource) that makes things far worse.</p> <p>This means that one cannot write a large distributed system relying on synchronous, tightly coupled operatiosn and transactions. Is simply impossible. You always rely on asynchronous operations (usually messaging and queues), which is something completely different from your run-of-the-mill database application.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload