데이터를 디스크에 저장하는 대신 데이터베이스를 사용해야하는 이유는 무엇입니까?

데이터베이스 대신 데이터를 JSON으로 직렬화하여 필요할 때 디스크에 저장하고로드합니다. 모든 데이터 관리는 프로그램 자체에서 이루어 지므로 SQL 쿼리를 사용하는 것보다 빠르고 쉽습니다. 이런 이유로 나는 데이터베이스가 왜 필요한지 전혀 모른다.

데이터를 디스크에 저장하는 대신 데이터베이스를 사용해야하는 이유는 무엇입니까?

1. 데이터베이스에서 데이터를 쿼리 할 수 ​​있습니다 (질문을하십시오).
2. 데이터베이스에서 데이터를 비교적 빠르게 조회 할 수 있습니다.
3. JOIN을 사용하여 서로 다른 두 테이블의 데이터를 연관시킬 수 있습니다.
4. 데이터베이스의 데이터에서 의미있는 보고서를 작성할 수 있습니다.
5. 귀하의 데이터에는 기본 제공 구조가 있습니다.
6. 주어진 유형의 정보는 항상 한 번만 저장됩니다.
7. 데이터베이스는 ACID 입니다.
8. 데이터베이스는 내결함성이 있습니다.
9. 데이터베이스는 매우 큰 데이터 세트를 처리 할 수 ​​있습니다.
10. 데이터베이스는 동시입니다. 여러 사용자가 데이터를 손상시키지 않고 동시에 사용할 수 있습니다.
11. 데이터베이스는 잘 확장됩니다.

요컨대, 매우 똑똑한 사람들이 수년에 걸쳐 개발 한 널리 알려진 입증 된 기술의 혜택을 누릴 수 있습니다.

데이터베이스가 너무 과도하다고 걱정되면 SQLite를 확인하십시오.

Robert가 말한 모든 것에 동의하지만, 데이터를 디스크에 저장하는 대신 데이터베이스를 사용해야하는 시점을 알려주지 않았습니다.

확장 성, 신뢰성, 내결함성 등에 대해 Robert가 말한 것 외에도 이것을 가져 가십시오.

RDBMS 사용시기에 대해 고려해야 할 사항은 다음과 같습니다.

• 관계형 데이터가 있습니다. 즉, 제품을 구매 한 고객이 있고 해당 제품에는 공급 업체 및 제조업체가 있습니다.
• 많은 양의 데이터가 있으며 관련 정보를 빠르게 찾을 수 있어야합니다.
• 확장 성, 안정성, ACID 준수와 같은 이전 문제에 대해 걱정해야합니다.
• 비즈니스 문제를 해결하려면보고 또는 인텔리전스 도구를 사용해야합니다

NoSQL 사용시기

• 구조화되지 않은 많은 데이터를 저장해야합니다.
• 확장 성 및 속도 요구
• 일반적으로 스키마를 미리 정의 할 필요가 없으므로 요구 사항이 변경되는 경우 이것이 좋습니다.

마지막으로 파일 사용시기

• 파일 시스템이 처리 할 수있는 합리적인 양의 비정형 데이터가 있습니다.
• 당신은 구조, 관계에 관심이 없습니다
• 확장 성 또는 안정성에 신경 쓰지 않습니다 (파일 시스템에 따라 수행 할 수는 있지만)
• 데이터베이스가 추가 할 오버 헤드를 원하지 않거나 처리 할 수 ​​없습니다
• 파일 시스템에 속하는 구조화 된 이진 데이터 (예 : 이미지, PDF, 문서 등)를 처리합니다.

아무도 언급하지 않은 것 중 하나는 레코드 인덱싱입니다. 현재 귀하의 접근 방식은 훌륭하며, 데이터 세트가 매우 적고 액세스하는 사람이 거의 없다고 가정합니다.

복잡해질수록 실제로 데이터베이스를 생성하게됩니다. 무엇을 호출하든 데이터베이스는 디스크에 저장된 일련의 레코드 일뿐입니다. 파일을 생성하든 MySQL , SQLite를 생성하든 파일을 생성하든 관계없이 모두 데이터베이스입니다.

누락 된 것은 사용하기 쉽게 데이터베이스 시스템에 내장 된 복잡한 기능입니다.

떠오르는 가장 중요한 것은 인덱싱입니다. 그래야 직렬화 된 배열 또는 JSON 문자열에 10 또는 20 또는 100 또는 1000 개의 레코드를 저장하고 파일에서 가져 와서 비교적 빠르게 반복 할 수 있습니다.

이제 10,000, 100,000 또는 1,000,000 개의 레코드가 있다고 가정하십시오. 누군가 로그인을 시도하면 현재 수백 메가 바이트 크기의 파일을 열고 프로그램의 메모리에로드하고 비슷한 크기의 정보를 가져온 다음 수십만 개의 레코드를 반복해야합니다. 액세스하려는 하나의 레코드를 찾으십시오.

적절한 데이터베이스를 사용하면 레코드의 특정 필드에 인덱스를 설정하여 대규모 데이터 세트를 사용하더라도 데이터베이스를 쿼리하고 매우 빠르게 응답을받을 수 있습니다. 이를 Memcached 또는 자체 양조 캐싱 시스템과 결합하십시오 (예 : 검색 결과를 10 분 동안 별도의 테이블에 저장하고 나중에 다른 사람이 곧 같은 것을 검색하는 경우 해당 결과를로드). 수동으로 파일을 읽거나 쓸 때 큰 데이터 세트로는 얻을 수없는 빠른 쿼리가 있습니다.

인덱싱과 관련이없는 또 다른 사항은 정보 전송입니다. 위에서 말했듯이 수백 또는 수천 메가 바이트의 파일이 있으면 모든 정보를 메모리에로드하고 수동으로 (아마도 동일한 스레드에서) 반복 한 다음 데이터를 조작해야합니다.

데이터베이스 시스템을 사용하면 자체 스레드 또는 자체 서버에서 실행됩니다. 프로그램과 데이터베이스 서버간에 전송되는 것은 모두 SQL 쿼리이며 다시 전송되는 것은 액세스하려는 데이터입니다. 전체 데이터 세트를 메모리에로드하지 않습니다. 보내고받는 모든 것은 전체 데이터 세트의 작은 부분입니다.

질문의 의견에 설명 된 것과 같은 간단한 데이터가 있으면 SQL 데이터베이스가별로 도움이되지 않습니다. 시간이 지남에 따라 데이터가 더 복잡해질 수 있다는 사실을 알고 많은 데이터베이스를 사용하는 라이브러리가 많기 때문에 많은 사람들이 여전히 데이터를 사용합니다.

그러나 간단한 목록을로드하더라도 메모리에 저장 한 다음 필요할 때 쓰면 여러 가지 문제가 발생할 수 있습니다.

프로그램이 비정상적으로 종료되면 데이터가 손실되거나 디스크에 데이터를 쓰는 동안 문제가 발생하여 전체 파일이 종료 될 수 있습니다. 이를 처리하기 위해 고유 한 메커니즘을 굴릴 수 있지만 데이터베이스는 이미 입증 된 기술을 사용하여이를 처리합니다.

데이터가 너무 커지고 업데이트가 너무 자주 시작되면 모든 데이터를 직렬화하고 저장하는 데 많은 리소스가 낭비되고 모든 것이 느려집니다. 사물을 분할하는 방법을 연구해야하므로 비용이 많이 들지 않습니다. 데이터베이스는 디스크로 변경되는 내용 만 내결함성있게 저장하도록 최적화되었습니다. 또한 설계되었으므로 언제든지 필요한 작은 데이터를 신속하게로드 할 수 있습니다.

또한 SQL 데이터베이스를 사용할 필요가 없습니다. 많은 사람들이하는 NoSQL "데이터베이스"를 사용할 수 있습니다 . JSON을 사용하여 데이터를 저장하면됩니다. 그러나 내결함성이있는 방식으로, 여러 컴퓨터에서 데이터를 지능적으로 분할, 쿼리 및 지능적으로 분할 할 수있는 방식으로 수행됩니다.

또한 어떤 사람들은 일을 섞습니다. 로그인 정보를 저장하기 위해 Redis 와 같은 NoSQL 데이터 저장소를 사용할 수 있습니다 . 그런 다음 관계형 데이터베이스를 사용하여 더 흥미로운 쿼리를 수행해야하는 더 복잡한 데이터를 저장하십시오.

동시성 및 안정성 문제에 대한 많은 답변이 있습니다. 데이터베이스는 동시성, 안정성 및 성능 외에도 다른 이점을 제공합니다. 메모리에서 바이트와 문자가 표현되는 방식을 신경 쓰지 않아도됩니다. 다시 말해, 데이터베이스를 통해 프로그래머는 "어떻게"가 아닌 "무엇"에 집중할 수 있습니다.

답변 중 하나는 쿼리를 언급합니다. "SQL 데이터베이스에 질문하기"는 질문의 복잡성과 함께 확장됩니다. 개발 과정에서 코드가 발전함에 따라 "모두 가져 오기"와 같은 간단한 쿼리는 프로그래머가 이러한 쿼리에 대한 데이터 구조를 최적화하지 않고도 "properties1이이 값과 같은 위치를 모두 가져 와서 property2로 정렬"하도록 쉽게 확장 할 수 있습니다. 특정 속성에 대한 인덱스를 만들어 대부분의 쿼리 성능을 향상시킬 수 있습니다.

다른 이점은 관계입니다. 쿼리를 사용하면 다른 데이터 세트의 데이터를 상호 참조한 다음 중첩 루프를 사용하는 것이 더 깨끗합니다. 예를 들어, 사용자와 게시물이 다른 데이터 세트 (또는 DB 테이블 또는 JSON 객체) 인 시스템에서 게시물이 3 개 미만인 사용자의 모든 포럼 게시물을 검색하면 가독성을 떨어 뜨리지 않고 단일 쿼리로 수행 할 수 있습니다.

데이터 볼륨이 클 수있는 경우 (예 : 1000 개 이상의 객체), 중요하지 않은 코드의 다른 부분에 대한 데이터 액세스와 다른 데이터 하위 집합에 대한 데이터 액세스는 SQL 데이터베이스가 일반 배열보다 낫습니다.

TLDR

애플리케이션에 대해 본질적으로 유효한 단기 데이터 저장소 기술 결정을 내린 것 같습니다. 사용자 지정 데이터 저장소 관리 도구를 작성하기로 선택했습니다.

어느 방향 으로든 이동할 수있는 옵션이있는 연속체에 앉아 있습니다.

장기적으로, 당신은 (거의 100 %는 아니지만) 자신을 곤경에 빠뜨릴 가능성이 있으며 기존 데이터 저장소 솔루션을 사용하는 것이 더 나을 수도 있습니다. 처리해야 할 매우 일반적이고 예측 가능한 특정 성능 문제가 있으며 자체 도구 대신 기존 도구를 사용하는 것이 좋습니다.

응용 프로그램에 내장되어 직접 사용되는 (소규모) 사용자 정의 목적 데이터베이스를 작성한 것 같습니다. 실제 디스크 쓰기 및 읽기를 관리하고이 조합을 데이터 저장소로 취급하기 위해 OS 및 파일 시스템에 의존한다고 가정합니다.

당신이 한 일을 할 때

데이터 저장을위한 스위트 스폿에 앉아 있습니다. OS 및 파일 시스템 데이터 저장소는 매우 편리하고 액세스 가능하며 플랫폼 간 이식성이 뛰어납니다. 이 조합은 오랫동안 사용되어 왔으며 거의 ​​모든 표준 배포 구성에서 지원되고 응용 프로그램을 실행할 수 있습니다.

또한 코드를 작성하는 쉬운 조합이기도합니다. API 는 매우 간단하고 기본적이며 작동하는 데 비교적 적은 코드 줄이 필요합니다.

일반적으로 다음과 같은 경우 수행 한 작업을 수행하는 것이 이상적입니다.

• 새로운 아이디어 프로토 타이핑
• 확장 성, 성능 측면에서 거의 필요하지 않은 응용 프로그램 구축
• 데이터베이스 설치를위한 자원 부족과 같은 비정상적인 상황에 의해 제약 됨

대안

당신은 옵션의 연속체에 있으며, 여기에서 갈 수있는 두 가지 '방향'이 있습니다. 내가 '아래로'와 '위로'생각합니다.

내려가는

이것은 적용 가능성이 가장 적은 옵션이지만 완전성을 기하기 위해 여기에 있습니다.

원하는 경우 다운 , 즉 OS와 파일 시스템을 모두 무시하고 실제로 디스크에서 직접 쓰고 읽을 수 있습니다. 이 선택은 일반적으로 극도의 효율성이 필요한 경우에만 관련이 있습니다. 예를 들어, 완벽하게 작동하는 OS를위한 충분한 RAM 이 없거나 최소한의 효율적인 질량을 요구 하는 Wayback Machine 과 같은 최소 / 소형 MP3 플레이어 장치 를 생각하십시오. 데이터 쓰기 작업 (대부분의 데이터 저장소는 더 빠른 읽기를 위해 느린 쓰기와 교환합니다. 거의 모든 응용 프로그램에서 가장 일반적으로 사용되는 사례이므로).

쪽으로

여기에는 몇 가지 하위 범주가 있습니다. 그러나 이것은 완전히 배타적이지는 않습니다. 일부 도구는 둘 다에 걸쳐 일부 기능을 제공하며, 일부 도구는 한 모드에서 다른 모드로 작동하도록 완전히 전환 할 수 있으며, 일부는 서로의 위에 계층화되어 응용 프로그램의 다른 부분에 다른 기능을 제공 할 수 있습니다.

보다 강력한 데이터 저장소

데이터 조작 복잡성을 관리하기 위해 자체 애플리케이션에 의존하면서 더 많은 양의 데이터를 저장해야 할 수도 있습니다. 다양한 기능을 지원하는 다양한 키-값 저장소를 사용할 수 있습니다. NoSQL 도구는이 범주와 다른 범주에 속합니다.

다음은 응용 프로그램을 설명 할 때 확장 할 수있는 확실한 방법입니다.

• 읽기에 의존하는 비정상적으로 무겁습니다
• 더 낮은 (단기) 일관성 보장 (많은 "최종 일관성"제공)을 위해 더 높은 성능으로 거래해도 괜찮습니다.
• 대부분의 데이터 조작 및 일관성 부족을 "직접"관리하고 있습니다 (실제로 처음에는 타사 도구를 사용하게되지만 결국에는이를 응용 프로그램이나 사용자 지정 작성 중간 계층으로 가져옵니다) .
• "상대적으로 간단한"데이터 조작 요구 사항을 사용하여 저장하는 데이터 양 및 / 또는 데이터를 검색 할 수있는 능력을 대폭 확장하려고합니다.

여기에는 약간의 흔들림이 있습니다-느린 읽기를 위해 더 나은 읽기 일관성을 유지할 수 있습니다. 다양한 도구 및 옵션은 데이터 조작 API, 인덱싱 및 기타 옵션을 제공하며, 이는 특정 응용 프로그램을 쉽게 작성하는 데 다소 적합 할 수 있습니다. 따라서 위의 사항이 애플리케이션을 거의 완벽하게 설명한 경우보다 강력한 데이터 저장소 솔루션을 사용하기에 "충분히 가까이"있을 수 있습니다.

잘 알려진 예 : CouchDB , MongoDB , Redis , Microsoft의 Azure , Google App Data Store 및 Amazon ECE와 같은 클라우드 스토리지 솔루션 .

보다 복잡한 데이터 조작 엔진

"SQL"데이터 스토리지 응용 프로그램 제품군과 그 밖의 다양한 제품군은 순수한 스토리지 엔진보다 데이터 조작 도구로 더 잘 설명됩니다. 이들은 데이터 저장을 넘어, 주요 가치 저장소 측면에서 제공되는 것 이상의 광범위한 추가 기능을 제공합니다. 다음과 같은 경우이 경로를 사용하고 싶을 것입니다.

• 성능 저하가 발생하더라도 읽기 일관성이 있어야합니다.
• 매우 복잡한 데이터 조작을 효율적으로 수행하려고합니다. 매우 복잡한 JOIN 및 UPDATE 조작, 데이터 큐브 및 슬라이싱 등을 고려하십시오.
• 성능 (강력하고 고정 된 데이터 스토리지 형식 (예 : 쉽고 효율적으로 변경 될 수없는 테이블) 형식)을 고려하여 견고성을 절충해도 좋습니다.
• 종종 더 복잡한 도구 및 인터페이스 집합을 처리 할 수있는 리소스가 있습니다.

이 데이터베이스 또는 데이터 저장소의 생각의 더 "전통적인"방법이며, 더 이상 주변에있다 - 그래서이 많은 여기에 해당, 그리고 다루는 많은 복잡성이 종종있다. 전문 지식과 지식이 필요하고 간단한 솔루션을 구축하고 많은 복잡성을 피할 수는 있지만 타사 도구와 라이브러리를 사용하여 대부분을 관리 할 수 ​​있습니다.

잘 알려진 예는 MySQL , SQL Server , Oracle 's Database 및 DB2 입니다.

작업 아웃소싱

복잡성을 관리 할 수 ​​있도록 데이터 저장소 도구와 응용 프로그램간에 자동으로 제공되는 여러 가지 최신 타사 도구 및 라이브러리가 있습니다.

이들은 처음에 데이터 저장소를 관리하고 조작하는 데 필요한 대부분 또는 모든 작업을 제거하려고하며, 필요할 때만 필요한 경우에만 복잡도로 부드럽게 전환 할 수 있습니다. 이것은 기업가 정신과 연구의 활발한 영역이며, 즉시 접근하고 사용할 수있는 몇 가지 최근 결과가 있습니다.

잘 알려진 예는 MVC 도구 ( Django , Yii ), Ruby on Rails 및 Datomic 입니다. 다양한 데이터 저장소의 API를 둘러싸는 래퍼 역할을하는 수십 개의 도구와 라이브러리가 있기 때문에 여기서는 공정하기가 어렵습니다.

추신 : 텍스트보다 비디오를 선호하는 경우 Rich Hickey의 데이터베이스 관련 비디오를 볼 수 있습니다. 그는 데이터 저장소 선택, 디자인 및 사용과 관련된 대부분의 사고를 설명하는 데 능숙합니다.

파일 시스템은 NoSQL 데이터베이스의 설명에 적합하므로 데이터 저장 방법을 결정할 때 RDBMS에 찬성하여 데이터를 저장하는 방법을 결정할 때이를 사용하는 것이 좋습니다.

파일 시스템 (및 일반적으로 NoSQL)의 한 가지 문제는 데이터 간의 관계를 처리하는 것입니다. 이것이 주요 차단기가 아니라면 지금은 RDBMS를 건너 뛰십시오. 또한 파일 시스템을 스토리지로 사용하는 긍정적 인 측면을 기억하십시오.

• 제로 관리
• 낮은 복잡성, 쉬운 설정
• 모든 운영 체제, 언어, 플랫폼, 라이브러리 등에서 작동
• 구성 설정 만 디렉토리입니다
• 사소한 테스트
• 기존 도구를 사용하여 검사, 백업, 수정 등을 간단하게 수행
• 좋은 성능 특성과 운영 체제에 의해 잘 조정
• 모든 개발자가 쉽게 이해할 수 있음
• 종속성 없음, 추가 드라이버 없음
• 보안 모델은 이해하기 쉽지 않으며 운영 체제의 기본 부분입니다.
• 외부 접근이 불가능한 데이터

( 소스 )

파일 시스템은 데이터베이스 유형입니다. 다른 사람들과 마찬가지로 RDBMS가 아니라 아마도 가장 엄격한 의미의 DB 일 것입니다. 스토리지를 추상화하고 프로그램이 통신하는 API가있는 데이터 (파일 내용)를 조회하기위한 키 (파일 이름)를 제공합니다.

따라서 데이터베이스를 사용하고 있습니다. 다른 게시물은 다른 유형의 데이터베이스의 장점에 대해 논쟁 할 수 있습니다 ...

데이터를 수정하는 여러 프로세스 (사용자 / 서버)가있는 경우 데이터베이스가 필요합니다. 그런 다음 데이터베이스는 서로의 변경 사항을 덮어 쓰지 못하게합니다.

데이터가 메모리보다 클 때 데이터베이스도 필요합니다. 오늘날 우리가 사용할 수있는 메모리로 인해 실제로 많은 응용 프로그램에서 데이터베이스 사용이 더 이상 사용되지 않습니다.

당신의 접근 방식은 "메모리 내 데이터베이스"의 넌센스보다 확실히 낫습니다. 본질적으로 귀하의 접근 방식이지만 많은 오버 헤드가 추가되었습니다.

특정 응용 프로그램에 RDBMS가 필요한지 항상 자문해야합니다. 너무 많은 응용 프로그램은 처음에 필요한 모든 도구와 프레임 워크를 자동으로 가정하는 설계 프로세스로 구축됩니다. 관계형 데이터베이스는 매우 일반적이며 많은 개발자가 이전과 유사한 응용 프로그램을 작업하여 프로젝트가 시작되기 전에 자동으로 포함됩니다. 많은 프로젝트가 이것으로 벗어날 수 있으므로 너무 심하게 판단하지 마십시오.

하나없이 프로젝트를 시작하면 작동합니다. SQL까지 기다릴 필요없이이를 시작하고 실행하는 것이 더 쉬웠습니다. 그것에 아무런 문제가 없습니다.

이 프로젝트가 확장되고 요구 사항이 복잡 해짐에 따라 일부 항목을 작성하기가 어려워 질 것입니다. 대체 방법을 연구하고 테스트 할 때까지 어느 것이 더 나은지 어떻게 알 수 있습니까? 프로그래머 에게 물어볼 수 있고 화염을 통해 잡초를 풀 수 있으며이 질문에 대답하기 위해 '그것은 달려 있습니다'. 일단 배운 후에는 데이터베이스의 이점 중 일부를 처리하기 위해 언어로 작성하려는 코드 줄 수를 고려할 수 있습니다. 어느 시점에서, 당신은 바퀴를 재발 명하고 있습니다.

쉬운 것은 종종 상대적입니다. 사용자가 코드를 작성하지 않고도 웹 페이지를 작성하고 양식을 데이터베이스 테이블에 연결할 수있는 프레임 워크가 있습니다. 마우스로 어려움을 겪으면 문제가 될 수 있습니다. 신은 당신이 GUI에 모든 것을 단단히 결합시키지 못했기 때문에 확장 가능하거나 유연하지 않다는 것을 알고 있습니다. 프로그래머가 아닌 사람이 프로토 타입을 만들었습니다. 여기에 많은 야구 니 가 있습니다.

SQL을 배우는 대신에 선택한 언어로 조작 한 ORM을 배우고 싶다면 SQL을 사용하여 인기있는 데이터베이스에서 테이블을 설치하고 테이블을 만들고 일부 데이터를 가져 오십시오 (Select * From; is not 부는 물건). 쉬운 일입니다. 그래서 누군가가 처음에 그것들을 만들었습니다. 정보에 입각 한 결정을 내리는 데 그렇게 큰 투자는 아닌 것 같습니다. 성능 테스트를 수행 할 수도 있습니다.

디스크에 데이터를 저장하면 IS 는 기록의 열쇠되는 파일의 이름으로 자신의 파일에 각 개체를 넣어 특히, 데이터베이스에 쓰기. 파일을 읽는 데 필요한 조회 시간을 최소화하려면 키의 처음 몇 문자를 기준으로 하위 디렉토리를 만드십시오.

예를 들어 key = ghostwriter는 g / ho / stwriter.json 또는 g / h / o / stwriter.json 또는 g / ho / ghostwriter.json 또는 g / h / o / ghostwriter.json에 있습니다. 키 분포에 따라 이름 지정 체계를 선택하십시오. 그것들이 시퀀스 번호라면 5 / 4 / 3 / 12345.json이 다른 방법보다 낫습니다.

그것은 데이터베이스이며 필요한 모든 것을 수행한다면 그렇게하십시오. 현재는 GDBM 또는 Berkeley db와 같은 NoSQL 데이터베이스라고합니다. 너무 많은 선택. 먼저 필요한 것을 파악한 다음 memcached 또는 CRUD 인터페이스와 같은 get / set 인터페이스와 같은 세부 정보를 처리하는 인터페이스 라이브러리를 구축 한 다음 데이터베이스 형식을 변경해야하는 경우 라이브러리를 교체 할 수 있습니다. 다른 특성으로.

PostgreSQL 및 Apache Derby DB와 같은 일부 SQL 데이터베이스를 사용하면 자체 개발 한 데이터베이스를 포함하여 여러 NoSQL 형식에서 SQL 쿼리를 수행 할 수 있습니다. MyBatis에 대해서는 확실하지 않지만 비슷할 수 있습니다.

NoSQL 과대 광고를 피하십시오. 기능에 대해 읽고 성능과 기능을 테스트 한 다음 애플리케이션 요구에 얼마나 잘 부합하는지 선택하십시오.

http://www.hdfgroup.org/HDF5/ 는 사람들이 자주 고려하지 않는 또 다른 흥미롭고 널리 사용되는 데이터 저장소 형식입니다.

데이터가 동시에 업데이트되는 즉시 데이터베이스 (메모리 데이터베이스에있을 수 있음)를 사용하는 접근 방식이 더 정확하고 성능이 향상되는 반면 코드는 쉽게 유지됩니다. 동시 업데이트, 트랜잭션, 캐싱, 비동기 I / O 등을 걱정해야합니다.

우리가 여기에 게시하는 것과 같은 QA를 저장 / 검색하려면 데이터베이스가 필요합니다! 단순 파일이 다른 주제와 관련된 데이터를 구성 할 수 없습니다.