대략 $1000 상당의 MySQL 서버를 얼마나 활용할 것으로 예상할 수 있습니까?

Question 1

당신이 언급했듯이 이것은 매우 광범위한 추정치입니다.

가장 큰 문제는 그 1000달러로 무엇을 사느냐 하는 것입니다. 평균적인 하드 디스크를 사용하여 약간 더 많은 메모리와 더 적은 프로세서 성능을 원한다고 가정하면 해당 매개변수를 사용하여 합리적으로 코딩된 응용 프로그램(합리적인 경우 = 주로 해당 언어에서 제공하는 추상화 라이브러리를 사용하는 경우)은 약 500개를 처리할 수 있어야 한다고 말하고 싶습니다. 동시 사용자. 행 세트의 크기를 제외하면 더 많은 것을 추측했을 것입니다(RAM에 직접 맞는 행이 많을수록 즉시 쓰기를 위해 수행해야 하는 디스크 작업이 줄어들기 때문입니다).

행에 있는 데이터 유형과 감당할 수 있는 RAM 용량이 이 시나리오에서 가장 큰 요소가 될 것입니다. 쓰기 횟수를 줄이고 인덱싱된 테이블의 크기를 줄일 수 있다면 동시에 1,000명의 사용자를 확보할 수 있을 것이라고 생각합니다.

당신이 보게 될 두 가지 문제는 다음과 같습니다.

RAM에 캐시할 수 있는 데이터의 양과 기본 OS 및 데이터베이스 서버 작업을 실행하는 데 필요한 최소 이상의 RAM 양에 따라 무엇을 피할 수 있는지가 결정됩니다. 더 많은 RAM, 더 적은 OS 요구 사항, 쿼리 및 쓰기를 위해 RAM에 보관해야 하는 유용한 데이터 양이 더 적다는 것은 수용 가능한 성능과 많은 스래싱 간의 차이를 의미합니다.
여기서는 앱 디자인이 절대적으로 중요합니다. 500~1000명의 사용자에게 분산된 한 번의 쓰기는 엄청난 영향을 미칩니다. 마찬가지로 통화가 간단하고 효율적이지 않으면 열차 사고가 빨리 발생할 것입니다. 나는 작동 방식에 대한 약간의 지식을 바탕으로 내가 본 여러 mySQL 앱을 기반으로 추정했습니다. 앱에 근본적인 문제가 있는 경우 사용자가 40명도 되지 않을 수 있습니다. 효율적으로 코딩하고 하드웨어 제한을 고려하면 쉽게 2,000개 이상으로 확장할 수 있습니다.

Answer

당신이 언급했듯이 이것은 매우 광범위한 추정치입니다.

가장 큰 문제는 그 1000달러로 무엇을 사느냐 하는 것입니다. 평균적인 하드 디스크를 사용하여 약간 더 많은 메모리와 더 적은 프로세서 성능을 원한다고 가정하면 해당 매개변수를 사용하여 합리적으로 코딩된 응용 프로그램(합리적인 경우 = 주로 해당 언어에서 제공하는 추상화 라이브러리를 사용하는 경우)은 약 500개를 처리할 수 있어야 한다고 말하고 싶습니다. 동시 사용자. 행 세트의 크기를 제외하면 더 많은 것을 추측했을 것입니다(RAM에 직접 맞는 행이 많을수록 즉시 쓰기를 위해 수행해야 하는 디스크 작업이 줄어들기 때문입니다).

행에 있는 데이터 유형과 감당할 수 있는 RAM 용량이 이 시나리오에서 가장 큰 요소가 될 것입니다. 쓰기 횟수를 줄이고 인덱싱된 테이블의 크기를 줄일 수 있다면 동시에 1,000명의 사용자를 확보할 수 있을 것이라고 생각합니다.

당신이 보게 될 두 가지 문제는 다음과 같습니다.

RAM에 캐시할 수 있는 데이터의 양과 기본 OS 및 데이터베이스 서버 작업을 실행하는 데 필요한 최소 이상의 RAM 양에 따라 무엇을 피할 수 있는지가 결정됩니다. 더 많은 RAM, 더 적은 OS 요구 사항, 쿼리 및 쓰기를 위해 RAM에 보관해야 하는 유용한 데이터 양이 더 적다는 것은 수용 가능한 성능과 많은 스래싱 간의 차이를 의미합니다.
여기서는 앱 디자인이 절대적으로 중요합니다. 500~1000명의 사용자에게 분산된 한 번의 쓰기는 엄청난 영향을 미칩니다. 마찬가지로 통화가 간단하고 효율적이지 않으면 열차 사고가 빨리 발생할 것입니다. 나는 작동 방식에 대한 약간의 지식을 바탕으로 내가 본 여러 mySQL 앱을 기반으로 추정했습니다. 앱에 근본적인 문제가 있는 경우 사용자가 40명도 되지 않을 수 있습니다. 효율적으로 코딩하고 하드웨어 제한을 고려하면 쉽게 2,000개 이상으로 확장할 수 있습니다.

Question 2

나는 그것에 대답할 수 있다. 방금 그 차에서 내려서 다시 타겠습니다.

$650-$800이면 1TB SATA2 드라이브를 실행하는 8GB RAM 중간 속도 쿼드 코어 AMD를 구입할 수 있습니다. 170달러로 상대적으로 빠른 두 번째 1TB 드라이브를 구입할 수 있습니다. 이는 대부분의 전자제품/사무실/베스트 바이 유형 장소의 기성품 하드웨어라는 점을 명심하세요. 다른 곳에서 더 많은 것을 얻을 수 있지만 돈이 나쁜 것은 아닙니다. 조금 더 많은 비용으로 더 빠른 쿼드 코어를 얻을 수 있습니다.

이제 앱과 관련하여 OS용으로 linux/BSD/unix를 실행하고 ms 대 unix 논쟁을 피한다고 가정하겠습니다. 내가 찾은 내용은 다음과 같습니다.

앱이 아무리 약하더라도 깜박임 없이 모든 애플리케이션에서 200명 이상의 활성 사용자/세션을 지정하는 데 아무런 문제가 없습니다. 사실, 우리는 한동안 우리가 실행한 쿼드 코어 서버에서 애플리케이션을 삭제/충돌/정지시킬 수 없었습니다.... 하지만 우리는 싱글 코어 200mhz 시절에 몇 가지 교훈을 얻었습니다.

예를 들어, 우리 자매 회사는 기계당 1300명 이상의 사용자와 시간당 평균 수백 개의 동시 세션을 제공하는 꽤 많은 mysql 기반 통신 모니터링 시스템을 판매합니다. 로깅 및 보고는 실시간으로 수행되며(일부 버퍼링이 발생함) 느린 PATA 드라이브의 3Ghz 듀얼 코어 시스템에서 실행되었습니다. 실제로 133Mhz P-ata 드라이브입니다. 가장 긴 사용자 인터페이스 지연은 약 2초였습니다. 그들은 10년 전에 MySQL용 MSSQL을 버리고 즉시 결과를 얻었습니다.

명심하세요, 이 기계들은 webapps+databases...를 실행하고 있으므로 계산을 하십시오. 그냥 작동합니다. 또한 나는 다수의 oracle/MS/xxxx 애플리케이션을 이것으로 교체했는데, 결코 활력이 떨어지지 않았습니다. 또한 다른 사람이 DBA 관점에서 말한 내용을 확장해 보겠습니다. 다음은 트렌치에서 얻은 6가지 팁입니다.

쓰기는 성능을 저하시킵니다. 특히 잠금 페널티가 코더에게 낯선 개념인 경우 더욱 그렇습니다.
하나의 거대한 테이블에서 모든 작업을 수행하면 죽을 것입니다.
과도한 정규화는 당신의 친구가 아닙니다. 코더가 완전한 3차 정규형으로 진행되면 앱이 제대로 실행되지 않습니다. 비정규화된 데이터는 더 많은 공간을 차지하지만 간단한 쿼리로 훌륭한 작업을 수행할 수 있습니다.
하나의 큰 테이블은 빈번한 쓰기로 인해 질식합니다. 1을 참조하세요.
데이터 표시를 위해 하나 이상의 테이블을 사용하고 시스템 로드가 허용될 때 읽기 테이블에 동기화될 수 있는 쓰기용 다른 테이블을 사용하도록 앱을 작성하면 모든 종류의 문제를 해결할 수 있습니다. 적은 수의 테이블을 사용하여 쓰기를 버퍼링하고, 누구도 밟지 않기 때문에 놀라운 수의 트랜잭션에 대처할 수 있습니다.
인덱스를 사용하세요. 어쨌든 쿼리의 어떤 부분이 키로 사용되는지 알고 있다면.
메모리를 기반으로 데이터베이스 설치를 조정합니다. 온라인으로 MySQL 문서를 참조하세요. 실제로 활성 세션이 1000개 미만인 경우 연결 수를 늘리고 계속 진행할 수 있는 경우가 많습니다. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

대부분의 wordpress 등을 보면 어리석은 SQL이 실제로 작동하는 것을 볼 수 있습니다. 플러그인. 대부분은 SQL을 사용하지 않는 사람들이 작성했으며 소수의 사용자만으로도 서버를 즉시 무릎 꿇게 만들 것입니다.

Answer