언제 Sql Azure를 사용해야하고 언제 Table Storage를 사용해야합니까?

언제 Sql Azure를 사용해야하고 언제 Table Storage를 사용해야합니까?

---

Sql Azure는 언제 사용해야하고 언제 Table Storage를 사용해야합니까? 나는 거래 처리 시나리오에 테이블 스토리지를 사용하고 (예 : 차변 신용 계정 시나리오) 데이터가보고와 같은 거래 목적으로 사용되지 않을 때 Sql Azure를 사용한다고 생각했습니다. 어떻게 생각해?

---

이것은 훌륭한 질문이며 솔루션 아키텍트가 Azure 용으로 설계 할 때 내려야하는 결정을 되돌리기가 더 어렵고 어렵습니다.

고려해야 할 여러 가지 차원이 있습니다. 부정적인 측면에서 SQL Azure는 기가 바이트의 스토리지에 비해 상대적으로 비싸고 확장 성이 뛰어나지 않으며 데이터베이스 당 150 기가로 제한되지만 이는 매우 중요합니다. SQL에 대한 거래 수수료가 없습니다. Azure와 개발자는 이미 이에 대해 코딩하는 방법을 알고 있습니다.

ATS는 모두 다른 동물입니다. 대규모 확장이 가능하며 저장 비용은 저렴하지만 자주 액세스하려면 비용이 많이 듭니다. 또한 조작하려면 노드에서 상당한 양의 CPU 성능이 필요합니다. 기본적으로 모든 관계형 활동의 위임이 그들에게 넘겨 짐에 따라 컴퓨팅 노드가 미니 DB 서버가되도록 강제합니다.

따라서 제 생각에는 큰 확장 성이 필요하지 않고 크기가 너무 크지 않은 자주 액세스하는 데이터는 SQL Azure, 그렇지 않으면 Azure Table Services로 향해야합니다.

특정 예를 들어 금융 거래의 트랜잭션 데이터는 ATS를위한 완벽한 장소 인 반면 메타 정보 (계정 프로필, 이름, 주소 등)는 SQL Azure에 적합합니다.

---

이고르와 마크는 훌륭한 대답을했습니다. 조금 더 추가하겠습니다 ...

SQL Database (이전 이름 ​​: SQL Azure)를 사용하면 이제 최대 500GB의 데이터베이스를 사용할 수 있습니다. 그 이상으로 나아가려면 데이터를 분할해야합니다. 참고 : 원래 SQL 페더레이션을 사용하여 샤드를 제안했지만이 기능은 이후 폐기되었습니다.

ATS는 파티션 수준에서 트랜잭션을 제공합니다 (엔티티 그룹 트랜잭션). 자세한 내용은 이 MSDN 문서 를 참조하십시오. 이는 SQL Azure 트랜잭션만큼 강력하지는 않지만 단일 트랜잭션에서 일괄 작업을 허용합니다.

편집 이 질문을하고 답변 한 지 1 년이 넘었습니다. 한 가지 비교 포인트는 가격 책정이었습니다. SQL Azure는 여전히 ATS보다 비싸지 만 SQL Azure의 비용은 작년에 크게 떨어졌습니다. 이제 데이터베이스에는 100MB의 경우 4.99 달러에서 시작하여 150GB의 경우 225 달러로 증가하는 계층화 된 가격이 적용됩니다 (작년에 비해 GB 당 9.99 달러의 가격에서 크게 떨어졌습니다. 자세한 가격은 여기) .

2014 년 8 월 편집 또 다른 1 년 후, 다른 업데이트. 웹 / 비즈니스 계층은 계속 존재하지만 지원이 중단되고 있으며 SQL Federation은 더 이상 사용할 수 없습니다. 이제 새로운 기본, 표준 및 프리미엄 계층을 사용할 수 있습니다 (자세한 내용은 여기 참조).

---

이 답변 중 일부가 완전하지 않은 것 같으므로 2 센트를 추가하겠습니다.

Azure Table의 장점 :

• 장점은 많은 양의 작은 데이터를 저장할 수 있다는 것입니다. Azure 테이블은 Azure Blob을 기반으로하지만 더 작은 데이터를 대상으로합니다.
• Azure SQL Server보다 훨씬 저렴
• 파티션 키와 행 키를 모두 알고있을 때마다 데이터 액세스가 매우 빠릅니다.
• Entity transactions 동일한 파티션 키에 두 개의 다른 "스키마"를 배치하면 가능합니다.
• 총 행 크기가 980K 미만인 경우 (SQL 행)
• 각 속성이 64K 미만인 경우 (SQL 열)
• 가난한 사람의 SQL 역할을 할 수 있습니다.

Azure 테이블의 단점 :

• SQL이 약점입니다. 큰 SQL 테이블에서 이것을 사용할 것으로 예상하지 마십시오. 그렇지 않으면 성능 문제가 발생합니다.
• 제한된 SQL을 사용할 수 있으며 Linq에서 구현하는 것 외에 어떤 유형의 조인도 기대하지 마십시오.
• Azure Table SQL은 무한한 양의 데이터를 저장할 수있을뿐만 아니라 확장되지 않습니다.
• WHERE 절에서 파티션 키와 행 키를 모두 지정하지 않을 때마다 느린 테이블 스캔이 발생할 것으로 예상됩니다.
• 행을 더 추가하면 테이블 스캔 성능이 저하 될 것으로 예상됩니다.
• 행을 더 추가 할 때 Azue Table 쿼리가 빠르다고 기대하지 마세요.
• 결론은 Azure Table을 사용하여 SQL처럼 작동하는 경우 데이터를 많이 추가하지 않습니다. 많은 데이터 (기가 바이트)가있는 경우 이에 대해 고성능 SQL 쿼리를받을 계획을 세우지 마십시오. 일반 SQL 기능이 필요하지 않으면 비용을 절약 할 수 있습니다.

---

트랜잭션에 관해서는 그 반대입니다. SQL Azure는 트랜잭션을 지원합니다. 테이블 스토리지는 그렇지 않습니다.

SQL Azure는 기본적으로 Windows Azure 내에서 실행되는 SQL Server이므로 SQL Server를 사용 하는 기존 애플리케이션 이있는 경우 SQL Azure는 좋은 마이그레이션 경로를 제공합니다 . 그러나 SQL Azure에서 보유 할 수있는 데이터베이스 크기 (현재 150GB)에는 제한이 있으므로 확장 할 수있는 정도에 제한이 있습니다.

반면에 테이블 스토리지는 확장 성이 매우 뛰어나지 만 다른 사고 방식이 필요합니다. 관계형 데이터베이스 가 아닙니다 . 좋은 소개는이 기사를 참조하십시오 : http://msdn.microsoft.com/en-us/magazine/ff796231.aspx

---

The real answer is, "Try really hard not to use Azure Table Storage". Whenever you move from a relational DB to a no-sql DB, you are of course going to have to change how you think about your storage architecture. But the problems with ATS go way, way beyond just needing to "think differently". As other folks have pointed out, it's not just a "No-SQL" data-store, it's a particularly stunted, handicapped, and very-low-featured instance of a No-SQL store. It's not a matter of needing to "think differently" about ATS; it's a matter of ATS not giving you the tools you need to do your job - tools that other no-sql data stores do give you.

About the only thing good about ATS is that you can put lots and lots of data into it very quickly, and with minimal storage fees. However, you basically can't hope to get that data back out again unless you're lucky enough to have a use-case that magically matches its Partition-Key/Row-Key storage model. If you don't - and I suspect very few people do - you're going to be doing a lot of partition scans, and processing the data yourself.

Beyond that, Azure Table Storage seems to be at a dead-end in terms of development. If you look at the "Support Secondary Indexes" request on the Azure feedback forums (http://feedback.windowsazure.com/forums/217298-storage/suggestions/396314-support-secondary-indexes), you can see that support for Secondary Indexes was promised as far back as 2011, but no progress has been made. Nor has any progress been made on any of the other top requests for Table Storage.

Now, I know that Scott Guthrie is a quality guy, so my hope is that all this stagnation on the Table Storage front is a preface to Azure fixing it and coming up with something really cool. That's my hope (though I have zero evidence that's the case). But for right now, unless you don't have a choice, I'd strongly recommend against Azure Table Storage. Use Azure SQL; use your own instance of MongoDB or some other No-SQL DB; or use Amazon DynamoDB. But don't use Azure Table Storage.

참고URL : https://stackoverflow.com/questions/4930368/when-should-i-use-sql-azure-and-when-should-i-use-table-storage