분산 키/값 저장소의 ORM과 동일합니까?

Question

백 엔드 용 분산 키/값 저장소를 사용하여 구현하는 방법을 평가하는 중입니다. 개체/관계형 매퍼에서 얻을 수있는 것과 비슷한 개체 모델을 지원하는 키/값 위에 레이어를 갖고 싶습니다.

누구든지이 일을하는 다른 사람들의 사례를 통해 나를 지적 할 수 있습니까? 나는 대부분 디자인 아이디어를 찾고 있는데, 내가 충분히 좋아하는 것을 가로 지르면, 나는 내 자신의 글을 쓰는 대신 그것을 사용할지도 모른다. 나는 아마도 Riak 위에 Perl에서 구현하는 것을 끝낼 것이지만, 그러한 결정은 최종적인 것이 아니다.

Answer 1

이전에 Riak을 사용하여 AciveModel 인터페이스를 노출하는 Ruby 클라이언트 리플을 사용하여 비슷한 작업을 수행했습니다. 그러나, 나는 그것을 (다른 사람들이 가지고있는 것처럼) 정말로 반대해야한다. 키/밸류 스토어 위에 무거운 ORM을 사용하면 속도가 빨라진다.

이제 Ripple을 건너 뛰고 Riak과 직접 대화하여 속도에 민감한 많은 작업을 수행합니다 (우리는 Erlang으로 이동하여 HTTP 인터페이스 대신 PBC를 사용하지만 다른 이야기 : D). 우리는 그것을한다 :

• 우리의 객체에서 우리는 리플 호환 형식으로 JSON 문서를 저장한다. 우리가 여전히 Ripple을 사용하는 것과 같은 몇 가지 요구 사항이 있지만 Ripple없이이 작업을 다시 수행하려면이 형식을 사용하는 것이 좋습니다.

• Riak 링크를 사용하여 개체를 함께 조인하고 외래 키를 문서 자체에 저장하지 마십시오. 개체에 저장할 수있는 링크의 수에는 제한이 있으므로 사용자 개체에 너무 미칠 수 없습니다 (예 : 사용자 개체의 각 설명에 대한 링크 저장).

• Ripple (및 Riak)은 인덱스를 지원하지 않으므로 자체 솔루션을 사용해야했습니다. 예를 들어 무작위로 생성 된 키가있는 사용자 객체를 '사용자'버킷에 'fen2nf4j9fecd'로 저장합니다. 'users'버킷의 객체에 대한 Riak 링크가있는 'users_index_by_username'버킷에 'tom'키가있는 객체를 저장합니다. 이렇게하면 사용자 이름이 'tom'인 사용자를 쉽게 찾을 수 있습니다.

key filtering을 살펴볼 수도 있습니다. 나는 아직 그걸 가지고 놀지 않았지만, 나는 꽤 잘 보이는 성능 수치를 보았다. Riak은 구현 방식에 따라 버킷의 키를 나열하지 않도록 Riak에주의해야합니다. Riak은 버킷의 키가 아닌 모든 키를 검색합니다.

Riak은 꽤 짐승이지만 일단 주위를 둘러 보면 머리가 좋아질 것입니다. 복제는 어려우며 '효과가 있습니다'.

Answer 2

이 경우 레이어가 많이 필요한 것은 아닙니다.

피트를위한 키/값 저장소입니다. 입력 한 개체와 백 엔드의 개체간에 변환 할 수있는 모든 serialization 메커니즘을 사용하십시오. 그 밖의 무엇을 할 것입니까?

ORM은 한 쪽에서 관계형 모델을 다루기 때문에 훨씬 더 복잡합니다. 키 값 저장소는 그렇지 않습니다.