Redis 리스트(List)는 입력순서에 따라 정렬된 string의 목록이다. 목록의 왼쪽 혹은 오른쪽 끝에 새로운 요소를 밀어 넣는 식으로 리스트에 string 데이터를 추가 할 수 있다. 링크드리스트(Linked List)의 구현이라고 보면 된다.LPUSH(Left push)는 왼쪽에 데이터를 추가하는 반면, RPUSH(Right Push)는 오른쪽에 데이터를 추가한다.LPUSH와 RPUSH의 사용방법이다.RPUSH key value LPUSH key value RPUSH를 이용해서 초기 데이터인 seoul, london, paris를 입력해보자.
2.0.0. 이후 버전에서 사용 시간복잡도 BRPOP은 RPOP의 블럭(Block) 버전이다. 기본적으로 RPOP 즉 리스트의 마지막에 있는 아이템을 POP하지만, POP할 아이템이 없을 경우 timeout 시간만큼 블럭된다. timeout 시간만큼 블럭되는 것을 제외하고는 RPOP와 동일하므로 자세한 사용법은 RPOP 문서를 참고하면 된다. timeout시간 동안 pop할 값이 없다면 nil을 반환한다. pop할 값이 있다면, 2개의 값을 반환한다. 첫 번째 값은 key의 이름이고, 두 번째 값은 POP된 value 다.
1.0.0 버전 부터 사용 시간 복잡도 LINDEX는 key의 index 위치에 있는 아이템을 반환한다.index는 0부터 시작하므로 0은 첫번째 아이템을, 1은 두번째 아이템을 의미한다. 음수의 경우 리스트의 끝에서 부터 index를 찾는다. -1은 마지막 아이템을 의미하고 -2는 마지막에서 두번째 아이템을 의미한다.key가 리스트(List)가 아닌 경우 에러를 반환한다.Index 위치에 있는 아이템을 반환한다. Index가 리스트의 범위 밖이라면 nil을 반환한다.
소프트웨어 프로그래밍에서 가장 먼저 다루는 데이터 스트럭처는 비트, 배열, 스트링, 리스트다. 단순해서 배우고 응용하기 쉽고, 다른 데이터 스트럭처를 이해하기 위한 기본이 되기 때문이다. 단점은 단순한 만큼 응용범위도 넓지 않다는데 있다.Sets는 좀 더 복잡하고 그 만큼 더 다양한 응용을 할 수 있다.Sets는 key에 하나 이상의 value를 가지는 데이터 스트럭쳐다. 값은 정렬되지는 않지만 데이터 중복을 허용하지 않는다. SADD 명령으로 key에 value를 추가 할 수 있다. 그리고 SMEMBERS명령으로 value들을 가져올 수 있다.
Joinc 위키 문서로 복사했습니다. 이 내용을 클라우드 환경에 맞게 해석해서, 아키텍처 문서를 만드는게 최종 목표입니다.이 방법론은 Heroku의 개발자가 초안을 작성했으며, 2011년에 Adam Wiggins가 처음 발표했다.클라우드가 널리 사용 되면서 소프트웨어를 서비스 형태로 제공하는 SaaS(Software As A Service) 혹은 웹앱이라고 부르는 애플리케이션이 일반화됐다. 이에 따라 SaaS 혹은 웹앱 형식의 애플리케이션을 개발하기 위한 방법론이 개발됐는데, 이를 12가지 요소로 정리한게 Twelve-Factor이다.
Twelve-Factor 앱은 Git, Mercurial, Subversion 같은 버전 컨트롤 시스템을 사용하여 변화를 추적할 수 있어야 한다. 버전별 소스코드를 관리하는 저장소를 코드 저장소 줄여서 저장소라고 부른다.코드베이스는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있습니다. 지금은 분산 버전관리 시스템인 Git을 더 널리사용하는 추세다.
대부분의 프로그래밍 언어는 라이브러리 배포를 위한 패키징 시스템을 제공하고 있습니다. Perl의 CPAN 이나 Ruby의 Rubygems가 그 예입니다. 라이브러리는 패키징 시스템을 통해 시스템 전체(site pakages)나 애플리케이션을 포함한 디렉토리(vendoring 혹은 bundling)에 설치될 수 있습니다.Twelve-Factor App은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않습니다. 종속선 선언 mainifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, 종속성 분리 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 “유출”이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다.
애플리케이션의 설정은 배포 (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다. 데이터베이스, memcached 등 백엔드 서비스들의 리소스 핸들 Amazon S3 이나 트위터 등의 외부 서비스 인증 정보 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값종종 개발자는 애플리케이션 설정을 코드에 상수로 저장한다. 이것은 Twelve-Factor를 위반한다. Twelve-Factor는 설정을 코드에서 엄격하게 분리하는 것을 요구합니다. 설정은 배치마다 달라질 수 있지만 코드는 배치에 상관없이 같아야 한다.
백엔드 서비스는 애플리케이션 정상 동작 중 네트워크를 통해 이용하는 모든 서비스입니다. 예를 들어, 데이터 저장소(예데이터베이스와 같은 백엔드 서비스들은 통상적으로 배포된 애플리케이션과 같은 시스템 관리자에 의해서 관리되고 있었습니다. 애플리케이션은 이런 로컬에서 관리하는 서비스 대신, 서드파티에 의해서 제공되고 관리되는 서비스를 이용할 수 있습니다. 예를 들어, SMTP 서비스 (예
코드베이스는 3 단계를 거쳐 (개발용이 아닌) 배포로 변환됩니다. 빌드 단계는 코드 저장소를 코드 저장소를 빌드라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, 종속성을 가져와 바이너리와 에셋들을 컴파일합니다. 릴리즈 단계에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 설정을 결합 합니다. 완성된 릴리즈는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있도록 준비됩니다.
38 POSTS HERE
Redis data structure - List
Redis 리스트(List)는 입력순서에 따라 정렬된 string의 목록이다. 목록의 왼쪽 혹은 오른쪽 끝에 새로운 요소를 밀어 넣는 식으로 리스트에 string 데이터를 추가 할 수 있다. 링크드리스트(Linked List)의 구현이라고 보면 된다.LPUSH(Left push)는 왼쪽에 데이터를 추가하는 반면, RPUSH(Right Push)는 오른쪽에 데이터를 추가한다.LPUSH와 RPUSH의 사용방법이다.RPUSH key value LPUSH key value RPUSH를 이용해서 초기 데이터인 seoul, london, paris를 입력해보자.
REDIS : BRPOP key [key ...] timeout
2.0.0. 이후 버전에서 사용 시간복잡도 BRPOP은 RPOP의 블럭(Block) 버전이다. 기본적으로 RPOP 즉 리스트의 마지막에 있는 아이템을 POP하지만, POP할 아이템이 없을 경우 timeout 시간만큼 블럭된다. timeout 시간만큼 블럭되는 것을 제외하고는 RPOP와 동일하므로 자세한 사용법은 RPOP 문서를 참고하면 된다. timeout시간 동안 pop할 값이 없다면 nil을 반환한다. pop할 값이 있다면, 2개의 값을 반환한다. 첫 번째 값은 key의 이름이고, 두 번째 값은 POP된 value 다.
REDIS : LINDEX key index
1.0.0 버전 부터 사용 시간 복잡도 LINDEX는 key의 index 위치에 있는 아이템을 반환한다.index는 0부터 시작하므로 0은 첫번째 아이템을, 1은 두번째 아이템을 의미한다. 음수의 경우 리스트의 끝에서 부터 index를 찾는다. -1은 마지막 아이템을 의미하고 -2는 마지막에서 두번째 아이템을 의미한다.key가 리스트(List)가 아닌 경우 에러를 반환한다.Index 위치에 있는 아이템을 반환한다. Index가 리스트의 범위 밖이라면 nil을 반환한다.
Redis data structures - SET
소프트웨어 프로그래밍에서 가장 먼저 다루는 데이터 스트럭처는 비트, 배열, 스트링, 리스트다. 단순해서 배우고 응용하기 쉽고, 다른 데이터 스트럭처를 이해하기 위한 기본이 되기 때문이다. 단점은 단순한 만큼 응용범위도 넓지 않다는데 있다.Sets는 좀 더 복잡하고 그 만큼 더 다양한 응용을 할 수 있다.Sets는 key에 하나 이상의 value를 가지는 데이터 스트럭쳐다. 값은 정렬되지는 않지만 데이터 중복을 허용하지 않는다. SADD 명령으로 key에 value를 추가 할 수 있다. 그리고 SMEMBERS명령으로 value들을 가져올 수 있다.
The Twelve Factors
Joinc 위키 문서로 복사했습니다. 이 내용을 클라우드 환경에 맞게 해석해서, 아키텍처 문서를 만드는게 최종 목표입니다.이 방법론은 Heroku의 개발자가 초안을 작성했으며, 2011년에 Adam Wiggins가 처음 발표했다.클라우드가 널리 사용 되면서 소프트웨어를 서비스 형태로 제공하는 SaaS(Software As A Service) 혹은 웹앱이라고 부르는 애플리케이션이 일반화됐다. 이에 따라 SaaS 혹은 웹앱 형식의 애플리케이션을 개발하기 위한 방법론이 개발됐는데, 이를 12가지 요소로 정리한게 Twelve-Factor이다.
The Twelve-Factor App 코드베이스
Twelve-Factor 앱은 Git, Mercurial, Subversion 같은 버전 컨트롤 시스템을 사용하여 변화를 추적할 수 있어야 한다. 버전별 소스코드를 관리하는 저장소를 코드 저장소 줄여서 저장소라고 부른다.코드베이스는 단일 저장소(Subversion 같은 중앙 집중식 버전 관리 시스템의 경우) 일수도 있고, 루트 커밋을 공유하는 여러 저장소(Git 같은 분산 버전 관리 시스템)일수도 있습니다. 지금은 분산 버전관리 시스템인 Git을 더 널리사용하는 추세다.
The Twelve Factors - 종속성
대부분의 프로그래밍 언어는 라이브러리 배포를 위한 패키징 시스템을 제공하고 있습니다. Perl의 CPAN 이나 Ruby의 Rubygems가 그 예입니다. 라이브러리는 패키징 시스템을 통해 시스템 전체(site pakages)나 애플리케이션을 포함한 디렉토리(vendoring 혹은 bundling)에 설치될 수 있습니다.Twelve-Factor App은 전체 시스템에 특정 패키지가 암묵적으로 존재하는 것에 절대 의존하지 않습니다. 종속선 선언 mainifest를 이용하여 모든 종속성을 완전하고 엄격하게 선언합니다. 더나아가, 종속성 분리 툴을 사용하여 실행되는 동안 둘러싼 시스템으로 암묵적인 종속성 “유출”이 발생하지 않는 것을 보장합니다. 이런 완전하고 명시적인 종속성의 명시는 개발과 서비스 모두에게 동일하게 적용됩니다.
The Twelve Factors - 설정
애플리케이션의 설정은 배포 (스테이징, 프로덕션, 개발 환경 등) 마다 달라질 수 있는 모든 것들입니다. 설정에는 다음이 포함됩니다. 데이터베이스, memcached 등 백엔드 서비스들의 리소스 핸들 Amazon S3 이나 트위터 등의 외부 서비스 인증 정보 배포된 호스트의 정규화된 호스트 이름(canonical hostname)처럼 각 배포마다 달라지는 값종종 개발자는 애플리케이션 설정을 코드에 상수로 저장한다. 이것은 Twelve-Factor를 위반한다. Twelve-Factor는 설정을 코드에서 엄격하게 분리하는 것을 요구합니다. 설정은 배치마다 달라질 수 있지만 코드는 배치에 상관없이 같아야 한다.
The Twelve Factor - Backend Service
백엔드 서비스는 애플리케이션 정상 동작 중 네트워크를 통해 이용하는 모든 서비스입니다. 예를 들어, 데이터 저장소(예데이터베이스와 같은 백엔드 서비스들은 통상적으로 배포된 애플리케이션과 같은 시스템 관리자에 의해서 관리되고 있었습니다. 애플리케이션은 이런 로컬에서 관리하는 서비스 대신, 서드파티에 의해서 제공되고 관리되는 서비스를 이용할 수 있습니다. 예를 들어, SMTP 서비스 (예
The Twelve Factor - 빌드, 릴리즈, 실행
코드베이스는 3 단계를 거쳐 (개발용이 아닌) 배포로 변환됩니다. 빌드 단계는 코드 저장소를 코드 저장소를 빌드라는 실행 가능한 번들로 변환시키는 단계입니다. 빌드 단계에서는 커밋된 코드 중 배포 프로세스에서 지정된 버전을 사용하며, 종속성을 가져와 바이너리와 에셋들을 컴파일합니다. 릴리즈 단계에서는 빌드 단계에서 만들어진 빌드와 배포의 현재 설정을 결합 합니다. 완성된 릴리즈는 빌드와 설정을 모두 포함하며 실행 환경에서 바로 실행될 수 있도록 준비됩니다.