1. 홈
  2. 질의 응답
  3. 블로그 데이터를위한 NoSql 솔루션

블로그 데이터를위한 NoSql 솔루션

2012-06-19 2 views
0

나는 블로그 스타일 앱을 쓸 계획이며 저장 용으로 무엇을 사용해야하는지 궁금합니다.블로그 데이터를위한 NoSql 솔루션

나는 DB 스키마를 수행하는 것이 지루하기 때문에 NoSql 솔루션을 사용할 생각이다. json 구조화 된 데이터로 대부분의 기능을 수행 할 수 있다고 생각합니다.

설계시 고려해야 할 사항은 무엇입니까? 어떤 NoSQL 기술이 이러한 목적에 더 잘 맞습니까?

대략 mongo/couchdb가 할 것이라고, 나는 몇 가지 경험을 기반으로 조언을 얻으려면 바래요.

감사합니다.

출처

2012-06-19 user1462192

답변

1

MongoDB를/CouchDB를이

I로 시작하는 둘 중 하나를 쉽게가 MongoDB를 것 같다. 오래된 열의 관계형 데이터베이스와 같은 기분이 약간 있습니다. 왜냐하면 인덱스에 열을 추가하거나 count와 같은 연산을 호출 할 수 있기 때문입니다. 내가 아는 한 CouchDB에서 Map-Reduce를 사용합니다. 색인은 CouchDB에서 소위 views으로 생성됩니다.

또한 MongoDB는 데이터베이스, 테이블 개념을 대략 NoSQL (데이터의 2 레벨 액세스)으로 매핑하는 반면 CouchDB는 하나의 레벨 (데이터베이스) 만 알고 있습니다.

mytable = Connection().mydatabase.mytable # MongoDB 
mytable.save(document) 

mydb = couchdb.Server()['mydatabase'] # CouchDB 
mydb.save(doc)

그래서 나는 CouchDB를 당신이 유형의 일종으로 문서를 선택 (또는 여러 DBS를 사용하기 때문에, 처음에 조금 이해하기 어려울 수도 있습니다 추측하지만 추가 속성 type 어떤 사람들 생각 이 presentation by David Zuelke page 41

MongoDB는 일반적으로 프로그래밍 언어에 포함 할 수 있습니다 (라이브러리가 있지만 대부분의 언어에 해당하는 경우).이 호출은 서버에 바이너리 형식으로 전송됩니다. 반면에 CouchDB는 REST-API를 사용합니다.

구조체 데이터

그물 주변의 일부 자습서를 둘러 볼 수 있습니다. 블로그는 문서 지향 데이터베이스의 좋은 예이기 때문에 블로그에 관해 자주 설명합니다.

여기에 작은 모양이 보일 것입니다. CouchDB를 사용하는 경우 테이블에 (또는 CouchDB를 사용하면 type) 귀하의 게시물이 있습니다. 각 게시물은 텍스트, 일부 태그, 날짜, 주석을 가질 수 있습니다. document dbs에 대한 요점은, 모든 것을 문서 옆에 저장할 수 있고 관계형 DB에있는 모든 관계를 저장할 수 있다는 것입니다.

이것은 우리가 다음과 같이 우리의 게시물을 모델링 할 수있는, 의미

{type: post, 
date: 2012-06-19 22:14:23, 
author: user1462192, 
text: Welcome to my blog, 
comments: [ 
    {author: Aufziehvogel, 
    date: 2012-06-19 22:14:45, 
    text: Hello! 
    }, 
    {author: user1462192, 
    date: 2012-06-19 22:14:45, 
    text: Hello, too! 
    } 
], 
tags: [welcome, new, interesting] 
}

그래서 그 후이 같이 볼 수 있었다거야.

소프트웨어를 개발할 때 항상해야 할 일. 어떤 데이터를 저장할지 생각해보십시오. 그것이 어떻게 관련되어 있는지 생각해보십시오. 그리고 문서 지향 데이터베이스의 경우 액세스 방법에 대해 생각해야합니다.

너무 큰 데이터는 게시물 자체의 하위 요소로 저장하면 안되는 경우가 있습니다.

{name: Aufziehvogel, 
age: 21, 
registration: 2012-06-19, 
interests: [php, nosql, data-mining, foreign-languages] 
}

당신은이 데이터를 첨부 싶지 않을 것이다 : 아마 당신은 단지 저자의 이름뿐만 아니라 나이, 등록 날짜, 같은 자세한 내용은 ...

그런 다음 사용자가 다음과 같을 수 없어 블로그 게시물 중 일부는 변경 될 수 있으며 크기가 매우 크기 때문에 각 블로그 게시물에 적용됩니다. 대신 (관계형 DB와 마찬가지로) 포스트 데이터에서 사용자에 대한 참조를 저장합니다. 그런 다음 위에 링크 된 프리젠 테이션과 같이 저자와 블로그 게시물을 병합해야합니다 (40-42 페이지). 이렇게하면 필요한 작성자가 블로그 게시물과 병합됩니다.

당신이 할 수있는 일은 authorname과 ID를 저장하여 데이터베이스에서 "진짜"저자를 얻지 않고 이름을 표시하고 HTML 링크를 생성 할 수있게하는 것입니다. Zuelke도 보여줍니다 무엇

문서 중심의 DBS에 대한로 데이터가 잘 형성되어 있는지 여부를 확인하기 위해 응용 프로그램의 작업 점이다 검증

. MySQL에서는 데이터베이스 (컬럼, 데이터 타입, 길이, UNIQUE 키)로 많은 작업을 수행 할 수 있지만, 문서 지향 DB를 사용하는 경우에는 응용 프로그램에서 직접 수행해야합니다 (단, MongoDB는 고유 키).

이렇게하면 코드 구조가 중요해 지므로 너무 많은 곳에서 데이터 형식에 대해 걱정할 필요가 없습니다.

내가 더 많이 말했을 것 같지만, 이것이 첫 번째 출발이되기를 바랍니다.

출처

2012-06-19 20:30:27 Aufziehvogel

관련 문제

 관련 문제