이벤트 / 활동 데이터에 관계형 데이터베이스 대 JSON 객체 사용


28

표준 SQL 관계형 데이터베이스 또는 JSON 객체를 사용하여 이벤트 또는 활동에 대한 데이터를 저장하도록 결정하려는 프로젝트를 진행 중입니다.

프로젝트는 여러 이벤트 유형에 데이터를 저장하므로이 질문에 대해 하나의 이벤트 유형 만 설명하기로 결정했습니다.

라이브 음악 이벤트 (이 질문의 맨 아래에 JSON 스키마를 사용하여 전체 설명)는 이벤트가 발생하는 위치, 이벤트 시간 / 날짜 및 이벤트 비용과 같은 데이터를 저장하는 객체입니다. 라이브 음악 이벤트 오브젝트에는 일대일 (이벤트-> 이름, 이벤트-> 설명) 및 일대 다 (이벤트-> 장소, 이벤트-> 날짜, 이벤트-> 티켓 유형이 있습니다. ) 관계. 또한, 이벤트 오브젝트는 하나 이상의 수행자 ID를 포함 할 수 있으며, 이는 수행자 오브젝트에 링크됩니다. 퍼포머 오브젝트는 라이브 음악 이벤트에서 연주하는 음악가에 대한 데이터를 저장합니다.

사용자는 단순 ( 'x'이름의 이벤트 찾기 ') 및 복잡한 ('x '음악 장르의 이벤트 찾기 및 현재'z '반경 내에서'y '비용을 사용하여 사용자가 데이터를 쿼리합니다. location ") 검색어 웹 양식을 사용하여 사용자가 데이터를 제출합니다.

정의 된 JSON 스키마에서 알 수 있듯이 원래 JSON 객체를 사용 하여이 데이터를 저장하려고했지만 내 데이터가 순전히 관계형이기 때문에 이전 메소드를 고수해야한다고 말하는 사람들로부터 들었습니다.

내 필요에 따라 각 접근 방식의 장단점에 대한 의견을 보내주십시오. 명확한 내용이 필요하면 언제든지 문의하십시오.

{
    "event": {
        "eventID":{
            "type":"string"
        },  
        "eventType":{
            "type":"array",
            "eventTypeItem":{
                "type":"string"
            }
        },
        "eventName":{
            "type":"string"
        },      
        "eventDescription":{
            "type":"string"
        },
        "eventVenueList":{
            "type":"array",
            "eventVenueListID":{
                "type":"integer"
            }
        },
        "eventURL":{
            "type":"string"
        },
        "eventTwitter":{
            "type":"string"
        },
        "eventFB":{
            "type":"string"
        },
        "eventInstagram":{
            "type":"string"
        },
        "eventEmail":{
            "type":"string",
            "format":"email"
        },
        "eventContactPerson":{
            "type":"string"
        },
        "eventDoorTime": {
            "type":"string",
            "format":"date-time"
        },  
        "eventPerformerIDList":{
            "type":"array",
            "liveMusicPerformerID":{
                "type":"integer"
            }
        },  
        "eventSetList":{
            "type":"array",
            "eventPerformerID":{
                "type":"integer"
            },
            "eventPerformerStartTime":{
                "type":"string",
                "format":"date-time"
            },
            "eventPerformerEndTime":{
                "type":"string",
                "format":"date-time"
            }                                   
        },
        "eventDateList": {
            "type":"array",
            "eventDateItem": {
                "type":"string",
                "format":"date-time"
            }   
        },
        "eventDateStartTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventDateEndTime": {
            "type":"string",
            "format":"date-time"
        },
        "eventTicket":{ 
            "type":"array",
            "eventTicketType":{
                "type":"string" 
            },
            "eventTicketLowPrice":{
                "type":"number"
            },
            "eventTicketHighPrice":{
                "type":"number" 
            },
            "eventDatesAdvancePrice": {
                "type":"number"
            }   
        }
    },  
    "performer": {
        "performerID": {
            "type":"integer"
        },
        "performerType": {
            "type":"string"
        },
        "performerName": {
            "type":"string"
        },
        "performerAlternateName": {
            "type":"array",
            "performerAlterateNameItem":{
                "type":"string"
            }
        },
        "performerGenreList": {
            "type":"array",
            "performerGenreItem":{
                "type":"string"
            }
        },
        "performerURL": {
            "type":"string"
        }                                       
    }
}   

사이트 요구 사항을 모르지만 공연자, ​​장소 및 날짜별로 검색하고 싶습니다. 배열 유형으로 유지되기 때문에 이것이 문제가됩니까?
JeffO

관련 배열에서 값을 검색하도록 쿼리를 프로그래밍 할 수 없습니까?
zgall1

13
JSON은 스토리지 형식이 아닙니다. 사실, 텍스트 파일을 사용하여 데이터를 저장할 수 있지만 가장 간단한 시나리오에서만 가능합니다. 관계형 데이터베이스보다 "최신"인 JSON은 의사 결정과 관련이 없습니다.
Robert Harvey

1
스토리지 형식이 아니라는 것을 알고 있습니다. MongoDB 또는 Postgre의 JSON 객체를 사용하여 JSON 형식으로 데이터를 저장할 수 있음을 의미했습니다.
zgall1

2
@RobertHarvey와 유권자, 요즘 (2017) JSON 상점 형식입니다 : PostgreSQL 9.6 이상 ... ~ 2012 년부터 기본, 2015 년 마지막부터 전문적이고 성숙함 (JSONb 데이터 유형).
피터 크라우스

답변:


45

귀하의 질문은 실제로 다음과 같이 요약됩니다. NoDB 접근 방식과 RDBMS를 언제 사용해야합니까? 아마도 Ajax 소비자가 있기 때문에 JSON (NoSQL-ish 결정)에 일찍 정착했습니다.

NoSQL 접근 방식과 RDBMS의 사용시기에 대한 대답은 기본적으로 작업중인 데이터 유형과 예상 소비자에 관한 것입니다. 데이터가 본질적으로 관계가있는 경우 (공평한 계층 구조, 이미지 또는 오디오와 같은 이상한 데이터 유형이없고 키로 쉽게 설명 할 수있는 스키마 간의 예측 가능한 관계) 소비자는 결국 비즈니스 인텔리전스 쿼리를 수행하려는 사람을 포함 할 것으로 예상됩니다 그런 다음 RDBMS를 사용하는 것이 좋습니다. 쿼리를 JSON 표현으로 변환하는 것은 매우 쉽습니다. 따라서 Ajax 소비자에게는 큰 부담이되지 않습니다. 엔드 포인트 (REST / SOAP / 무엇이든)에 약간의 변환 코딩 만 추가하면됩니다. 거꾸로데이터가 매우 계층 적 (심층 스키마)이고 이미지, 오디오, 비디오 등과 같은 이상한 데이터 유형을 포함하는 경우 엔터티간에 관계가 거의 없으며 최종 사용자가 BI를 수행하지 않을 것임을 알면 NoSQL / storing JSON이 적절할 수 있습니다.

물론 이러한 일반적인 지침조차 확실하지 않습니다. 그 이유 구글은 구글 파일 시스템, 맵리 듀스 (일 야후 하둡을 구축 더그 커팅에 의해 사용되었다)을 개발 하고 정확하게했다 나중에 BigQuery에 (대규모 데이터를 관리하는 NoSQL의 중심 [스키마] 방식) 때문에 그들이 임시 많이했다을 BI는 요청했으며 관리하려는 tera / peta / exa / zetta / yotta 스케일로 확장하기위한 관계형 접근 방식을 얻을 수 없었습니다. RDBMS가 제공하는 임시 쿼리 사용자 친 화성을 희생하고 특정 쿼리에 대해 상당히 쉽게 코딩 할 수있는 간단한 알고리즘 (MapReduce)을 대체하여 실용적으로 접근 할 수있었습니다.

위의 스키마를 고려할 때 기본적으로 내 질문은 다음과 같습니다. 왜 RDBMS를 사용 하지 않습니까? 나는하지 않는 많은 이유를 보지 못합니다. 우리의 직업은 패션 중심이 아닌 공학 중심이어야하는데, 본능은 가장 효과적인 솔루션을 선택해야합니까? 소비자가 Ajaxy 인 경우 엔드 포인트가 약간의 번역을 수행해야하지만 데이터가 매우 평평 해 보이고 비즈니스 사용자가 음악 이벤트와 같은 항목에 대해 모든 종류의 임시 쿼리를 수행하려고 할 것 같습니다 ( 작년에 수도에서 50 마일 이내에 가장 많이 참석 한 이벤트?)

'그들에게 조언을 구하지 마십시오. 그들은'아니요 '라고 말할 것입니다.' -프로도


"우리의 직업은 패션 지향이 아닌 엔지니어링 지향적이어야하므로 본능은 최고의 선택입니다." ;)
Bink

5

나는 당신이 찾고 있지 않을 수도있는 더 많은 고려 사항이 있다고 생각합니다. 여기에는 두 가지 광범위한 관심사가 있습니다.

  • 저장
  • 검색 및 검색

저장

데이터에 no-sql 또는 RDBMS 저장소를 사용하는 이유에 대한 많은 의견이 있습니다. 우리가 유용하다고 생각한 가장 중요한 항목 중 하나는 json 객체를 전체 구조 또는 다른 유형의 객체 간의 관계 정의에 대해 걱정할 필요없이 스토리지에 쉽게 정의하고 저장할 수 있다는 것입니다. NoSql DB를 사용하는 다른 이유 중 일부는 자동 샤드 데이터, 위치 기반 검색 및 손쉬운 유지 관리 기능입니다. 좋은 NoSql 데이터베이스가 많이 있으며 개인적 선호는 MongoDB입니다. 그러나 이전에 NoSql 데이터베이스를 사용해 본 적이 없다면 마음을 다시 연결하는 법을 배우면서 명확한 학습 곡선이 있습니다. 우리 대부분은 지금까지 RDBMS를 사용해 왔으며 그 습관을 벗어나려면 의식적인 노력이 필요합니다. 또한 노력을 기울이고 개념을 더 잘 이해하면서 데이터 모델을 다시 만들고자합니다. 리팩토링 또는 리모델링 기능이 프로젝트의 옵션이 아닌 경우 이미 알고있는 것을 고수하는 것이 좋습니다.

수색

사용할 수있는 모든 종류의 검색을 제공하려면 SOLR 과 같은 전용 텍스트 검색 엔진 을 사용하여 검색을 수행 하는 것이 좋습니다 . 텍스트 검색 속도가 느리고 샤드가 여러 개인 경우 훨씬 느려집니다. SOLR은 가중 검색 매개 변수, 위치 기반 검색 등을 포함한 빠른 텍스트 검색을 지원합니다. 그러나 SOLR은 데이터의 기본 저장소로 적합하지 않습니다. 이것은 이벤트를 추가하거나 업데이트 할 때 기본 데이터베이스와 SOLR 계층 모두에 이중 삽입 및 업데이트를위한 메커니즘을 작성해야 함을 의미합니다. 또한 오래되거나 종료 된 이벤트를 제거하여 나중에 SOLR을 업데이트해야합니다.

이것은 많은 추가 작업처럼 보이지만 나중에 전체 텍스트 검색 엔진을 사용하는 것에 대한 예측에 감사드립니다. NoSql 데이터베이스 나 RDBMS는 SOLR / Lucene의 성능과 민첩성에 근접하지 않습니다.


3

첫째, NoSQL 데이터베이스가 아닌 모든 스토리지에 JSON 데이터 를 저장 하려는 경우 JSON 을 사용하지 않는 것이 좋습니다. 예를 들어 데이터를 JSON 파일로 저장하면 데이터를 열거 나 구문 분석하고 반복하는 등의 작업이 매우 느리기 때문입니다.

우선, 귀하의 질문을 다음 과 같이 좁힐 수 있습니다 : NoSQLRDBMS의 장단점은 무엇입니까 ? 그리고 그것은 이미 인터넷에서 수천 번 응답되었습니다.

프로젝트를 업그레이드하면 물론 NoSQL 또는 RDBMS를 사용할 수 있습니다 . 그러나 일반적으로 당신에게 권장 할 수있는 것은 상자 밖으로 생각하고 두 가지 옵션 중에서 결정하는 데 도움이되는 다른 눈에 잘 띄지 않는 요소를 찾는 것입니다. 어떤 옵션이 개발 속도를 높일 수 있는지 알아 보시겠습니까? 단독 개발자가 아닌 경우 다른 팀 구성원에게 더 적합합니다. 이 제품을 판매하는 경우 개발자가 아닌 고객에게 더 저렴하고 쉽고 일반적으로 더 적합한 제품은 무엇입니까?

이 방법으로 최종적으로 어떤 방법을 결정할 수 있습니다.


2

대부분의 응용 프로그램에는 다음 요구 사항이 있습니다.

  1. 입력 데이터, 일부 처리 수행, 데이터 저장, 데이터 검색 및 쿼리. 데이터에 대한 보고서를 생성해야 할 수도 있습니다.
  2. 시스템의 다른 부분 간 또는 외부 시스템과 데이터 교환

항목 1에 대한 요구 사항을 달성하려면 데이터 지속 방법이 필요합니다. 일반적으로 데이터 볼륨이 매우 작고 데이터 유형이 단순하고 광범위한 검색 기능이 필요하지 않은 경우 간단한 파일 구조를 사용할 수 있습니다. 데이터가 복잡 해짐에 따라 파일에 저장된 데이터와 함께 XML (또는 JSON) 구조를 사용할 수 있습니다. 그러나 검색은 더욱 문제가됩니다. 데이터의 양이 증가하고 검색의 복잡성이 증가함에 따라 데이터 지속성, 쿼리 등을위한 산업 표준 방법을 제공하는 데이터베이스가 일반적으로 선택됩니다. 데이터베이스는 대량의 데이터를 처리하고 데이터를 빠르고 효율적으로 저장, 검색 및 검색하도록 설계 될 수 있습니다. .

항목 2에 대한 요구 사항을 달성하기 위해 XML, JSON 등을 포함한 시스템간에 데이터 교환을 허용하는 다양한 방법이 있습니다.

이들 방법은 데이터 구조가 사용자에 의해 정의 될 수있게하며, 언어에 독립적이므로 다른 시스템이 데이터를 교환 할 수있게한다.

특별한 경우 JSON을 올바르게 사용하고 있으며 일련의 음악 이벤트를 설명합니다. 음악 이벤트 수가 증가함에 따라이 데이터를 검색하여 JSON 형식으로 데이터를 저장할 수는 있지만 속도가 느리고 비효율적입니다.

우려 분리 접근법을 사용하면 데이터를 수집하고 데이터베이스에 저장하며 데이터베이스의 사용자 입력을 기반으로 쿼리를 수행 한 다음 JSON 형식의 결과를 클라이언트 측에 반환하여 데이터를 표시하는 것이 더 좋습니다.

JSON 접근 방식의 추가 문제는 데이터 구조 변경입니다. 현재 귀하의 구조는 비교적 간단합니다. 이 구조를 몇 개월 동안 사용하면 추가 필드가 식별됩니다. 그런 다음 기존의 모든 JSON 객체로 무엇을합니까? 이것들을 업데이트하는 것은 문제가 될 것입니다.

데이터베이스를 사용한 경우 추가 필드를 추가하는 것은 비교적 간단하며 JSON을 생성하기위한 코드 만 한 곳에서 수정하면 새 필드가있는 모든 새 JSON이 제공됩니다.

간단히 말해 각 기술은 데이터 교환을위한 JSON 및 데이터 지속성을위한 데이터베이스 용으로 설계된 것입니다.


0

나는 당신이해야 할 쿼리 때문에이 데이터를 저장하기 위해 SQL보다 NoSQL을 사용하는 것이 더 좋을 것이라고 생각합니다.

또한 일부 데이터가 순전히 관계형이라고해서 더 이상 RDBMS (SQL)에 유지되어야한다는 의미는 아닙니다. IMO 관계형 데이터는 그래프 데이터베이스로 더 잘 변환됩니다.

물론 쿼리를 SQL로 작성할 수도 있지만 필요한 조인 수로 인해 성능이 끔찍합니다 (데이터가 어느 정도 표준화되어 하나의 이벤트 테이블에있는 것은 아님).

그러나 결론적으로 이미 지속 된 데이터를 고려하지 않고 스키마를 수정할 수 있다는 점을 고려하여 NoSQL (따라서 JSON 또는 데이터베이스에서 지원하는 다른 형식)을 사용하면 더 많은 자유를 얻게됩니다.

NoSQL을 고려할 때 매우 복잡한 쿼리를 사용하려는 경우 그래프 데이터베이스를 살펴볼 수 있습니다. 쿼리를 쉽게 만들고 빠르게 실행할 수있는 이점이 있기 때문입니다.


0

나는 당신이 두 가지를 모두 사용해야한다고 생각하며 그것을 '대'결정으로 보지 않습니다.

관계형 데이터베이스는 관계형 속성이있는 데이터를 빠르고 효율적으로 저장하고 검색하는 데 적합합니다.

JSON은 단순하고 가벼우 며 텍스트 정보를 저장하고 교환하는 데 적합한 구문을 사용하여 원시 데이터를 매우 기본적인 형식으로 전달하는 데 이상적이므로 훌륭한 데이터 형식입니다. 브라우저와 서버간에 적은 양의 데이터를 전달하는 데 좋습니다. 관계형 데이터 쿼리에 사용하기 쉬운 형식이 아닙니다.

따라서 데이터 저장소에는 SQL을, 데이터 전송 형식에는 JSON을 권장합니다.

Mongo, Redis 등과 같은 SQL 키-값 옵션이 없다는 것은 사실입니다. JSON 형식에 대한 매핑이 더 간단 할 수 있지만 일반적으로 쿼리에 사용하기가 조금 더 어렵습니다. 이들의 주요 장애물은 특히 잘 알려져 있고 상상할 수있는 거의 모든 상황에 사용할 수있는 방대한 자원과 지식이없는 SQL과 비교할 때 일반 IT 커뮤니티에 익숙하지 않다는 것입니다.


쿼리에서 noSQL 키-값 저장 방법을 사용하는 방법에 대해 잘 알고있는 프로그래머를 찾으려면 JSON을 데이터 저장 형식으로 사용하여 극복하는 것이 가장 어려운 과제라고 생각하십니까?
zgall1

나는 단지 데이터 구조가 열악하고 평균보다 열악하기 때문에 그럴 것이라고 확신합니다. 개발자는 관계형 데이터베이스라는 것을 알고 있습니다. 이것은 개발자의 평균 품질과 학습을 피하는 방법에 관한 것입니다 .NoSQL은 비 관계형 데이터에 적합한 선택입니다 ... 실제로 데이터가 실제로 아닌 것으로 가정하면 실제로는 개발자에게 더 간단합니다. 관계형. 그러나 DB를 올바르게 선택해야합니다. NoSQL은 초기 선택을하거나 깨뜨립니다.
JM Becker
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.