스트림과 큐의 차이점은 무엇입니까?

스트림과 큐의 차이점은 무엇입니까? 둘 다 순서가 지정된 요소의 개념을 가지고 있지만, 다른 구현과 '삽입'/ '추출'(스트림) 대 '인큐'/ '디큐'(큐)의 다른 어휘를 갖는 경향이 있습니다. 이것들은 상호 교환 가능합니까? 그들은 다른 개념이나 패턴을 제안합니까? 그렇다면 차이점은 무엇입니까?

스트림은 정말 (개념적으로)와 같은 데이터 구조 아니지만, 디지털 방식으로 인코딩 된 간섭 신호를 전송하는데 사용되거나 "정보를 수신 (데이터 또는 데이터 패킷의 패킷)의 순서이다. 그래서, 기본적으로 데이터의 시퀀스.

큐 는 큐의 뒤쪽에 항목을 추가하거나 전면에서 취할 수있는 간단한 FIFO 메커니즘입니다.

스트림에는 항상 소스 (예 : 파일, 네트워크 위치 등)가 있습니다. 큐에는 기본적으로 데이터가 없습니다.

따라서 본질적으로 개념이 상당히 다르며 Mason이 지적한 것처럼 다르게 사용됩니다.

기본적인 차이점은 사용 방식에 있습니다. 스트림에서는 일반적으로 작업의 한쪽 만 사용합니다. 스트림을 열어서 읽거나 쓰지만 둘다는 아닙니다. 대기열이있는 동안, 물건을 싣고 벗는 것입니다.

또한 대기열은 물건을 넣고 꺼내는 순서에 대해 매우 엄격하지만 스트림은 종종 (항상 그런 것은 아니지만) Seek작업을 지원합니다 ( 특히 읽는 경우).

내 경험에 따르면 스트림은 종종 스트림 내의 데이터에 의해 결정되는 속도로 생성 / 소비되는 바이트 시퀀스입니다. 예를 들어, MPEG 데이터 스트림에는 다음 바이트 시퀀스의 기능과 소비해야하는 바이트 수를 설명하는 프레임 헤더가 있습니다. 문서의 이진 직렬화는 비슷합니다. 항상 자체 설명하는 것은 아닙니다. STDOUT에 쓰는 것은 스트림 방식으로 수행 할 수 있지만 사람이 읽을 수 있거나 구문 분석 할 수없는 데이터 일 수 있습니다.

반대로, 대기열은 일반적으로 전체적으로 소비되는 잘 알려진 유형의 객체 (또는 인터페이스 지원 객체)입니다. 여러 데이터베이스 워커가 처리하는 데이터베이스 작업 큐가 그 예입니다.

스트림과 큐의 차이점은 데이터 속도가 제어되는 방식입니다.

• 대기열에서 발신자는 독자의 속도에 적응합니다. 발신자는 대기열이 가득 찬 경우 수행 할 작업을 결정합니다. 대기열의 가용성을 기다리거나 데이터를 버립니다.

• 스트림에서 리더는 발신자의 속도에 적응합니다. 리더는 오래된 데이터가 소비되기 전에 새로운 데이터가 도착하면 어떻게해야할지 결정합니다.

이러한 관점에서 Unix 파이프와 같은 문자 스트림은 스트림이 아니라 대기열로 간주됩니다.

단어가 일반적으로 사용되는 방식에 대해 더 시각적으로 생각하면 특정 언어 및 구현에 의한 특정 사용의 혼란을 피할 수 있으므로 이러한 용어는 실제로 무언가를 의미 할 수 있습니다.

• 큐 라인에 사람들이 대기와 하나씩 제공됩니다. 더 많은 사람들이 꼬리에 줄을 듭니다. 서비스가 진행될 때마다 대기하며 서비스 시간은 달라질 수 있습니다. 총 인원 수에 대해 이야기 할 수 있습니다.
• 예를 들어, 문을 통해 건물을 떠나는 사람들 의 흐름 은 하나씩 제공되지 않으며, 다소 일정한 속도로 출구를 통과합니다. 지연은 예상되지 않으며 허용되지 않습니다. 초당 1 명씩 사람들의 비율을 말할 수 있습니다.

이것이이 용어의 의도입니다. 그들은 은유입니다. (다른 모든 것과 마찬가지로) (S! 당신은 이야기를 망칠 것입니다!)

큐는 스트림보다 높은 수준의 개념입니다. 큐 의 기본 요소는 메시지 / 객체로, 소비자가 스스로 해석 할 수있는 일관된 (일반적으로 유형이 지정된) 데이터 구조입니다. 반면에, 스트림 의 기초 에는 (보통 고정 크기) 비트 / 바이트 / 문자가 있으며, 그 자체로는 대개 응용 프로그램에 무의미합니다. 이러한 문자의 시퀀스는 "메시지"를 작성할 수 있지만 스트림 API는이를 사용하여 문자 시퀀스를 적절한 청크로 분할합니다.

스트림 버퍼는 일반적으로 스트림 버퍼가 가득 차고 다른 쪽이 읽기 / 쓰기가 아닌 경우 부분 읽기 및 쓰기를 허용합니다. 대기열을 처리하는 응용 프로그램은 일반적으로 대기열이 내부적으로 처리 할 것으로 예상합니다.

큐는 스트림 위에 구현 될 수 있으며, 이는 메시지 프레이밍을 구현하여 수행됩니다. 예를 들어, TCP는 스트림 인터페이스를 제공하고 HTTP는 TCP 위에 구축되며 Content-Length / chunked 전송 인코딩을 사용하여 메시지 프레이밍을 추가합니다. HTTP 연결 API 사용자는 HTTP 연결 스트림을 HTTP 요청으로 분할하는 것을 처리하지 못합니다.

반면, 메시지 프레이밍 처리에 불필요한 오버 헤드가 추가되므로 일반적으로 큐 위에 스트림 API를 구현하는 것이 의미가 없습니다.

함수형 프로그래밍 언어 (예 : 스칼라) 및 다른 언어에서도 스트림은 실제로 함수형 목록과 비슷하며 대기열입니다. 그러나 큐는 실제로 한 쌍의 목록을 사용하여 구현할 수 있습니다 . 스칼라와 다른 곳에서 Stream은 단지 게으른 목록입니다.보다 구체적으로, 목록의 꼬리는 lazy val입니다.

기능적 스트림은 목록과 달리 대기열과 일부 유사점을 공유 할 수 있으므로 스트림 헤드에 대한 참조를 유지하지 않는 방식으로 사용할 수 있습니다. 그러나 https : // stackoverflow.com/a/5159356/3096687 . 이것은 대기열에 대한 대기열 제거 호출과 다소 유사합니다 (스트림의 경우에도 암시 적으로 수행합니다) : http://daily-scala.blogspot.com/2010/01/streams-2-stream-construction.html ).

스트림은 일련의 데이터를 직렬 또는 병렬 또는 대량으로 생성하고 소비하는 개념 / 프레임 워크입니다. Que는 스트림을 구현할 수있는 데이터 구조입니다. 스트림을 구현할 수있는 list 또는 seq와 같습니다.