새벽이 아니면 집중이 안되는 도서관

결론적으로,

온-프레미스 : 기업이 직접 서버를 관리하고, 직접 소프트웨어를 제공하는 방식.
인프라를 직접 유지-보수 해야하며, 보안 전문가를 고용해야한다.
오프-프레미스 : 외부 업체가 서버를 관리해주고, 기업에서는 소프트웨어만 관리하는 방식.
인프라의 유지보수와 보안에는 신경쓰지 않고, 소프트웨어의 관리에만 집중할 수 있다.

온 프레미스와 오프 프레미스 각각의 장-단점을 흡수하여
중요 부분은 온 프레미스로, 사용자에게 제공되는 부분은 오프 프레미스로 구현하는,
하이브리드 클라우드 방식을 사용하기도 한다.

배경

기업에서 소프트웨어를 제공할 수 있는 방법은

코드 배포, CD/USB 제공 등 여러가지 방법이 있지만

CI/CD 등의 전략과 배포망 안정화를 이유로,

가장 흔한 배포-사용 방법은 온라인 서비스일 것이다.

이 소프트웨어를 어디서 구동시킬까?

- 만든 사람이 직접 구동할까?

- 다른 사람에게 구동을 시킬까?

- 내가 하기 쉬운 것만 구동하고, 다른 사람에게 맡길까?

이 세가지 방법에 대해 알아보고자 한다.

온 프레미스 (On-premise)

위키백과에 따르면 온 프레미스 (On-premise) 란,

고전적인 제공 방식으로,

기업이나 배포자가 직접 서버를 구축하고 소프트웨어를 설치하여 소프트웨어를 제공하는 방식이다.

초기 비용과 유지 관리에는 어려움이 있지만,

하드웨어를 적합하게 커스터마이징 할 수 있고, 내부 보안에도 유리하다.

오프 프레미스 (Off-premise)

NASA, Meta 등이 사용하는 구독형 스토리지 플랫폼, 퓨어 스토리지에 따르면,

기업 외부의 업체에서 서버와 인프라를 관리해주고,

기업은 안정적인 환경에 소프트웨어만을 배포하는 방식이다.

온 프레미스와 달리,내가 사용한 만큼만 지불하면 되고

서버-보안 등의 관리자가 필요하지 않다.

또, 언제든 추가 비용을 지불하면 인프라를 확장할 수 있다.

온프레미스와 오프프레미스의 특징

두 방법에는 각각의 장단점이 있기 때문에,

현재는 하이브리드 클라우드 방식을 많이? 사용합니다.

보안과 직결되는 부분은 온프레미스로,

사용자가 마주보는 부분은 클라우드로 제공하는 것처럼요.

이와는 별개로 코로케이션 (Colocation)이라는 방식도 있는데,

 데이터센터(IDC) 내 공동 공간을 빌려 자사의 서버를 설치하는 것을 의미합니다.

결론

각각의 방식은 장단점이 있다.

두 가지 방식을 혼용해서 사용하면 각각의 장단점을 흡수할 수 있다.

그리고

다시 맨 위로 올라가자,

결론적으로,

SQL : 엄격한 스키마가 있는 관계형 데이터베이스.
NoSQL : schimaless한, RDBMS를 제외한 나머지 데이터베이스

전자는 잦은 수정을 하거나, 중복 제거로 인한 이상현상을 줄이는데 유리하고,
후자는 더 유연하며, 수정이 없이 조회만을 주로 하고, 수평적 확장을 대비하는데 유리하다.

우선, SQL과 NoSQL이 무엇인지 알고, 두 가지를 비교해보자.

SQL (Structured Query Language) : 구조화된 쿼리(데이터 질의) 언어.

 원래 SQL은, DB에 데이터를 삽, 삭, 갱 할수 있는, 말 그대로 "쿼리 언어" 이다.

하지만 처음에는 이 언어를 RDBMS에서 사용하기 위해 만든 까닭에, 데이터베이스 까지 통용하는 말이 된 것 같다.

RDBMS는 크게 두 가지 특징이 있으며,

 1. 관계를 사용하 데이터 중복 제거.

 2. 엄격한 스키마를 통해, 데이터 무결성 보장.

RDBMS의 예시로는,

NoSQL (Not Only SQL) : SQL이 아닌 것.

나무위키에서, NoSQL/등장 배경 :

크게는 네 가지 종류가 있으며,

1. Key-Value : Memcached, Riak, Redis, Amazon Dynamo DB, LevelDB

2. Document :  MongoDB, CouchDB, MarkLogic

3. Column-family : HBase, Cassandra, Hypertable

4. Graph 모델 : ...

NoSQL의 예시를 먼저 보고가면 좋을 것 같다.

아래는 MongoDB의 도큐먼트 구조 예시,

딱 봐도 RDBMS보다 자유롭고, 제약이 없어보인다.

실제로도 유연함과, 이로 인해 따라오는 조회 속도가 장점이다.

데이터를 프로그램측에서 유리하게 저장할 수 있기 때문이다.

도큐먼트에서도 여러 방법이 있는데,

관심있으면 아래 페이지를 한 번 더 읽어봤으면 한다.

NHN meetup : mongoDB Story 3

뭐가 다른가?

결론.

다시 맨 위로 올라가보자.

오늘도 수분 보충 완료 !

https://siyoon210.tistory.com/130

https://velog.io/@octo__/SQL-vs-NoSQL

NCSA의 모자이크에서 시작해 AOL을 거쳐 Mozilla 재단까지 내려오는

firefox 브라우저의 역사를 Mozilla japan에서 정리한 이미지.

pdf 파일로만 제공되어, 이미지 파일로 가져왔다.

Foxkeh의 블로그

저작권 © 2006-2011 Mozilla Japan. 판권 소유. 일부 콘텐츠는 크리에이티브 커먼즈(Creative Commons)에 따라 라이선스가 부여됩니다. 자세한 내용은 각 내용의 설명을 참조하십시오. Mozilla, Firefox 및 Firefox 로고는 미국 및 기타 국가에서 Mozilla Foundation의 상표 또는 등록 상표입니다. 기타 회사 이름 및 제품 이름은 해당 회사의 상표 또는 등록 상표입니다.

CC BY-NC-ND 2.1

결론적으로,

JSON과  XML 모두 데이터 교환에 사용되는 데이터 포맷.
JSON : 데이터 교환을 목적으로 설계되어, 성능과 통신속도가 빠르며, 더 간걀하고 읽기 쉽다.
XML : 레거시 시스템 등에서 JSON보다 안정적이고, 다양한 데이터 형식을 지원하는 무거운 포맷.


두 형식 모두 데이터 교환에 사용되지만 JSON은 더 새롭고 유연하며 널리 사용되는 옵션이다.

오픈소스로 운영되는 모질라 재단의 문서 저장소, MDN(Mozila Developer Network)에 따르면,

기술산업에 선도적인 클라우드 컴퓨팅 플랫폼인 AWS(Amazon Web Services)에서는,

유사점

만약, 자바에서 파이썬으로 자료를 보낸다면, 아무런 문제 없이 교환할 수 있을까?

프로그래밍 언어와 플랫폼마다 동일한 데이터를 다르게 표현한다.

자바에서는 객체를 사용하는 반면, 파이썬에서는 엔티티를 딕셔너리 자료형을 사용하여 저장한다.

이 때, 데이터 직렬화를 위해 두 형식을 사용할 수 있다.

포맷

XML 문법

<guests>

  <guest>

    <firstName>John</firstName> <lastName>Doe</lastName>

  </guest>

  <guest>

    <firstName>María</firstName> <lastName>García</lastName>

  </guest>

  <guest>

    <firstName>Nikki</firstName> <lastName>Wolf</lastName>

  </guest>

</guests>

JSON 문법

{"guests":[

  { "firstName":"John", "lastName":"Doe" },

  { "firstName":"María", "lastName":"García" },

  { "firstName":"Nikki", "lastName":"Wolf" }

]}

차이점

형식

JSON은 키:값 페어를 사용한 맵과 유사한 구조를 갖는다.

XML은 마크업 언어로서 HTML과 유사하며, 트리 구조를 갖는다.

구문 분석

JSON은 쉽게 액세스할 수 있는 표준 JavaScript 함수로 구문분석 할 수 있다.

XML은 XML 구문 분석기를 사용해야 하는데, 프로세스가 느려지고 복잡해지는 경우가 많다.

스키마 문서

JSON에서도 스키마를 사용할 수 있지만, XML에서보다 스키마가 더 단순하고, 유연성이 뛰어납니다.

XML 문서의 헤더에는 스키마에 대한 링크가 있고, 파일의 예상 내용을 읽을 수 있다.

데이터 유형 지원

JSON은 문자열, 숫자, 객체, 부울 등 한정된 데이터 유형만 지원한다.

XML은 더 유연하며, 이진 데이터 및 타임스탬프와 같은 복잡한 데이터 유형을 지원한다.

보안

JSON 구문 분석은 XML보다 안전하다.

XML구조는 무단 수정에 취약하며, 외부 엔티티 삽입(XXE), DTD의 보안 위협이 발생한다.

 비정형 외부 문서 형식 선언(DTD) 기능을 비활성화 하면 두가지 문제를 모두 방지할 수 있다.

결론

이하 참고한 AWS 문서를 인용한다 : 

XML은 데이터를 기계가 읽을 수 있는 방식으로 저장하는 데 중점을 두므로,
복잡한 데이터의 오류를 검사하는 데 있어서 JSON보다 더 효율적입니다.
또한 더욱 발전된 도구 및 라이브러리 세트를 갖추고 있으며 레거시 시스템에서 더 잘 작동할 수 있습니다.

반면 JSON은 데이터 교환을 목적으로 설계되었으며 더 간단하고 간결한 형식을 제공합니다.
또한 성능과 통신 속도를 향상시킵니다.

JSON은 일반적으로 API, 모바일 앱 및 데이터 스토리지에 더 적합하며,
XML은 데이터 교환이 필요한 복잡한 문서 구조에 더 적합합니다.

JSON은 일반적으로 API, 모바일 앱 및 데이터 스토리지에 더 적합하며, XML은 데이터 교환이 필요한 복잡한 문서 구조에 더 적합합니다.

두 형식 모두 데이터 교환에 사용되지만 JSON은 더 새롭고 유연하며 널리 사용되는 옵션입니다.