플랫 파일 데이터베이스가 적합합니까?

Question

플랫 파일 데이터베이스의 장점에 대한 정보 옵션이 필요합니다. 플랫 파일 데이터베이스 스키마를 사용하여 사용자 정의 블로그의 데이터를 관리하는 것을 고려 중입니다. Linux OS 변형에서 배포되고 Java로 작성됩니다.

기사와 주석 모두의 읽기 및 쓰기 성능과 관련된 잠재적 인 부정이나 긍정적 인 점은 무엇입니까?

슬래시가 찍히는 경우 RDBMS가 아닌 플랫 파일이기 때문에 기사 검색이 엉망이 되겠습니까? (희망찬 생각)

나는 RDBMS를 사용하는 것에 반대하지 않고 커뮤니티에 그러한 소프트웨어 아키텍처 계획의 실행 가능성에 대해 묻는다.

후속 :가 이 질문의 경우에는 내가 "플랫 파일 == 파일 시스템 기반은"예를 들어 각 블로그 항목과 그 동반 메타 데이터를 하나의 파일에있을 것입니다 볼 것입니다. 파일 폴더의 날짜 구조 (블로그 \ testblog2 12 \ 01 \ 2008 \) == 2008년 12월 1일

Answer 1

플랫 파일 데이터베이스는 적절한 위치에 있으며 올바른 도메인에서 사용할 수 있습니다.

과거의 메일 서버와 NNTP 서버는 실제로 이러한 것들 (실제로 파일 시스템은 수백만 개의 파일과 디렉터리를 가질 수 있음)을 얼마나 멀리 가져갈 수 있는지에 대한 한계를 밀어 냈습니다.

플랫 파일 DB는 인덱싱과 원자 적 업데이트가 가장 큰 두 가지 약점이지만 도메인이 적합한 경우 문제가되지 않을 수 있습니다.

그러나 예를 들어 적절한 잠금을 사용하면 최소한 Unix에서는 기본 파일 시스템 명령을 사용하여 "원자 적"색인 업데이트를 수행 할 수 있습니다.

단순한 경우 데이터를 통해 인덱싱 프로세스가 실행되어 임시 이름으로 새 인덱스 파일을 만듭니다. 그런 다음, 끝내면 이전 파일을 새 파일로 바꿉니다 (시스템 호출 rename (2) 또는 쉘 mv 명령). Rename과 mv는 Unix 시스템에서의 원 자형 연산입니다 (즉, 작동하거나 그렇지 않습니다). "상태 간"이 누락되지 않습니다.

새 항목을 만들 때와 같습니다.기본적으로 임시 파일에 파일을 완전히 작성한 다음 이름을 바꾸거나 mv로 최종 위치에 배치하십시오. 그렇다면 "DB"에는 "중간"파일이 없습니다. 그렇지 않으면 경쟁 조건 (예 : 아직 쓰고있는 파일을 읽는 프로세스가 있고 쓰기 프로세스가 완료되기 전에 끝나야 할 수도 있습니다 - 경쟁이 심한 경쟁 조건)이있을 수 있습니다.

기본 색인 생성이 디렉토리 이름과 잘 작동하는 경우 제대로 작동합니다. 예를 들어 해싱 스키마를 사용하여 새 파일을 찾기위한 디렉토리와 하위 디렉토리를 만들 수 있습니다.

파일 이름과 디렉토리 구조를 사용하여 파일을 찾는 것은 오늘날 대부분의 파일 시스템이 색인을 생성하기 때문에 매우 빠릅니다.

디렉토리에 백만 개의 파일을 저장하는 경우 조사하려는 튜닝 관련 문제가있을 수 있지만 그 중 대부분은 수십 만 개를 쉽게 처리합니다. 디렉토리를 스캔해야한다면 스캔 할 파일이 많을 것입니다. 디렉토리를 통한 파티셔닝은이를 방지하는 데 도움이됩니다.

하지만 모두 색인 생성 및 검색 기술에 따라 다릅니다.

효과적으로 정적 컨텐츠를 제공하는 선반 웹 서버의 스톡은 대형 평면 파일 데이터베이스이며 모델은 꽤 잘 작동합니다.

마지막으로 무료 Unix 파일 시스템 레벨 도구가 많이 있지만, 모든 파일에 수많은 문제가 있습니다. 파일에서 무언가를 찾으려면 grep 1000000 번을 포기해야 성능이 저하됩니다. 오버 헤드는 단순히 합산됩니다).

모든 파일이 동일한 파일 시스템에있는 경우 하드 링크는 동일한 파일을 다른 위치 (기본적으로 색인 생성)에 넣는 측면에서 옵션을 제공합니다.

예를 들어, "today"디렉토리, "yesterday"디렉토리, "java"디렉토리 및 실제 메시지 디렉토리를 가질 수 있습니다.

그래서 "today"디렉토리의 "java"디렉토리 (게시물에 "java"태그가 붙어 있기 때문에)와 마지막 위치 (/ articles/2008/12)에 링크가 연결될 수 있습니다. /01/my_java_post.txt). 그런 다음 자정에 두 개의 프로세스를 실행합니다. 첫 번째 파일은 "today"디렉토리의 모든 파일을 가져 와서 "오늘"이 아닌지 확인하기 위해 생성 날짜를 확인합니다 (프로세스가 몇 초가 걸리고 새 파일이 잠길 수 있기 때문에) 어제". 다음으로, "어제"디렉토리에 대해서도 똑같은 일을합니다. 단지 오래된 것 인 경우 삭제하면됩니다.

한편 파일은 여전히 ​​"java"및 ".../12/01"디렉토리에 있습니다. 유닉스 파일 시스템과 하드 링크를 사용하고 있기 때문에 "파일"은 한 번만 존재합니다. 이들은 파일에 대한 포인터 일뿐입니다. 그들 중 누구도 "the"파일이 아닙니다. 모두 동일합니다.

각 개별 파일 이동이 원 자성 인 반면 대량은 아닙니다. 예를 들어, "today"스크립트가 실행 중이지만 "yesterday"스크립트가 아직 실행되지 않았기 때문에 "yesterday"디렉토리에 "yesterday"및 "before the day"파일이 포함될 수 있습니다.

트랜잭션 DB에서 모든 작업을 한꺼번에 처리 할 수 ​​있습니다.

하지만 간단하고 정확한 방법입니다. 유닉스는 특히이 관용구와 잘 작동하며, 현대 파일 시스템은이를 잘 지원할 수있다.

Answer 2

(here에서 복사 및 수정 답)

나는 것 주최 많은 파일 만들기 읽기 전용 액세스 외에 플랫 파일을 사용하지 말라고 조언하십시오. 한 번에 하나의 프로세스 만 파일에 쓰는 것과 같은 동시성 문제를 처리해야하기 때문입니다. 대신 파일에 저장된 SQL 데이터베이스 인 SQLite을 사용하는 것이 좋습니다. SQLite는 이미 동시성을 내장하고 있기 때문에 파일 잠금과 같은 것에 대해 걱정할 필요가 없으며 읽기에는 정말 빠릅니다.

그러나 많은 데이터베이스 변경 작업을 수행중인 경우 transaction 안에 모든 작업을 한꺼번에 수행하는 것이 가장 좋습니다. 변경 쿼리가 발행 될 때마다 파일에 한 번만 변경 사항을 기록합니다. 이렇게하면 여러 변경 작업을 수행하는 속도가 크게 향상됩니다.

변경 쿼리가 실행되면 트랜잭션이 트랜잭션인지 여부에 관계없이 쿼리가 완료 될 때까지 전체 데이터베이스가 잠 깁니다. 즉, 매우 큰 트랜잭션은 데이터베이스에 액세스하기 전에 트랜잭션이 완료되기를 기다려야하기 때문에 다른 프로세스의 성능에 나쁜 영향을 미칠 수 있습니다. 실제로이 문제가 눈에 띄는 것으로 밝혀진 것은 아니지만 문제가되는 데이터베이스 수정 쿼리의 수를 최소화하는 것이 좋습니다. 물론 플랫 파일을 사용하는 것이 더 빠릅니다.

Answer 3

끔찍한 생각. 추가 할 때마다 파일을 추가 할 때마다 파일 끝까지 검색해야합니다. 업데이트 할 때마다 매번 전체 파일을 다시 작성해야합니다. 읽기에는 테이블 스캔이 포함됩니다 (또는 쓰기/업데이트와 동일한 문제점을 갖는 별도의 인덱스 유지). 물론 RDBMS가 제공하는 모든 것을 다시 구현하지 않는 한 데이터베이스를 사용하여 솔루션을 적절하게 확장 할 수 있습니다.

Answer 4

이 작업은 Dasblog의 asp.net에서 수행되었습니다. 그것은 파일 기반 스토리지를 사용합니다.

몇 가지 세부 정보가이 이전 링크에 나열되어 있습니다. http://www.hanselman.com/blog/UpcomingDasBlog19.aspx

또한 나는 성능에 약간의 혼합 의견을 들었습니다 http://dasblog.info/Features.aspx

에 대한 자세한 정보를 얻을 수 있습니다. 그 유형의 시스템이 당신에게 잘 작동하는지 좀 더 연구하도록 권합니다. 이것은 내가 들었던 가장 가까운 것입니다.

Answer 5

네이티브 코드로 엔진을 작성하면 범용 데이터베이스보다 뛰어난 성능을 발휘할 수 있습니다.

그러나 엔진의 품질과 기능 수준은 절대로 그렇게되지 않을 것입니다. 데이터베이스가 여러분에게 핵심 기능인 인덱싱, 트랜잭션, 참조 무결성 등 모든 것을 제공하므로 모든 것을 직접 구현해야합니다.

휠을 다시 개조하는 것보다 (모든 것이 Linux가 바로 그랬습니다),하지만 기대와 시간을 염두에 두는 것이 좋습니다.

Answer 6

새로운 데이터가 추가되는 높은 쓰기, 낮은 읽기, 업데이트되지 않는 데이터베이스의 경우 매우 잘 작동하는 것처럼 보입니다.

웹 서버와 그 사촌은 로그 파일을 많이 사용합니다.

DBMS 소프트웨어 또한 로그 용으로 사용합니다.

디자인이 이러한 제한 범위 내에 있으면 좋은 회사에 속한 것 같습니다. 메타 데이터와 포인터를 데이터베이스에 보관하고 코멘트를 버퍼링하는 일종의 빠른 비동기 대기열 작성기를 설정하고 싶지만 파일 시스템은 이미 버퍼링 및 쓰기 잠금 수준에서 꽤 좋다.

Answer 7

플랫 파일 데이터베이스가 가능하지만 다음을 고려하십시오.

데이터베이스는 모든 ACID 요소 (원 자성, 일관성, 격리, 내구성)를 달성해야하며, 모든 파일이 플랫 파일 (특히 동시 액세스가 가능)로 수행되도록하려면 기본적으로 본격적인 DBMS.

왜 처음부터 본격적인 DBMS를 사용하지 않으시겠습니까?

무료 옵션 (SQLite, MySQL, PostgresSQL 등) 중 하나를 사용하면 쓰기와 재 작성에 수반되는 시간과 비용을 절약 할 수 있습니다. .

Answer 8

파일 크기가 작 으면 무작위 액세스가 손실되지 않도록 fiat 파일 데이터베이스를 사용할 수 있습니다. 랜덤 액세스가 많은 대용량 파일은 매우 느립니다. 복잡한 쿼리도 없습니다. 조인, 합계, 그룹화 등이 없습니다. 또한 플랫 파일에서 계층 적 데이터를 가져올 수는 없습니다. XML 형식은 복잡한 구조에 훨씬 좋습니다.

Answer 9

플랫 파일 데이터베이스가 좋은지 또는 나쁜지에 대해 대답하지 않으려 고합니다. 다른 사람들은 충분한 작업을 수행했습니다.

그러나 일부 사람들은 SQLite를 사용하고 있습니다. 자바를 사용하기 때문에 가장 좋은 방법은 HSQLDB을 사용하는 것입니다.이 방법은 SQLite와 똑같지 만 Java로 구현되어 응용 프로그램에 포함됩니다.

Answer 10

대부분의 경우 플랫 파일 데이터베이스가 충분합니다. 이제입니다. 그러나 데이터베이스로 프로젝트를 시작하면 더 어린 자신에게 감사 할 것입니다. PostgreSQL과 같은 전체 데이터베이스 시스템을 설정하지 않으려면 SQLite이 될 수 있습니다.

Answer 11

이것을 확인하십시오. http://jsondb.io 오픈 소스 자바 기반 데이터베이스는 여러분이 찾고있는 대부분의 것을 가지고 있습니다. 데이터를 플랫 .json 파일, 다중 스레드 지원, 암호화 지원, ORM 지원, 원자력 지원, XPATH 기반 고급 쿼리 지원으로 저장합니다.

면책 조항 :이 데이터베이스를 작성했습니다.