대량의 _structured_ 데이터를 저장하는 방법은 무엇입니까?

응용 프로그램은 지속적으로 (약 1 초마다) 사용자의 위치를 수집하여 저장합니다.

그러나 데이터가 너무 많습니다. 매일 사용자 당 60 × 60 × 24 = 86,400 개의 레코드가 있습니다. 사용자가 1000 명인 경우에도 매일 86,400,000 개의 레코드를 의미합니다.

그리고 그것은 매일 86,400,000 건의 기록이 아닙니다. 이러한 레코드가 처리되고 처리 된 버전도 저장되기 때문입니다. 따라서이 숫자에 약 2를 곱하십시오.

데이터 사용 계획

본질적으로, 더 쉬운 소비를 위해 더 세분화 된 버전의 위치 데이터를 만들 계획입니다. 그건:

수신 된 데이터 wrt 타임 스탬프를 정렬하십시오.
이 목록을 순서대로 반복하여 위도와 경도가 얼마나 변화했는지 확인하여 위치가 크게 변경되었는지 확인하십시오.
중요하지 않은 위치 변경은 출력에서 단일 항목으로 나타냅니다 (따라서 출력은 위치 데이터의보다 거친 버전입니다).
큰 변화를 위해 위도와 경도를 더 크게 변경하여 출력에서이 과정을 반복하십시오. 따라서 이전 출력에서 생성되는 출력은 훨씬 더 거칠게됩니다.
필요한만큼 전체 프로세스를 반복하십시오.
다양한 해상도를 집계하여 사용자에게 보냅니다. 또한 나중에 사용할 수 있도록 데이터의 모든 해상도를 저장하십시오.

이 데이터를 저장하기 위해 무엇을 사용해야합니까? 관계형 데이터베이스 또는 NoSQL 솔루션을 사용해야합니까? 이 응용 프로그램을 디자인 할 때 고려해야 할 다른 사항은 무엇입니까?

database big-data

— t 쿠
소스

초당 2000 개의 레코드가 최신 SQL 엔진에 문제가되지 않을 것입니다. 간단한 용량 테스트는 대량로드되는 파일에 임의의 파일을 쓰는 콘솔 프로그램을 얻는 것입니다.

— Caleth

@ Caleth 그러나 확장 가능합니까? 사용자 기반이 100 배 성장하면 어떨까요?

— Utku

하드웨어가 현재 처리 할 수있는 것을 측정하십시오. 병목 현상은 CPU가 값을 "처리"하거나 원시 디스크 속도 일 수 있습니다. 당신은 무엇을 의도 할 할 이 데이터 모두와 함께? 스토리지를 위해 어떤 기술을 선택

— 해야하는지

Caleth는 절대적으로 옳습니다. 수백만 개의 레코드가 최신 데이터베이스 시스템을 방해하지 않습니다. NoSQL 저장소는 방대한 양의 데이터를 매우 빠르게 작성 하는 데 능숙 하지만 궁극적으로 다시 읽는 것과 관련된 작업을 수행 하려고합니다. 얼마나 많은 독서가 필요한지는 종종 어떤 종류의 상점을 사용해야하는지 결정합니다.

— Kilian Foth

좋은 답변을 제공 하기 위해이 데이터 를 어떻게 사용할 계획인지 알아야합니다 . 임시 쿼리를 원할 경우 데이터베이스를 선택하는 것이 좋으며 파일 기반 솔루션은 전체 데이터 집합 분석에 더 적합 할 것입니다. 마감 투표.

— kdgregory

답변:

이 데이터를 저장하기위한 몇 가지 대안 :

Apache Kafka와 같은 메시지 큐 (배포 가능)

이것은 데이터 스트림을 쓰고 읽는 데 최적화됩니다. 처리하기 쉬운 형식으로 데이터 스트림을 수집하는 데 이상적이지만 일반적으로 스트림 전체를 읽지 않으면 쿼리 할 수 없습니다. 따라서 이것은 보관 목적이거나 처리 계층으로가는 중간 단계입니다.

관계형 데이터베이스

데이터베이스에 쓸 수 있고 볼륨이 처리 할 DB 용량을 초과하면 데이터베이스를 분할 할 수 있습니다 (= 데이터의 여러 하위 집합이 다른 데이터베이스 서버에 있음). 이점 : 관계형 DB를 사용할 수 있으며 새로운 것을 배울 필요가 없습니다. 단점 : DB를 다루는 모든 코드는 어떤 샤드 데이터가 어느 조각에 있는지 알고 있어야하며, 집계 된 쿼리는 애플리케이션 소프트웨어에서 수행되어야합니다.

Cassandra와 같은 분산 NoSQL 데이터베이스

분산 NoSQL 데이터베이스에 데이터를 쓰면 자동으로 데이터가 파쇄됩니다. Cassandra를 사용하면 클러스터에서 쿼리를 수행 할 수 있으므로 데이터를 다시 얻는 데 필요한 응용 프로그램 코드가 더 적습니다. 이점 : 대량의 데이터에보다 자연스럽게 적합합니다. 단점 : 이러한 시스템이 우수한 성능을 달성하고 필요에 따라 데이터를 쿼리 할 수 있도록하는 방법에 대한 전문 지식과 기술에 대한 깊은 이해가 필요합니다. NoSQL은 마법의 성능 수정이 아니며 탐색해야하는 일련의 절충점입니다.

하둡 / 파일

데이터는 Hadoop 플랫폼에 의해 서버에 자동으로 배포되고 M / R 또는 Apache Spark와 같은 도구를 사용하여 해당 서버에서 처리 된 후 Hive 또는 Impala와 같은 Hadoop SQL 엔진을 사용하여 파일로 쿼리되는 파일에 추가됩니다.

어느 것을 선택해야합니까?

이러한 대안들 사이의 절충은 복잡하며, 쓰기와 읽기 패턴에 크게 의존하므로 이러한 절충을 결정할 수있는 유일한 사람은 당신입니다. 이러한 대안에 대한 깊은 이해를 쌓을 시간이 없다면 관계형 DB를 사용하고 진행하면서 샤딩 솔루션을 찾으십시오. 모든 가능성에서, YAGNI .

— 조리 세브 레흐트
소스

데이터 사용 계획에 대한 자세한 내용을 제공했습니다. 이 정보가 주어진 것을 추가 하시겠습니까?

— Utku

아직도 "해결"의 의미가 무엇인지 명확하지 않습니다. 지리적 수준 (도시, 주, ...) 또는 geohash와 같은 좌표계로 집계 하시겠습니까? 또는 이동 임계 값을 기반으로 알림을 작성하려고하므로 델타 양에 관심이 있습니까? 한마디로,이 모든 것이 무엇입니까?

— Joeri Sebrechts

사용자 추적 용입니다. 사용자는 서로를 추적하고, 내가 추적 한 사용자가 장치에서 지난 5 시간 동안 있었던 위치를 그래프로 표시합니다. 본질적으로 입자가 미세할수록 좋습니다. 그러나 모바일 장치의 메모리는 제한되어 있으므로 해상도를 낮추지 않으면 데이터를 보낼 수 없습니다. 즉, 사용자 A가 사용자 B, C 및 D를 추적한다고 가정 해 봅시다. 서버 측에서 처리하지 않고 B, C 및 D에서 수신 한 위치 데이터를 단순히 A로 전달하면 사용자 A의 장치 메모리가 매우 빠르게 채워집니다 . 따라서 처리가 필요합니다.

— Utku

설명하는 내용을 작성하려면 스파크 스트리밍을 통해 연결된 일련의 kafka 로그로 구성하고 위치는 스파크 스트림의 창에서 통합되며 최종 출력 kafka 로그는 끌어 오기 및 웹 API를 클라이언트에게 푸시하십시오. 그러나 ... 이것은 매우 특별한 기술이며 배경과 사용 가능한 시간에 따라 선택이 잘못 될 수 있습니다.

— Joeri Sebrechts

감사. 나는 그것을 명심하지만 YAGNI 원칙에 따라 지금은 관계형 데이터베이스를 사용할 계획입니다. 필요가 생기면 응용 프로그램에 더 적합한 것으로 전환합니다. 원하는 경우 언제든지 정보를 자유롭게 수정하십시오.

— Utku

요구 사항을 좀 더 자세히 살펴보십시오. 매초마다 추적 위치의 환상을 만드는 방법이 있습니다.

현재 GPS 위치를 알고 데이터베이스에 기록하는 앱이 있다면 왜 위치가 바뀌지 않으면 계속 기록합니까? 데이터가 필요한 경우에도 사용자가 7 시간 동안 잠 들어있는 경우 누락 된 시간 슬롯을 중복 위치로 프로그래밍 방식으로 입력하여 계산 또는 매핑 또는 기타 필요한 작업을 수행 할 수 있습니다.

매 초마다 위치를 추적하는 경우 이러한 데이터를 영원히 저장해야합니까? 현재 테이블이 너무 커지지 않도록 레코드를 다른 데이터베이스에 아카이브 할 수 있습니다. 또는 위치 변경이있는 곳에 기록을 보관할 수도 있습니다. 이것은 데이터웨어 하우스에서 일반적입니다.

— 제프
소스

데이터는 일련의 시계열입니다. 시간에 따라 진화하는 숫자 세트 (사용자 당 2 개)를 부여했습니다. 일반적으로 모든 종류의 관계형 저장소가 아니라 RRD 저장소를 찾고 있습니다. 이러한 스토리지는 버퍼링을 통해 수많은 소규모 쓰기의 I / O 작업을 줄이는 데 중점을 둡니다.

관계형 저장은이 많은 양의 시계열에 대한 이단입니다. 그러나 RRD의 개발은 SQL보다 프로그래밍 가능한 악용 측면에서 잘 지원되지 않는다는 점에주의하십시오. 아마도 심각한 통합 작업을 고려하고 있지만 요구 사항을 감안할 때 거의 피할 수 없습니다.

— 아서 하 블리 케
소스