두다다쿵

In a batch-processing system such as Hadoop, we usually care about throughput—the number of records we can process per second, or the total time it takes to run a job on a dataset of a certain size

하둡 같은 배치 시스템에서 성능 지표는 소위 말하는 스루풋 (초당 처리해야할 레코드의 수) 이나 일정 사이즈로 어떤 데이터셋을 처리하는 총 시간등이다. 

In online systems, latency is usually more important—the time it takes to serve a request, also known as response time.

온라인 시스템에서는 응답시간이라고 알려진 지표 - 각각의 요청을 처리하는데 걸린 시간 - Latency

We therefore need to think of latency not as a single number, but as a probability distribution.

latency는 측정할 때 마다 살짝 달라질 수 있어서 단일 수치로 취급하지말고 정규분포 형태로 취급해야 한다.

Now, when testing a system at various levels of load, you can track the median and higher percentiles of response times in order to get a quick measure of the performance.

다양한 부하를 받는 시스템을 테스트 하기 위해서는 평균 대신 중앙값 이나 상위의 percentile  백분위 계수(뭔가 퍼포먼스가 제일 떨어지는 놈)를 사용해야 한다.

High percentiles become especially important in backend services that are called multiple times as part of serving a single end-user request. Even if you make the calls in parallel, the end-user request still needs to wait for the slowest of the parallel calls to complete

대박 중요 (왜 굳이 상위 백분위 계수의 값이 (즉 성능이 떨어지는 최악의 수치들이) 중요한 이유는 병렬처리 환경에서 저렇게 편차를 보이는 퍼포먼스가 나왔을때 결국 그 병렬처리의 끝은 맨 마지막에 끝난 놈의 수치가 퍼포먼스가 되기 때문에....)

The tools and technologies that help data-intensive applications store and process data have been rapidly adapting to these changes. New types of database system (“NoSQL”) have been getting lots of attention, but message queues, caches, search indexes, frameworks for batch and stream processing, and related technologies are very important too. Many applications use some combination of these.

RDB에서 시작된 데이터 시스템은 시간이 지남에 따라 다양한 요구사항을 대응하여 새로운 기술들을 마구 쏟아내었다.  비정형데이터를 처리하기 위한 NoSQL 이 대표적이다. 하지만 메시지 큐 , 캐시 , Search Index, 배치프레임워크(아마도 Hadoop을) , 그리고 스트림 처리(CQL, 예를 들자면 스플렁크) 역시도 데이터 처리 기술에서 중요한 역할을 차지하며 많은 애플리케이션들이 이런 기술들을 조합해서 사용하고 있다. 

그리하여 각 기술의 장단점과 언제 어떻게 써야 하는지를 알아보겠다는게 이 책의 목표같다.(매우 당찬 포부다)

 Store data so that they, or another application, can find it again later (databases), 

 Remember the result of an expensive operation, to speed up reads (caches),

 Allow users to search data by keyword or filter it in various ways (search indexes),

 Send a message to another process, to be handled asynchronously (message queues),

 Observe what is happening, and act on events as they occur (stream processing), 

 Periodically crunch a large amount of accumulated data (batch processing).

Reliability The system should continue to work correctly (performing the correct function at the desired performance) even in the face of adversity (hardware or software faults, and even human error).  

Scalability As the system grows (in data volume, traffic volume or complexity), there should be reasonable ways of dealing with that growth. 

Maintainability Over time, many different people will work on the system (engineering and operations, both maintaining current behavior and adapting the system to new use cases), and they should all be able 14 to work on it productively. 

Scalability

1번 방식 : 트윗 계정에 로그인 할 때 위에 처럼 전통적인 RDB 에서 자신이 팔로우 하는 사람들의 트윗들을 JOIN으로 쿼리해서 타임라인에 뿌린다. 쿼리는 다음과 같을 것이라고 한다. 

2번 방식은 일종의 캐쉬를 이용한 방식인데 1번과 달리 계정 사용자가 로그인할 때 쿼리 하는 방식이 아니라 트윗을 등록하는 사람이 일단 글로벌 저장소(캐쉬)에 푸쉬를 하면 개별 계정들이 자신의 타임라인에 대한 캐쉬를 가지고 있고 글로벌 저장소는 들어온 트윗을 각각의 팔로워들의 캐쉬에 밀어 넣는 방식이다.

1번을 매번 타임라인을 확인할때마다 쿼리를 해야하는 방식인데 실제 트위터를 운영하다보니(?) 사람들이 트윗을 등록하는데 쓰는 시간보다 자신의 타임라인을 읽는데 (서버의) 더 많은 자원을 쓴다는 것을 알았고 그래서 타임라인은 퀴리로 요청하기보다는 캐쉬로 유지하고 푸쉬를 받는 방식을 취하는 것이다. 등록하는 일이 비교적 더 적으니까 그때 더 많은 일을 하자는 것이다

However, the downside of approach 2 is that posting a tweet now requires a lot of extra work. On average, a tweet is delivered to about 75 followers, so 4.6 k tweets per second become 345 k writes per second to the home timeline caches

2번 방식에서 고려해야 할 load 는 팔로워가 많은 유저가 트윗을 등록했을때 그 팔로워의 수만큼 푸쉬하는 작업이 늘어나기 때문에 이 부분에서 얼마나 많은 팔로워의 캐쉬들에 트윗을 복제해서 푸시해줘야 하는데 그 양이 결국 Scability의 고려 사항이 되는 것이다. 

현재 트위터는 2번을 주된 방식으로 하되 아까 언급했던 팔로워가 많은 셀러브리티들의 트윗은 1번 방식으로 긁어와서 2번에 수집한 내용과 섞어서 하이브리드로 동작한다고 한다. 이게 핵심인듯

Twitter is moving to a hybrid of both approaches. Most users’ tweets continue to be fanned out to home timelines at the time when they are posted, but a small number of users with a very large number of followers are excepted from this fan-out. Instead, when the home timeline is read, the tweets from celebrities followed by the user are fetched separately and merged with the home timeline when the timeline is read, like in approach 1.

이 부분을 읽어보니 Scability가 뭔지 대충 알 것 같다. 좋은 책인거 같다