모든 사용자가 종종 10 ~ 300 초 동안 테이블에 레코드를 얻는 모듈을 만들고 있습니다.

시간이 만료되면 레코드가 삭제됩니다. 사례는 다음과 같습니다. 많은 사용자와 레코드가 자주 변경 될 것입니다. 레코드가 자주 변경되고 mysql에 문제가 있는지 궁금하기 때문에이 테이블의 애플리케이션 성능에 어떤 영향을 미치나요? 인덱스가왔다 갔다하는 것처럼이 특정 테이블의 데이터는 200 회 / 초처럼 변경됩니다. 어쩌면 나는 이런 종류의 일을 위해 나쁜 해결책을 선택하고있을 것입니다. 어떤 제안?

감사합니다!

고려해야 할 사항 중 하나는 MySQL이 주요 스토리지 엔진에 버퍼를 사용하는 방식 ( InnoDB 및 MyISAM) 입니다.

메모리에 캐시 된 것은이 스토리지 엔진마다 크게 다릅니다.

InnoDB는 데이터와 인덱스 페이지를 모두 캐시합니다. 이들은 innodb_buffer_pool_size 크기로 InnoDB 버퍼 풀에로드됩니다 .

MyISAM은 인덱스 페이지 만 캐시하며 키 캐시 (키 버퍼)에로드되며 키 크기는 key_buffer_size 로 조정됩니다 .

InnoDB 버퍼 풀 및 MyISAM 키 캐시의 크기를 올바르게 조정 하려면 디스크에서 데이터 및 인덱스 크기를 확보 하려면 information_schema.tables 를 사용해야 합니다 .

보유한 데이터 양과 허용 시간에 따라 다음과 같이 캐시를 예열 할 수 있습니다.

모든 테이블에 대해

• 각 인덱스 NDX로 이동
• 각 인덱스 NDX
  • NDX의 모든 열에 대해 SELECT를 실행하십시오 . TableT 에서 TableT에 색인화되지 않은 하나 이상의 열

이렇게하면 모든 데이터 및 색인 페이지를 한 번 이상 읽을 수 있습니다. 그들은 캐시에 앉아있을 것입니다. 이 개념은 부분적으로 그리고 원칙적으로 Percona 에 의해 실행됩니다 . Percona는이 개념을 mk-slave-prefetch에 구축했습니다 . 이 프로그램이하는 일은

• 슬레이브에서 SQL을 처리하는 슬레이브보다 릴레이 로그 읽기
• 릴레이 로그에서 SQL 문을 가져 와서 인덱스 선택에 대한 지침으로 WHERE, GROUP BY 및 ORDER BY 절을 사용하여 SELECT로 변환하십시오.
• 변환 된 SQL에서 온 SELECT 문을 실행하십시오.

이로 인해 슬레이브가 SQL을 신속하게 처리하는 데 필요한 데이터의 99.99 %가 슬레이브에있게됩니다. 또한 수동으로 슬레이브로 페일 오버하고 마스터로 승격시키는 경우 슬레이브가 준비된 상태로 만듭니다.

결론

캐시를 준비하고, 기꺼이 준비하고, 무거운 INSERTS, UPDATE 및 DELETE 환경에서 사용할 수있는 것이 가장 좋습니다.

시도 해봐 !!!

경고

memcached와 같은 제품이 탄생함에 따라 일부는 MySQL의 적절한 튜닝을 수행 할 필요가 없어졌습니다. 물론 많은 사이트에서 개발자가 memcached로 빠르게 본 것처럼 데이터의 캐싱 동작을 제어하여 제공되는 데이터 검색이 향상되었습니다. 스토리지 엔진을 전환하거나 MySQL을 올바르게 구성하기 만하면 다른 많은 사이트에서도 동일한 성능 이점을 얻을 수 있습니다. 데이터베이스를 포기하고 리포지토리로 엄격하게 사용하기 전에 데이터베이스를 최대한 활용하십시오. 실사를 따르고 MySQL이 당신을 위해 무엇을하는지 유쾌하게 놀라게 될 것입니다.

그것이 나쁜 해결책이라면 많은 것들에 달려 있습니다. 이 데이터는 지속적이어야합니까? 그렇지 않으면 단순히이 데이터를 메모리에 유지하는 솔루션이 더 효과적 일 수 있습니다.

"많은 사용자"는 실제로 누구에게도 도움이되지 않습니다. "많은"것이 수백을 의미한다면 MySQL이 가장 좋을 것입니다. (데이터베이스가 처리해야 할 내용에 따라 다르지만 수천 개가 작동해야합니다.)

결국 몇 초에서 몇 분 후에 기록을 유지하거나 삭제하기 위해 기록을 작성하는 경우에는 그다지 중요하지 않습니다. 삭제하면 두 가지 작업 중 하나만 수행됩니다. 그리고 MySQL은 많은 양의 레코드 생성 및 삭제를 확실히 처리 할 수 ​​있습니다. 간단한 색인을 사용하여 삭제를 위해 해당 레코드를 다시 찾으십시오.

그러나 실제 숫자와 데이터베이스 서버가 사용하는 하드웨어에 대한 정보가 없다면, 정확하게 대답 할 수 없습니다.

가장 좋은 것은 작은 실제 응용 프로그램을 작성하는 것입니다. 실제로 많은 처리를하지 않고도 얻을 수있는 부하량을 시뮬레이션하고 서버에 대해 많은 레코드를 삭제하고 삭제하십시오. 나머지 프로그램은 생성됩니다. 서버를보고 어떤 식 으로든 영향을 받는지 확인하십시오.

확실하지는 않지만 MySQL에서 테이블을 메모리에 완전히 캐시 할 수있는 옵션이 있습니다. 어쨌든 많은 상황 에서이 작업을 수행하므로 크게 변경할 필요가 없습니다. 그러나 매우 많은 양의 사용자 및 레코드에 대해 이야기하는 경우 몇 가지 매개 변수를 조정하여 특별한 요구에 맞게 캐싱을 최적화 할 수 있습니다.

여기 미친 아이디어가 있습니다. 그것은 가정을 포함하고 항상 권장되는 관행 (키 업데이트와 같은)은 아닙니다.

대량의 행과 대량의 삭제가 있다고 가정하면 테이블에 2 개의 파티션을 작성하여 삭제 성능을 향상시킬 수 있습니다. 파티션은 키의 첫 번째 숫자에 따라 다릅니다. 예:

키 값 1123234441은 활성 행용이고 키 값 : 9123234441은 비활성 행용입니다 (이 예에서 첫 번째 숫자는 다음과 같이 사용됩니다 : 1 = 활성, 9 = 비활성).

이제 사용자가 행을 삭제할 때 행을 실제로 삭제하지 않고 키 (Ouch!)를 업데이트하면 행이 자동으로 비활성 행 파티션으로 이동합니다.

물론 활성 파티션에서만 데이터를 읽도록 선택을 제한해야합니다. 이제 멋진 부분은 비활성 행 파티션을 삭제하는 것이 매우 빠르다는 것입니다.

앞에서 말했듯이 테이블이 하나만 있으면 작동합니다. 나는 이것을 테스트하지 않았으므로 이론적 인 접근 방식이지만 파티션 삭제 속도를 경험했으며 놀랍도록 빠릅니다.

선택을 향상 시키려면 적절한 색인 작성을 사용하고 삽입을 향상시켜 행 크기 및 색인 수를 최소화하십시오 (이 명령문은 매우 일반적입니다 ...)

참조는 http://dev.mysql.com/doc/refman/5.1/en/partitioning-types.html을 참조하십시오. 이것이 도움이 되길 바랍니다.