PHP에서 가장 안정적인 세션 스토리지는 무엇입니까 : Memcache, 데이터베이스 또는 파일? [닫은]


10

PHP 세션을 처리하는 가장 안전하고 안전한 방법은 무엇입니까? 세션을 저장하는 가장 좋은 방법은 다음과 같습니다.

  1. 데이터베이스 (보다 안정적이지만 높은 병목 현상, 느린 속도, 높은 데이터베이스 사용 웹 사이트에는 적합하지 않음)?

  2. Memcache (초고속이지만 더 많은 보안 문제, 서버가 다시 시작될 때 데이터를 잃을 가능성 및 캐시가 가득 찼을 때 데이터를 잃을 가능성)을 분배 했습니까?

  3. 파일 (기본 옵션, 파일 I / O에서 읽고 쓰기 때문에 보안이 저하되는 등 속도가 느립니다).

어떤 방법이 가장 좋습니까? 각 접근 방식의 문제점과 좋은 점은 무엇입니까?


2
하나의 컴퓨터 만 사용하는지 또는 응용 프로그램이 배포되는지 여부를 지정해야합니다. 응답에 큰 영향을 미치기 때문입니다.
Arseni Mourzenko

1
@haylem 이것은이 질문을하기에 가장 적절한 장소이며, 프로그래밍 질문이 아닙니다. 프로그래밍 개념 문제입니다.
user1179459

3
'최상의'는 특정 상황에 따라 다르기 때문에 이것은 실제로 나쁜 질문입니다. Facebook의 '최고'는 개인 홈페이지와 동일한 '최고'가 아닐 수 있습니다.
GrandmasterB

1
@GrandmasterB 나는 그것이 왜 "각 접근 방식의 문제점과 좋은 점은 무엇입니까?"라고 분명히 물었습니다. 어느 것이 나에게 가장 적합한 지 알아 내야합니다.
user1179459

답변:


6

다른 문제 (캐시 크기, 보안 등)를 쉽게 해결할 수 있으므로 Memcached에 저장하는 것이 가장 좋습니다.

페이스 북 은 memcached 의 # 1 소비자입니다. 관심이 있으시면 읽으십시오 : http://www.facebook.com/note.php?note_id=39391378919

다른 문제를 해결하는 방법?


4

대부분의 일상적인 응용 프로그램의 경우 데이터베이스에서 세션을 유지하는 것이 좋습니다. SQL Server가 처리 할 수있는 볼륨 및 수준의 동시성은 충분합니다. 핵심은 각 항목의 크기를 작게 유지하고 불필요한 행을 규칙적으로 제거하는 것입니다. 물론 적절한 색인 생성.

파일 시스템-나는 그럴 필요를 본 적이 없다. 수천 개의 작은 파일이 아닌 테이블에서 행을 관리하는 단순성을 선호합니다. 또한 세션 통계를 파고 싶다면 파일을 쿼리 할 수 ​​없습니다.

PHP를 사용하면 세션 핸들러를 쉽게 교체 할 수 있습니다. 따라서 하나의 스토리지 형식으로 시작하여 번거 로움없이 다른 스토리지 형식으로 마이그레이션 할 수 있습니다.


4

MySQL에서 MEMORY 스토리지 엔진을 사용하는 것은 어떻습니까?

Memcache만큼 빠르지는 않지만 일반 SQL을 사용할 수 있다는 장점이 있으며, 필요하지 않을 때는 일반 스토리지 엔진을 사용하고 사용자 / 요청 수가 증가하면 MEMORY로 전환 할 수도 있습니다.

자주 변경되는 웹 앱에 많은 양의 통계 데이터를 저장하는 데 사용하므로 세션을 처리하는 데 사용되지 않지만이 목적에 적합해야한다고 생각합니다.


3

블로그 게시물 은 Magento와 다른 세션 스토리지 엔진의 성능 비교 결과를 보여 주며 최대 75 명의 동시 사용자가 실제로 성능 차이가 없다고 결론 지은 것 같습니다.

나는이 수준 (초당 약 5 건의 트랜잭션, 12 시간 동안 약 430k 히트)을 가지고 있다고 생각합니다. 파일 / DB / Memcache / Redis가 모두 행복하게 처리하기 때문에 다른 모든 것의 오버 헤드가 성능 수치를 지배합니다. 제대로 사용하면 땀을 흘리지 않고 교통.

따라서 확장 성, 안정성 및 보안과 같은 다른 요소가 남습니다.

먼저 파일 저장소를 손상시키는 것은 공격자가 응용 프로그램 코드를 수정하거나 키 및 저장소 액세스 프로토콜 / 자격 증명이 읽기 전용 인 경우에도 발견 할 수 있기 때문에 다른 모든 것을 손상시킬 가능성이 있다고 말하고 싶습니다. 접속하다. 파일 저장소는 볼륨이 적은 사이트에 적합하며 설정이 쉽고 추론하기 쉽습니다. 디스크를 누르는 것처럼 DB 읽기도 디스크를 치고 DB가이를 캐시 할 수 있으면 OS도 세션 파일을 캐시했을 것입니다. 또한 하나의 파일을 읽었으며 파일 이름이 이미 알고 있으면 파일 시스템이 훌륭합니다. PHP를 사용하는 경우 응용 프로그램을 제공하기 위해 시스템이 얼마나 많은 파일 읽기를해야하는지 알고 있습니까? 단점은 당신이 할 수 있다는 것입니다.

Memcache는 비교적 빠르며 Memcache 클래스 솔루션을 더 광범위하게 고려하고 있다면 (Redis 등) 속도에 대한 메모리 읽기에서 지속성을 약속하여 두 세계를 최대한 활용할 수있는 솔루션이 있습니다. 또한 추론하기가 비교적 간단하며 세션의 키-값 특성은 정확히 설계된 것입니다. 이 중 하나를 채우기 위해 얼마나 많은 세션에 참여해야하는지 알고 있습니까? 어쨌든 모든 옵션은 용량에 도달하면 타협해야합니다. 디스크는 파일 (여기서 숫자 및 크기 요소)로 채워지고, 캐시 저장소는 용량으로 채워지고 데이터베이스에는 파일 수와 동일한 행 수와 동일한 디스크 용량 제한이 있습니다. 또한 이러한 시스템은 분산 방식으로 실행하는 경우에만 분산됩니다. 단일 서버 설정으로 대부분 잘 작동합니다. 배포하는 경우 이미 분산 웹 서버 / 데이터베이스 서버 등이 있으므로 분산 시스템 문제가 세션 저장소 선택에서 확실히 나타나지 않습니다. 그러나 10 배의 트래픽 / 용량 등을 원할 때 파일 저장 방식보다 훨씬 자연 스럽습니다. 일부 키 / 값 저장소를 사용하면 세션 데이터를 비교적 쉽게 분석 할 수 있지만 대부분 SQL을 수행 할 수있는 곳은 없습니다.

데이터베이스가 다른 옵션보다 더 신뢰할 수 있다고 제안하는 이유는 확실하지 않지만 PHP 응용 프로그램이 이미 데이터베이스를 사용하고 있기 때문에 데이터베이스의 호소력을 얻습니다. 즉, 다른 서버 종속성을 추가하지 않고 세션 데이터를 가져와 사용자 데이터를 가져 오기 위해 사용하는 것과 동일한 연결을 재사용 할 수 있으므로 데이터, Memcache 등을 설정할 필요가 없습니다. 테이블을 잘 작성하면 상당히 빠른 성능을 발휘하며 이전 세션을 거두거나 세션 데이터를 분석하는 데 이미 익숙한 매우 간단한 의미를 제공합니다 (왜 내가 원하는지 확실하지 않은 경우 확실하지 않습니다) 중요하지 않습니다). 대규모로 확장하는 것은 Redis와 같이 사소한 것이 아닙니다.

처음에는이 선택이 그렇게 중요하지 않다고 생각합니다. 각 접근 방식에는 도전 과제와 장점 및 고려해야 할 사항이 있습니다. 일반적으로 말하자면, 기본 PHP / 사용하는 프레임 워크 또는 가장 쉬운 방법을 사용하여 벗어날 수 있습니다. 나중에 선택이 잘못되면 성능 분석에서 알려주고 트래픽의 특정 특성에 따라 적절한 선택을 수행하는 데 필요한 데이터로 무장합니다. 우선, 당신이 합리적으로 가질 수있는 것은 일반적인 추측입니다.


0

그것은 당신의 필요에 달려 있습니다.

파일과 데이터베이스 스토리지간에 약간의 차이가 있습니다. 이 질문을 참조하십시오 .

그러나 기본적으로 Rails 3에서 수행 된 작업을 수행하고 세션에 암호화 된 쿠키 만 사용할 수 있습니다. 따라서 나중에 만 개인 / 공개 키와 같이 암호를 해독 할 수있는 방식으로 모든 값을 암호화하고 클라이언트가 상태를 유지하도록 할 수 있습니다.

한편으로는 일반적으로 충분합니다 (일반적으로 전체 객체가 아닌 ID를 저장하기를 원하기 때문에) 4Kb로 제한하지만 실제로 얻는 이점은 세션 정리에 대해 걱정할 필요가 없다는 것입니다. 당신은 실제로 클라이언트에이를 떠나 해야 합니다.


2
쿠키 경로 외부에 고정 리소스를 분리하지 않는 한 쿠키는 모든 요청에 ​​대해 지불해야하는 고정 세입니다.
Joeri Sebrechts

jQuery와 Bootstrap은 약 150kb가 결합되어 있으며 다른 라이브러리가 없습니다. 쿠키 최대 값은 4kb이며 일반적으로 1KB 미만입니다. OP가 극단적 인 상황에 대해 묻지 않는 한, 누가 그런 종류의 세금에 관심이 있습니까?
얌 마르코비치

@ YamMarcovic 몇 가지 문제가 있습니다 1) 쿠키도 서버에 가고 있습니다 (사용자는 일반적으로 다운로드 후 업로드가 빠름) 2) 일반적으로 페이지에는 정적 파일 (이미지, JS, CSS)에 대한 100 개의 요청이 있으므로 각 요청마다 100kb로 들어갈 수 있습니다 올라가고
Miro Svrtan

@MiroSvrtan 사용자가 페이지 당 수백 건의 요청을 보내 게 만드는 경우 (어디에서 그랬습니까?) 최적화는 분명히 문제가되지 않습니다.
얌 마르코비치

속도 최적화에 대해 상담하기 전에 사이트에서 프론트 페이지를로드하기 위해 ~ 170 건의 HTTP 요청을하는 클라이언트가 있었으므로 발생합니다. Btw에서 개인 / 공개 키는 비대칭 암호화의 개념으로, 일반적으로 대칭 암호와 동등한이 시나리오에서는 적용되지 않으며 구현하기가 더 복잡합니다. 또한 대부분의 세션 저장소 구현은 클라이언트가 관리하는 일부 쿠키를 사용하므로 답변의 마지막 단락에 설명 된 이점이 모든 쿠키에 적용됩니다.
jeteon December

0

특정 상황에서는 데이터베이스의 세션이 서버 중단의 가장 큰 원인이라고 말할 수 있습니다. 세션 테이블이 자주 손상되어 선제 적으로 잘라 버렸습니다.

memcache는 매력적으로 들리지만 전체 memcache를 지우는 프로세스가 너무 많아서 사용자 세션이 너무 자주 차단됩니다. 이전 세션은 메모리가 가득 차면 지워 지므로 더 이상 영구 로그인하지 않아도됩니다.

곧 기본 파일 기반 세션을 시도 할 것입니다.

세션 데이터의 보안이 걱정되면 해당 데이터를 세션에 넣지 말고 세션을 신뢰하지 않아야합니다. 모든 요청에 ​​대해 사용자를 확인하십시오.


0

Redis에 세션을 저장해 볼 수 있습니다 . Redis는 Memcached와 비슷하지만 몇 가지 데이터 지속성 옵션이 있습니다. 또한 다양한 PHP 클라이언트가 지원됩니다.

또한 내장 복제 및 스토리지 엔진 기능이 있는 Memcached Cloud 와 같은 타사 서비스를 사용해 볼 수 있습니다

공개, 저는 Garantia Data의 공동 창립자이자 CTO입니다.


2
공개해 주셔서 감사합니다! 당신이 비록 당신의 자신의 제품을 언급 할 수 게시물을 넘어이 사이트에 참여하고 있는지 확인 작업을 수행, 우리는 원하는 당신을 기여하는 사람이 아닌 기업.
Martijn Pieters
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.