호스팅된 웹 애플리케이션을 디자인하는 방법은 무엇입니까?

Question

호스팅된 웹 애플리케이션을 어떻게 디자인하시겠습니까?Basecamp, Campaign Monitor, Freshbooks 등과 같은 애플리케이션을 보고 있습니다.사용자가 온라인으로 가입할 수 있고 애플리케이션이 호스팅되는 곳입니다.

1. 하나의 큰 데이터베이스를 사용하여 모든 고객의 데이터를 저장하시겠습니까, 아니면 데이터를 다르게 처리하시겠습니까?2개 이상의 데이터베이스를 사용하시겠습니까?각 고객에 대한 데이터베이스를 만드시겠습니까?
2. 각 가입/고객에 대해 코드 기반을 복제하시겠습니까, 아니면 모든 고객을 처리하기 위해 1개의 코드 기반을 사용하시겠습니까?
3. 제가 고려해야 할 다른 디자인 요소가 있나요?
4. 이에 대해 이야기하는 웹사이트나 책이 있나요?

편집하다:다중 테넌트 데이터 아키텍처를 논의한 MSDN 기사를 찾았습니다.http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

Answer 1

37Signals를 참조하십시오.이 분야의 전문가이며 커뮤니티 질문에 대답하는 많은 기사가 있습니다 (많은 사람들이 등장해야합니다).

높은 확장 성 = 37signals 아키텍처

37Signals에게 물어보십시오 : 신용 카드를 어떻게 처리합니까?

David Heinemeier Hansson의 데이터베이스 수와 관련하여 무엇을 알고 싶습니까?

몇 가지 기술 답변…

랜스, 예정된 모든 청구 작업이 자동화됩니다. 어떤 것도 우리를 미치게 할 것입니다. 신용 카드에 실패하기 위해 우발 사태 취급이 마련되어 있는지 확인하는 것이 특히 중요합니다. 마지막으로, 나는 만료 된 신용 카드 덕분에, 한도를 통해 또는 폐쇄 된 신용 카드 덕분에 우리의 요금의 5%가 튀어 나왔다고 생각합니다. 우아하게 처리하십시오.

우리는 숫자를 안전하게 유지하는 Authorize.net과 별도의 신용 카드 응용 프로그램 (레일로 개발되어 내부 네트워크의 다른 앱에서 사용하는 작은 앱)을 사용합니다.

워렌, 우리는 동일한 데이터베이스에서 무료로 운영하고 계정을 지불합니다. 응용 프로그램 당 하나의 데이터베이스입니다. 계정 당 하나의 데이터베이스는 일반적으로 정말로 정말 나쁜 생각입니다. 일반적으로 데이터는 상당히 정규화되지만 우리는 분명히 종교적이지 않습니다. 일반적으로 스키마를 통해 소스 코드를 소중히 여깁니다. 따라서 스키마를 구부하여 더 나은/더 예쁘게 소스 코드를 얻을 수 있다면 일반적으로 그렇게하겠습니다. 그러나 성능 또는 코드 구조가 요구함에 따라 정규화되고 비정규 화에서 시작합니다.

Jason, 우리는 SMS에 이메일을 사용합니다. 모든 미국 항공사에는 폰@carrier-gateway.com 게이트웨이가 있습니다.

Jake Good, Ahh, 좋은 ol '“그러나 그것은 규모가 규모입니다”질문. 나는 몇 년 전에 그 대답했다. 그 이후로 우리를 위해 아무것도 바뀌지 않았습니다. 우리는 많은 캐싱에 의지하지 않고 매일 수백만과 수백만의 동적 요청을 관리합니다 (대부분의 응용 프로그램의 대부분의 화면은 사용자별로 다르므로 전통적인 캐싱 체계는 적용하기가 더 어렵습니다).

수천만 건의 일일 요청을 관리하는 다른 레일 애플리케이션이 많이 있습니다. 모두 동일한 공유 접근법을 다소 따르십시오. 높고 키가 크고 스케일링을위한 모든 기술이 있습니다. 턴키 솔루션은 아니지만 약속 한 것은 일반적으로 그로 가득합니다.

Answer 2

수천 명의 고객 (수십만 또는 수백만 대)에 대해서만 이야기하고 있다면 고객 당 수천 행 이상을 가지고있을 수있는 테이블이 있다는 것을 알지 않는 한 차이는 매우 적습니다. 그러면 디자인이 바뀔 수 있습니다.

관계형-데이터베이스 기반 DataStore를위한 정상적인 설정은 customer_id 대부분의 테이블에 대한 외국 키. 그런 다음 해당 데이터를 다른 사람에게 보여주지 마십시오. 고객 (또는 어떻게 든 명시 적 권한이 다른 사람에게 부여 된 경우).

RDBMS 스케일링 문제에 대해 너무 많이 걱정하지 마십시오. 한 테이블에 수백만 행을 가질 수 있습니다. 그런 다음 분산 키/가치 저장소를 조사 할 때가 될 수 있습니다. 그러나 그러한 종류의 문제는 좋은 문제라는 점을 명심하십시오. 아마도 당신이 많은 현금을 만들고 있다는 것을 의미하기 때문입니다.

즉, 당신이 그것에 올 때 스케일링 브리지를 건너십시오. 현재 능력을 최대한 활용할 수있는 최선을 다하지만 조기 최적화는 모든 악의 근원입니다.

Answer 3

저는 여러 SaaS 앱의 컨설턴트로 일하면서 다양한 아키텍처를 보았습니다.나는 다음을 추천합니다:

1. 모든 고객을 위한 하나의 데이터베이스.자신의 고유 ID인 사용자에 대한 기본 키를 갖도록 DB를 잘 설계해야 합니다.나는 디자인이 효과적으로(실제로는 아니지만 그랬을 수도 있음) 이메일, 전화번호 등과 같은 것을 기본 키로 만든 일부 혼란을 보았습니다.또한 모든 것을 거대한 사용자 테이블에 집어넣지 마십시오.

   1. 어느 시점에서 많은 사용자 상호 작용 동작을 추적하기 시작하고 싶을 것입니다.이를 위해 NoSQL 이름-값 저장소를 사용하고 나중에 분석하기 위해 여기에 이벤트를 던지기 시작할 수 있습니다.또는 MixPanel이나 KISSmetrics와 같은 것을 사용하세요.

   2. 시간이 지남에 따라 발생한 상황을 쉽게 쿼리할 수 있도록 KPI 테이블에 행을 작성하여 일일 KPI를 추적하세요.그렇지 않으면 DB에 질문을 하고 싶게 되고 그렇게 하는 것이 엄청난 쿼리라는 것을 알게 될 것입니다.

단일 SQL DB를 갖는 주요 이점은 마케팅 담당자가 SQL을 알고 있는 경우(권장!) 직접 쿼리할 수 있다는 것입니다.NoSQL 경로로 가면 훨씬 더 어려워지며 마케팅은 일반적으로 잘못된 가정을 하기 시작하고 이러한 가정을 기반으로 잘못된 경로를 따라가는 데 많은 시간을 낭비하게 됩니다.