준수의_개발정리노트

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다. 문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다. 본문:  ElasticSearch 공식레퍼런스 ElasticSearch(이하 ES)는 항상 접근 가능하고 필요에 따라 확장이 가능하도록 설계되었다. 서버(node)를 클러스터에 추가하기만 하면 ES가 자동으로 데이터와 쿼리 로드를 사용가능한 노드들로 분산하여 준다. Shard는 Primary와 Replica 두가지 종류가 있다. Index에 포함된 각각의 document는 1개의 primary shard에 포함된다. replica shard는 primary shard의 복제이다. Replica는 하드웨어 문제에 대응할 수 있도록 해주고 searching이나 document를 불러오는 작업을 처리하는 capacity를 늘려준다.

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다. 문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다. 본문:  ElasticSearch 공식레퍼런스 ElasticSearch(이하 ES)는 클러스터 매니징, 인덱싱, 데이터 검색을 위한 사용이 간단한 REST API를 제공한다. 그리고 테스트 목적으로 Command Line이나 Kibana의 개발자 콘솔에서 직접 request를 보낼 수도 있다. ES의 REST API는 구조화된 쿼리, 텍스트 쿼리, 두개가 혼합된 쿼리를 지원한다. 만약 gender와 age field를 employee index에서 검색하고 hire_date에 따라 정렬한다면 Full-text 쿼리는 query string과 매치되는 모든 document를 찾고, 연관도에 따라 정렬한다.

ElasticSearch를 도입하기전, ElasticSearch에대해 공부하기 위해 레퍼런스를 읽으면서 번역&정리한 글입니다. 문서 전체를 번역한 것이 아니라 개인적으로 정리가 필요하다 싶은 내용만 정리하였습니다. 본문:  ElasticSearch 공식레퍼런스 ElasticSearch (이하 ES)는 데이터를 분산 저장한다. 그리고 테이블에 행과 열의 방식으로 데이터를 저장하는 것이 아니라 JSON으로 직렬화하여 저장한다. 만약 클러스터가 여러개의 ES 노드로 구성되어 있다면 저장된 document들은 클러스터에 분산 저장되어 어떤 노드에서든 접근이 가능하다. Document가 저장되면 index가 되어 1초안에 거의 실시간으로 검색이 가능하다. ES는 Inverted Index라는 자료구조를 사용하여 매우 빠른 Full-Text-Search(이하 FTS)가 가능하다. Inverted Index는 document안에 존재하는 모든 유니크한 단어들을 정리하여 그 단어가 포함된  document들을 찾아낸다. Index 는 최적화된 document들의 모음이라고 할수있다. 그리고 각각의  document 들은 key-value로 구성된 데이터들을 저장하는  field 들로 구성된다. ES는 기본적으로 모든 field들을 인덱싱(앞의 index와는 조금 다름)하며 각각의 인덱싱된 field들은 최적화된 자료구조를 가지고 있다. 텍스트로 구성될 field들은 inverted indices 자료구조로 저장되고, 숫자와 위치정보 field들은 BKD 트리 구조로 저장된다. 이렇게 각각의 필드에 맞춤 자료구조를 사용하는 것이 ES가 매우 빠른 이유이다. 가끔은 하나의 field를 여러가지 방법으로 인덱싱하는 것이 유용할때가 있다. 예를 들면 문자열 field를 Full-Text-Search를 위하여 text field로 인덱싱하고, 데이터 정렬과 수집을 위해서 keyword field로도 인덱싱...

원문:  https://dev.to/nicolus/what-you-should-know-about-cors-48d6 CORS는 Cross-Origin Resource Sharing의 줄임말이다.  처음배우는 사람들에게는 CORS가 무엇때문에 사용되는지 헷갈릴때가 많다. 첫째로, CORS는 보안을 강화하기 위한 수단이 아니다. 사실 그의 정반대이다. CORS는 Same Origin Policy(Browser의 정책중 하나로 document나 script가 다른 domain과 교신하는 것을 막는다)를 피하기위함이다. Same Origin Policy는 하나의 도메인에서 다른 도메인으로 요청하는 것을 막는다. 이렇게 하면 악성 웹사이트들이 다른 웹사이트들에게 요청보내는 것을 막을 수 있다. 이 정책은 브라우저에 적용되어 있기때문에 서버에서 보낸 요청이나 다른 HTTP 클라이언트(cURL / POSTman 등)에게는 적용되지 않는다. 서버는 이 요청들을 신뢰할 수 있는 도메인에서 보낸 요청이라고 생각하고 처리할 수 밖에 없다.  SOP(Same Origin Policy)는 공격자가 요청을 보내는 것을 막기 위한 수단이 아니다(공격자들은 브라우저를 사용하지 않을 것이다..). SOP는 단지 정당한 사용자들이 본인도 모르게 보내는 요청들을 걸러주는 역할을 한다. 그래서 CORS는 일반적으로 SOP에 의해 막힐요청을 화이트리스트에 등록해 허용해주는 역할을 한다(예를 들자면 front-end app이 API에 요청을 보내는 것)

본문은 Node.js Design Patterns - Mario Casciaro 를 번역/정리한 글입니다. Blocking I/O - 기존의 Blocking I/O를 웹서버에 사용하게 되면 동시에 여러 접속을 처리하기 위해 각각의 커넥션을 별도의 쓰레드로 분리를 하여야한다. 이렇게 각가의 쓰레드가 하나의 커넥션만을 처리하게 되면 실제로 일을 하는 시간보다 기다리는 시간이 훨씬 많아지게 된다. 그리고 쓰레드를 여러개 사용하는것은 메모리를 많이 잡아먹고 Context Switch를 발생시키므로 효율적이지 않다. Non Blocking I/O - Non-blocking I/O에서는 system call이 데이터를 읽고 쓰는것을 기다리지 않고 만약 그시점에 처리할 것이 없다면 바로 반환해버린다. Busy Waiting - Non-blocking I/O에서는 여러 커넥션을 병렬적으로 처리하기 위한 방법 중 가장 간단한 방법으로 리소스를 polling(수시로 체크)하는  busy-waiting 이라는 방법이 있다. 아래의 pseudo 코드 방식으로 작동한다: resources = [socketA, socketB, socketC]; while(!resources.isEmpty()) { for(i=0;i < resources.length; i++){ resource = resources[i] var data = resource.read(); if (data == NO_DATA_AVAILABLE) continue; if (data == RESOURCE_CLOSED) resources.remove(i); else consumeData(data) } } 이런방식을 사용하면 동시에 여러개의 접속을 하나의 쓰레드에서 처리할 수 있다. 하지만 이러한 Polling 알고리즘들은 CPU를 너무 낭비한다. Sync...