쓰기가 많은 웹 응용 프로그램의 데이터베이스 디자인

Question

우리가 고객에게 제공하는 많은 LOB 응용 프로그램은 마케팅/홍보 성격 (경품 행사, 이벤트 등록 등)입니다. 대부분의 응용 프로그램은 매우 간단하지만 데이터베이스에서 매우 까다로운 작업을 수행합니다. 예를 들어 슈퍼 보울 중 방송되는 상업용 광고의 뒷받침으로 "등록"유형 사이트를 상상해보십시오 (예, 몇 가지 있습니다).

웹 응용 프로그램 코드를 최적화하는 데 매우 능숙했지만 응용 프로그램이 비교적 간단 함에도 불구하고 데이터베이스는 항상 문제가되었습니다. 흐름은 일반적으로 같은 것입니다 : 기록이 많은 경우

새로운 경우 기록을 데이터베이스에

쓰기를 기존 감지하는 데이터베이스에서

1. 읽기,이 모든 데이터는 우리의 응용 프로그램에 필요에 액세스입니다 행하다. 그러나 응용 프로그램의 유일한 목적이므로이 간단한 프로세스를 크게 최적화하는 것이 중요합니다.

   이 질문에서 우리는 하나의 서버에 데이터 파일에 대한 RAID 5 디스크 배열과 로그에 대한 RAID 5 배열을 실행합니다. 현재 OS는 Windows 2003 표준 32 비트이고 서버는 4GB의 메모리를 가지고 있습니다. 일부 응용 프로그램은 SQL 2005 표준을 사용하는 반면, 일부 응용 프로그램은 MySQL 5.1을 사용합니다. 저는 입니다. 여기에서는 특정 OS 및 하드웨어 최적화가 가능하지만 소프트웨어 측면에서 먼저 필요를 충족시키기 위해 노력하고 있습니다. 광범위한 프로파일 링은 디스크 IO가 일반적으로 주 병목 인임을 가르쳐 왔습니다.

   대부분의 읽기가 고유하고 매우 적은 데이터 (종종 레코드가 존재하는지 여부를 나타내는 비트)를 반환하기 때문에 캐싱이별로 도움이되지 않는다는 것을 알고 있다면, 필자는 실제 데이터베이스에 대한 쓰기 캐시 계층의 일종 인 메모리 내 데이터베이스의 영역. 이것은 대용량 트래픽의 대부분이 본질적으로 산발적이며 몇 시간 동안 지속되지 않는다는 점을 고려할 때 적합합니다. 또한 대부분의 경우 서버 충돌로 인한 몇 분의 데이터 손실 가능성이 있습니다.

   1. 쿼리 기존 레코드
   2. 것도, 메모리 DB에 데이터를 쓸 경우의 디스크 DB와 메모리 DB : 가장 단순한 형태에서

      , 나는 다음을 수행하는 전형적인 등록 앱을 수정 것 디스크 DB에

   3. 정기적으로 세척 메모리 DB를 반환

   내 질문은입니다 :이 중간 나를 - 내 옵션이 무엇입니까 메리 데이터베이스? 나는 메모리 내 해시 테이블, 데이터 테이블 등을 실험했지만 다른 옵션이나 완전히 다른 접근법에 대한 제안을 찾고있다.

Answer 1

"모든 것이 메시지입니다. 데이터베이스는 백업입니다"라는 새로운 개념을 포용하십시오. 저장할 항목이 있으면 메시지를 작성하고 XMPP를 사용하여 eJabberD와 같은 블랙 박스로 보내십시오. 블랙 박스가 자신의 일정대로 데이터베이스를 업데이트하게하십시오. 이것이 트위터가 작동하는 방식입니다.

는이 슬라이드 쇼에서보세요 : http://www.slideshare.net/kellan/beyond-rest

Answer 2

SQLite의 동작 모드는 in memory입니다. 이것은 페이지 히트 처리기 뒤에 영구 서버 프로세스가있는 경우 작동합니다.

그렇지 않으면 일반 파일 기반 데이터베이스를 속여 파일을 tmpfs과 같은 메모리 파일 시스템에 쓸 수 있습니다.

Answer 3

실시간으로 기존 레코드가 있는지 (예 :레코드가 들어가는 것이 중요하지만 사용자에게 새 레코드인지 기존 레코드인지를보고 할 필요는 없습니다.) 인라인 (in-place) 레코드가 필요없이 매우 빠른 쓰기 시간을 허용하는 방식으로 데이터베이스를 구성 할 수 있습니다. 메모리 데이터베이스는 서버가 다운되거나 작업 프로세스가 다시 시작될 경우 많은 잠재적 인 문제를 발생시킵니다.

이 쓰기가 많은 플로우와 관련된 각 테이블에 대해 데이터베이스에 두 개의 테이블을 작성하십시오. 하나의 테이블은 사용자의 "실행중인"테이블이어야하며 최대한 쓰기 최적화되어야합니다 (즉, 인덱스가없고 읽기 테이블로 이동할 때를 제외하고는 읽지 않습니다). 다른 테이블은 읽기 최적화 테이블이어야합니다.보고 고려 사항 등에 따라 적절하게 인덱싱됩니다.

라이브 테이블에 글을 쓸 때마다 레코드가 새 것이 든 기존이든 상관없이 무시하십시오. 가능한 빨리 테이블에 데이터를 가져오고 DB에서 벗어나는 것입니다. 실시간 테이블의 레코드를 최적화 된 테이블로 이동시키는 예약 된 작업을 설정하고 기존 레코드와 일치하는 것에 대해 걱정하십시오. 이상적으로 이것은 피크 시간이 아닌 시간에 수행 될 것이지만 그렇지 않은 경우에는 라이브 테이블에 언제든지 경합하지 않도록 세 번째 스테이징 테이블을 고려할 수 있습니다.

Answer 4

언급 한 데이터베이스에 대해 잘 모르겠지만 데이터베이스의 내용 (또는 중요한 테이블)이 메모리에 들어 있으면 오라클이 캐시에 고정 할 수 있으므로 기본적으로 메모리 데이터베이스.

데이터베이스의 격리 수준 설정도 확인합니다. 당신이 그 (것)들을 이완 할 수있는 경우에 당신은 잠그기를 감소시킬 수있을 것입니다.

마지막으로 고유 제한 조건을 제거하거나 사용량 제한 시간 동안 사용하지 않도록 설정하는 것이 좋습니다.

Answer 5

내 견해로, 사용자가 사용할 수있는 캐시가있는 RDBMS로 작업량을 수용 할 수 있어야합니다. 일반 하드웨어를 사용하는 간단한 C++ 호출 가능한 RDBMS를 사용하여 초당 10000 개의 인덱싱 된 레코드 순서를 보았습니다. 여기에는 디스크 커밋이 포함됩니다. 또한 레코드에서 하나의 작은 필드 만보고있을 수 있으므로 열 기반 데이터베이스 (데이터를 열 아래에 저장하는 데이터베이스)를 찾습니다. 한 필드에만 관심이있는 경우 전체 행을 읽는 데 아무런 의미가 없습니다. 난 당신이 이미

인 메모리 데이터베이스를 조사하기 전에이 있었던 것 같아요 있지만

Answer 6

많은 다른 사람에 의해 언급 한 바와 같이, 읽기보다는 쓰기에 대한 데이터베이스 스키마 최적화가, 호출의 첫 번째 포인트입니다, 당신은 할 수 있습니다 사용할 수있는 ORM 중 일부, 특히 NHibernate를 살펴보아야합니다.

NHibernate는 일부 데이터를 메모리에 유지하고 데이터 업데이트가 메모리에서 플러시되고 데이터베이스와 동기화 될 때 일부 제어를 허용합니다.

보기 좋을 것 같습니다.

Answer 7

프로그래밍과 관련이 없지만 분명히 도움이 될 것입니다. 새로운 솔리드 스테이트 디스크를 구하십시오.

예 그들은 크기면에서 비싸지 만 디스크 IO는 병목 현상이므로 일부 SSD의 경우 현재 HDD를 교체하면 성능이 크게 향상됩니다.

Answer 8

편집 : 당신이 할 수

1. 만큼 불필요한 인덱스를 추출 ... 디스크 I/O에 엄격하게 집중. 지수는 자유 공간 또는 시간에 오지 않습니다.
2. 불필요한 특수 트리거 또는 제한 조건을 추출하십시오.
3. 절대적으로 중요하지 않은 엔티티 관계/관계 무결성 연산자를 추출합니다.
4. 현재 DBMS에서 지원하는 경우 트랜잭션 테이블을 여러 디스크로 분리하십시오 (예 : 라운드 로빈).
5. 더 많은 데이터베이스 서버를 서로 독립적으로 추가하는 것을 고려합니다 (복제가 필요 없음). 이렇게하려면 트랜잭션을 승인 할 서버와 트랜잭션을 통합하는 계획/별도 프로세스를 결정하는 스케줄러가 필요합니다.

기본적으로 이베이 (ebay)가 채택한 접근 방법은 데이터베이스 로직의 양을 최소화하고 서버를 옆으로 추가하는 것입니다 (최첨단 서버 기술과 반대 됨).

Answer 9

다음은 이상한 생각 : 초기 캡처에 대한 데이터베이스를 사용하지 않습니다. 두세 가지의 비명을 지르며 빠르게 색인 된 파일을 디자인하십시오. 형식은 자주 변경하지 않아도됩니다. 해당 파일의 데이터를 캡처하십시오.

캡쳐 된 데이터를 데이터베이스로 복사하지만 대화 형 사용자는 지연시키지 않는 적절한 소프트웨어를 작성하십시오. 중복 된 사본을 방지하고 파일의 공간을 재활용하려면 복사 된 데이터를 표시하십시오.

이제 캡처 프로세스를 유지하는 아이디어보다는 여러 용도로 데이터를 공유하는 아이디어로 데이터베이스를 디자인 할 수 있습니다. 결국 데이터 공유는 데이터베이스가 실제로 빛나는 곳입니다.