플랫 파일과 데이터베이스 / API를 프론트 엔드와 백엔드 간 전송으로 사용

두 개발자 사이에 다소 화제가 된 응용 프로그램이 있습니다.

기본적으로 웹 레이어와 백엔드 레이어로 나뉩니다. 웹 계층은 간단한 웹 양식으로 정보를 수집하고이 데이터를 JSON 문서 (문자 그대로 .json 파일)로 백엔드에서 사용하는 감시 폴더에 저장합니다. 백엔드는 몇 초마다이 폴더를 폴링하고 파일을 가져 와서 기능을 수행합니다.

파일 자체는 매우 간단합니다 (예 : 모든 문자열 데이터, 중첩 없음). 백엔드 처리 단계는 메시지 당 약 10 분이 걸립니다.

관계형 데이터베이스 (MySQL), noSQL 데이터베이스 (Redis) 또는 일반 REST API 호출과 같은 것을 대신 사용해야하는 경우 한 개발자가 파일 시스템을 메시징 계층으로 사용하는 것이 나쁜 해결책이라고 제안 할 때이 주장이 제기됩니다.

Redis는 대기중인 메시지 처리를 위해 조직 내 다른 곳에서 사용됩니다.

내가 들었던 주장은 다음과 같이 분류됩니다.

플랫 파일에 찬성하여 :

• 플랫 파일은 파일을 "감시"폴더에서 가져온 후 "처리 중"폴더로, 마지막으로 완료되면 "완료"폴더로만 이동하기 때문에 다른 솔루션보다 더 안정적입니다. 매우 낮은 수준의 버그를 제외하고 메시지가 사라질 위험이 전혀 없습니다.

• 플랫 파일은 이해하기 위해 기술적 정교함이 덜 필요 cat합니다. 쓸 쿼리가 없으며, 실수로 큐에서 메시지를 튀어 나와 영원히 사라질 위험이 없습니다.

• 파일 관리 코드는 모든 언어 표준 라이브러리의 일부이므로 프로그래밍 측면에서 데이터베이스 API보다 간단합니다. 이렇게하면 코드베이스의 전체 복잡성과 가져와야하는 타사 코드의 양이 줄어 듭니다.

• YAGNI 원리 플랫 파일 지금 잘 작동하는지 상태, 아니 그래서 그것을두고, 더 복잡한 솔루션을 변경 필요성이 입증되지 것.

데이터베이스를 선호하는 경우 :

• 파일로 가득 찬 디렉토리보다 데이터베이스를 확장하는 것이 더 쉽습니다.

• 플랫 파일은 누군가 "완료"파일을 "감시"디렉토리로 다시 복사 할 위험이 있습니다. 이 응용 프로그램 (가상 시스템 관리)의 특성으로 인해 심각한 데이터 손실이 발생할 수 있습니다.

• T / S에 더 많은 기술적 정교함이 필요하다는 것은 앱을 교육받지 않은 직원이 물건을 찌르는 것만으로 무언가를 망칠 가능성이 적다는 것을 의미합니다.

• 특히 Redis와 같은 DB 연결 코드는 표준 라이브러리 파일 관리 기능만큼 강력합니다.

• DB 연결 코드는 파일 조작보다 수준이 높기 때문에 개발자의 관점에서 볼 때 (기능적 으로 는 아니더라도) 훨씬 간단합니다.

내가 볼 수 있듯이 두 개발자 모두 유효한 포인트가 많습니다.

따라서이 두 사람 (프로 파일 개발자 또는 프로 데이터베이스 개발자) 중 소프트웨어 엔지니어링 모범 사례와 더 일치하는 이유는 무엇입니까?

Ewan이 언급 한 데이터베이스 또는 대기열 시스템이 포함 된 솔루션으로 전환하면

• 백엔드 및 프론트 엔드 모두에서 새롭고 복잡한 시스템에 대한 종속성을 만듭니다.
• 불필요한 복잡성과 새로운 실패 지점을 도입
• 비용 증가 (소유 비용 포함)

단일 볼륨 내에서 파일 이동 / 이름 바꾸기는 파일 / 레코드 잠금과 관련하여 어려움이 있더라도 모든 현재 OS에서 원 자성으로 보장됩니다. OS 수준의 권한 관리는 세탁되지 않은 사용자를 잠그고 권한이있는 운영자 (관리자 / 개발자)가 실수 / 부주의로 잘못 조작하는 것을 방지하기에 충분해야합니다. 따라서 현재 솔루션의 성능이 향상되는 한 데이터베이스는 전혀 제공 할 것이 없습니다.

우리 회사에서는 수십 년 동안 비슷한 파일 기반 인터페이스를 사용하여 큰 성공을 거두었습니다. 다른 많은 것들이왔다 갔다했지만, 이러한 인터페이스는 그 단순성, 신뢰성 및 최소한의 커플 링 / 의존성으로 인해 남아 있습니다.

두 솔루션 중 어느 것이나 나쁜 습관이라고 생각하지 않으므로 최선의 방법에 대한 답변이 어려울 수 있습니다.

규모를 다루는 경우 YAGNI 교장이 여기에 적용된다고 생각하지 않습니다. "작업"은 상대적입니다. 치명적인 데이터 손실 가능성이 높고 확장 할 수있는 능력이 거의 없다면 그 작업을 실제로 고려하지는 않습니다. 나는 당신이 다루고있는 규모를 정확하게 확신하지 못하지만, 많은 양의 엔트리가 있다면, 각각이 새로운 시스템으로 전환하기가 더 어려워집니다. 이 경우 데이터베이스가 가장 좋습니다.

MongoDB 또는 redis (나는 redis에 대한 경험이 없으며 좋은 일만 읽음)는 데이터가 이미 잘 맞아야하므로 잘 작동해야합니다 (json 문서는 종종 MongoDB의 경우 BSON 문서로 변경됩니다). 디스크에 대한 읽기 / 쓰기를 자주하는 대신 많은 양의 데이터를 메모리에 유지하는 이점도 있습니다. 또한 동시 읽기 / 쓰기로 인해 손상이나 차단이 발생하지 않도록합니다.

YAGNI 주체가 여기에 적용되고 파일에 병목 현상이 없으면 범위 내에서 확장되며 치명적인 문제가없는 경우 파일을 고수하는 것이 "모범 사례"라고 말하고 싶습니다. 문제가없는 경우 변경해야 할 이유가 없습니다. 테스트를 작성하고 스트레스를 받고 한계와 병목 현상이있는 위치를 확인하십시오.

어쨌든 데이터베이스 가이 컨텍스트의 솔루션인지 확실하지 않습니다. 같은 서버에서 통신하는 경우 일종의 IPC를 수행 할 수 있습니다.

좋은 파일을 저장하고 완료 된 디렉토리에 복사하는 것은 많은 통신 계층의 주요 요소입니다. 구형 메인 프레임 시스템 등 '반티'녀석은 한 가지 지적이 있습니다. 많은 문제와 엣지 사례가 있다는 점에서 100 % 신뢰도가 필요한 경우 다루기가 어렵고 파일의 빈도와 볼륨을 확장 할 때 더 자주 발생합니다.

트랜잭션의 양쪽을 제어하면 사용 가능한 많은 간단한 큐 시스템 중 일부를 살펴볼 것을 제안합니다. 데이터베이스가 아닌 ZeroMQ, RabbitMQ, MSMQ 등 그러나 당신이 암시하는 것처럼, 그것이 깨 졌다면 ...

데이터베이스 솔루션이 옳습니다. 특정 호스트 또는 경계 조건에 대한 많은 종속성을 해결합니다.

데이터베이스가 특정 호스트에서 호스팅되지 않는다는 점을 제외하면 둘 다 비슷한 솔루션입니다. 이것은 유닉스 시스템의 방화벽 / 액세스 문제를 제거합니다. 우리는 파일 시스템에서 "우연한"삭제 사례를 보았으며 아무도 책임을지지 않습니다.

database를 사용하면 동일한 문제가 발생할 수 있지만 삭제를 제거하기 위해 감사를 설정하거나 논리 만 삽입 할 수 있습니다.

또한 파일 시스템에서 파일 이름 (예 : OASIS)에 응용 프로그램을 넣어야하는 경우 OASIS.john_doe.system1.20160202 파일을 작성해야합니다. 이것은 지루해지고 데이터베이스에서 더 쉽게 표현 될 수 있습니다. 이를 기반으로 데이터베이스 및 논리에 널 필드를 가질 수도 있습니다.

또한 테이블에서 수행 할 패치 나 수정 사항이있는 경우 전체 파일 디렉토리보다는 데이터베이스를 쉽게 업데이트 할 수 있습니다. 물론 파일 시스템에서 수행 할 수 있지만 데이터베이스 업데이트는 더 직관적입니다.

예를 들어, 재실행을 원하지만 OASIS와 다른 시스템으로 DESERT 및 john_doe는 doe_smith라고 말하고 20160101에서 20151231 사이의 날짜

쉘 스크립트로 파일을 작성하지 않고 원래 세트에서 DESERT / doe_smith / 20151231에 대한 행을 쉽게 생성 할 수 있습니다.

따라서 가독성으로부터 확장 관점 데이터베이스 솔루션이 더 좋습니다.