node.js가 백그라운드 처리에 적합합니까?


10

나는 천천히 배우고 node.js있으며 시작하고 싶은 작은 프로젝트가 있습니다. 이 프로젝트에는 많은 백그라운드 프로세스가 있습니다 (외부 사이트에서 데이터 다운로드, CSV 파일 구문 분석 등).

나와 노드의 큰 "승리"는 클라이언트와 서버 모두에 JavaScript를 사용한다는 사실입니다. 나는 하루 종일 Java와 JavaScript로 코딩하지만 Ruby에도 능숙합니다.

그러나 내가 말했듯이 어느 곳에서나 하나의 언어를 사용하는 것이 매력적이며 JS는 그 법안에 맞는 것 같습니다.

그러나 백그라운드 작업을 실행하기 위해 JS를 사용한 경험이 많지 않았습니다. 루비는이 점에서 뛰어나다. 그리고 나는 그것을 사용하는 것에 반대하지 않습니다. 그래서 이것을 위해 100 % JS를 사용하는 것에 대한 당신의 생각은 무엇입니까? 매우 큰 프로젝트에는 맞춤형 솔루션이 필요하다는 것을 알고 있습니다. 노력할만한 가치가 있는지 궁금합니다. 아니면 그런 종류의 일에 루비를 고수해야합니까?

의견에 감사드립니다.

감사


노드의 대안으로 vert.x 를 볼 수도 있습니다 .
Mike

답변:


13

특히 많은 양의 파일 I / O를 처리하는 데 강력하며 많은 네트워크 통신도 잘 처리 할 것으로 기대합니다. 소켓 중심 앱에 특히 인기가있는 것 같습니다. 명심해야 할 중요한 점은 기존 라이브러리에서 요구 사항을 충족하지 못하면 (많은 경우가 있음) JS 명령에 바인딩 될 수있는 일부 C로 다이빙해야 할 수도 있다는 것입니다. 추가 노드 프로세스를 생성 할 수도 있지만 많은 양의 작업을 수행하면 세금이 부과 될 수 있습니다 (잘못된 것으로 가정합니다. 각각에 대해 V8 인스턴스가 생성되었습니다).

JS는 단일 스레드 및 차단이므로 함수 호출이 완료 될 때까지 다른 것을 실행할 수 없습니다. 이것은 JS의 원하는 기능으로 본질적으로 모든 스레드 및 대기열 문제를 해결합니다. JS는 C / C ++ 항목이 더 많은 멀티 스레드 방식으로 실행되는 것을 막지 않으므로 JS의 역할은 실제로 더 많은 아키텍처 / 메신저입니다. 이미지 처리를 수행하는 경우 앱 또는 서버의 다른 모든 항목이 완료 될 때까지 차단되므로 동기식 JavaScript 명령으로 처리하지 않을 것입니다. 아이디어는 바인딩 된 C / C ++ 기능으로 이미지를 처리 ​​한 다음 이미지 처리가 완료되면 '완료'이벤트에 응답한다는 것입니다.

이를 위해서는 모든 Node.js 앱의 JS가 많은 이벤트와 콜백을 유발해야합니다. 그렇지 않으면 성능이 매우 저하 될 수 있습니다. 따라서 나중에 사용하기 위해 함수를 전달하지 않는 많은 메소드 호출이 Node에 표시되지 않습니다. 노드에서 매우 빠르게 밝혀지는 것은 콜백 피라미드를 처리 할 방법을 찾지 못하면 못생긴 세상에 있다는 것입니다. 예 :

//event CBs are more DOM-style than Node style and this isn't built-in Node file I/O
//keeping it simple and quick since I'll just get Node stuff wrong from memory
file.get('someFile.txt', function(e){
    e.fileObj.find('some snippet', function(e){
        someFinalCallBackHandler( e.snippetLocations );
    } );
} );

다행히도이를보다 잘 처리하기위한 도구와 예제가 많이 있습니다. 대부분은 약속 메커니즘을 중심으로 돌아가며 서로의 콜백 상태에 응답하기위한 일련의 함수를 단순히 체인으로 연결하는 경향이 있습니다.

개인적으로, 나는 우리가 JS를 높은 수준으로, C / C ++를 크롬에 더 가깝게 만드는 것을 좋아합니다. 그것은 궁극적 인 콤보이며 C를 배우기 시작하도록 영감을주었습니다. 라이브러리 잠재력이 부족하여 연구를 마칠 때까지 당신을 놀라게하지 마십시오. 노드 라이브러리는 매우 빠른 속도로 생산되고 있으며 매우 빠르게 성숙하고 있습니다. 당신이 매우 특이한 확률을하지 않으면 누군가가 그것을 커버 좋은 것입니다.

Rails와의 가장 큰 차이점은 JS가 그대로 레일에있을 가능성이 없다는 것입니다. 우리는 그것을 가질 수 있도록 코딩하는 경향이 있지만 매우 빠르게 원하기 때문에 요소에 매달릴 수있는 밧줄이 있으며 아키텍처는 최근 몇 년 전까지 JS에서 꽤 DIY였습니다. 나는 그 자유를 부르지 만, 그것은 많은 개발자들에게 이상적이지 않다는 것을 알고 있습니다.

또한 Mac 이외의 다른 버전에 설치하려고했기 때문에 Node.js에서 "gem"문제가 발생하지 않습니다. 클라이언트 측 웹은 종속성 문제를 경멸하며 많은 노드 코어가 시작됩니다. 모든 인기있는 플랫폼에서 5 분 이내에 즉시 작동하지 않으면 일반적으로 그것을 구부려 버립니다. 나는 인기있는 모듈을 아직 실행하지 않았으므로 작동하도록 특별한 작업을 수행해야했습니다. 패키지 시스템이 우수합니다.

그러나 핵심 질문에보다 명확하고 간결하게 대답하려면 백그라운드 프로세스에 적합합니까?

예, 노드는 기본적으로 이벤트 및 콜백을 통해 앱을 구동하는 수단으로 백그라운드 프로세스입니다.


1
여기에는 많은 일반 정보가 있지만 요청을 비동기 적으로 처리하는 node.js의 기능에 대해서는 언급하지 않았습니다.
Robert Harvey

좋은 지적. 나는 거기에 더 초점을 둘 것이다.
Erik Reppen

전 Rails 개발자이자 경험이 풍부한 Node.js 개발자 인 저는 Ruby / Rails world와 JS / Node.js world Erik의 패키지 시스템 비교에 동의하지 않습니다. 경험이 많거나 경험이없는 Rails 개발자라면 "보석"은 문자 그대로 보석과 같다는 것을 알고 있습니다. 그들은 쉽게 일합니다. 대부분은 잘 테스트되고 강력하며 안정적입니다. 그러나 NPM 모듈의 절반 이상이 제대로 설계되지 않았으며 테스트되지 않았으며 완료되지 않았습니다. 예를 들어, 아무도 정확히 동일한 품질과 기능이 풍부한 Devise 또는 Paperclip의 JS 대체품을 보여줄 수 없습니다. 절대 안돼.
scaryguy

그것은 맥 이외의 다른 경험이 아닙니다. 즉, 이전보다 일반적인 노드 모듈의 OS 간 호환성에 덜 감탄했습니다. 내가 경험이있는 더 나쁜 계란을 겪었는지 또는 커뮤니티가 플랫폼을 심각하게 생각하지 않는 많은 개발자를 포함하도록 성장했는지 확실하지 않습니다. 그러나 분명히 리눅스 스노 버가 있습니다.
Erik Reppen

이 답변은 많은 upvotes을받을 권리
아민 모하메드 Ajani에게

2

알아야 할 한 가지 문제 는 비동기 환경에서 큰 파일을 처리 할 때 발생 하는 것입니다. 입력 스트림 (파일)이 출력 스트림 (db)보다 빠르면 입력 데이터 이벤트를 빠르게 처리 할 수 ​​없습니다 충분히. 이로 인해 일부 시스템 (출력 스트림 또는 메모리)이 압도되거나 데이터가 손실 될 수 있습니다. 이러한 이유로 비동기 적으로 데이터를 처리하는 것은 약간 까다로울 수 있습니다. 그러나 필자가 링크 한 기사에서 설명했듯이 입력 스트림을 일시 중지하면 상황에 맞는 방식으로 조절할 수 있습니다.


1

Node.js는 IO에서 뛰어납니다. 대부분의 스레드가 SQL 호출에서 차단되므로 프로세스가 중단 된 것을 발견 할 가능성이 거의 없습니다.

그러나 node.js는 컴퓨팅 바운드 작업에서 실제로 나쁩니다 . "많은 IO"가 들리면 "yeah! go node!"라고 생각하지만 "구문 분석"이 들리면 조금 주저합니다. 이것이 사람들이 멀티 스레딩 노드를 올바르게 사용하지 않는 것 이외의 이유인지 확실하지 않지만, 내 제품의 모든 컴퓨팅 바운드 작업은 노드 외부에서 발생합니다.

node.js의 멀티 스레딩은 올바르게 설정하기가 까다 롭습니다. 기본적으로 모든 것이 단일 스레드이며 대부분의 코드는 하나의 스레드에서만 실행된다는 가정하에 작성됩니다. 하나의 스레드에서 오류가 발생하여 전체 애플리케이션이 다운되지 않도록 하려면 도메인 을 사용해야 합니다 .

또한 일부 엔터프라이즈 기능에서는 노드가 약간 약할 수 있습니다. 예를 들어, 로깅 라이브러리는 Java와 비교되지 않습니다. 현재는 MDC를 지원하는 훌륭한 로깅 프레임 워크가 없습니다. 실제로 많은 작업을 수행해야합니다 var logPrefix = userId + ": ".

또한 개인 npm 저장소를 실행 한 적이 없으며 코드의 독점 여부에 따라 이들 중 하나가 필요할 수 있습니다.


1

백그라운드 프로세스가 순차적으로 실행될 수 있다면 꽤 좋을 수 있습니다. 마지막 위치에서 많은 데이터 소스에 대한 여러 전 처리기, 내보내기 및 변환 유틸리티를 작성해야했습니다. NodeJS를 사용하는 것은 매우 쉬웠습니다.

당신이 일을하지 않으면 많은 컴퓨팅 바운드 처리, 짧은 문자열의 간단한 조작, 정수 구문 분석을 사용하면 이미지를 조작해야하는 경우 호출 래퍼와 모듈이 있기는하지만 (아마 가장 좋은 도구가 아닙니다, 그렇게 나쁘지 않다 잘 작동합니다).

조언, 스트림을 사용하는 모듈을 고수하십시오. 이를 통해 처리를 특정 단계에 대한 모듈로 쉽게 파이프 할 수 있습니다. 어떻게 보면 이벤트 스트림 에 사용되는 꿀꺽 - 옥 대한 꿀꺽 빌드 도구 예를 들어, 당신은 어떻게 할 볼 수 있습니다.

CSV의 경우 node-csv를 사용할 수 있습니다 . 이는 레코드를 프로세서 스트림으로 파이핑하기위한 기반을 설정하는 데 매우 적합합니다.

한 번에 단일 레코드를 수행하려는 대형 XML의 경우 SAX 프로세서를 사용하여 XML 스트림을 읽고 각 노드에 대한 이벤트를 발생시키는 node-halfstreamxml 을 살펴 보겠습니다 . 원하는 것을 일치시킬 수 있도록 읽기 / 쓰기 스트림으로 래핑합니다. 노드의 많은 xml 객체 파서는 전체 xml을 한 번에 읽고 파싱하려고 시도합니다. 예를 들어 100MB의 XML이 커지면 halfstreamxml은 스트림으로 읽습니다.

참고 : xml-stream 과 같은 다른 프로세서 가 아래에 expat (C 라이브러리)를 사용하여 성능을 향상시킬 수 있지만 빌드 환경이 없으면 이식성이 떨어집니다.

일반적으로 사용하는 것은 정말 기뻤습니다 ...

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.