Measuring Load

It’s common to see the average response time of a service reported. (Strictly speaking,?the term “average” doesn’t refer to any particular formula, but in practice it is usually?understood as the arithmetic mean: given n values, add up all the values, and divide?by n.) However, the mean is not a very good metric if you want to know your “typical”?response time, because it doesn’t tell you how many users actually experienced?that delay.?Usually it is better to use percentiles. If you take your list of response times and sort it?from fastest to slowest, then the median is the halfway point.?The median is also known as the 50th?percentile, and sometimes abbreviated as p50.

Approaches for Coping with Load

Scaling up (vertical scaling, moving to a more powerful machine) and scaling out (horizontal scaling, distributing the load?across multiple smaller machines). Distributing load across multiple machines is also known as a shared-nothing architecture.

An architecture that scales well for a particular application is built around assumptions?of which operations will be common and which will be rare—the load parameters.?If those assumptions turn out to be wrong, the engineering effort for scaling is at?best wasted, and at worst counterproductive. In an early-stage startup or an unproven?product it’s usually more important to be able to iterate quickly on product features?than it is to scale to some hypothetical future load.

we will pay particular attention to three design principles for software?systems:
Operability
Make it easy for operations teams to keep the system running smoothly.
Simplicity
Make it easy for new engineers to understand the system, by removing as much?complexity as possible from the system. (Note this is not the same as simplicity?of the user interface.)
Evolvability
Make it easy for engineers to make changes to the system in the future, adapting?it for unanticipated use cases as requirements change. Also known as extensibility,?modifiability, or plasticity.?

As previously with reliability and scalability, there are no easy solutions for achieving?these goals. Rather, we will?try to think about systems with operability, simplicity,?and evolvability in mind.

?SQL vs NoSQL

There are several driving forces behind the adoption of NoSQL databases, including:
? A need for greater scalability than relational databases can easily achieve, including?very large datasets or very high write throughput
? A widespread preference for free and open source software over commercial?database products
? Specialized query operations that are not well supported by the relational model
? Frustration with the restrictiveness of relational schemas, and a desire for a more?dynamic and expressive data model

?

轉載于:https://www.cnblogs.com/codingforum/p/9236879.html

總結

以上是生活随笔為你收集整理的Data intensive Application (1)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。