반응형

시스템에서 카산드라를 사용한지 3년이 넘어가면서 그 동안 도움을 받았거나 좋은 내용들의 글을 모아놨었는데 로컬에 남겨놓는건 찾기도 힘들고 언제 사라질지 모르니 포스팅으로 남겨본다.

1. How is data written?

https://docs.datastax.com/en/archived/cassandra/2.2/cassandra/dml/dmlHowDataWritten.html

 

How is data written?

Understand how Cassandra writes and stores data. Cassandra processes data at several stages on the write path, starting with the immediate logging of a write and ending in with a write of data to disk: Logging data in the commit log Writing data to the mem

docs.datastax.com

 

2. How is data read?

https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/dml/dmlAboutReads.html

 

How is data read?

How Cassandra combines results from the active memtable and potentially multiple SSTables to satisfy a read. To satisfy a read, Cassandra must combine results from the active memtable and potentially multiple SSTables. Cassandra processes data at several s

docs.datastax.com

 

3. Materialized View Performance in Cassandra 3.x

https://www.datastax.com/dev/blog/materialized-view-performance-in-cassandra-3-x

 

Materialized View Performance in Cassandra 3.x | Datastax

DataStax, Titan, and TitanDB are registered trademarks of DataStax, Inc. and its subsidiaries in the United States and/or other countries. Apache, Apache Cassandra, Cassandra, Apache Tomcat, Tomcat, Apache Lucene, Lucene, Apache Solr, Apache Hadoop, Hadoop

www.datastax.com

 

4. Apache Cassandra Materialized View Design

https://docs.google.com/document/d/1sK96wsE3uwFqzrLQju_spya6rOTxojOKR9N7W-rPwdw/edit

 

Google 문서 - 온라인에서 문서를 작성하고 수정할 수 있으며 무료입니다.

하나의 계정으로 모든 Google 서비스를 문서로 이동하려면 로그인하세요.

accounts.google.com

 

5. Cassandra 3.0 Materialized Views Technical Deep Dive

http://www.doanduyhai.com/blog/?p=1930

 

Cassandra 3.0 Materialized Views Technical Deep Dive | DOAN DuyHai's blog

In this blog post, we’ll dig into the brand new materialized view feature of Cassandra 3.0. We’ll see how it is implemented internally, how you should use it to get the most of its performance and which caveats to avoid. For the remaining of this post Cass

www.doanduyhai.com

 

6. 카산드라 compaction관련 장애처리

http://knight76.tistory.com/entry/cassandra-compaction-%EA%B4%80%EB%A0%A8

 

cassandra gc 튜닝 - compaction과 full gc

cassandra를 운영하면서 CMS Full GC가 발생하면서 수십 초동안 stop the world (hang)이 발생했다. 이를 간단히 해결한 내용을 작성한다. Case #1 node repair를 하고 난 직후 바로 다른 table(colum family)에서..

knight76.tistory.com

 

7. Myths of Big Partitions

https://www.slideshare.net/DataStax/myths-of-big-partitions-robert-stupp-datastax-cassandra-summit-2016

 

Myths of Big Partitions (Robert Stupp, DataStax) | Cassandra Summit 2…

Large partitions shall no longer be a nightmare. That is the goal of CASSANDRA-11206. 100MB and 100,000 cells per partition is the recommended limit for a sing…

www.slideshare.net

 

8. Hinted Handoff: repair during write path

https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsRepairNodesHintedHandoff.html

 

Hinted Handoff: repair during write path

Describes hinted handoff, repair during write path. On occasion, a node becomes unresponsive while data is being written. Reasons for unresponsiveness are hardware problems, network issues, or overloaded nodes that experience long garbage collection (GC) p

docs.datastax.com

 

9. Cassandra performance: the most comprehensive overview you’ll ever see

https://www.scnsoft.com/blog/cassandra-performance

 

Cassandra Performance: The Most Comprehensive Overview You’ll Ever See

Cassandra Performance: The Most Comprehensive Overview You’ll Ever See Head of Data Analytics Department, ScienceSoft Apache Cassandra obviously can’t tell the future. It can only enable you to organize data storage (or at least make it as organized as it

www.scnsoft.com

 

반응형
반응형

카산드라 Connection Pooling에 따른 요청수와 요청 처리방법

'카산드라 클러스터 노드수가 많아지면 request처리할 있는 양이 얼마나 많아질까?' 라는 궁금증에서 시작

API서버에서 어떻게 Connection Pool이 설정되어 있고 설정에 따라 카산드라 클러스터 노드(node)당 얼마나 처리할 수 있는지 알아보자

(단순히 datastax문서의 내용에만 의지한 것으로 실제 서비스에서는 Network I/O나 다른 요인들에 의해 영향을 받을 수 있음을 유의하자!!!)

How managed node contactPoints?

// (1)
//ContactPoints 하나라도 존재해야함!!!
Assert.isTrue(StringUtils.hasText(contactPoints), "At least one server is required");

public Builder addContactPoints(String... addresses) {
    for (String address : addresses)
        addContactPoint(address);  (2)
    return this;
}

(3)
public Builder addContactPoint(String address) {
    // We explicitly check for nulls because InetAdress.getByName() will happily
    // accept it and use localhost (while a null here almost likely mean a user error,
    // not "connect to localhost")
    if (address == null)
        throw new NullPointerException();
    try {
        addContactPoints(InetAddress.getAllByName(address)); (4)
        return this;
    } catch (UnknownHostException e) {
        throw new IllegalArgumentException("Failed to add contact point: " + address, e);
    }
}

(5) 
public Builder addContactPoints(InetAddress... addresses) {
    Collections.addAll(this.rawAddresses, addresses);
    return this;
}

(6)
contactpoints는 배열로 관리됨
private final List<InetAddress> rawAddresses = new ArrayList<InetAddress>();

How selected node when API server requests

RounRobinPolicy : 라운드로빈방식에 대해서는 따로 설명하지 않겠다. (단순 동일하게 각 노드에게 돌아가면서 요청하는 방식)

스크린샷 2018-09-13 오전 9.32.04.png

Cassandra 버전 별 허용 Request수

Cassandra versions 1.2 and 2.0 allow the clients to send up to 128 requests without waiting for a response per connection.
Higher versions of Cassandra ( that is 2.1 or greater) allow clients to send up to 32768 requests without waiting for a response.
단순히 이 계산식으로 계산을 했을 때
한 노드 당 14억(1415577600)정도의 요청을 처리 할 수 있음.
http://datastax.github.io/nodejs-driver/features/connection-pooling/
스크린샷 2018-09-13 오전 9.25.46.png


Cassandra 커넥션 맺는 flow 및 ProtocolVersion에 따른 차이

참고 : https://docs.datastax.com/en/developer/java-driver/3.6/manual/pooling/


참고 : https://docs.datastax.com/en/developer/java-driver/3.6/manual/native_protocol/



ContactPoints는 클러스터 모든 서버 목록을 적어줘야하나???

결론을 먼저 말하자면 '그렇지 않다'이다!!!

실질적으로 어플리케이션이 로드될 때 카산드라 드라이버는 컨택포인트에 적어진 노드 하나에 접근하게 되고 

그 노드로부터 실제 클러스터의 노드 정보등을 받아와 메모리상에 메타정보로 관리하게 된다.

따라서 클러스터가 10대로 구성되어 있더라도 ContactPoints에는 2~3대만 기입해줘도 문제가 없다.

다음의 내용을 참고하자.

Contact points setting is a list of one or many node address. When creating a Cluster instance at client side, the driver tries to connect to the nodes specified in the "contact points" in order. If it fails to connect to the first node, try the next ... As long as one node is successfully connected, it does not try to connect the other nodes anymore.

Why it is not necessary to connect to all the contact points is because, each node contains the metadata of all the other nodes, meaning as long as one is connected, the driver could get infomation of all the nodes in the cluster. The driver will then use the metadata of the entire cluster got from the connected node to create the connection pool. This also means, it is not necessary to set address of all your nodes to the contact points setting. The best practice is to set the nodes which responds the fastest to the client as contact points.


자세한 내용이 궁금하다면 다음을 참고하자.


참고 : https://teddyma.gitbooks.io/learncassandra/content/client/which_node_to_connect.html  (Which Node to Connect)




반응형
반응형


카산드라(Cassandra) ttl은 read의 성능에 영향을 미치는가?

테스트 환경 및 프로세스

1. 알파 카산드라(node3개)에 ttl을 설정한 테이블과 ttl설정을 하지 않은 테이블을 각각 만든다.
2. 각각의 테이블에 2만개씩의 데이터를 넣는다 (id, value1, value2)  - id(1~20000)
3. api로 해당 테이블을 select하는 요청(id는 1~20000 중 랜덤으로 선택)을 한다.(20초동안 2000번)


테스트 결과 1

99th percentile에 주목해주세요(요청의 99% 평균 처리시간을 의미합니다.

1번2번3번
NO TTL 테이블 select 요청스크린샷 2018-03-09 오후 3.26.02.png스크린샷 2018-03-09 오후 3.26.29.png스크린샷 2018-03-09 오후 3.27.33.png
TTL 걸린 테이블 select 요청스크린샷 2018-03-09 오후 3.28.12.png스크린샷 2018-03-09 오후 3.28.45.png스크린샷 2018-03-09 오후 3.29.17.png

99th percentile을 보시면 알겠지만 ttl이 걸린 테이블이 오히려 처리속도가 더 빠른경우도 있습니다....(살짝 멘붕)

아무리 그래도 ttl걸린 테이블이 당연히 latency가 높을줄 알았는데....ㅎㅎ

그래서 각각의 테이블에 10000개의 데이터를 더 놓고 테스트를 진행하였습니다.

여기서 다른점은 ttl이 걸린 테이블에 임의로 10000개의 데이터의 ttl을 1분을 주고 tombstone이 발생하도록 하였습니다.

그리고 나서 다시 api로 select 테스트를 하였습니다.


테스트 결과2 (각각 테이블에 1만개씩 더 밀어넣음 - ttl걸린테이블에는 tombstone이 발생하도록 ttl을 1분으로 설정하고 넣음)

123
NO TTL 테이블 select 요청스크린샷 2018-03-09 오후 3.38.28.png스크린샷 2018-03-09 오후 3.38.53.png스크린샷 2018-03-09 오후 3.39.16.png
TTL 걸린 테이블 select 요청스크린샷 2018-03-09 오후 3.38.00.png스크린샷 2018-03-09 오후 3.37.40.png스크린샷 2018-03-09 오후 3.36.56.png

결과를 보시면 1만개씩을 더 밀어넣었지만 기존 TTL이 걸리지 않은 테이블은 첫 번째 테스트 속도와 거의 비슷한 결과를 도출한 반면

1만개의 데이터를 tombstone이 발생하도록 밀어넣은 TTL이 설정된 테이블은 속도가 현저히 떨어진 것을 확인해볼 수 있습니다.



그렇다면 왜 이런 결과가 나온것인가?

카산드라는 read요청이 들어올 경우 첫 번째로 memtable을 뒤지고
그 다음으로 row cache데이터가 있다면 row cache데이터를 확인합니다. (카산드라는 빈번하게 요청되는 row를 위한 캐시기능을 제공합니다)
row cache에도 데이터가 없는 경우 Bloom filter(메모리에 상주) 확인하여 찾는 row의  키가 있는 SSTables를 확인하여
해당 SSTables를 통해서 데이터를 읽어오게 됩니다.

따라서 데이터가 insert되면서 Bloom filter SSTables내의 데이터의 키값들이 해싱되어 업데이트 되는 경우에는
실제로 SSTables(dis I/O)를 사용하지 않고 데이터를 가지고 오게되어 빠르게 처리가 가능합니다.

하지만 Bloom filter의 해싱된 데이터들이 업데이트 되기전 SSTables의 값이 delete나 drop등으로 변경되는 경우에는
Bloom filter와 SSTable사이간 데이터의 정밀도가 떨어지게 됩니다.

이 경우 Bloom filter는 이미 SSTable내의 Tombstone된 데이터를 가르키게 되고 잘못된 포인팅으로 인해
카산드라는 SSTables에서 직접 해당 데이터를 다시 가져오는 작업(Disk I/O 발생)을 진행합니다.
이러한 이유로 ttl이 걸린 테이블 혹은 row에서 select시 성능이 떨어질 수 있다고 생각됩니다.
더 정확한 내용은 다음 문서를 참고해보시면 좋을 것 같습니다.
[Cassandra how is data read?](How is data read?)


TTL을 설정하고도 성능을 떨어트리지 않는 방법이 있는가?

SSTables과 Bloom Filter 정밀도를 높여서 운영하는 방법입니다.
하지만 모든선택에는 tradeoff가 있듯이 정밀도를 높이게 되면 더 많은 메모리를 필요로 하게 됩니다.
설정 방법은 테이블을 만들 때 bloom_filter_fp_chance 옵션을 주는 방법입니다.
추천값은 0.1이지만 최대 1.0까지 설정이 가능합니다.
1.0으로 설정할 경우 SSTables과의 정밀도를 높일 수 있으나 더 많은 메모리를 필요로 하기 때문에
상황에 맞는 설정값으로 운영하시면 될 것 같습니다.

반응형
반응형

Chapter 2. Introducing Cassandra

Cassandra in 50 Words or Less

"Apache Cassandra is an open source, distributed, decentralized, elastically scalable(탄력적인 확장성), highly available(고가용성), fault-tolerant, tuneably consistent, row-oriented database that bases its distribution design on Amazon's Dynamo and its data model on Google's Bigtable. Created at Facebook, it is now used at some of the most popular sites on the Web."

Distributed and Decentralized

  • The fact that Cassandra is decentralized means that there is no single point of failure.
  • All of the nodes in a Cassandra cluster function exactly the same. This is sometimes referred to as “server symmetry.” (서버 대칭)
  • they are all doing the same thing, by definition there can't be a special host that is coordinating activities(활동을 조정하는),
    as with the master/slave setup that you see in MySQL, Bigtable, and so many others.
  • RDMBS(master/slave) - centerlized, NOSQL(cluster) - distributed
  • Note that while we frequently understand master/slave replication in the RDBMS world, there are NoSQL databases such as MongoDB that follow the master/slave scheme as well.
  • Decentralization has two key advantages
    • it's simpler to use than master/slave, and it helps you avoid outages.(중단을 방지)
    • It can be easier to operate and maintain a decentralized store than a master/slave store because all nodes are the same.
      That means that you don't need any special knowledge to scale; setting up 50 nodes isn't much different from setting up one.
  • Cassandra is distributed and decentralized, there is no single point of failure, which supports high availability.

Elastic Scalability

  • Scalability is an architectural feature of a system that can continue serving a greater number of requests with little degradation in performance(성능저하거의없이)
  • Horizontal scaling means adding more machines that have all or some of the data on them so that no one machine has to bear the entire burden of serving requests.
  • You don't have to restart your process. You don't have to change your application queries. You don't have to manually rebalance the data yourself. Just add another machine
  • you won't need to upset(뒤집다) the entire apple cart to scale back (!!!!important)

High Availability and Fault Tolerance

  • Cassandra is highly available. You can replace failed nodes in the cluster with no downtime, and you can replicate data to multiple data centers
    to offer improved local performance and prevent downtime if one data center experiences a catastrophe(대재앙) such as fire(화재) or flood.

Tuneable Consistency

  • When considering consistency, availability, and partition tolerance, we can achieve only two of these goals in a given distributed system, a trade-off known as the CAP theorem
  • In Cassandra, consistency is not an all-or-nothing proposition.
  • We might more accurately term it “tuneable consistency” because the client can control the number of replicas to block on for all updates.
  • The replication factor lets you decide how much you want to pay in performance to gain more consistency.

Brewer's CAP Theorem

  • Consistency
    • All database clients will read the same value for the same query, even given concurrent updates.
  • Availability
    • All database clients will always be able to read and write data.
  • Partition tolerance
    • The database can be split into multiple machines; it can continue functioning in the face of network segmentation breaks.
  • Brewer's theorem is that in any given system, you can strongly support only two of the three.
  • “You can have it good, you can have it fast, you can have it cheap: pick two.”

  • Figure2-1illustrates visually that there is no overlapping(중첩) segment where all three are obtainable(세 가지 모두 얻을수 있는).
[ Figure 2-2 ]

Although databases its on line two property
According to the Bigtable paper, the average percentage of server hours that "some data" was unavailable is 0.0047% (section 4), so this is relative, as we're talking about very robust systems already.
So what does it mean in practical terms(실제적인 측면) to support only two of the three facets of CAP?
CA (Consistency, Availability)
To primarily support consistency and availability means that you're likely using two-phase commit for distributed transactions. It means that the system will block when a network partition occurs, so it may be that your system is limited to a single data center cluster in an attempt to mitigate(완화) this. If your application needs only this level of scale, this is easy to manage and allows you to rely on familiar, simple structures.
CP (Consistency, Partition tolerance)
To primarily(주로) support consistency and partition tolerance, you may try to advance your architecture by setting up data shards in order to scale. Your data will be consistent, but you still run the risk of some data becoming unavailable if nodes fail.
AP (Availability, Partition tolerance)
To primarily support availability and partition tolerance, your system may return inaccurate data, but the system will always be available, even in the face of network partitioning.

Row-Oriented

  • Cassandra's data model can be described as a partitioned row store, in which data is stored in sparse multidimensional(다차원) hashtables.
  • "Partitioned" means that each row has a unique key which makes its data accessible, and the keys are used to distribute the rows across multiple data stores.

High Performance

  • Cassandra was designed specifically from the ground up to take full advantage of multiprocessor/multi-core machines, and to run across many dozens of these machines housed in multiple data centers.
  • As you add more servers, you can maintain all of Cassandra's desirable properties(바람직한 특성) without sacrificing performance(성능저하).

Is Cassandra a Good Fit for My Project?

  • if you expect that you can reliably serve traffic with an acceptable level of performance with just a few relational databases, it might be a better choice to do so,
    simply because RDBMSs are easier to run on a single machine and are more familiar.
  • the ability to handle application workloads that require high performance at significant write volumes with many concurrent client threads is one of the primary features of Cassandra.

그렇다면 DMP에 Cassandra를 쓰는게 적합한가???

번외

CAP Theorem

  • CAP Theorem은 분산시스템에서 일관성(Consistency), 가용성(Availability), 분할 용인(Partition tolerance)이라는 세 가지 조건을 모두 만족할 수 없다는 정리로, 세 가지 중 두 가지를 택하라는 것으로 많이 알려졌있다.
  • CAP는 분산시스템 설계에서 기술적인 선택을 돕는다. 분산시스템이 모든 것 특성을 만족시킬 수 없음을 인지하게 하고 선택지를 제공해주는 것이다.

CAP Theorem의 오해와 진실

Brewer가 2000년에 이정리를 발표할 때 P에 대한 정의.
The system continues to operate despite arbitrary message loss or failure of part of the system
2002년에 이에 대해 Gilbert와 Lynch가 이 정리에 대해 증명에 사용된 P에 대한 새로운 정의
The network will be allowed to lose arbitrarily many messages sent from one node to another
  • CAP Theorem의 정의를 살펴보면 마치 C,A,P가 동등한 선상에 있는 것처럼 느껴진다. 이런 연유로 C,A,P가 모두 분산시스템의 특성에 대한 것으로 여겨지지만, 실상은 그렇지 않다.
    앞에서 언급한 정의를 생각해본다면, C와 A는 분산시스템의 특성이지만, P는 그 분산시스템이 돌아가는 네트워크에 대한 특성이다.
  • CAP Theorem의 정의가 이해하기 어렵게 되어 있다. 세 가지 특성 중 두 개까지 고를 수 있다는 것으로도 많이 알려졌는데 마치 P를 포기하고 CA를 선택할 수도 있는 것 같은 기분을 들게 한다.
    하지만 실상은 P의 정의는 네트워크가 임의의 메시지 손질을 할 수 있다는 것을 허용하느냐는 의미로 네트워크가 가끔 장애가 날 수 있다는 것을 인정하냐는 것이다.
    P의 선택을 배제하려면 절대로 장애가 나지 않는 네트워크를 구성해야하지만 그런 것은 세상에 존재하지 않는다. 따라서 원하든 원하지 않든 P는 선택되어야 하며 결국 선택권은 C나 A중 하나 밖에 없다.
애초에 P는 네트워크 장애가 있을 수 있다는 것을 인정하느냐의 문제이고 이는 인정 할 수밖에 없는 문제이므로 처음부터 선택되어있는 것이다.
결국, CAP Theorem이 내포하고 있는 의미는 분산시스템에서 네트워크 장애상황일 때 일관성과 가용성 중 많아도 하나만 선택할 수 있다는 것이다.
하지만 이런 식의 해석은 정상 상황일 때의 분산시스템 동작을 서술해주지 못한다. 이에 대해 Daniel Abadi가 PACELC라는 아주 우아한 표기법을 제시하였다.

CAP보다는 PACELC를 사용하자

CAP는 분산시스템 디자이너의 선택에 도움을 주는 정리다. CAP가 장애 상황일 때의 선택에 대해 서술하는 것으로 생각하면, 정상 상황일 때의 선택에 대해 서술하지 못하게 된다.
그래서 정상상황일 때와 장애상황을 때를 나누어 설명하자는 것이 PACELC의 핵심이다. PACELC의 의미를 인용하자면 아래와 같다.
if there is a partition (P) how does the system tradeoff between availability and consistency (A and C);
else (E) when the system is running as normal in the absence of partitions, how does the system tradeoff between latency (L) and consistency (C)?

  • 파티션(네트워크 장애)상황일 때에는 A와 C는 상충하며 둘 중 하나를 선택해야 한다는 것이다.
  • 변경된 값을 모든 노드에서 바라볼 수 있도록 하려면 신뢰성 있는 프로토콜을 이용하여 데이터에 관여하는 모든 노드에 데이터가 반영되어야 한다.
    하지만 네트워크 단절이 일어나 몇 개의 노드에 접근할 수 없을 때 C를 위해 데이터 반영이 아예 실패하던지 C를 포기하고 일단 접근 가능한 노드들이게 만 데이터를 반영하던지 둘 중의 하나만 골라야 한다.
  • 정상상황일 때에는 L과 C는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다.
– HBase는 PC/EC이다. 장애 상황일때 C를 위해 A를 희생한다. 그렇지 않은 경우에도 C를 위해 L을 희생한다.
– Cassandra는 PA/EL이 가능하도록 디자인 되었다. 설정에 따라 Eventual Consistency의 특성을 가지게 되는데, 이 경우 PA/EL이 된다.
장애 상황인 경우에는 가능한 노드에만 데이터를 반영하고 정상으로 복구되면 필요한 노드에 데이터를 모두 반영한다. 정상상황일때도 Latency를 위해 모든 노드에 데이터를 반영하지 않는다.

결론

  • 절대로 장애가 없는 네트워크는 존재하지 않으며, 따라서 분산시스템에서 P는 무조건 인정하고 들어가야 한다
  • 네트워크가 단절되었을 때 시스템이 어떻게 동작할지 결정해야 하며, 이 때 C와 A를 모두 만족시키는건 불가능하므로 둘 중에 하나를 골라야 한다.
  • CAP로 표현하는 것보다 PACELC로 표현하는 것이 훨씬 명확하다.

[ Cassandra definitive guide(카산드라 완벽 가이드 정리). Chapter1. Beyond Relational Databases ]

반응형
반응형


Chapter1. Beyond Relational Databases

Preface

  • Apache Cassandra는 2009년 1월 Apache에서 Incubator프로젝트로 처음 시작했다.
  • 카산드라는 페이스북, 트위터, 넥플릭스(Netflix)를 포함한 웹상의 가장 큰 회사들에 사용되고 있다.
  • 빠른 쓰기를 수행하고 수백 테라 바이트의 데이터를 분산화 시켜 저장할 수 있고 단일 실패 지점(SPOF)가 없다.
  • 이 책은 Apache Cassandra 3.0과 DataStax Java Driver 버전 3.0을 사용하여 개발되었습니다.

Chapter1. Beyond Relational Databases

If at first the idea is not absurd, then there is no hope for it.
Albert Einstein

What's Wrong with Relational Databases?

  • We encounter scalability problems(확장성 문제) when our relational applications become successful and usage goes up.
  • Joins are inherent in(내재되어 있다) any relatively normalized relational database(상대적으로 정규화된 데이터베이스) of even modest size, and joins can be slow.
  • The way that databases gain consistency is typically through the use of transactions, which require locking some portion of the database so it's not available to other clients.
  • This can become untenable(견딜수 없는) under very heavy loads, as the locks mean that competing users start queuing up, waiting for their turn to read or write the data
We typically address these problems in one or more of the following ways.
  • Throw hardware at the problem by adding more memory, adding faster processors, and upgrading disks.This is known as vertical scaling. - This can relieve you for a time.

  • When the problems arise again, the answer appears to be similar: now that one box is maxed out(최대치), you add hardware in the form of additional boxes in a database cluster.

  • We try to improve our indexes and optimize the queries. But this also has a limitaion.

  • When we use cache, Now we have a consistency problem between updates in the cache and updates in the database, which is exacerbated(악화시키다) over a cluster.

  • For addressing these problems we try denormalization. But this violates rules of relational data.

RDBMS: The Awesome and the Not-So-Much

  • There are many reasons that the relational database has become so overwhelmingly popular over the last four decades.
    • An important one is the Structured Query Language (SQL), which is feature-rich and uses a simple, declarative syntax.
  • SQL is easy to use. The basic syntax can be learned quickly, and conceptually SQL and RDBMSs offer a low barrier to entry.

TRANSACTIONS, ACID-ITY, AND TWO-PHASE COMMIT

  • RDBMSs and SQL also support transactions
  • ACID (Atomic, Consistent, Isolated, Durable)

특징

 DB기능

 설명

 Atomicity(원자성) 

 회복성의 보장, Commit/Rollback

 트랜잭션은 분해가 불가능한 논리적 최소 단위로 실행 전체가 승인되거나 취소되어야 함

(All or Nothing) 

 Consistency(일관성)

 무결성 제약조건, 동시성 제어

 트랜잭션의 수행 이후 데이터는 무결성이 유지되고 모순되지 않아야 함

 Isolation(고립성)

 분산트랜잭션, Lock

 다수의 트랜잭션이 동시에 수행되더라도 개별 트랜잭션의 결과에 영향을 미쳐서는 안됨

 Durability(지속성)

 회복기법, 회복 컴포넌트관리

 성공적으로 수행된 트랜잭션은 해당 요인에 의해 변경 및 손실되지 않아야 함


  • Transactions become difficult under heavy load. When you first attempt to horizontally scale a relational database, making it distributed, you must now account for(고려하다) distributed transactions,
    where the transaction isn't simply operating inside a single table or a single database, but is spread across multiple systems.
  • In order to continue to honor the ACID properties of transactions, you now need a transaction manager to orchestrate(조정) across the multiple nodes.
  • In order to account for successful completion across multiple hosts(여러 호스트에서 성공적 완료를 설명하기 위해), the idea of a two-phase commit (sometimes referred to as “2PC”) is introduced.
  • But then, because two-phase commit locks all associated resources, it is useful only for operations that can complete very quickly.

Gregor Hohpe, a Google architect, wrote a wonderful and often-cited blog entry called“Starbucks Does Not Use Two-Phase Commit”.

스타벅스의 사례에 접목해보면, "2단계 커밋"은 점원(cashier)이 커피가 완성될 때까지 한 고객만을 바라보며 영수증과 돈을 테이블 위에 올려놓고 기다리는 것과 같습니다. 마지막으로 음료가 준비되면, 영수증과 돈으로 일거에 교환하는 것입니다. 이런 상황에서는 점원뿐만 아니라 고객까지도 "트랜잭션(거래)"이 끝날 때 까지 자리를 떠날 수 없게 됩니다. 이러한 "2단계 커밋" 방식을 적용하게 되면 일정 시간에 서비스 할 수 있는 고객 수는 극적으로 감소할 것이고, 스타벅스의 비즈니스를 확실하게 망하게 만들 것입니다. 이것은 2단계 커밋이 일상을 좀 더 단순하게 만들 수는 있지만, 메시지들의 자유로운 흐름을 방해하게 된다(그리고 확장성을 해친다)는 사실을 일깨워 주는 사례입니다. 왜냐하면, 비동기의 다중 작업 흐름 속에서 트랜잭션의 상태를 관리해야 하기 때문입니다.
출처: http://sunnykwak.tistory.com/100 一生牛步行

Summary

  • Relational databases are very good at solving certain(특정) data storage problems, but because of their focus, they also can create problems of their own when it's time to scale.
  • The recent interest in non-relational databases reflects the growing sense of need in the software development community for web scale data solutions.

번외

  • 2000년 후반으로 넘어오면서 인터넷이 활성화되고, 소셜네트워크 서비스 등이 등장하면서 관계형 데이터 또는 정형데이터가 아닌 데이터, 즉 비정형데이터라는 것을 보다 쉽게 담아서 저장하고 처리할 수 있는 구조를 가진 데이터 베이스들이 관심을 받게 되었다.
    • 해당 기술의 발전과 더불어 NoSQL 데이터베이스가 각광을 받게되었고 어떤 엔지니어들은 NoSQL을 Modern web-scale databases라고 정의하기도 한다고 한다.

NoSQL과 RDBMS 차이점

  • 관계형 모델을 사용하지 않으며 테이블간의 조인 기능이 없음
  • 대부분 여러 대의 데이터베이스 서버를 묶어서(클러스터링) 하나의 데이터베이스를 구성
  • 관계형 데이터베이스에서는 지원하는 Data처리 완결성(Transaction ACID 지원) 미보장
  • 데이터의 스키마와 속성들을 다양하게 수용 및 동적 정의(Schema-less)
  • 데이터베이스의 중단 없는 서비스와 자동 복구 기능지원
  • 다수가 Open Source로 제공
  • 확장성, 가용성이 높음

NoSQL 종류

Key Value DB
  • key와 value의 쌍으로 데이터가 저장되는 단순한 형태의 솔루션
  • Riak, Vodemort, Tokyo etc.
Columnar Store
  • Key Value에서 발전된 형태의 Column Family데이터 모델을 사용
  • HBasem Cassandra, ScyllaDB etc.
Document DB
  • JSON, XML과 같은 Collection 데이터 모델 구조를 채택하고 있다.
  • MongoDB, CoughDB etc.
Graph DB

  • Nodes, Relatsionship, Key-value 데이터 모델을 채용하고 있다.
  • Neo4J, OreientDB etc.


반응형

+ Recent posts