데이터베이스 질문 : 간단한 관계형 테이블을 비 관계형으로 변경합니까?
https://stackoverflow.com/questions/938751
-
06-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
MySQL 데이터베이스 (개발 중)를 통한 웹 응용 프로그램이 있습니다. 응용 프로그램을 Google App Engine으로 마이그레이션하는 것을 고려하고 있으며 간단한 관계형 데이터베이스 모델을 비 관계형 접근 방식으로 어떻게 전환 할 수 있는지 더 잘 이해하고 싶습니다.
저는 오랜 시간 관계 데이터베이스 사람이며 BigTable과 같은 열 기반 DBS에 대한 경험이 없습니다. Google이 관계형 데이터베이스의 소규모 배포를 지원하는 경우, 내 질문이 일반적이고 Google에만 국한되지 않는다고 말하고 싶습니다. 간단한 관계형 모델이 비 관계형 DBS로 어떻게 표현 될 수 있는지 이해하고 싶습니다.
내 데이터베이스 (단순화)는 다음과 같습니다.
Items Table
------------
ItemID ItemName ItemPriority
1 "Car" 7
2 "Table" 2
3 "Desk" 7
ItemProperties Table
---------------------
ItemID Property Importance
1 "Blue" 1
1 "Four Wheels" 2
1 "Sedan" 0
2 "Rectangular" 1
2 "One Leg" 1
나는 각각 이름과 ID가있는 많은 항목이 있습니다. 각 항목에는 여러 속성이 있으며 각 속성에는 여러 매개 변수가 있습니다 (각 속성의 이름과 "중요성"만 언급했지만 더 많은 것이 있습니다). 나는 수천만 개의 품목을 가지고 있으며 각각 수백 개의 속성이 있습니다.
사용 시나리오 : ItemName을 입력으로 받고 항목 테이블에서 ID를 찾아 모든 속성을 해당 ID로 가져옵니다. 그런 다음 속성 목록 (메모리)에 대한 분석을 수행하고 결과를 반환합니다.
작업의 90%는 매개 변수를 기반으로 한 조회입니다.
권장 접근법은 무엇입니까?
해결책
비 관계형 DB와 함께 일한 사람으로부터 두 테이블이 비 임대 DB로 번역하기가 정말 쉽습니다.
두 테이블을 가져 와서 단일 객체로 바꿉니다.
항목 : - id- 이름 - 속성 -Prop1 -Prop2
모든 것을 데이터 스토어 열 (big-table), 문서 (couchDB) 또는 그 밖에 사용하는 모든 것을 저장하십시오.
ID, 이름 또는 속성으로 항목을 찾을 수 있습니다. 비 관계형 DBS의 더 큰 통증 중 하나 인 결합은 없습니다. 당신이 의미하는 바를 이해하지 못한다면 매개 변수 조회는 실제로 고통스러운 점이 아닙니다. 여러 번 조회해야 할 수도 있지만 대부분의 경우 문제가되지 않으며 RDBMS보다 더 잘 확장됩니다.
귀하의 예에서는 실제로 비 관계형 모델을 더 간단하고 구현하고 이해하기 쉽다고 생각합니다.
각 비 관계형 데이터 저장소에는 다른 규칙과 제약이 있지만 일반적인 의미에서 지침을 제공하는 것은 어렵습니다. CouchDB는 예를 들어 뷰와 함께 객체의 모든 부분에 인덱스를 생성 할 수 있습니다. BigTable을 사용하면 빠른 인덱스 조회를 얻으려면 탈피 된 데이터의 여러 사본을 저장해야 할 수도 있습니다. 다른 사람들은 데이터를 저장하는 방법을 결정할 때 고려해야 할 사항이 있습니다. SQL의 세계를 떠나면 많은 차별화가 있습니다.
다른 팁
GQL은 조인을 지원하지 않습니다. 두 가지 방법 으로이 문제를 해결할 수 있습니다.
- 직접 가입하십시오
항목을 가져오고 ItemId를 확인하고 해당 itemID로 ItemProperties에 대한 쿼리를 확인하십시오. 당신의 테이블은 당신이 지정한 것처럼 보일 것입니다. 물론 이것은 두 쿼리이지만 두 쿼리는 간단합니다.
- Expando 모델을 사용하십시오
Expando 모델에서는 런타임에 새 필드를 만들 수 있습니다. 그것들은 색인화되지 않기 때문에 검색하고 싶다면 느리게 될 수 있지만 단순히 가져 오는 것은 괜찮습니다. ListProperty와 같은 복잡한 유형도 사용할 수 있습니다. 이런 종류의 유연성을 통해 ItemProperties 테이블의 모든 것을 항목 테이블에 넣고 쿼리를 저장하는 방법을 생각할 수 있습니다. 창의적입니다.
매우 유사한 데이터베이스 구조 ( "레코드"및 "레코드 엔트리"테이블은 귀하의 "항목"및 "ItemProperties"를 미러링)를 가지고 있으며 비 관계형 데이터베이스와 유사한 마이그레이션을 고려하고 있습니다. 우리는 아마도 Google이 아닌 CouchDB 또는 MemcachedB 또는 그와 비슷한 것을 방문 할 것입니다.
당신처럼 나는 비 관계형 데이터베이스를 사용한 경험이 없습니다 (내 개발자도 마찬가지입니다). 그러나 우리는 몇 가지 아이디어를 던졌습니다. 현재의 생각은 (스키마 사용)입니다.
- 첫째 : 각 항목과 항목 속성을 필드 (본질적으로 XML 문서)가있는 하나의 객체로 붕괴시키고 식별자가 키워진 데이터베이스에 넣습니다. 항목을 검색 할 때마다 모든 ItemProperties도 되돌아갑니다.
우리가 가진 차이점은 데이터베이스 외부 (SOLR) 외부에 컨텐츠를 색인하므로 "이름"속성이므로 ymmv를 사용하여 데이터베이스 자체에서 조회를 할 필요가 없다는 것입니다.
- 둘째 : 위의 모델에서 지원할 수없는 모든 "관계형"운영에서 목록을 작성하고 있습니다. 여기에는 아이템 테이블의 특수 필드를 기반으로 항목을 쿼리하는 몇 가지 "그룹화"작업과 최근에 수정 된 모든 항목 (이전에 날짜 열에서 쿼리에 의해 달성 된 모든 항목을 감지하려는 쿼리가 포함됩니다. 항목 테이블). 우리는 이러한 각 사례에 대한 대체 구현을 발명하고 있습니다 (운 좋게도 몇 가지만 있습니다).
이것이 너무 어려워지면 다른 모델로 동일한 운동을 시도 할 것입니다. 운 좋게도 우리는 계획 할 시간이 있습니다.
우리의 핵심 요점 중 하나는 우리가 Solr로 외부 인덱싱을 수행하므로 (예를 들어) itemproperties 값의 값에 대한 데이터베이스 조회를 수행하거나 항목 테이블에서 이름으로 조회를 수행 할 필요가 없다는 것입니다.
어쨌든, 그것은 아마도 큰 도움이되지는 않지만, 경험이 많은 사람들이 어떤 종류의 솔루션을 생각해 낼 수 있는지보고 싶어합니다.
추신 : 귀하의 속성 테이블에는 수십억 행이 있어야합니다. MySQL 서버를 정확히 얼마나 정확히, 어떤 하드웨어를 실행하고 있습니까? MySQL에 아직 확장 성 문제가 있습니까?
당신은 그것을 모두 평평하게해야합니다. Appengine은 다음과 같은 구조물을 허용한다고 생각합니다.
id = 1, itemname = car, itempriority = 7, property = (blue, 1), property = (4 휠, 2), property = (세단, 0) id = 2, itemname = table, itempriority = 2, property = (직사각형, 1), Property = (한쪽 다리, 1) ID = 3, ItemName = Desk, ItemPriority = 7
동일한 "필드"는 여러 값을 가질 수 있으며 여러 항목을 사용할 수 있습니다.
샘플 데이터는 한 테이블에서 3 행입니다.
