하둡 디렉토리hadoop directory) 존재 여부나 파일이 있는지 확인을 해야 하는 경우가 있다.

이 때 사용할 수 있는 명령어가 -test 라는 명령어이다.

help명령어를 통해 사용할 수 있는 옵션을 살펴보면

> hadoop fs -help test 

다음과 같은 옵션을 확인할 수 있다.

보통 해당 하둡 디렉토리 확인 여부(-d), 하둡 path 존재여부(-e), path에 파일 존재하는 여부 확인(-f) 옵션을 자주 사용한다.

보통 다음과 같이 쉘스크립트(shell script)에서 사용할 수 있다.

> -e옵션과 -z옵션을 통한 하둡파일체크

해당 path가 하둡에 있는지 확인(-e)하고 -z 옵션을 이용해 해당 path의 파일의 사이즈가 0byte가 아닌지 확인한다.

위와 같이 하둡디렉토리에 정상적인 파일이 있는 경우 작업시행시 조건으로 사용할 수 있다.

-test(하둡 명령어)를 유용하게 활용해보시길~

톰캣(tomcat)의 기본포트가 8080인 이유를 아시나요???

많은 분들이 WAS로써 톰캣(tomcat)을 사용하실텐데요. 

특히나 요즘은 스프링부트로 인한 임베디드 톰캣을 사용하실줄로 압니다.

톰캣도 그렇고 스프링부트의 임베디드 톰캣도 그렇고 그럼 왜 기본 디폴트 포트는 8080이냐???하는 의문이 생길 수도 있는데요...(저는 그랬습니다...)

간단히 설명을 드리자면 리눅스나 유닉스는 1024이하의 포트(well-known port)들은 일반 유저 권한에서 바인딩 할 수 없도록 되어 있습니다.

이유는 보안때문인데요~!

8080포트에 대한 특별한 이유는 없습니다. 그저 1024이상의 포트중 하나를 임의로 디폴트로 설정한 것 일뿐(이라고 저는 생각합니다.)

하지만 외부 서비스를 해야하는경우에는 80포트로의 접근이 필요한 경우가 있습니다.

단순히 naver.com:8080이라고 사용자들이 접속하게 된다면 불편할테니까요...

그래서 루트권한(sudo)로 톰캣 포트를 80으로 설정 후 어플리케이션을 기동시켜서 사용할 수 는 있습니다.

다만! 위에서 말씀드렸듯 보안 문제가 존재합니다.

애드센스 자동삽입 광고

톰캣서버는 구동시에 tomcat 유저 권한으로 구동되게 됩니다. 때문에 톰캣을 통해 서비스되는 웹을 통해 해킹이 되더라도

tomcat유저 권한에 해당하는 부분까지만 접근 가능하게 됩니다.

따라서 루트권한(sudo)로 80포트로 구동시키게 된다면 해킹당했을 경우보단 안전하다고 할 수 있습니다.

물론 이런 문제를 회피하는 방법은 iptables를 통한 포트포워딩 방식이나 WAS앞단에 웹서버(apache, nginx)를 둬서 해결할 수 있지만

저 경험상에 의해서 iptables를 통해 포트포워딩을 할 경우 문제가 있었던 경험이 있기에 톰캣 80포트 8080 포트로 포워딩 이슈 

앞단에 웹서버를 두시고 서비스하는 방법이 좋다고 생각합니다.

Chapter 2. Introducing Cassandra

Cassandra in 50 Words or Less

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(세 가지 모두 얻을수 있는).

So what does it mean in practical terms(실제적인 측면) to support only two of the three facets of CAP?

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의 오해와 진실

The system continues to operate despite arbitrary message loss or failure of part of the system

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중 하나 밖에 없다.

CAP보다는 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는 상충하며 둘 중 하나를 선택해야 한다. 모든 노드들에 새로운 데이터를 반영하는 것은 상대적으로 긴 응답시간이 필요하기 때문이다.

결론

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

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

리눅스에서 openjdk 업그레이드 하기!!!

1. 자바 버전 확인

2. 설치 가능한 openjdk 버전 확인

3. 설치고자하는 버전을 확인 후 설치

나의 경우에는 설치하고 java -version 명령어를 통해 확인했을 때 잘 업그레이드 된 걸 확인할 수 있었다.

혹시 바뀌지 않은 경우 다음과 같이 바꾸도록 하자.

해당 명령어를 쳐서 원하는 버전의 번호를 선택해주면 된다~!!!!

Column count doesn't match value count at row 1 메세지가 발생한다면

DB에 insert하는 데이터의 개수와 컬럼의 개수가 일치하는지 확인해보시길~

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)

• 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.

보통 웹서비스에서 포트를 두 개 사용하는 경우는 http, https를 사용하는 경우이다.

보통은 ssl작업은 앞단에 웹서버(apache, nginx)를 두지 처리하는데 springboot만으로도 처리가 가능하다.

application.properties에 server.port=8080을 설정해두고 

추가로 8082 포트를 사용하고자 하면 다음과같이  ConfigurableEmbeddedServletContainer에

Connector에 추가로 사용하고자 하는 포트(port)를 설정해 셋팅해주면 된다.

이렇게 설정하고 실행시켜서 테스트해보면

localhost:8080, localhost:8082로 모두 서비스를 사용할 수 있다.

어떻게 언제 사용하냐고????

보통은 http, https 처리하는 경우, 그 외에는 사실 잘모르겠다...

Java8 Stream을 사용하다 보면 자주 발생할 수 있는 미묘한 실수 중에 하나는

이미 사용했던 Stream을 다시 사용하려고 하는 것이다. Stream은 오직 한 번만 사용할 수 있다.

A Stream should be operated on (invoking an intermediate or terminal stream operation) only once. 

A Stream implementation may throw IllegalStateException if it detects that the Stream is being reused.

이미 사용했던 Stream을 또 사용하게 될 경우 다음과 같은 에러 로그를 발견할 수 있을 것이다.

[ 문제가 발생했던 코드 ]

코드를 보면 Stream을 두 번 사용하고 있는 것을 볼 수있다.

로깅기능으로 잠깐 보려고 했던 코드가 문제가 되었다.

정리하자면

Stream shoud be used only Once!!!

[ Spring ] 문제해결 no suitable constructor found, can not deserialize from Object value 

API로 JSON 데이터 받아와 모델에 매핑시키는 부분에서 다음과 같은 에러가 발생하였다.

쉽게 말해 API 응답으로 받아와 JSON 데이터가 내가 매핑하고자 하는 Model에 알맞지 않다는 것이다...

API호출 결과 날아오는 JSON의 형태는 다음과 같았다.

내가 받고자 했던 JAVA MODEL의 형태는 다음과 같았다.

문제는 Result Array 내부에 있는 데이터들을 매핑해 오지 못해생겼던 것 같다.

일단 해결은 내부의 BittrexCoin 클래스에 static을 선언해 해결하였다.

이렇게 inner class를 static으로 변경하고 나니 정상적으로 데이터를 받아 올 수 있었다.

static 지시사의 역할은 메소드나 변수를 메모리에 로딩해서 다른 클래스가 이 클래스의 인스턴스를

생성하지 않고서도 사용할 수 있게 해주는 목적이다. 

RestTemplate으로 요청을 날리면서 동시에 내가 원하는 모델에 매핑해서 데이터를 가져오는데 static을 선언해주지 않았을 경우에

inner class인스턴스를 못만들어내서 매핑이 되지 않는 것 같다. 더 정확한 원인까지는 잘 모르겠다...

나중에 시간되면 더 파고들어볼만한 이슈인 것 같다.

혹시 원인에 대해 아시는분이 계시다면 댓글남겨주시면 감사하겠습니다.