sql server scale out with distributed partitioned views


hi.
our company manages online auction , shopping website(something ebay), , have questions regarding scaling out solutions.

running sql server 2008 r2 enterprise edition(which servicing asp.net) on our 2 servers near each other.
server specifications:

server 1:
4   x intel xeon e5-4650 cpu processor 8-core 2.7ghz/20mb/8gt
14 x samsung 16gb ddr3-1600

server 2:
4   x intel xeon e5-2670 cpu processor 8-core 2.6ghz/20mb/8gt (1 per each node)
4   x samsung 16gb ddr3-1600

have 2g database!


know not considered large-scale website since expecting gradual growth searching through scaling out solutions.
have read far seems  "distributed partitioned views" can work fine among things scalable shared database, p2p replication, ddr,... because not willing make major changes in application,and have frequent updates(users insert new items sell,...).
although have concerns relating <b>performance of linked servers</b>. since servers near each other thought maybe physical solution (lan) more appropriate in connecting two.
thing restrictions of view in order <b>updatable </b>(like not having identity column in base tables) , fact think using "instead of triggers" can slow performance.

right in choosing "dpv"?

appreciate help, , thank time.
 

no.  dpvs not right feature scaling out web site back-end.

first, try not scale out.  if can run workload on single server, solution simpler.  servers faster , new sql server technologies too.  for instance sql 2014 ship in-memory oltp which designed support extremely high throughput scenarios.  so gradual upgrades , gradual code optimization, should able hande gradual growth.

if scale out, there's no feature handle aspects without code changes.  for extremely high-scale applications common approach have multiple databases (also called shards, or federated databsaes) on multiple servers , have application handle server connect particular transaction.

peer-to-peer replication can make easier schema designs can't partitioned replicating writes nodes.  the application still has route writes nodes such same row not updated @ different nodes @ same time, typically requires less change application supporting full sharding.

david


david http://blogs.msdn.com/b/dbrowne/





SQL Server  >  SQL Server Database Engine



Comments

Popular posts from this blog

Conditional formatting a graph vertical axis in SSRS 2012 charts

Register with Power BI failed

SQL server replication error Cannot find the dbo or user defined function........