문제

Amazon SimpleDB 데이터 저장소와 같은 것을 백엔드 데이터베이스로 사용하는 것을 고려한 사람이 있습니까?

SQL Server 호스팅(적어도 영국에서는)은 비용이 많이 들기 때문에 애플리케이션과 함께 성장할 수 있는 앱을 구축하는 데 클라우드 파일 스토리지(S3)와 함께 이와 같은 것을 사용할 수 있습니다.

이론적으로는 훌륭하지만 누구나 그것을 사용하는 것을 고려할 것입니다.사실 현재 실제 생산 소프트웨어에 이를 사용하고 있는 사람이 있나요? 여러분의 의견을 듣고 싶습니다.

도움이 되었습니까?

해결책

이것은 Amazon 서비스에 대한 좋은 분석입니다. 도전.

S3는 일반적으로 "BLOB 저장소"라고 설명되는 것을 처리했습니다.일반적인 웹 애플리케이션에는 일반적으로 이름/경로로 간단히 액세스할 수 있는 미디어 파일과 기타 리소스(이미지, CSS 스타일시트, 스크립트, 비디오 파일 등)가 있습니다.그러나 이러한 리소스 중 다수에는 메타데이터도 포함되어 있습니다(예:YouTube의 동영상 파일에는 등급, 업로드한 사람, 조회수 등에 대한 메타데이터도 포함되어 있으며 저장해야 합니다.쿼리 가능하고 도식화된 스토리지에 대한 요구가 바로 SimpleDB가 등장하는 이유입니다.EC2는 어떤 이유로든 가상 서버가 다운되는 경우 지속되지 않는 로컬 파일 시스템 인스턴스로 계산 완료에 사용할 수 있는 가상 서버를 제공합니다.SimpleDB와 S3를 사용하면 EC2에서 제공하는 컴퓨팅 기능을 추가하여 대규모 "Web 2.0" 스타일 애플리케이션을 구축할 수 있는 빌딩 블록을 갖게 됩니다.그러나 S3나 SimpleDB는 단순히 데이터베이스 기반 웹 애플리케이션을 구축하는 일반적인 LAMP 또는 WISC 개발자 경험을 원하는 개발자나 Blob 스토리지 버킷에 딱 맞지 않는 사용자 정의 스토리지 요구 사항이 있는 애플리케이션에 대한 솔루션을 제공하지 않습니다. 도식화된 저장.영구 파일 시스템에 액세스하지 못한 채 Amazon 클라우드 컴퓨팅 플랫폼의 개발자는 원하는 경험을 얻기 위해 EC2에서 S3로 데이터를 수동으로 백업하는 것과 관련된 정교한 솔루션을 고안해야 했습니다.

다른 팁

방금 Perl의 simpledb, Net::Amazon::SimpleDB::Simple로 앱을 포팅할 수 있는 라이브러리 작성을 마쳤습니다. 왜냐하면 Amazon 클라이언트 라이브러리가 고통스럽다는 것을 알았기 때문입니다.라이브러리는 아직 CPAN에 없지만 다음 위치에 있습니다. http://rjurneyopen.s3.amazonaws.com/SimpleDB/Simple.pm 아이디어는 SimpleDB 안팎으로 해시를 채우는 것을 간단하게 만드는 것이었습니다.

그냥 사용하려고 앱을 포팅했습니다.전반적으로 SimpleDB에 깊은 인상을 받았습니다.비효율적인 쿼리라도 반환하는 데 2~3초밖에 걸리지 않습니다.SimpleDB는 Erlang/병렬 특성으로 인해 테이블 ​​크기에 신경 쓰지 않는 것 같습니다.TableScan은 쉽습니다.

고통은 셀 수도, 합할 수도, 그룹화할 수도 없다는 사실에서 비롯됩니다.그런 일을 할 계획이라면 ...그렇다면 SimpleDB는 아마도 당신에게 적합하지 않을 것입니다.현재 기능면에서 memcached와 MySQL 사이 어딘가에 존재합니다.SELECT ORDER BY LIMIT를 선택할 수 있습니다. 이는 좋은 일입니다.또한 직접 크기를 조정할 필요가 없다는 점도 좋고, 얼마나 많이 넣든 상관하지 않는다는 점도 좋습니다.그러나 분석과 같은 고급 작업은 기껏해야 고통스럽습니다.서버 측에서 직접 계산을 수행해야 합니다.어느 컴퓨터에서나 simpledb CLI를 사용할 수 있다는 것도 큰 장점입니다. http://code.google.com/p/amazon-simpledb-cli/ 내 데이터를 쿼리합니다.

혼란스러운 'Gotchas'가 있습니다. 예를 들어, 속성은 둘 이상의 값을 가질 수 있으며 항목을 저장할 때 '교체'를 명시 적으로 설정해야합니다.또한 undef 또는 null 문자열을 저장하면 해당 속성 이름/값 쌍을 삭제하거나 null/빈 문자열로 설정하는 대신 라이브러리 오류가 발생합니다.

대체로 표준화되지 않은 방식으로 생각하는 방법을 배우는 것도 약간 이상합니다. 이것이 바로 새로운 응용 프로그램에 가장 적합하다는 위의 제안을 두 번째로 생각하는 이유입니다.SQL 앱에서 SimpleDB로 포팅하는 것은 애플리케이션 논리를 변경해야 하기 때문에 어려울 수 있습니다.일을 하는 방식이 조금 다릅니다.Amazon 문서는 이에 대해 꽤 잘 설명하고 있습니다.

이 모든 것은 SimpleDB 위에 있는 라이브러리에서 추출 가능하므로 SimpleDB를 사용하려면 좋은 라이브러리를 선택하는 것이 좋습니다.당신은 아마도 그것을 직접적으로 다루고 싶지 않을 것입니다.작업을 쉽게 하기 위해 PHP 측에 몇 가지 작업이 있으며 내 라이브러리도 있습니다.RAILS 활성 소스가 있지만 그다지 도움이 되지 않는 것 같습니다.

전체적으로 아직 초기 단계이지만 다른 API(트위터가 떠오름)에 비해 SimpleDB REST API는 매우 간단하고(특히 XML이라는 점을 고려하면) 작업하기 정중하다고 말하고 싶습니다.나는 그것을 추천할 것이다...귀하의 응용 프로그램 요구 사항과 사용 경제성에 따라 다릅니다.DB에 큰 부하를 주지 않는 서비스를 빠르게 확장하고 확장 가능한 MySQL/memcache 콤보를 사용하고 싶지 않다면...그러면 SimpleDB가 '간단한' 솔루션을 제공할 수 있습니다.

나는 그 기능이 계속해서 성장할 것이며 더 복잡하고 흥미로운 일을 하는 점점 더 많은 응용 프로그램에 대한 좋은 선택이 될 것이라고 기대합니다.그러나 지금은 일반적인 Web 2.0 서비스를 대상으로 하고 있으며 이에 적합합니다.

우리는 새 프로젝트에 거의 독점적으로 SimpleDB를 사용하고 있습니다.유지 관리가 필요 없고 가용성이 높으며 설치가 필요 없다는 측면은 너무 좋습니다.Ruby 개발자라면 다음을 확인해 보세요. 심플레코드, SimpleDB용 인터페이스와 유사한 ActiveRecord로 매우 사용하기 쉽습니다.

하지만 정말 SQL Server가 필요한가요?PostgreSQL이나 MySQL을 사용할 수 없나요?둘 다 대부분의 작업에 적합한 것으로 입증되었습니다.

이제 SQL Server 기능이 필요하다면 운이 없는 것입니다.

또 다른 옵션은 서버를 임대하는 것입니다.얼마나 비싼가요?

(저는 애플리케이션용 이미지를 저장하기 위해 Amazon S3를 사용했습니다. 적어도 그 점에서는 괜찮고 잘 작동합니다.)

저는 SimpleDB를 사용하지 않았지만 애플리케이션에 S3, EC2 및 MySQL의 조합을 사용해 왔습니다.

SimpleDB를 사용할 의향이 있다면 MySQL(확장성이 뛰어나고 비용이 많이 들지 않음)을 사용하는 것도 고려해 볼 수 있습니다.

S3와 EC2 측면에서도 실제로는 훌륭합니다.

SimpleDB는 많은 애플리케이션에서 훌륭하게 작동합니다....프로젝트에 많은 분석 보고, 참여 등이 필요한 경우 MySQL 또는 하이브리드 모델을 고려할 수 있습니다.

SimpleDB로 가면 우리는 내부용으로 Radquery.com을 개발하여 대중에게 공개했습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top