NoSQL에 대한 Wikipedia 페이지를 살펴 보았고 Key / Value 저장소 데이터베이스에서 여러 변형이 나열되어 있지만이 컨텍스트에서 Key / Value 저장소의 의미에 대한 세부 정보는 찾을 수 없습니다. 누군가 나에게 설명을 설명하거나 연결할 수 있습니까? 또한 언제 그런 데이터베이스를 사용합니까?
NoSQL에 대한 Wikipedia 페이지를 살펴 보았고 Key / Value 저장소 데이터베이스에서 여러 변형이 나열되어 있지만이 컨텍스트에서 Key / Value 저장소의 의미에 대한 세부 정보는 찾을 수 없습니다. 누군가 나에게 설명을 설명하거나 연결할 수 있습니까? 또한 언제 그런 데이터베이스를 사용합니까?
답변:
키 / 값 쌍의 개념에 익숙하십니까? Java 또는 C #에 익숙하다고 가정하면 언어는지도 / 해시 / 데이터 테이블 / KeyValuePair와 같습니다 (마지막은 C #의 경우)
작동 방식은이 작은 샘플 차트에 나와 있습니다.
Color Red
Age 18
Size Large
Name Smith
Title The Brown Dog
키 (왼쪽)와 값 (오른쪽)이있는 경우 문자열, int 등이 될 수 있습니다. 대부분의 KVP 객체를 사용하면 값만 있기 때문에 모든 객체를 오른쪽에 저장할 수 있습니다.
반환하려는 특정 객체에 대한 고유 키가 항상 있으므로, 해당 고유 키에 대한 데이터베이스를 쿼리하고 객체가있는 노드에서 결과를 다시 가져올 수 있습니다 (이는 분산 시스템에 적합합니다. 다른 노드와 일치하는 값을 반환하기 위해 첫 번째 n 노드에 대한 폴링과 같은 다른 것들이 있기 때문에).
위의 예제는 매우 간단하므로 KVP의 약간 더 나은 버전이 있습니다.
user1923_color Red
user1923_age 18
user3371_color Blue
user4344_color Brackish
user1923_height 6' 0"
user3371_age 34
간단한 키 생성을 볼 수 있듯이 사용자에게 사용자 고유 번호, 밑줄 및 개체를 "사용자"로 지정하는 것입니다. 다시 말하지만 이것은 간단한 변형이지만 왼쪽 부분을 정의하고 일관된 형식을 지정하여 값을 가져올 수 있다는 것을 이해하기 시작했습니다.
키 값 (텍스트 전용과 같은 일부 제한이있을 수 있음) 또는 value 속성 (크기 제한이있을 수 있음)에는 제한이 없지만 지금까지는 복잡한 시스템이 없었습니다. 조금 더 시도해 봅시다.
app_setting_width 450
user1923_color Red
user1923_age 18
user3371_color Blue
user4344_color Brackish
user1923_height 6' 0"
user3371_age 34
error_msg_457 There is no file %1 here
error_message_1 There is no user with %1 name
1923_name Jim
user1923_name Jim Smith
user1923_lname Smith
Application_Installed true
log_errors 1
install_path C:\Windows\System32\Restricted
ServerName localhost
test test
test1 test
test123 Brackish
devonly
wonderwoman
value key
당신은 아이디어를 얻습니다 ... 모든 것들이 분산 노드의 하나의 거대한 "테이블"에 저장되고 (모든 수학 뒤에 있습니다) 분산 시스템에 필요한 값을 이름으로 요구하면됩니다.
적어도 그것이 그것이 어떻게 작동하는지에 대한 나의 이해입니다. 몇 가지 잘못되었을 수도 있지만 이것이 기본입니다.
필수 위키피디아 링크 http://en.wikipedia.org/wiki/Associative_array
user1923_color: red, user1923_age: 18, ...
반대하는 이유를 모르겠습니다 user1923: {color: red, age: 18, ...}
.
SQL 용어로 NoSQL 데이터베이스는 두 개의 열이있는 단일 테이블입니다. 하나는 기본 키이고 다른 하나는 값입니다. 이것이 바로 NoSQL의 마법입니다.
확장 성이라는 주요 이유 중 하나는 NoSQL을 사용하는 것입니다.
애플리케이션이 초당 수백만 건의 쿼리를 처리해야하는 경우이를 달성하는 유일한 방법은 더 많은 서버를 추가하는 것입니다. NoSQL을 사용하면 매우 저렴하고 쉽습니다. 반대로 기존 SQL 데이터베이스의 확장은 훨씬 더 복잡합니다.
실제로 가장 큰 웹 사이트 만이 Cassandra를 실행하는 수천 대의 서버가있는 전체 NoSQL 잠재력 (예 : Facebook)을 활용하고 있습니다 .
SQL, NoSQL 및 ORM을 비교 하여이 블로그 게시물을 읽는 것이 좋습니다.
NoSQL 이동 및 비 관계형 데이터베이스 모델에 대한 기본 지식이 있다고 가정합니다.
키 값 저장소는 그래프, 문서 지향 데이터베이스 모델과 같은 비 관계형 데이터베이스 모델 중 하나입니다.
키 값 저장소 및 NoSQL 이동
일반적으로 SQL은 특수하게 구조화 된 데이터를 처리하고 해당 부서의 요구에 따라 매우 동적 인 쿼리를 허용했습니다.
이 특정 분야에서 SQL에 대한 실제 경쟁자는 아직 없지만 일상적인 웹 응용 프로그램의 사용 사례는 다릅니다. 큰 테이블에 대한 외부 및 내부 조인, 공용체 및 복잡한 계산으로 가득 찬 매우 동적 인 범위의 쿼리를 찾을 수 없습니다. 일반적으로 매우 객체 지향적 인 사고 방식을 찾을 수 있습니다. 특히 MVC와 같은 패턴을 채택하면 백엔드의 데이터는 일반적으로 데이터베이스 용으로 모델링되지 않고 논리적 무결성을 통해 사람들이 거대한 소프트웨어 인프라를 이해하는 데 도움을 줄 수 있습니다. 이러한 객체 지향 모델을 관계형 데이터베이스에 배치하기 위해 수행되는 작업은 테이블의 복잡한 계층 구조로 이어지고 객체 지향 프로그래밍의 기본 개념과 완전히 일치하는 대량의 표준화입니다.
SQL은 복잡한 데이터 집합에 대한 임의의 동적 쿼리를 허용한다는 사실은 객체 지향 데이터의 영구 저장에만 SQL 데이터베이스를 사용함으로써 쓸모 없게되며, 이는 오늘날 대부분의 응용 프로그램이 기본적으로 수행하는 작업입니다.
Key Value 상점이 등장하는 곳입니다.
Key value stores allow the application developer to store schema-less data. This data is usually consisting of a string which represents the key and the actual data which is considered to be the value in the "key - value" relationship
. 데이터 자체는 대개 프로그래밍 언어 (문자열, 정수, 배열) 또는 키 값 저장소에 대한 프로그래밍 언어 바인딩에 의해 마샬링되는 객체의 일종의 기본 형식입니다. 이는 고정 데이터 모델의 필요성을 대체하고 올바른 형식의 데이터에 대한 요구를 덜 엄격하게 만듭니다.
They all allow storage of arbitrary data which is being indexed using a single key to allow retrieval
. "단순한"상점의 가장 큰 차이점은 가능한 경우 다른 상점을 인증하거나 액세스 할 수없는 방법입니다. 데이터를 저장하고 검색 할 때 속도 이점이 일반적인 SQL 데이터베이스보다 데이터를 고려해야하는 이유 일 수 있지만 키-값 저장소를 사용할 때 나타나는 또 다른 큰 장점은 내장 된 SQL 문자열과 비교할 때 결과 코드가 깨끗하고 단순 해 보입니다. 프로그래밍 언어. 이것은 사람들이 최대 절전 모드 또는 활성 레코드와 같은 객체 관계형 매핑 프레임 워크와 싸우는 경향이 있습니다. 객체 관계형 맵퍼를 갖는 것은 기본적으로 SQL 데이터베이스와 객체 지향 프로그래밍 언어 사이에 정말 복잡한 코드를 많이 추가하여 키 값 저장소를 에뮬레이트하는 것 같습니다.전체 커뮤니티가 " NoSQL "태그 아래에 모여 이러한 데이터베이스의 장점과 단점을 논의하여 데이터베이스 관리 시스템을 대체 할 수있는 대안을 사용합니다. 더 읽어보기
이것은 약간 오래된 기사이지만 매우 유용합니다.
when would I use such a database?
Could someone explain or link an explanation to me?
아키텍처 결정과 논쟁의 여지가 많은 것 ... 확장 성, 성능 등과 같은 많은 요소를 고려해야합니다.
아래 슬라이드 / 기사를 보면 키 값 저장소를 언제, 왜, 왜 사용하지 않을지에 대한 아이디어를 얻을 수 있습니다. :)
다른 사람들은 이것을 설명했지만 어쨌든 찌를 것입니다.
키 / 값 데이터베이스는 기본 키로 데이터를 저장합니다. 이를 통해 버킷에서 레코드를 고유하게 식별 할 수 있습니다. 모든 값이 고유하기 때문에 조회 속도가 엄청나게 빠릅니다. 항상 간단한 디스크 찾기입니다.
값은 모든 종류의 값입니다. 데이터가 저장되는 방식은 데이터베이스 자체에 불투명합니다. 키 / 값 저장소에 데이터를 저장하면 데이터베이스는 XML, JSON, 텍스트 또는 이미지인지 알지 못합니다. 실제로 키 / 값 저장소에서 수행하는 작업은 데이터가 데이터베이스에서 데이터를 검색하는 응용 프로그램으로 저장되는 방식을 이해해야 할 책임이 있습니다. 버킷 당 하나의 키 범위 만 걱정하면되므로 많은 서버에 키를 분산시키고 분산 프로그래밍 기술을 사용하여이 데이터에 신속하게 액세스 할 수 있습니다 (모든 서버가 다양한 데이터를 저장함) .
이 데이터 접근 방식의 단점은 검색이 매우 어려운 작업이라는 것입니다. 버킷 데이터의 모든 레코드를 읽거나 보조 인덱스를 직접 만들어야합니다.
키 / 값 데이터베이스를 사용하려는 몇 가지 이유가 있습니다.
RDBMS를 사용하는 것만 큼 키 / 값 데이터베이스를 사용하는 데는 여러 가지 이유가 있으며, 서로를 정당화하기위한 많은 인수가 있습니다. 데이터를 쿼리하는 방법을 살펴보고 해당 데이터 액세스 패턴이 데이터 삽입 및 저장 방법을 어떻게 안내하는지 이해하는 것이 중요합니다.
키 / 값 데이터베이스는 NoSQL 데이터베이스의 한 유형일뿐입니다.
관계형 데이터베이스가있는 경우 다음을 쉽게 실험 할 수 있습니다.
create table keyvalue (my_key varchar2(255), my_value varchar2(255));
create unique index ix_keyvalue on keyvalue (my_key, my_value);
이것은 1979 년부터 버클리 DBM 이 좋은 예가 되었던 모든 데이터베이스의 예입니다. 그 이후로 모든 것이 발전했습니다 ( 모든 RDBMS에서 키당 많은 값을 가질 수 있음 ). 많은 응용 프로그램의 경우 키-값 저장소로 충분합니다 (예 : sendmail이 해당 별칭을 저장하는 방식). 그러나 자신의 코드에서 값을 사전 처리하거나 문자열을 연결하여 "키"를 만들면 구분 기호에서 값을 분할하거나 구문 분석하여 사용할 수 있기 전에 더 나은 결과를 얻을 수 있습니다. RDBMS에 실제로 저장합니다.