반응형


엘라스틱서치(ElasticSearch)에서 제공하는 API를 통해 데이터를 조회할 때 한번쯤은 'pretty?=true'가 붙어있는 것을 보았을 것이다.


단순히 search의 결과를 보기좋게 출력해주는 파라미터이다. 



[ 'pretty?=true' 사용하지 않고 조회했을 경우 ] 


> curl -XGET http://localhost:9200/logs/_search




[ 'pretty?=true' 사용 ] 


> curl -XGET http://localhost:9200/logs/_search?pretty=true




이미지를 보면 알겠지만 'pretty?=true' 사용하여 조회하는게 훨씬 결과를 보기좋게 볼 수 있다.


콘솔화면에서 데이터 조회시 유용하게 사용할 수 있을 것 같다.

반응형
반응형


신규 맥북(Mac)을 받아 기존에 사용하던 맥북(Mac)에서 사용하던 메모 앱의 파일들을 옮겨야 하는데 


회사규정상 icloud가 막혀있어 되게 난감한 상황이였다. 


그러다가 'exporter'라는 앱을 발견!!! 보아하니 맥북(Mac)의 메모 파일들을 모두 .txt 파일로 추출해준다.


그래서 한 번 사용해봤더니 정말 간편하다:)


https://itunes.apple.com/us/app/exporter/id1099120373?mt=12




다운 받은 후 앱을 켜서 사용해보자!



저기 가운데 별모양을 누르고 맥북의 노트들을 .txt파일로 추출해 저장할 디렉토리만 설정해주면 끄읕~!



작업이 진행되고 작업이 끝나면 추출된 파일을 볼 수 있다.



짜자안~!!!!


맥북(mac)에 메모 파일을 .txt파일로 추출할 일이 있을 때 써보자~





반응형
반응형
이전에 데이터 처리하는 어플리케이션을 개발할 때 NoSQL로 어떤걸 쓰면 좋을지 조사한 글을 포스팅해본다.
그 당시 고민했던 NoSQL 중 카산드라(Cassandra), HBASE, MongoDB 세 가지로 선정해 조사했었다.
RDBMS? NOSQL?
  • 데이터의 읽기 쓰기 등 퍼포먼스에 치중한다면 NOSQL, 트랜잭션과 같은 정합성 위주의 시스템을 사용한다면 RDBMS
  • RDBMS 컬럼 변경 용이하지 않음, NOSQL 컬럼 변경 용이
  • NOSQL의 경우 sorting, join, grouping, range query, index 매우 취약
  • RDBMS 학습 비용 x
  • NOSQL 학습 비용 소요 (운영시 어떤 장애상황이 생길지 예측이 어려움)
  • NOSQL 가장 큰 장점 (Scale-Out, RDBMS보다 상대적으로 빠른 쓰기/읽기)

NOSQL 분류
[ 키 밸류형 ] redis, memcached, Oracle Coherence
[ 컬럼형 ] Cassandra, HBASE, Cloud Datastore
[ 문서형 ] MongoDB, Couchbase, MarkLogic, PostgreSQL, MySQL, DynamoDB MS-DocumentDB
[ 그래프형 ] Neo4j

DataStore설 명장 점단 점
Cassandra

-Facebook에 의해 2008년 아파치 오픈소스로 공개된 분산 데이터 베이스 (자바 언어 기반) 
-컬럼 단위로 관리되어 컬럼형으로 분류 
-대용량의 데이터 트랜잭션에 대해 고성능 처리가 가능(실제 트위터 MYSQL -> Cassandra로 전환)

-대량으로 쓰기가 발생하는 서비스에 좋음 
-확장성이 뛰어남  
-Apache Foundation에서 개발중이며커뮤니티 활발 
- Scale-Out

-최소 3대 이상 구성(클러스터 환경) 
-복잡한 조건 검색 불가 
-데이터 갱신 및 입력시 Atomic한 처리가 힘듬

HBase

-대량 데이터를 우수한 성능으로 데이터 일관성을 보장하면서 다뤄야 할 때 주로 사용 
-대량 데이터 분석 및 처리를 위해 사용되는 Hadoop의 산하 프로젝트로 시작된 데이터베이스 (HDFS 및 MapReduce등과 함께 사용하기에 최적화) 
-수십 테러바이트가 넘는 빅데이터에 적합

-하둡 기반에서 동작하고 다양한 하둡 의 도구들과 상호 운영성이 좋음
-데이터 일관성 보장 우수(상대적)

-5대 미만에서는 사용할 수 없다(대규모 전용) 
-성능이 좋진 않다 (상대적)

MongoDB

-MongoDB는 10gen 사에서 개발된 높은 성능과 확장성을 가지고 있는 데이터베이스
NoSQL 데이터베이스에서는 문서형 데이터베이스로 분류(C언어 기반)
-데이터를 입력할때 데이터 구조 정보를 포함하여 BSON(JSON을 바이너리화한것)형식으로 저장하고, key value로 사용
-NON-SCHEMA
-비정형 데이터, 파일 데이터등의 스키마프리(Scheme free)모델에서 적합  - SQL 과 비슷한 방식의 쿼리 사용

-스키마 없이 사용 가능 
-SQL 과 비슷한 방식의 쿼리 사용 
-몽고는 쓰기할때 메모리에 먼저 Write 후에
  1분 단위로 Flushing하는 Write back 방식을     사용한기 때문에 write성능이 좋음
-Read시에는 파일의 Index를 메모리에 로딩해   놓고 찾는다(memory mapped file) - 빠름
-다양한 기능 제공

-JOIN이나 트랜잭션 처리가 불가능 
-디스크에 쓰기가 비동기식으로 이루어진다. 때문에 경우에 따라 데이터가 유실될 가능성도 있다.

[ Cassandra & HBase ]

  • 카산드라 클러스터 설정 및 구성이 HBase 클러스터 구성보다 훨씬 쉽다.
  • 카산드라가 일반적으로 write시 5배 이상의 더 나은 성능, read시 4배 이상의 성능을 보인다.

[ Cassandra & MongoDB ]

  • Cassandra 노드가 추가될수록 MonogoDB  보다 훨씬 나은 선형적인 성능 향상을 보인다.
    - 다중 Index가 필요한 구조라면 MongoDB를 선택하고, 데이터 항목 변경이 많고 unique access가 많은 경우라면 Cassandra가 적합
  • http://db-engines.com/en/system/Cassandra;MongoDB

성능비교

https://academy.datastax.com/planet-cassandra/nosql-performance-benchmarks
https://www.datastax.com/nosql-databases/benchmarks-cassandra-vs-mongodb-vs-hbase



반응형
반응형


OSX Server의 경우 curl은 별도 설치가 필요 없지만 wget 은 설치가 필요하다.


물론 설치를 하면 되지만 귀찮다면 curl을 사용하도록 하자.


MAC에서 wget이 안먹힐 떄


curl -O -L '다운받을경로' 를 사용하여 다운받을 수 있다


여기서 끝내면 아쉬우니 간단히 둘의 공통점과 차이점에 대해서 자료를 가져왔다.



[ wget, curl 공통점 ]

둘다 FTP, HTT, HTTPS 로 자료를 전송할 수 있다.

둘다 HTTP POST 요청을 보낼 수 있다.
둘다 HTTP 쿠키를 지원한다.
둘다 스크립트처럼 사용자와 상호작용없이 작동한다. 
둘다 오픈소스이며 무료다.
둘다 90년대부터 시작한 프로젝트이다.
둘다 메타링크를 지원한다.

.

 

[ wget, curl 차이점 ]

1. curl
-  라이브러리 존재 libcurl . 
- 더 다양한 프로토콜 지원
- 더 다양한 플랫폼에서 빌드/작동 가능. 
- 더 다양한 SSL 라이브러리와 SSL 지원.
- 더 활발히 개발 중

2. wget
- 라이브러리 없음.
- Recursive! 재귀적! 가장 큰 장점. 디렉토리 구조와 파일을 그대로 복사해 온다.
- 더 오래되었음 Wget 1995, curl late 1996)
- 100% GPL v3. curl is MIT licensed.

참고 : http://daniel.haxx.se/docs/curl-vs-wget.html

반응형
반응형


엘라스틱서치(ElasticSearch) 설치 후 /bin/elasticsearch 실행하는 과정에서 다음과 같은 에러가 발생했다.


(java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed)


java.lang.UnsupportedOperationException: seccomp unavailable: CONFIG_SECCOMP not compiled into kernel, CONFIG_SECCOMP and CONFIG_SECCOMP_FILTER are needed

        at org.elasticsearch.bootstrap.SystemCallFilter.linuxImpl(SystemCallFilter.java:364) ~[elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.SystemCallFilter.init(SystemCallFilter.java:639) ~[elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.JNANatives.tryInstallSystemCallFilter(JNANatives.java:258) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Natives.tryInstallSystemCallFilter(Natives.java:113) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Bootstrap.initializeNatives(Bootstrap.java:111) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:195) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:342) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:132) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Elasticsearch.execute(Elasticsearch.java:123) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.cli.EnvironmentAwareCommand.execute(EnvironmentAwareCommand.java:70) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.cli.Command.mainWithoutErrorHandling(Command.java:134) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.cli.Command.main(Command.java:90) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:91) [elasticsearch-5.6.3.jar:5.6.3]

        at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:84) [elasticsearch-5.6.3.jar:5.6.3]


로그를 보아하니 커널에서 seccomp를 지원하지 않는 것 같았고 엘라스틱서치(ElasticSearch) 버전 5.2.0 이상부터는 seccomp를 기본적으로 사용하도록 되어있다고 한다.


문제 해결은 /config/elasticsearch.yml 에 들어가서 


bootstrap.system_call_filter: false


를 기입해주면 된다. 그리고 다시 실행해보면 문제 없이 엘라스틱서치가 실행되는 것을 확인할 수 있을 것이다.


에러가 발생했을 때도 엘라스틱서치는 정상적으로 구동되는것 같긴한데...정확히 어떤 부분에 영향을 미칠지 몰라 불안하긴하다. 


Seccomp(Secure Computing Mode)의 약어로 프로세스가 호출할 수 있는 system call을 제한하는 역할을 하는 것인데


해당 역할을 true로 해주었을 떄 정확하게 어떤 부분이 좋은지에 대해서는 조사가 더 필요할 것 같다.


참고 : https://github.com/elastic/elasticsearch/issues/22899

반응형
반응형


MAC 터미널에서 혹시나 메이븐(maven)을 통해 빌드해야하는 경우가 있을 경우 메이븐(maven)을 설치해주어야 한다.

밑의 url에 들어가 tar.gz 파일을 다운받아서 압축을 풀어준다.

http://maven.apache.org/download.cgi

그 후 mvn 명령어로 손쉽게 메이븐(maven)을 사용하기 위해 환경변수를 설정해준다.

vi ~/.bash_profile

vi로 열어서 압축을 푼 곳의 디렉토리 위치를 설정해준다.

#path setting
export M2_HOME=/Users/nhnent/Documents/apache-maven-3.5.2   (본인의 압축 푼 경로에 맞게!!!)
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

저장 후 설정 변경을 위해 다음 명령을 실행한다.

source ~/.bash_profile

실행 후 echo $PATH 를 해보면 본인의 PC에 설정된 path들의 리스트가 출력된다.

해당 리스트에 메이븐(maven) PATH가 정상적으로 추가되었다면 mvn -version을 통해 확인해 볼 수 있다.

mvn -version 명령을 내렸을 경우 이런 버전을 나타내는 stdout이 출력되지 않았다면 정상적으로 설치되지 않은 경우이기 떄문에

설치 경로 및 환경변수를 다시 한 번 확인이 필요하다.


반응형
반응형


작업 중 java.sql.SQLException: Before start of result set 오류가 발생하였다.



뭔가 하고 보니 소스코드에서 mysql에 질의를 던져 데이터를 가져와서 ResultSet에 담는데 ResultSet에서 데이터를 읽을 경우 cursor의 points를 첫 번째 로우에 맞추어주어야 한다.


즉, 결과값을 읽기전에 next() 메서드를 호출 후 사용 하여야 한다. 


[ 오류가 발생했던 소스코드 ] 




[ 문제 해결 소스코드 ] 



보다시피 result.next() 전에 result.getString()으로 값을 불러오려고 했을 때 문제가 발생했다.

result.next() while문 안으로 넣어서 해결~!

반응형
반응형

톰캣은 웹 애플리케이션을 어떻게 관리하는가?


톰캣은 한 번에 여러 개의 웹 애플리케이션을 실행할 수 있도록 설계되어 있다.

웹 애플리케이션은 배포 명세서 web.xml을 가진 WAR 파일로 정의되어 있다. 대개 서버는 하나의 톰캣 인스턴스를 실행하며 관련된 WAR 파일이 톰캣 인스턴스의 webapps 디렉터리에 설치된다. 이는 기본 설정이며 위치를 변경할 수 있다.


톰캣의 구성 요소들

톰캣은 몇 가지 구성 요소로 이루어져 있는데, 그중 하나가 서블릿 컨테이너와 JSP를 처리하는 것이다. 서블릿 컨테이너 구성 요소는 카탈리나(Catalina)라고 하며 JSP 구성 요소는 재스퍼(Jasper)라고 한다.


톰캠 사용 문서를 읽다 보면 이 이름들에 대한 참조를 쉽게 볼 수 있다. 예를 들어 결과 로그 파일의 기본 이름은 catalina.out이고, 톰캣 홈 디렉터리의 환경 변수는 $CATALINA_HOME이다.


기본으로 실행 중인 톰캣 인스턴스는 webapps 디렉터리에서 일어난 변화를 감지한다. 새 WAR 파일이 이 디렉터리에 저장되면 톰캣은 WAR 파일 이름에 대응하는 디렉터리에 파일 내용을 풀어놓고 컨텍스트의 애플리케이션을 해당 이름에 대응시킨다.


예를 들어 BookingApplication.war라는 WAR파일을 webapps 디렉터리에 배포하면 그 파일은 BookingApplication 디렉터리에 압축을 푼다. 톰캣은 WEB-INF 하위에 있는 web.xml 파일을 읽고 정의된 대로 애플리케이션을 실행하고 /BookingApplication 경로를 통해 클라이언트에게 제공한다.


이 접근 방법은 개발 방향을 빠르게 전환하는 데 상당히 유용하다. 지속해서 배포 할 수 있는 방법을 갖게 할 뿐만 아니라 접근할 수 있는 서버에 단위 테스트를 완료해 빌드된 WAR 파일을 자동으로 배포할 수 있으며 통합 테스트를 준비할 수 있기 때문이다. 테스트 범위가 충분하고 팀의 개발 프로세스가 가능하다면 실제 환경에도 자동으로 배포되게 할 수 있다.


# Reference - 자바프로그래밍 면접 이렇게 준비한다.

반응형
반응형

WAR 파일이란 무엇인가?



웹 아카이브Web Archive 파일인 WAR 파일은 자바의 JAR 파일과 같은 역할을 하며, 주로 웹 어플리케이션을 묶는 데 사용된다. 파일 안에는 애플리케이션을 실행하기 위해 컴파일된 모든 클래스 파일들뿐만 아니라 제공되어야 하는 모든 프로퍼티 파일과 다른 설정 파일들도 포함된다.


WAR 파일의 가장 중요한 점은 웹 애플리케이션을 어떻게 설정할지 정의한 배포 명세서(web.xml 파일)가 있다는 것이다. 이 파일은 애플리케이션 서버에게 애플리케이션을 어떻게 배포하고 제공할지에 관한 내용을 명령으로 제공한다.


IntelliJ IDEA나 이클립스 같은 IDE 대부분은 프로젝트에서 클릭 몇 번으로 WAR파일을 생성할 수 있다. 메이븐 상단에 packaging태그를 사용해 쉽게 WAR파일을 생성할 수 있다.




반응형

+ Recent posts