Amazon SimpleDB를 사용하는 이유는 무엇입니까?

https://stackoverflow.com/questions/648270

22-07-2019
|

문제

저는 SimpleDB를 사용하여 애플리케이션에서 가장 어려운 영역(확장에 관한 한)을 처리할 수 있다고 생각했습니다. 트위터와 같은 댓글이지만 위치가 맨 위에 표시됩니다. 실제로 구현을 시작하기 전까지는 말이죠. SDB.

우선, SDB에는 속성 값당 1000바이트 제한이 있습니다. 이는 주석에도 충분하지 않습니다(더 긴 값을 여러 속성으로 분해해야 할 수도 있음).

그러면 최대 도메인 크기는 10GB입니다.SDB는 데이터 로드가 증가해도 성능이 저하되지 않으므로 데이터베이스 샤딩 등에 대한 걱정 없이 확장할 수 있다는 약속이 있었습니다.그러나 내가 올바르게 이해했다면 도메인의 경우 샤딩과 정확히 동일한 문제가 발생하게 됩니다.어떤 시점에서는 애플리케이션 수준에서 도메인 전체에 걸쳐 데이터 레코드의 배포 및 쿼리를 구현해야 합니다.

전체 애플리케이션에 포함된 가장 간단한 개체의 경우에도 마찬가지입니다.원자적인 사용자 등급, SDB는 쿼리 내에서 평균을 계산할 수 없기 때문에 옵션이 아닙니다(모든 것이 문자열 기반임).따라서 개체에 대한 평균 사용자 등급을 계산하려면 모든 기록(한 번에 250개)을 로드하고 애플리케이션 수준에서 계산해야 합니다.

SDB에 대해 뭔가 빠졌나요?10GB가 실제로 모든 SDB 제한을 극복할 만큼 많은 데이터베이스인가요?나는 이미 S3와 EC2를 사용하고 있기 때문에 솔직히 SDB를 활용하는 데 열중했지만 이제는 사용 사례가 보이지 않습니다.

해결책

몇 가지 대형 응용 프로그램에서 SDB를 사용합니다. 도메인 당 10GB 한도는 나를 걱정하지만, 우리는 아마존에서 도박을 통해 필요한 경우이를 확장 할 수 있습니다. 더 많은 공간을 원한다면 사이트에 요청 양식이 있습니다.

크로스 도메인 결합에 관한 한 SDB를 기존 데이터베이스로 생각하지 마십시오. 내 데이터를 SDB로 마이그레이션하는 동안, 나는 일부를 수동으로 교차 도메인 조인을 할 수 있도록 일부를 제거해야했습니다.

속성 제한 당 1000 바이트도 해결하기가 어려웠습니다. 내가 보유한 응용 프로그램 중 하나는 데이터베이스에 게시물 및 댓글을 저장하는 블로그 서비스입니다. SDB로 포팅하는 동안이 제한 사항에 도달했습니다. 게시물과 댓글을 S3의 파일로 저장하고 코드에서 읽었습니다. 이 서버는 EC2에 있으므로 S3 로의 트래픽은 추가 비용이 들지 않습니다.

아마도 조심해야 할 다른 문제 중 하나는 SDB의 최종 일관성 모델 일 것입니다. 새로 작성된 데이터가 귀하에게 반환 될 것이라는 보장으로 데이터를 작성한 다음 다시 읽을 수 없습니다. 결국 데이터가 업데이트됩니다.

이 모든 것이 말했다. 나는 여전히 SDB를 좋아한다. 나는 그것으로 전환하는 것을 후회하지 않습니다. SQL 2005 서버에서 이동했습니다. 나는 SQL에 대해 훨씬 더 많은 제어력을 가지고 있다고 생각하지만 일단 그 제어를 포기하면 더 많은 유연성이 있습니다. 스키마를 사전 정의 할 필요가 없다는 것은 대단합니다. 코드에 강력하고 강력한 캐싱 레이어를 사용하면 SDB를보다 유연하게 만들 수 있습니다.

다른 팁

나는 단순 50GB를 가지고 있으며 30 개의 도메인에 걸쳐 샤드를 뿌립니다. 이것을 사용하여 S3에 저장된 객체의 여러 키를 허용하고 S3 비용을 줄입니다. 전체 텍스트 검색을 위해 SimpleDB를 사용한 적이 없었지만 시도하지는 않았습니다.

SimpleDB는 작동하고 쉽게 작동하지만 모든 상황에 적합한 기능 세트는 아닙니다. 귀하의 경우 집계가 필요한 경우 SimpleDB가 올바른 솔루션이 아닙니다. DB는 단지 핵심 가치 저장소 일 뿐이라고 생각한 학교를 중심으로 지어졌으며, 집계는 주요 가치 저장소에 결과를 기록하는 집계 프로세스에 의해 처리되어야합니다. 이것이 바로 필요한 것입니다 일부 응용 프로그램의 경우.

여기에 있습니다 simpledb를 사용하여 페니를 꼬집는 방법에 대한 설명

도메인에 걸쳐 자신의 샤드 로직을 작성 해야하는 것은 이상적이지 않지만 성능 측면에서 더 가치가 있습니다. 예를 들어 100GB의 데이터를 검색 해야하는 경우 하나의 시스템이 전체 작업을 수행하는 것이 아니라 책임 부분에 대해 동일한 검색을 수행하도록 각각 5GB를 보유하는 20 대의 기계를 요청하는 것이 좋습니다. 목표가 정렬 된 목록으로 끝나는 경우 20 개의 동시 쿼리에서 반환 된 최상의 결과를 가져 와서 요청을 시작하는 기계에서 수집 할 수 있습니다.

즉, 나는 이것을 정상적인 사용에서 추상화하고 API에 "힌트"와 같은 것을보고 싶다. 따라서 100GB의 데이터를 저장하는 경우 Amazon이 20 대 또는 10 또는 40에 걸쳐 분할되어 있는지 결정하고 작업을 배포하도록하십시오. 예를 들어, Google의 BigTable 디자인에서 테이블이 커지면서 400MB 태블릿으로 지속적으로 분할됩니다. 테이블에서 줄을 요구하는 것은 그다지 간단하며 Bigtable은 하나의 태블릿 또는 수백만 개의 정제에서 살아있는 위치를 파악하는 작업을 수행합니다.

그런 다음 BigTable은 쿼리를 수행하기 위해 MapReduce 호출을 작성해야하지만 SimpledB Index는 자체적으로 동적으로 인덱스를 작성해야하므로 일부를 잃게됩니다.

속성 당 저장된 크기가 문제 인 경우 S3을 사용하여 더 큰 데이터를 저장하고 S3 객체에 대한 링크를 SDB에 저장할 수 있습니다. S3은 파일만을위한 것이 아니라 일반적인 저장 솔루션입니다.

아마존은 간단한 객체 데이터베이스를 구현하려고합니다. 이것은 주로 속도 이유입니다. SimpleDB 레코드를 S3의 요소에 대한 포인터/키라고 생각하십시오. 이 방법으로 쿼리를 실행할 수 있습니다 (결과 목록을 얻으려면 SimpleDB에 대해 느리게 또는 키 (빠른)로 S3를 직접 누르면 한 번에 레코드를 검색하거나 수정해야 할 때 객체를 당기도록 할 수 있습니다.

한계는 현재에 적용되는 것 같습니다 베타 풀어 주다.나는 그들이 경제적으로 수요를 충족할 수 있는 방법을 파악한 후에 미래에 더 큰 데이터베이스를 허용할 것이라고 가정합니다.한계에도 불구하고 높은 확장성과 안정성을 지원하는 10GB의 데이터베이스는 유용하고 비용 효율적인 리소스입니다.

확장성은 다음을 유지하는 능력을 의미합니다. 꾸준하고 얕은 성능 곡선, 데이터 양이나 요청 양이 증가하는 동안.이는 반드시 최적의 성능을 의미하지 않으며 매우 높은 용량의 데이터 스토리지를 의미하지도 않습니다.

Amazon SimpleDB는 또한 다음을 제공합니다. 무료 서비스 계층, 최대 1GB를 저장하고 최대 25시간의 시스템 시간을 사용하여 월 최대 1GB를 전송할 수 있습니다.이 제한은 매우 낮게 들리지만 무료라는 사실로 인해 일부 소규모 고객은 대규모 서버 팜에 투자하지 않고도 이 기술을 사용할 수 있습니다.

SimpleDB를 기본 데이터 저장소로 사용하는 Commericial .NET 응용 프로그램을 구축하고 있습니다. 나는 아직 생산에 없지만 SimpleDB 대 RDBS를 사용하는 문제 중 일부를 다루는 오픈 소스 라이브러리를 구축하고 있습니다. 내 로드맵의 일부 기능은 언급 한 문제와 관련이 있습니다.

데이터의 투명한 분할
의사 트랜잭션
1000 바이트 한도를 능가하기 위해 속성의 투명한 스패닝

SimpleDB는 여전히 활발한 개발 중이며 오늘날에는없는 많은 기능으로 끝날 것입니다 (일부는 핵심 시스템과 일부 코드 라이브러리에 추가됩니다).

.NET 라이브러리는입니다 간단한 저사반.

나는 Simpledb 주변의 모든 과대 광고를 구매하지 않으며 다음 한계를 바탕으로 사용해야하는 이유를 볼 수는 없습니다 (이제 거의 모든 기술로 거의 모든 것을 구축 할 수 있지만 이것이 하나를 선택 해야하는 이유는 아닙니다). .

그래서 내가 본 한계는 다음과 같습니다.

Amazon AWS에서만 실행할 수 있습니다. 많은 직원을 지불하십시오
도메인의 최대 크기 (테이블)는 10GB입니다.
속성 값 길이 (필드 크기)는 1024 바이트입니다.
선택 응답의 최대 항목 -2500
선택의 최대 응답 크기 (반환 할 수있는 최대 데이터의 양) -1MB, 실제로 모든 것을 확인할 수 있습니다. 여기에 제한이 있습니다
드라이버 만 있습니다 몇 언어 (Java, Php, Python, Ruby, .net)
케이스 무의미한 검색을 허용하지 않습니다. 추가 소문자 필드/애플리케이션 로직을 소개해야합니다.
정렬은 만 수행 할 수 있습니다 한 필드에서
5S Timelimit 때문에 계산은 이상하게 행동 할 수 있습니다. 5 초가 지나고 쿼리가 끝나지 않으면 부분 번호와 토큰이있어 쿼리를 계속할 수 있습니다. 응용 프로그램 논리는이 모든 데이터를 요약 한 채로 수집 할 책임이 있습니다.
모든 것이 UTF-8 문자열입니다, 이는 숫자, 날짜와 같은 비 현수 값으로 작동하는 것이 엉덩이에 고통을줍니다.
정렬은 숫자에 이상한 행동을합니다 (모든 것이 문자열이기 때문에). 이제 당신은해야합니다 패딩이있는 샤머니즘 춤
둘 다 거래가없고 조인이 없습니다
화합물, 기하학적, 다중 열 지수, 외래 키 없음

이것으로 충분하지 않다면, 당신은 또한 다음과 같은 기본적인 것들을 잊어야합니다. group by, sum average, distinct 데이터 조작뿐만 아니라. 전체적으로 쿼리 언어는 매우 기초적이고 SQL이 할 수있는 일의 작은 부분 집합을 상기시킵니다.

따라서 기능은 Redis/Memcached보다 실제로 풍부하지는 않지만 사용 사례에 대해이 두 DB만큼 우수한 성능이 우수하다는 것을 의심합니다.

SimpleDB는 스키마가없는 문서베이스 NOSQL 데이터베이스로 위치하지만 MongoDB/CounchDB의 쿼리 구문이 더 표현력이 뛰어나고 그 한계가 더 합리적입니다.

그리고 마침내 - 잊지 마십시오 공급 업체 잠금. 몇 년 안에 Azure (또는 다른 등장)가 AWS보다 5 배 더 저렴한 클라우드를 제공한다면 실제로 전환하기가 어려울 것입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow