9. Recap
Queue-based Load:
-Removes app failure caused by 3rdparty services
Competing-Consumers:
-Ensures messages (= tasks) are processed faster, even under high load
Priority Queue:
-Ensures important tasks run first
11. •Most developers think about how data is stored in OOP manner
•In NoSQL, commonly store everything in a single entity
•In SQL, we have size constraints
•End-up in:
•Performance impact
•High prices
What about data repo. limit.?
12. •Can generate views in advance, containing data on a per-requirement basis
•Only contain data required by query
•Include current values of calculated columns or data items
•May be optimized for a single queries
•Updated a.s.a.p. (schedule / triggered)
What about data repo. limit.? (cont’)
15. Materialized-View Pattern
When to use
Queries are complex
Data difficult to query directly
Temporary views dramaticallyimprove perf.
Temporary views act as DTOs for UI, reporting etc.
Data store not always available (SQL Azure)
Security or privacy reasons
16. Recap
So far, I’ve talked about:
•Taking pieces of code out of the ‘front facing’ apps
•Messaging methods between apps and consumers
•Simple queue
•Priority queue
•Response queues
•Partitioning data into views
•Materialized views!
Hip-hip, Hurray!
WE CAN SCALE OUR COMPUTE ROLES!
17. But what about data?
•Thought:
If we scale-out our compute roles…
… why not scale out our databases too?
18. Sharding Pattern
•Scale-up vs. scale-out applies to dbs. too!
•Shard = horizontal partition of overall data
•Must scale out data because:
•Storage limitations
•Concurrent requests
•Customer isolation
•Geography
19. Sharding Pattern (cont’ed)
•Horizontal partitions of data
•(a.k.a. shards)
•Same schema, different data
•Runs on its own server
•Benefits:
•Use commodity hardware
•Better performance
•Closely located geographically
30. Patterns for Scalability in Microsoft Azure Applications
Alex Mang
alexmang.ro | @mangalexandru
25thof October 2014
Please fill the online evaluation form after event