수십억의 레코드 저장을 처리 할 수있는 데이터베이스는 무엇입니까?

Netflow 데이터를 캡처하고 분석하는 도구를 개발하는 중입니다. 매일 우리는 약 14 억 개의 흐름 레코드를 캡처하여 다음과 같이 json 형식으로 표시합니다.

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

데이터 세트에서 빠른 검색 (10 초 미만)을 할 수 있기를 원하며 좁은 시간 간격 (10-30 분 간격) 일 가능성이 높습니다. 또한 대부분의 데이터 포인트를 인덱싱하여 각 데이터 포인트를 빠르게 검색 할 수 있습니다. 또한 검색이 실행될 때 데이터를 최신 상태로보고 싶습니다. 오픈 소스 세계에 머무르는 것이 좋을 것입니다. 그러나 우리는이 프로젝트를위한 독점 솔루션을 보는 것에 반대하지 않습니다.

아이디어는 약 1 개월 분량의 데이터를 유지하는 것입니다. 약 443 억 개의 레코드입니다. 각 레코드가 약 480 바이트의 데이터를 포함 할 것으로 추정하면 대략 한 달에 ~ 18.7 테라 바이트의 데이터와 같으며 인덱스의 경우 3 배가됩니다. 결국 우리는이 시스템이 수조 개의 레코드를 저장하는 능력을 키우고 자합니다.

우리는 (거의 기본적으로)이 프로젝트의 가능한 후보까지 소파베이스, 카산드라 및 mongodb를 평가했지만 각자 고유 한 과제를 제안합니다. couchbase를 사용하면 인덱싱이 데이터를 삽입하는 동안이 아닌 간격으로 수행되므로 뷰가 최신 상태가 아니므로 cassandra의 보조 인덱스는 일반적으로 전체 클러스터를 스캔하여 결과를 검색해야하므로 결과를 반환하는 데 매우 효율적이지 않습니다. 마스터 / 슬레이브 / 샤드이므로 확장하기가 훨씬 어렵습니다. 우리가 평가할 다른 후보는 elasticsearch, mysql (이것이 적용 가능한지 확실하지 않음) 및 몇 가지 열 지향 관계형 데이터베이스입니다. 어떤 제안이나 실제 경험이 있으면 감사하겠습니다.

저는 회사에서 비슷한 양의 데이터 (약 10TB의 실시간 검색 가능 데이터)를 처리하고 있습니다. 우리는 Cassandra 로이 문제를 해결하고 다중 TB 데이터베이스에서 O (1) 검색을 수행 할 수있는 몇 가지 아이디어를 언급하고 싶습니다. 이것은 Cassandra db에만 국한된 것이 아니며 다른 db와 함께 사용할 수도 있습니다.

이론

• 데이터를 파쇄하십시오. 단일 서버가 이러한 양의 데이터를 안정적이고 현실적으로 보유 할 수있는 방법은 없습니다.
• 하드웨어 결함 및 전체 노드 장애에 대비하고 데이터를 복제하십시오.
• 처음부터 많은 백엔드 서버를 사용하십시오.
• 최고급 고성능 서버와 비교하여 더 저렴한 상용 서버를 많이 사용하십시오.
• 데이터가 샤드에 균등하게 분산되어 있는지 확인하십시오.
• 쿼리를 계획하는 데 많은 시간을 소비하십시오. 쿼리에서 API를 파생시킨 다음 신중하게 테이블을 디자인하십시오. 이것은 가장 중요하고 장기적인 작업입니다.
• Cassandra에서는 복합 열 키를 설계하고 O (1)에서 해당 키에 액세스 할 수 있습니다. 그들과 함께 시간을 보내십시오. 보조 인덱스 대신 검색 가능한 레코드에 액세스하는 데 사용됩니다.
• 넓은 행을 사용하십시오. 시간 소인이있는 이벤트를 저장하는 데 유용합니다.
• 이러한 볼륨에서 전체 스캔 또는 실제로 O (Log N) 이상의 작업을 수행하지 마십시오. O (Log N) 이상이 필요한 경우 이러한 작업을 Map-Reduce 알고리즘으로 오프로드하십시오.

연습

• OS 이미지를 작성하거나 물리적 시스템에 서버를 설치하는 데 시간을 소비하지 마십시오. 빠른 프로토 타이핑을 위해 클라우드 기반 공급자를 사용하십시오. Amazon EC2와 함께 작업했으며 단순성, 안정성 및 프로토 타이핑 속도를 강력히 추천 할 수 있습니다.
• Windows 시스템은 부팅시 속도가 느려지고 유휴 상태에있는 리소스를 상당히 많이 사용합니다. 유닉스 기반 OS 사용을 고려하십시오. 개인적으로 우분투 서버가 안정적인 OS라는 것을 알았지 만 askubuntu 에는 꽤 좋은 커뮤니티가 있습니다.
• 네트워킹에 대해 생각해보십시오. 노드는 이상적으로 서로 가까이 있어야 빠른 험담과 메타 데이터 교환이 가능합니다.
• 극단적 인 경우에 들어 가지 마십시오 : 실제로 넓은 열 행 또는 예외적으로 긴 열 패밀리 (테이블). 정상적인 경계에서 최상의 성능을 달성합니다. db 가 의도적으로 많은 N 개의 행을 지원 한다고해서 성능이 좋은 것은 아닙니다.
• 검색에는 약 3-5 초가 걸리며, UI와 데이터베이스 사이의 중간 노드 때문입니다. 요청을 데이터베이스에 더 가깝게 만드는 방법을 고려하십시오.
• 네트워크로드 밸런서를 사용하십시오. 확립 된 것을 선택하십시오. 우리는 간단하지만 빨리 죽은 HAProxy를 사용합니다. 문제가 없었습니다.
• 복잡한 솔루션보다 단순성을 선호하십시오.
• 회사 규모의 예산으로 백업하지 않는 한 무료 오픈 소스 솔루션을 찾으십시오. 여러 대의 서버를 사용하면 인프라 비용이 크게 높아질 수 있습니다.

저는 Amazon에서 일하지 않으며 HAProxy 및 Ubuntu 팀과 관계가 없습니다. 이것은 어떤 종류의 판촉보다는 개인적인 의견입니다.

이것을 SQL Server에 넣으려는 경우 다음과 같은 테이블을 제안합니다.

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

결과적으로 단일 테이블에 대한 총 예상 스토리지 요구 사항이되며 43.2 beeellion 레코드 (지정된 요구 사항)에 대한 추가 인덱스가 5.5TB가 아닙니다. 이는 데이터 자체에 대해 130 바이트, 오버 헤드 행당 7 바이트, 오버 헤드 페이지 당 96 바이트로 계산됩니다. SQL Server는 8KB 페이지에 데이터를 저장하여 페이지 당 59 행을 허용합니다. 이는 한 달 동안의 데이터에 대해 732,203,390 페이지에 해당합니다.

SQL Server는 물리적 I / O 당 472 행에 해당하는 8 페이지 청크 (64KB)로 디스크에 쓰는 것을 좋아합니다. 초당 16,203 개의 플로우 레코드가 생성되므로 매초마다 보장되는 34 IOps의 최소 I / O 속도가 필요합니다. 이것 자체는 그다지 많지는 않지만 시스템의 다른 I / O (SQL Server 등)는이 필요한 IOps 속도를 침해 할 필요가 없습니다. 따라서 최소한 10 배 더 많은 IOps 또는 340 개의 지속 IOPS를 지원하는 시스템을 설계해야합니다. 처리량을 보장하려면 2 배 더 지속 가능한 IOPS가 필요하다고 추정하는 경향이 있습니다.

점으로 구분 된 십진수 형식으로 IP 주소를 저장하지 않습니다. 이를 통해 스토리지 (대용량 주소 당 7 바이트)를 크게 절약 할 수 있으며 IP 주소를 색인화, 검색, 정렬 및 비교할 수 있습니다. 여기서 단점은 점으로 구분 된 십진 IP를 저장하기 전에 8 바이트 정수로 변환 한 다음 다시 표시하기 위해 점으로 구분 된 십진 IP로 변환해야한다는 것입니다. 그렇게하는 코드는 사소한 것이지만 행 속도로 인해 처리중인 각 흐름 행에 상당한 양의 처리 오버 헤드가 추가됩니다. SQL Server와 물리적으로 다른 컴퓨터에서이 변환 프로세스를 수행 할 수 있습니다.

필요한 색인을 논의하는 것은 특정 요구 사항을 나열하지 않았으므로 완전히 별개의 문제입니다. 이 테이블의 디자인은 흐름 행을 SQL Server가받는 물리적 순서로 저장하고 tcp_traffic_id필드는 각 레코드마다 고유하며 기록 된 순서대로 행을 정렬 할 수 있습니다 (이 경우에는 일대일 관련 가능성이 높습니다) 흐름 이벤트 시간까지).

HBase를 추천 합니다. 쿼리해야 할 대상에 따라 모든 원시 데이터를 하나 이상의 HBase 테이블에 저장할 수 있습니다. HBase는 큰 데이터 세트를 처리 할 수 ​​있으며 영역 분할을 통해 자동 샤딩을 수행합니다.

또한 행 키를 잘 디자인하면 O (1) 쿼리까지 매우 빠릅니다. 큰 데이터 세트를 검색하는 경우 데이터 검색이 O (n) 조작이므로 여전히 느립니다.

각 필드에서 쿼리하려는 경우 각 필드마다 고유 한 테이블을 작성하는 것이 좋습니다. src_address 데이터의 예는 다음과 같은 테이블이 있습니다.

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

따라서 3 월 27 일 오전 12 시부 터 3 월 27 일 오전 12시 1 분까지 1.2.3.4에서 모든 데이터를 쿼리하려는 경우 지정된 시작 및 중지 행을 사용하여 범위 스캔을 수행 할 수 있습니다.

행 키 디자인은 IMBase를 사용하는 데있어 가장 중요한 부분 인 IMHO입니다. 잘 디자인하면 빠른 쿼리를 수행하고 많은 양의 데이터를 저장할 수 있습니다.

이것을 말했다 :

... 우리는이 프로젝트의 독점 솔루션을 보는 것에 반대하지 않습니다.

IBM Informix 데이터베이스 + TimeSeries 데이터 블레이드를 고려 하십시오. 일부 사람들의 말과는 반대로, Informix는 살아 있고 잘 진행되고 있습니다. 마지막 버전은 지난 달에 릴리스되었습니다 (2013 년 3 월, 버전 12.10).

TimeSeries는 귀하와 같은 상황을 처리 할 수있는 "플러그인"(무료)과 같습니다.
또한 무료 버전의 Informix 데이터베이스 ( 버전 Innovator-C ) 로 프로덕션 환경에서 사용할 수 있습니다 . (물론, 무료 버전에는 제한된 리소스가 많으므로 기술 부분 만 평가하십시오)

여기 에서 참조로 사용할 수있는 벤치 마크 PDF를 확인할 수 있습니다. 더 많은 기술적 인 예제가 포함 된 두 가지 프레젠테이션 : 인형 안내서 및 기타 팁

나는 TimeSeries에 대한 개인적인 경험이 없기 때문에 그것이 "솔루션"이 될 것이라는 데 동의 할 수는 없습니다.

Informix TimeSeries를 살펴 보는 것이 좋습니다. IBM 문헌에 따르면 TimeSeries는 이러한 종류의 정보를 공간의 1/5에 저장할 수 있으며 기존 관계형 테이블보다 5 배 빠른 속도로 수행 할 수 있습니다.

추가 이점은 TimeSeries 데이터가 최종 사용자에게 기존 관계형 테이블처럼 보이도록 할 수있는 가상 테이블 인터페이스 (TimeSeries의 이점을 얻는 동시에 응용 프로그램 개발 단순화), 현재 버전 12.1의 TimeSeries 데이터를 지원하는 HDR 노드가있는 간단한 HA 및 복잡한 데이터웨어 하우스 보고서의 속도를 높이고 무료 Informix Developer 또는 Innovator-C 에디션을 사용하여 Informix에서 TimeSeries 솔루션을 프로토 타입 화하는 데 사용할 수있는 TimeSeries 데이터를 Informix Warehouse Accelerator에 통합합니다.