version을 낮추면, 기존의 생성한 인덱스들(documents)?도 버전을 맞춰줘야한다

필자의 경우 아예 인덱스를 삭제 후 재생성했다

롱주컨트리 1828283637

위키와 블로그에서 읽은 글을 나름대로 요약해본다

구입할 카메라를 고르는 과정에서 둘을 비교하게 되었다

우선 Mirrorless와 DSLR을 비교해보자

Mirrorless는 말그대로 거울이 없다는 뜻.

DSLR의 풀네임은 Digital Single-Lens Reflex camera

거울은 카메라 내부에 있는 것을 의미하는 것으로, 거울이 빠지면서 카메라의 크기와 무게가 작아진다는 장점이 있다.

즉, 휴대가 편리하다.

그래서 카메라 입문용으로는 Mirrorless가 적합해보인다

이건 그냥 생각이지만, 스마트폰 카메라보다 Mirrorless 카메라가 야간촬영에 더 우세하지 않을까 라는 기대를 가지고 있다. 만약 맞다면 이것은 스마트폰과 비교했을 때의 장점이 되겠다.

(추가: 아래 링크에서 카메라 화질비교를 확인할수 있었고, 센서크기 등으로 인해 확실히 스마트폰 카메라의 노이즈가 훨씬 심했다. 추가로 고가격 하이엔드 디카와 보급형 미러리스도 큰 차이가 없음을 확인할 수 있다

https://m.blog.naver.com/PostView.nhn?blogId=clauds&logNo=220779707145&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

)

아래 링크에서는 DSLR을 설명하면서, 카메라에서 중요한 것은 렌즈라고 이야기한다 (화소가 아니라)

Mirrorless와 DSLR 둘다 렌즈를 교체할 수 있다는 공통점이 있다.

하지만 컴팩트 카메라는 아니다

지금까지 4가지의 카메라를 다루었다. 스마트폰 카메라, 컴팩트 카메라, Mirrorless, DSLR.

현재 스마트폰 카메라를 사용하고 있으며, 야간촬영 노이즈에서 불편함을 느꼈다

컴팩트 카메라(똑딱이, 디지털 카메라)는 스마트폰 카메라의 하위호환이 된것같다. 스마트폰 카메라보다 성능상 메리트는 크지 않다고 느껴지며 스마트폰 카메라보다 사진 저장&업로드에 불편함이 있다

추가로, 하이엔드 디카는 성능이 우수하다. 하지만 Mirrorless가 나오면서 1세대는 소멸했고 더 작은 크기의 2세대가 활동중이라고 한다

Mirrorless는 스마트폰 카메라 이상의 화질을 원하며, DSLR을 다룰만큼 전문가가 아닌 입문자에게 적당하게 보인다. 사진 저장이나 업로드의 단점은 있을수도 있겠지만 (카메라 옵션기능에서 극복할수 있을수도 있고)

특히 카메라 렌즈를 다뤄볼수 있다는 점도 크다. 기본렌즈만을 사용해도 문제없고.

DSLR은 최고의 성능을 자랑하지만 입문자에게는 난이도나 가격이 부담스러울 것 같다.

과거였으면 ISO 등의 값을 설정할 수 있는 것이 카메라의 장점이었겠으나, 최신 스마트폰에서는 그런 기능까지 지원하더라. 그래서 그것은 카메라의 장점으로 서술하지 않았다.

결론 내자면,

스마트폰 카메라보다 조금더 좋은 성능을 원한다면 미러리스 카메라를 통해 입문해보도록 하자.

미러리스 vs DSLR 차이

http://beautinaru.tistory.com/56

나무위키 - 하이엔드 카메라

https://namu.wiki/w/%ED%95%98%EC%9D%B4%EC%97%94%EB%93%9C%20%EC%B9%B4%EB%A9%94%EB%9D%BC

https://stackoverflow.com/a/44875175

또는

sudo mongod --httpinterface --port 27018

https://stackoverflow.com/a/7948986

http://devman.tistory.com/entry/MONGO-DB-%EC%89%BD%EA%B2%8C-%EC%84%A4%EC%B9%98%ED%95%98%EA%B8%B0-%EB%B0%8F-%EC%B2%B4%ED%81%AC%EC%82%AC%ED%95%AD-STEP-by-STEP

http server가 잘 실행되면 로그의 마지막에서 아래 메세지를 확인할수 있다

[websvr] admin web console waiting for connections on port 28018

27018은 내부에서 사용하는 포트이고,

브라우저를 통해 접속할 포트는 +1000한 28018라는 의미이다

MySQL: RDBMS로서, 스키마가 필요하여 테이블 생성/수정이 번거롭다

PostgreSQL: ORDBMS로서 MySQL과 단점 동일

MongoDB: Doc-based NoSQL DB, schema-less라는 장점.

Elasticsearch: Search Engine으로서 NoSQL DB의 솔루션으로 활용가능. schema-less, query에 대하여 analyzing, tokenizing이 가능.

https://cloud.google.com/compute/pricing?hl=ko

Compute Engine은 Google Cloud Platform 무료 등급의 일환으로 특정 한도까지 일정량을 무료로 사용할 수 있습니다.

• 표준 영구 디스크 저장소 30GB/월

영구 디스크 가격 책정 (Standard Persistent Disk)

<가이드북>
하나투어 앱 등에서 여행정보를 제공한다

<면세점>

입국 기준으로 면세 한도는 600달러이다

면세점은 출국/입국 시 총 2회 방문할 수 있는 것 같다 (비행기 타기 전)

단, 술/담배/향수는 한도에서 제외이며 일본공항에서는 일본 면세점을 가야하므로 출국 시에 사는게 편하다는듯

https://m.blog.naver.com/PostView.nhn?blogId=kata_good&logNo=220746916195&proxyReferer=https%3A%2F%2Fwww.google.com%2F

<캐리어>

물건 넣을 공간 남겨놓자

네임택, 배낭도 추가로 챙겨가자

그리고 우산도

<메모>

돈키호테에서 10만원 이상 구매하면 할인(관세할인?)을 해준다

돈은 10,000엔씩 여러 주머니에 분산보관

<살것>

시계/향수/담배 - 면세점

로이스 초콜릿

우마이봉 오이시이아지 (큰 사이즈 1가지맛)

곤약젤리 (입국 제한)

<가볼만한 곳>

난바 파크스

유니버셜 스튜디오 (구경&놀이공원)

돈키호테

덴덴타운

도톤보리 강

오사카 성

온천 (스파 스미노에, 주오선 요쓰바시선)

주택 박물관

만다라케

부엉이 카페

(디즈니랜드)

GCE: Google Cloud Engine

https://cloud.google.com/compute/docs/disks/add-persistent-disk#resize_pd

disk 탭으로 가서 disk의 이름을 클릭하고 용량을 적는다

debian linux의 경우 reboot하면 자동으로 resize 된다

주의: 사이즈를 줄이는건 안된다

Windows 포맷 시 GPT 파티션 관련 에러 fix 방법

https://m.blog.naver.com/PostView.nhn?blogId=withdon&logNo=220950154800&proxyReferer=&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F

(GPT는 Windows를 서포트하지 않는다)

GPT: GUID Partition Table

<---> MBR: Master Boot Record

<여행코스 계획>

가이드북같은 것을 참고하면 좋을것 같다

유니버셜 스튜디오는 유니버셜 스튜디오 패스라는 입장권이 필요한데, 현재 기준 7900엔인듯하다

그리고 추가로 익스프레스를 구입하면 줄을 안서도 된다는데, 본인은 구입안함.

온라인으로 티켓구매가 더 싸진 않지만 줄을 안서도 되므로, 전날 구입할 생각 (일정이 어떻게 될지 모르므로 전날 구매)

온천도 가보려는데, 들은 정보에 의하면 수건을 챙겨가야 한다는듯. (다 그런진 모르겠지만)

가볼만한 곳만 알아보고, 코스는 구체적으로 짜지는 않으련다..

<여행자보험>

한화다이렉트에서 3500원 정도에 가입했다 저렴하게

혜택은 분실/파손 시 20만원까지 보상해주는 것이 눈에 띄더라 (품목당 가격과 품목갯수 제한이 있는듯)

<유심/데이터>
일본 8일 4G 데이터 무제한 유심을 WAUG(와그)라는 곳에서 온라인 구입했다

8일 13000원이면 약 1600원/일 정도이므로 포켓와이파이 3300원/일에 비하면 절반정도의 가격이다

<환전>

KB 리브 앱으로 환전우대 80% 받아서

8만엔 환전에 1만원 혜택받았다

공항에서 수령하기에는 사람이 많을 것 같으므로 지점에서 수령하기로 했다

<교통/패스>

지인에게 스이카라는 교통카드를 빌렸다

스이카를 왜 써야하는지는 아래 블로그에 잘 설명되어있는데

http://blog.naver.com/PostView.nhn?blogId=smmsnanumi&logNo=220917441025&parentCategoryNo=&categoryNo=47&viewDate=&isShowPopularPosts=true&from=search

오사카 주유패스를 사용하면 대중교통을 무제한으로 이용할 수 있지만, 가장 긴 상품이 2일3일?

주유패스가 아니면 지하철표를 매번 끊어야하지만, 스이카를 사용하면 편리하게 이용할수 있다는 듯하다

<전자제품>

일본은 100V 50Hz 또는 60Hz를 사용한다고 한다 (우리나라는 220V 60Hz)

그래서 어댑터 또는 변압기가 필요하다

본인의 스마트폰 충전기는 정격입력이 100-240V 50-60Hz이므로, 100V 50-60Hz도 호환된다

그러므로 어댑터만 있으면 됨

하지만 100V나 50Hz가 호환되지 않는 제품이라면 변압기가 필요하다

그리고 추가로, 멀티 콘센트도 가져가면 어댑터 하나로 여러 제품을 사용할 수 있으므로 가져가자

그리고 드라이기. 다행히 호스텔에 비치되어 있다고 한다

카메라, 노트북 등의 제품도 정격입력 확인하자

<여행물품>

액체들은 작은 용기에 담아가야 한다 (로션/폼 클렌저/치약 등)

셀카봉 가져갈 계획.

<그외 정보>

음식점은 8시에 거의다 닫는다고 한다

호스텔에 수화물 보관소가 따로 제공되는듯 하다!

첫 여행, 초보 여행, 게다가 혼자 준비하고 혼자 오사카를 가려고 한다

특히 일주일 전에 급하게 예매해서 가느라 더 난리였다

아무튼 나중에 참고하기 위해 그 일지를 기록하려고 한다

<여권>

여권은 예전에 만들어둔게 있었다 (해외여행 간적은 없음)

Date of expiry도 넉넉했다 (비행기 예매할 때 보니 귀국날짜보다 여권만료일이 6개월 더 남아있어야 하더라)

<비행기 예매, 호스텔 예약>

비행기 예매는 skyscanner.com에서 했다

오사카/후쿠오카는 25만원 정도가 보통인것 같더라

본인은 일주일 후에 출국할 항공권을 급하게 예매하느라 32만원으로 예매했는데 그마저도 힘들었다

기간은 8박9일 (원래는 6박7일이었는데 예매 과정에서 항공권 가격 맞추느라 늘어남;)

"비행기 예매할 때 최저가 항공권의 수화물 여부/내 카드로 결제시의 가격/탑승시간을 자세히 확인하자"

"그리고 특가행사나 출발 1~2일전에 훨씬 싸게 예매할 수 있다고 한다"

호스텔 예매는 booking.com에서 했다

숙소가격은 1박 기준 호스텔(게스트 하우스)는 2~3만원, 호텔은 5~만원인듯 하다

본인은 오사카 근처 호스텔로 16500엔/8박으로 예약했다 (특가였던 것 같음)

예약한 방 이름은 혼성 도미토리룸 내 싱글침대.

혼자 여행이므로 싸게 호스텔로 예약하였다

그리고 호스텔에서 다른 여행객들을 만나서, 심심하지 않을수도.

그런데 분실도난은 조심해야 할것같다

(방 어떻게 생겼는지도 모르고 예약함 ㅎㅎ)

호스텔 예약 후 비행기 예매를 했는데, 예매 과정에서 여행기간이 늘어났다

취소 수수료가 있는 호스텔이라서, 여행기간 변경에 수수료가 들까봐 걱정했는데

숙소 측에서 잘 변경해주어서 다행

<여행테마 및 코스>

여행테마는 몇가지로 분류할 수 있을 것 같더라

관광, 휴양, 식도락, 쇼핑

본인은 관광/식도락으로 가려고 한다

원래는 여행코스를 먼저 계획하고 예매를 하는 게 맞는것 같은데, 급해서 일단 그냥 예매부터 함;

유니버설 스튜디오, 디즈니랜드 등등 많은 추천지가 있는데

디즈니랜드는 줄을 몇십분씩 서야하는듯. 혼자 여행이라서 거기는 포기 ㅎㅎ

<교통수단>

총 3가지의 대중교통을 이용할수 있는듯 하다

철도, 택시, 버스

도착하면 공항-숙소까지 철도를 타고갈 생각이고

그 후에는, 아직 모르겠다 ㅎㅎ

택시는 편한대신 비싸고, 버스는 조금 불편할수도 있다는 듯 하다

<여행자보험>

여행은 준비해야할 것들이 정말 많다

첫번째는 여행자보험. 가까운 일본이긴 하지만 홀로여행이므로 보험도 들고 가려고한다

가격은 3천원~1만원정도에서 가능한듯

<인터넷>

그리고 인터넷. 비행기 예매를 하나투어에서 결제했는데, 포켓와이파이는 일본기준 3300원/일이더라

다른 방법으로 데이터 로밍과 현지 유심이 있는데, 데이터 로밍은 엄청 비싼것 같고

현지 유심이 혼자 여행 기준 가장 싼것같다

한국에서 살수도, 현지에서 살수도 있는 것 같다

7일짜리, 8일짜리 등 상품들이 별도로 있는데 8일기준 14000원짜리도 있더라

<환전>

마지막 환전. 환전에는 수수료가 있다

일본이므로 이중환전같은 건 안해도 되고

인터넷/모바일앱으로 환전시 수수료가 할인된다고 하는데, 알아봐야됨.

여행일당 10,000엔정도로 환전하면 된다고 다른 블로그에서 읽었음

<캐리어(수화물)>

수화물 위탁이 항공권 옵션인것 같더라.

근데 아시아나항공은 기본옵션인듯

항공권 예약할 때 수화물 위탁 해주는지도 잘 확인하자

<Elasticsearch?>

엘라스틱 서치란 Lucene-Based Search engine으로, data를 저장하고 indexing하여 빠르게 search할수있다

search engine으로 활용하거나 Mongodb처럼 NoSQL로도 활용할 수 있다

NoSQL로 활용할 때의 장점은 RDB보다 서치 퍼포먼스와 scalability(확장성)가 뛰어나다는 것이다

또한 REST API를 기본적으로 제공한다

REST API는 아래 형식의 curl로 사용할 수 있다

curl -H "Content-Type: application/json" -X<method> <url> -d '<json data>'

<Elasticsearch 6 Breaking changes>

5버전에서는 index당 여러개의 type을 가지고있었는데, 6버전에서는 index-type 1:1 관계이다

이것은 mapping을 remove하기 위한 first step이라고 문서에서 언급하고 있다

여러개의 type을 create하려고하면 reject 메세지를 받게된다

<python client library>

필자는 python에서 elasticsearch를 사용하고 있다

python에는 client library로 크게 두가지가 있다

low-level인 elasticsearch-py

high-level인 elasticsearch-dsl

DSL은 Domain Specific Language를 의미한다

elasticsearch-dsl은 ORM을 사용할 수 있다는 점이 큰 차이이다

주의할 점은 elasticsearch server version과 client library version을 sync해야 한다는 점이다

<구조>

사용법을 보기전에, 기본적인 구조를 보자

Elasticsearch의 구조를 URL 형태로 살펴보자

http://server/index/doc_type/doc_id

server가 있고

그 아래에 여러개의 index들

그 아래에 1개의 doc_type (Elasticsearch 6버전은 index가 type을 한개씩만 가짐)

그 아래에 여러개의 doc_id들

이 존재한다

이것은 논리적 배치이고, 피지컬 배치는 node/shard가 있는데 아래 포스트를 참고하자

http://ssaemo.tistory.com/126

<document version field>

RDB에는 transaction이 있는데, Elasticsearch에서는 어떻게 처리해야할까?를 생각했었는데,

version field가 그 역할을 해준다

document의 몇가지 필드를 살펴보자

_id: document id

_source: document data fields

version: document's version

document가 create되면 version: 1이다

그리고 update 될때마다 version이 1씩 증가한다

만약 동시에 같은 document를 update하려고 한다면?

version: 1인 document에 2개의 update request가 발생했다고 하자

2개의 update 중 먼저 끝나는 것이 document의 version을 2로 update할 것이다

그러면 그 다음에 끝난 update는 version이 이미 2로 update되었으므로 document version conflict가 발생한다

즉, 누가 먼저 request를 보냈든 먼저 완료된 update가 적용된다

_update API의 conflict 옵션으로 proceed를 주면 이것을 무시하고 document를 update한다

이렇게 elasticsearch에서는 version field를 통해 동시요청을 처리할 수 있다

<Elasticsearch examples>

postman으로 아래 예제들을 매우 편리하게 테스트해볼 수 있다 (또는 curl)

단 GET 메서드에서는 body를 입력할수 없게 되어있으므로 POST 메서드를 사용하자

index, search, random scoring, aggregation를 설명할 것이다

Elasticsearch에서 RDB의 Insert는 Index에 해당한다

구조상의 index와 api상의 index는 다른 의미이고, RDB의 insert에 대응되는건 후자의 index이다

아래는 index API example이다

URL: /index/doc_type

body: {

"_id": <id>

"_source": {

"my_field": "my_value",

...

}

}

_id 필드가 없을 경우 랜덤하게 할당된다

또는

URL: /index/doc_type/doc_id

body: {

"my_field": "my_value",

...

}

index 예제를 매우 심플하게 살펴보았고 search example을 소개하겠다

elasticsearch의 핵심이고 매우 다양한 syntax들이 존재한다

우선 모든 document들을 검색하는 예제

URL: /index/doc_type/_search

body: {

"from": 0,

"size": 10,

"query": {

"match_all": {}

},

"sort": {

"my_field": "asc",

...

}

}

(sort field 형식이 저게 맞는지 가물가물하다)

이하 search 예제들의 URL은 모두 위와 같다

body를 아예 비우거나, {}를 보내거나, 위와 같이 보낼 경우 10개의 document를 response로 받을 수 있다

from, size, sort 필드는 옵션이고, 각 필드가 없을경우 기본값은 위와같이 0과 10이다 / sort 필드는 기본값이 _score - _id 순으로 정렬일 것이다 아마

query 필드가 있는데, 이 필드에 따라 search 결과가 결정된다

모든 문서 출력 예제를 보았으니, Elasticsearch의 filter를 소개하겠다. 이것은 RDB의 WHERE절에 대응되는 키워드이다

아래 documentation을 참고하였다

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-filtered-query.html

{

"query": {

"bool": {

"filter": {

"term": {

"my_field": "my_term",

...

}

}

}

}

}

굉장히 복잡해보이는데(callback hell같다) 하나하나 풀어보자

일부 document를 search하기위해 query 필드를 사용하였고

bool은 document search를 할때 True or False로만 판단하기 위해서 사용한 것이다

자세한 설명은 아래의 _score를 참고하자

filter는 위에서 말했듯 RDB의 WHERE절의 기능을 한다

term은 말그대로 단어를 검색하는 것이다. 특정 필드에서 특정 단어를 검색한다

term과 비슷한 것으로 match가 있는데, match는 완벽일치하는 것만 필터링하고

term은 일부분만 일치해도 될때도 있다. 이건 또 analyzer 관련 내용이므로 패스하고

현재 analyzer를 사용하지 않는 상태에서는 term과 match 둘다 완벽일치한 결과만 response한다

결과적으로 my_field의 값이 my_term인 document만 search 결과로 리턴될것이다

term 뿐 아니라 terms도 존재한다

{

"query": {

"bool": {

"filter": {

"terms": {

"my_field": ["my_term1", "my_term2", ...],

...

}

}

}

}

}

(기억을 더듬는거라 틀릴지도)

my_field의 값이 my_term1 OR my_term2인 document들을 리턴한다

위에서 _score를 언급하기로 했었다

각 document의 _score는 relevance를 의미하는데, 유사성/일치성이다

search의 sort 기본값은 search result를 _score 순으로 sorting 함으로써 가장 유사한 document를 최상단에 배치시킨다

어쨌든 elasticsearch는 search를 할때 각 document의 relevance를 계산한다

match_all 또는 bool search를 할때는 모든 document의 _score가 1 또는 null로 세팅된다

즉 bool 필드를 사용할 경우, _score를 계산하지 않는다

그 결과 속도가 더 빨라지고, caching도 가능하다고 한다

bool 필드는 오버헤드를 줄이기 위해 사용한 것이다

오버헤드의 핵심은 _score이고, 이것은 partial search에서 relevance 정보를 표현한다

analyzer로 간단하게 언급하자면, partial search를 할때 "Good bye"라는 값을 "good"과 "bye"로 나눔으로써

partial search를 가능하게 해주는 것이 바로 analyzer이다

각 필드마다 analyzer를 할당할 수 있다

필자는 NoSQL 용도로 사용하고 있으므로, 이정도까지 간단하게 이해하였다

random을 설명하겠다

random도 여전히 search의 일부 기능일 뿐이다

아래 레퍼런스를 참고했다

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-function-score-query.html

{

"size": 10,

"query": {

"function_score": {

"query": {

"match_all": {}

},

"random_score": {}

} 

} 

}

random search의 원리는 score를 랜덤으로 할당한 후 result를 리턴하는 것이다

구조가 간단하진 않지만 사용하지 못할정도는 아니다

드디어 마지막 aggregation 예제이다

aggregation은 집계라고 직역되는데, document들의 doc_count 등을 통계내기 위해서 사용하는 것이다

user가 각 document들의 값에는 관심이 없고 오직 통계에만 관심이 있을 때 aggregation은 매우 유용하다

아래 레퍼런스를 참고헀다

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-daterange-aggregation.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html

{

"aggs": {

"my_agg": {

"date_range": {

"field": "my_date",

"format": "yyyy-MM-dd",

"ranges": [

{"to": "2017-06-08"},

{"from": "2017-06-08"}

]

}

}

}

}

아까처럼 하나하나 살펴보자

aggs는 aggregations의 축약어이다

my_agg에는 자신이 원하는 aggregation name을 입력하면 된다

field에는 aggregation에 사용할 field name

ranges는 list로서 2개의 아이템을 가지고 있는데, 이는 각각 bucket이 된다

첫번째 bucket은 2017-06-08 이전의 document들의 aggregation

두번째 bucket은 2017-06-08 이후의 document들의 aggregation

하지만 필자가 필요로했던 aggregation은 이것이 아니라 data histogram aggregation이었다

doc_count per day

{

"aggs" : {

"my_agg" : {

"date_histogram" : {

"field" : "my_date",

"interval" : "day",

"min_doc_count": 1

}

}

}

}

interval은 aggregation의 interval(간격)을 의미하고

min_doc_count은 최소 doc_count (optional field)

특정 기간 내의 data histogram만 필요하다면, 위에서 사용한 aggs 필드와 함께 query-bool-filter 필드를 사용하면 된다

추가로, script가 있는데 painless 등의 언어로 elasticsearch에서 script를 실행시킬 수 있다

기본적인 문법은 C언어와 아예 같으므로 어려울 것은 없다

그러나 document 갯수에 따라 exec time이 linear하게 증가하므로, 웬만하면 사용하지 않는 것이 좋을 것 같다 (주관적인 의견)

<ORM: Object Relational Mapping>

OOP 언어에서 RDBMS를 연동할 때, 클라이언트 라이브러리/SQL을 사용하여 구현할 수 있다

하지만 ORM을 사용하면, 좀더 높은 생산성(빠른 개발속도, 짧은 개발기간)으로 개발할수 있다

즉, ORM의 사용목적/이유는 생산성에 있는 것이다

<ORM 라이브러리>

Flask에서는 SQLAlchemy, Django는 내장 ORM을 가지고 있다

Node.js에도 Sequalize라는 ORM이 있다

<ORM 장단점>

ORM을 사용하면 SQL을 사용하지 않아도 된다

이것은 프로젝트 소스를 다른 환경에서 clone받아서 사용할 때, 프로젝트 소스의 DBMS 제한을 받지 않게 해주는 장점이 된다

DBMS 연동이 추상화 되어있기 때문이다

또다른 장점으로, SQL을 몰라도 DB 연동이 가능하다는 점이 있다

하지만 이것은 장점이자 단점인 것이, SQL을 작성하느라 소비되는 시간을 절약할 수 있다는 장점임과 동시에

SQL을 별도로 공부하지 않는한, ORM 없이는 DB 연동을 할줄모르는 코드몽키가 될지도 모른다

참고:

webframeworks.kr/tutorials/expressjs/expressjs_orm_one/

<Overview>

web app framework인 flask와 django를 비교하면서, 

final product를 생산하는 게 목적인 프레임워크들과, 그렇지 않은 프레임워크들이 있다는 것을 알게되었다

(주관적인 기준이다)

최대한의 abstraction이 전자, 적절한 abstraction이 후자이다

openGL, flask가 전자이고, django/unity/spring이 후자이다 (spring은 사용해보지 않았지만 추측)

필자는 framework 사용법 목적으로 unity를 공부했었는데, unity를 사용할줄 안다고해서 unreal engine 사용에 도움이 되지 않앗다

final product을 생산하기 위한 프레임워크들은 의존성이 매우 커서, 다른 프레임워크들과 공통점이 거의 없다

<game engine>

필자는 프레임워크 공부 목적으로 unity를 공부했었는데, 이 목적과 unity는 적절하지 않다

그리고 배우는 재미가 없어서 의욕이 안생긴다

하지만 제대로된 게임을 만들어보는게 목적이라면 unity가 최고다 (unity가 없으면 아무것도 못 만들겠지만)

unreal engine도 아마 마찬가지일 것이다. 그런면에서 보면 blue print는 최고의 기능일 지도 모르겠다

"그래서 정말 서비스 목적의 게임을 만들 계획이 생기지 않는한, unity는 사용하지 않을 예정이다"

"django도 마찬가지."

다른 사람들도 web server '공부' 목적으로 django를 접한다면 차라리 flask 등 다른 프레임워크를 사용하는 것을 추천한다

flask를 먼저 사용해보면, django에 적응하는 것도 쉬울 것이다

(flask도 SQL을 완전 추상화하고 있긴 하지만..)

Create, Read, Update, Delete - 기본 데이터 처리기능을 의미

참고: 위키피디아

<Elasticsearch란?>

Lucene-based Search engine이다

특징: Real-time searching과 Distributed Computing(Clustering), REST API 제공

Usage: NoSQL(like mongodb), Analytics

default port: 9200

<Logical 배치> (Application 관점)

 - 구성요소: index, type(doc type), document 3가지

   각각 RDB의 Database, Table, Row와 비슷한 개념이다

 - Index: number of shards를 설정한다. Physical 배치에서 설명.

 - Type: schema-free (Indexing을 하면 field type을 자동으로 추측하므로, schema를 직접 세팅하지 않아도 된다)

   (하지만 매핑이 실패할 수도 있으므로, 직접 매핑하는 것이 좋다고 한다)

 - Document: JSON 형식으로, 실제 데이터는 여기에 저장된다

<Physical 배치> (Manager 관점)

 - 구성요소: Node, Shard

 - Node: Process

 - Shard: Index의 조각(일부분)으로서, Index는 Shard 1개 이상으로 구성되어있다

   Shard는 또 Primary Shard, Replica 2가지가 있다

   Primary Shard: Index의 일부분

   Replica: Primary Shard의 복제본 -> reliability, search performance 효과가 있다

   Elasticsearch는 Lucene-based이다. Elasticsearch의 Index는 Shard라는 Chunk들로 나뉘고, 각 Shard는 Lucene Index이다.

   reverse index 등은 패스했다.

<REST API>

CRUD: Create/Read/Update/Delete로 설명하겠다 (기본 데이터 처리기능)

 - Create(Indexing): PUT

   curl -XPUT "Content-Type: application/json" localhost:9200/index_name/type_name/document_id -d <body>

   body example: 

 - Read(Search): GET, POST

   curl localhost:9200/index_name/type_name/document_id

   curl -XPOST localhost:9200/index_name/type_name/doc_id -d <body>

   body example: {"query": {"match_all": {}}, "sort": {"_id": "asc"}}

   _search 까먹음

 - Update: PUT, POST

   이미 존재하는 document에 PUT

   POST 까먹음

   _update 까먹음

 - Delete: DELETE, POST

   curl -XDELETE localhost:9200/index_name/type_name/doc_id

   POST 까먹음

   _delete_by_query 까먹음

REST API를 테스트할 때 linux/mac은 curl, windows는 postman을 사용하자

<ELK Stack?>
Elasticsearch(search engine)

Logstash(data processing pipeline)

Kibana(analytics, visualization platform)

참고:

http://www.minecraftforum.net/forums/support/server-support/server-administration/1934074-trying-to-install-plugins-but-no-plugin-folder

Bukkit isn't actually a plugin. It's a server mod, which means it's a standalone piece of software. Bukkit is the server software that allows you to have plugins.
버킷은 사실 플러그인이 아니라, 서버 모드이다. 버킷은 서버에 플러그인을 적용할수 있게해주는 서버 소프트웨어이다

You'll need to download the latest CraftBukkit jar and setting that up the same way you set up minecraft_server.jar. After you do that, you should be able to see the "plugins" folder.

(요약하면) craftbukkit을 링크에서 다운받으라는 뜻.

bukkit의 종류로 craftbukkit이 대표적이고 그외에 하나가 더 있었던 것으로 기억한다

---

https://getbukkit.org/download/craftbukkit

포스팅 날짜 기준으로 1.12.2가 최신버전이다

실행하면 spigotmc로부터 추가 다운로드를 받는걸 보니, craftbukkit이 spigotMC 거인듯

그러므로 plugin들도 spigotMC에서 받으면 되겠다

essential, choptree 등.

plugins 디렉토리에 플러그인을 설치하고 server console에 reload 커맨드를 실행해주자

console log에 plugin enabled message를 확인할 수 있다

단, permission 문제로 op 외에는 작동하지 않을 수 있다

<근본적 차이>

32bit, 64bit라는 것은 register 각각의 size를 의미한다

<OS>

memory accessing이 register를 통해 이뤄지므로 32bit OS는 4GB(2^32) 메모리 한계를 가진다

<python>

배열 사이즈 한계가 2^31-1라는 점이 가장 눈에 띈다

그런데 웬만하면 이정도 사이즈까지는 사용하지 않으므로 굳이 64bit를 사용해야할 이유는 되지 못한다

참고

http://ithuman.tistory.com/entry/CPU-%EA%B5%AC%EC%A1%B0-32bit-vs-64bit

http://ssaemo2.tistory.com/6

우선 FFmpeg이 return하는 video_frame은 WH 형식의 배열이다

그리고 여기서 중요한 것은, 각각의 RGBA 스트림을 "별도의 배열"로 return한다는 것이다

즉 이 3개의 배열을 이어주면 CWH가 완성된다!

결국 FFmpeg의 video_frame 형식은 CWH이다

Spring Framework 책에서 처음 접했는데, 디자인 패턴 중 하나로 분류하기도 한다

Maze 클래스의 인스턴스 멤버인 room, wall을 외부에서 설정할 수 있다 (의존성 주입, dependency injection)

dependency = room, wall

injection = 생성자 또는 메서드를 통해 외부(클라이언트 코드)에서 설정

<code example>

<Consistency>

Consistency란 단어는 Memory Model과 Database Transaction ACID 두곳에서 만날수 있다

이 글에서는 Consistency라는 용어의 의미에 대해 메모해놓으려 한다

Consistency는 직역하면 일관성으로, data에 언제 access하든지 일관성있게 access된다는 의미로 이해하면 된다

아래 두 내용도 모두 이와같은 맥락에서 이해하면 된다

<Consistency Model>

Multi-core와 같은 Distributed Shared Memory System에서 나오는 용어이다

예를 들면 Consistency Model은 아래와 같은 상황에서 필요하다

Client A,B(Multi-core에서는 Core A,B)가 있다고 하자

1. A가 Node N, M(Memory의 N번위치, M번위치)에 순서대로 data를 write했다

2. B가 Node M에서 data를 read했다

이때, B는 "A가 Node M에 write한 값"을 확인해야한다.

하지만 "오직 A가 Node M에 write한 값만" 공유할 것인지, "그 이전의 memory access들(Node N에 write)까지 모두" 공유할 것인지

일관성이 필요하다.

일관성이 제공되지 않을경우, 프로그램 작성이 복잡해지기 때문이다

그리하여 다양한 Consistency Model들은 이런 Memory Access에 일관성(consistency)을 보장해준다

이것이 바로 Consistency Model의 목적 및 기능이다

<ACID의 Consistency>

Consistency는 안전한 Transaction을 위해서 지켜져야하는 성질이다

이것도 마찬가지로 Data의 일관성을 이야기하는데, 대표적으로 Constraint(제약조건)이 있다

balance > 0이라는 제약조건이 있을 경우, 이 제약조건을 깨는 트랜잭션은 실패하게 되어있다

그 결과, 트랜잭션 성공 후 balance라는 data는 balance > 0이라는 일관성을 가지게 된다

결국 data의 일관성이라는 점에서 Consistency Model과 일맥상통한다

추상적인 개념(용어)이라서 처음 이해하기에 어렵기도 하지만, 이해하고나면 단순한 내용이었다.

(DIP:Digital Image Processing 관련 내용)

JPG wiki의 내용을 정리해놓으려 한다

<camera vs image - pixel format (color space)>

caffe2에서 skimage를 통해 jpg를 읽어오는 코드를 camera로 바꾸기 위해, jpg와 camera를 비교하게 되었다

겸사겸사 JPG에 대한 내용을 정리하려는 것이고.

우선 ffmpeg을 통해 camera을 읽을경우 default pixel foramt은 YUV420P(12bit)이다

그리고 python skimage.io.imread(img)를 통해 jpg를 읽어올 경우, RGB24 pixel format으로 읽어온다

(camera: YUV420P / jpg: RGB24)

<jpg 압축과정>

jpg pixel format에 대해 찾아보다가, 내용이 흥미로워 정리하게 되었다

wiki에 의하면, JPG는 RGB24를 더 효과적으로 compression 하기위해 YCbCr로 color space convert과정을 수행한다

(pixel format과 color space는 같은 의미이다)

이 과정 때문에 JPG는 Lossy compression(손실 압축) 방식이 된다

이후 Quantization(양자화)와 entropy encoding(엔트로피 부호화)를 통해 압축이 완료된다

<YUV, YCbCr>

이 둘도 항상 헷갈려서 정리해놓으려 한다

YCbCr은 YUV의 한 종류 또는 동일하게 생각하면 된다

Y = Luminance(밝기, 휘도) (사람이 가장 민감해하는 정보)

C = Chrominance(색차)

Cb = C(blue)

Cr = C(red)

<image array with skimage>

프로그램에서 image를 처리할 때, array 형태로 저장하게 되는데, 거기에도 종류가 있다

skimage.io.imread(img)로 jpg를 읽어오면 HWC(Height/Width/Channels)로 읽어온다

camera는 더 찾아본 후 포스팅하도록 하겠다

---

<image array from FFmpeg>

FFmpeg을 통해 camera의 video frame을 array로 읽어와보았고, 위에서 언급했듯이 그 구조에 대해서 추가포스팅하겠다.

camera or video file로부터 FFmpeg을 사용하여 이미지(비디오 프레임)을 읽어올 경우, WHC 형태로 읽어온다

WHC는 배열과 똑같이 생각하면 되기 때문에 매우 쉽다

11111

22222

33333

44444

화면 각각의 픽셀값을 그대로 배열로 표현했을 때가 바로 WHC이다

위와 같은 배열을 화면에 그대로 매핑했을 때와 같다는 것이다

<conclusion>

JPG 압축 전후와 python skimage or FFmpeg으로 이미지(비디오 프레임)를 읽어왔을 때를 비교해보았다

그리고 YUV와 YCbCr도 비교해보고 의미를 살펴보았다

FFmpeg으로 읽어온 이미지를 skimage에서 processing 하기위해 조사해보았고(+개인흥미)

포맷을 맞추는데에 많은 도움이 될것같다

<camera(webcam) - linux>

# print available foramts list

ffmpeg \

-list_formats all \

-i /dev/video0

# camera to mp4

ffmpeg \

-f v4l2 \

-video_size 320x240 \

-pix_fmt bgr24 \

-i /dev/video0 \

output.mp4

-i /dev/video0 앞에 있으면 이것의 옵션으로, output.mp4 앞에 있으면 이것의 옵션으로 취급된다

(즉 순서도 중요하다)

특히 pix_fmt

# pipe

/dev/video0 대신 pipe:0 (stdin)을 사용할수도 있고

output.mp4 대신 pipe:1 (stdout)을 사용할수도 있다

stderr는 ffmpeg에 관한 string이 출력된다

# etc

ffmpeg -pix_fmts

https://answers.microsoft.com/ko-kr/windows/forum/windows_10-update/%EC%9C%88%EB%8F%84%EC%9A%B010/90d8f326-3c4b-49e4-8a00-4680d54be92c

git submodule --update

https://stackoverflow.com/questions/9189575/git-submodule-tracking-latest

Input -> System -> Output

Input을 넣었을 때 처리 후 Output을 내는 것을 Function, System, Filter이라고 한다

<Consistency Model>

Shared Memory System (예를들면 Multi-processor)에서 만날수 있는 개념인데

Consistency Model 자체의 설명은 너무 추상적이라서 이해하기 어렵다

그래서 필자는 Sequential Consistency Model을 특정하여 작성하고자 한다

아래 위키를 참조했다

https://en.wikipedia.org/wiki/Sequential_consistency

<Sequential Consistency Model>

Sequential Consistency model은 Multi-processor의 Multi-thread와 비슷하므로 좀더 이해하기 쉬울 것이다

이것은 Consistency Model의 한 종류일 뿐일지라도, Consistency Model에 대한 이해를 쉽게 만들어줄 수 있을것이다

일반 PC에서 Multi-thread 동작을 생각해보자.

A, B라는 2개의 스레드가 있을 때, 각 스레드 내의 실행 순서는 보장된다

A: A1 -> A2 -> A3

B: B1 -> B2 -> B3

Sequential Consistency Model, 즉 실행순서의 일관성을 보장하는 모델이다

그러나 A 스레드와 B 스레드 사이의 실행 순서는 보장되지 않는다 (오직 각 프로세서 내에서만 보장)

<Consistency Model 필요성>

wiki 글 일부를 인용하면

The data consistency model specifies a contract between programmer and system, wherein the system guarantees that if the programmer follows the rules, memory will be consistent and the results of reading, writing, or updating memory will be predictable.

데이터 consistency 모델은 프로그래머와 시스템 사이의 계약을 specify한다

시스템은, 프로그래머가 룰을 지킬 경우 메모리가 consistent하고 메모리의 reading/writing/updating의 결과가 예측가능함을 보장한다

즉 프로그래머에게 편의성을 제공하는 것이다. memory operation 결과가 일관성있음(예측가능함)으로써 거기에 기반하여 프로그램을 문제없이 작성할수 있게된다.

다시 Sequential Model로 돌아가면, A3가 실행되었다는 것은 A1, A2가 실행되었다는 것을 보장받을 수 있다.

<Consistency Model vs Cache Coherence>

종종 Consistency Model은 Cache Coherence와 혼동되는데, 서로 다른개념이다

Cache Coherence는 단일 변수에 대한 멀티프로세서의 access 관점이지만

consistency model은 여러 location에 대한 access 순서에 대하여 처리한다는 점이 차이이다

<트랜잭션의 정의>

논리적인 수행단계를 의미힌다. 내부적으로는 여러개의 연산단계로 구현된다.

<트랜잭션의 필요성>

여러개의 request가 동시에 처리되거나, 시스템 문제가 발생하더라도 데이터를 안전하게 관리하기 위해서 트랜잭션은 필요하다

트랜잭션의 안전성을 보장하기 위해서, ACID라는 개념을 소개한다

<ACID의 정의>

ACID는 트랜잭션을 안전하게 수행하기 위해서 지켜져야 하는 성질들이다

Atomicity(원자성) / Consistency(일관성) / Isolation(고립성) / Durability(지속성)

<Atomicity>

Atomicity는 concurrent computing에도 등장하는 개념으로, "All or none"을 의미한다

트랜잭션이 성공했을 경우에는 All, 트랜잭션이 처음부터 실패했을 경우에는 none에 해당한다

하지만 트랜잭션은 여러개의 연산단계로 이루어져있으므로, 연산 도중에 실패할수도 있다

트랜잭션이 "도중에 실패"했을 경우, 일부 연산결과만 반영하면 처리가 꼬이게된다

그러므로 연산결과를 rollback함으로써 none으로 처리되게 하는 것이다

결론적으로 트랜잭션을 안전하게 처리하기 위해서는 Atomicity가 지켜져야한다

<Consistency>
여기서는 대표적으로 Constraint를 이야기할 수 있다

트랜잭션은 처리된 후에도 Constraint를 깨지지 않아야한다

데이터의 Constraint가 깨지지 않는다는 것은 데이터가 일관성있게 유지된다는 의미로 이해할 수 있다

데이터의 일관성 또한 트랜잭션의 안전한 처리가 목적이다

<Isolation>
트랜잭션들은 서로 간섭받지 않아야한다

각각의 트랜잭션들은 고립되어, 다른 트랜잭션들의 영향을 받지 않아야한다

이렇게 트랜잭션 각각이 고립됨으로써 트랜잭션을 안전하게 처리할 수 있다

<Durability>

트랜잭션이 성공적으로 처리되었다면, 이후에 시스템에 문제가 발생하더라도 로그 등을 통해 복구됨으로써

지속적으로(영구적으로) 처리내용이 반영되어야 한다

<결론>

트랜잭션은 논리적 수행단계를 의미하며, ACID는 트랜잭션을 안전하게 처리하기 위해서 지켜져야하는 성질들이다

추상적이어서 이해가 잘 되지않으므로, 글로 다시한번 정리하였다

------------------------------------------------------------------------------------------------------------

<old post>

DB는 Query 실행을, Query 단위가 아니라 Transaction 단위로 DB에 update(갱신)한다

즉 Query의 성공(commit)/실패(rollback) 또한 transaction 단위로 결정된다

Transaction의 목적/효과는 무엇일까?

<Transaction의 목적?>

Transaction을 통해 Query가 일부만 성공하거나 실패하는 것을 막을 수 있다

즉, Query의 성공과 실패가 분명해진다

성공하면 COMMIT하고 실패하면 ROLLBACK한다

Transaction은 Query들을 한꺼번에 실행하는데, 이것을 통해 Transaction간의 독립성을 보장한다

즉 Transaction끼리는 간섭받지 않는다

---

Transaction은 ACID를 보장하기 위한 수단이라고도 이야기한다

ACID 중 Atomicity(원자성)와 Isolation(고립성)만 살펴보자

Isolation부터 살펴보는 게 순서상 더 쉽다

이것은 여러개의 Transaction들이 서로 고립되어있다는 의미로, 다른 Transaction들의 상태를 고려하지 않아도 된다

비유하면 process들이 각자 고유한 영역을 가지는 것과 비슷하다

Atomicity은 concurrent processing에도 나오는 개념이다

DB Server에 Transaction이 여러개가 동시에 들어왔다고 가정하자

Transaction의 입장에서 DB의 record들은 공유 데이터이므로, Transaction들의 Query들이 서로 섞이게 되면

기대하지 않은 결과가 나올 수 있다. Atomic은 이러한 이슈를 발생하지 않게해준다

즉, DB Server에 Transaction request 여러 개가 동시에 들어온다 하더라도 Transaction은 하나씩 처리된다는 것이 Atomicity이다

ACID에 대한 자세한 내용은 아래참고

https://ko.wikipedia.org/wiki/ACID

---

병렬 컴퓨팅에서의 Consistency는, shared memory를 사용할 때 memory에 대한 consistency를 의미하는데,

이후에 추가하겠다

2xx: success

ex) 200 ok

4xx: request error

ex) 403 forbidden, 404 not found

5xx: server error

ex) 503