2010-04-05 6 views
11

나는 페이스 북과 매우 유사한 기능을 가진 새로운 앱을 개발하는 중이며, 분명히 400000000000 명의 사용자가 좋아할만한 것을 여전히 사용하지는 않을 것이다. 실질적인 사용자 기반으로 운영되며 대다수는 매우 빠르게 실행되도록 요구합니다.소셜 네트워킹 앱을위한 MySQL 대신 Cassandra

저는 MySQL에 대한 폭 넓은 경험을 가지고 있지만 소셜 앱은 MySQL이 적합하지 않은 복잡성을 제공합니다. Facebook, Twitter 등은 많은 데이터를 위해 Cassandra로 옮겼지만 얼마나 멀리 갈지 확신하지 못합니다.

예를 들어 사용자 데이터 (예 : 사용자 이름, 비밀번호, 주소 등)를 Cassandra에 저장 하시겠습니까? 카산드라에 전자 메일, 의견, 상태 업데이트 등을 저장 하시겠습니까? 나는 또한 neo4j가 그래프 데이터베이스 인 것처럼 소셜 앱이 사용하는 친구 관계를 나타내는 데 훨씬 더 낫다는 것을 많이 읽었습니다. 나는 단지 NoSQL 경로를 시작하기 만하면 어떤 지침도 크게 감사 할 것입니다.

아무에게도 이것에 대해 조언 해 줄 수 있습니까? 나는 너무 일반적이지 않기를 바란다!

+0

neo4j는 샤딩을 지원하지 않으며 거대한 데이터에서 매우 낮은 성능을 보입니다. 우리는 그것을 테스트했습니다 –

답변

5

예를 들어 사용자 데이터 (예 : 사용자 이름, 비밀번호, 주소 등)를 Cassandra에 저장 하시겠습니까?

아니요, 일관성을 보장하지 않으므로 아니오입니다. 카산드라는 결국 이고 일관성은입니다. 분명히 특정 사용자 계정의 데이터에 동시성이 없어야하지만, 그것에 내기하고 싶지는 않습니다. 전체 텍스트 검색, 메시지받은 편지함 등에 일관성이 필요하지 않을 수도 있습니다.하지만 보안과 관련된 모든 것에 일관성을 원합니다. 나는 또한 neo4j 같은 뭔가 작정 읽고

는 그래프 데이터베이스입니다 소셜 앱에서 사용되는 친구 관계를 나타내는 훨씬 낫다.

저는 올바른 직업을위한 올바른 도구에 대한 큰 팬입니다. neo4j를 사용하지는 않았지만 db4o (객체 데이터베이스)를 사용하여 매우 유용했습니다. 기본적으로 사용자의 요구를 지원하는 도구를 사용하기 쉽게 개발합니다. 그래프가 필요하고 SQL에서 그래프로 작업하는 것이 고통 스럽기 때문에 한 번만보고 특정 요구 사항에 적합한 지 평가하는 것이 좋습니다.

데이터베이스를 믹싱하는 것은 당연한 선택입니다. 즉, 해당 데이터베이스는 특정 작업, 그래프 용 그래프 데이터베이스, 테이블 용 테이블, 트랜잭션이 필요한 모든 것에 대한 ACID 데이터베이스와 같이 자연 스럽다. 안전 등).

+8

RDBMS에서 쿼리하는 것이 더 쉽다는 사실 외에 카산드라에 모든 데이터를 저장하지 않을 이유가 없습니다. Cassandra는 원하는 경우 (정족수 읽기/쓰기) 일관성을 보장합니다 (http://spyced.blogspot.com/2010/04/cassandra-fact-vs-fiction.html 참조). 신뢰성에 대해 궁금한 점이 있으시면 http://thread.gmane.org/gmane.comp.db.cassandra.user/3454 –

+4

을 참조하십시오. 나는 이것에 대해 완전히 확신하지는 않지만 노드간에 일관성을 보장 할 수 있다고 이해했지만 배치 수준의 쓰기는 원자 적이지 않습니다. 그게 정말로 문제가된다면 두 번째 질문입니다.데이터의 종류는 RDBMS가 만든 것 뿐이라고 생각하지만 가용성/파티션 허용 오차에 관해서는 중요한 부분이 있으므로 특정 시나리오에서 사용자 데이터에 Cassandra를 사용하는 것이 좋습니다. – mnemosyn

1

님이 카산드라에게을 (를)로 이동 시켰습니다. 작성했습니다. :) 내 지식으로 noSQL DBMS는 을 필요로하지 않으며 (수정시 mnemosyn 덕분에 Facebook은 Oracle과 Cassandra를 사용함)은 관계형 데이터베이스와 나란히 실행됩니다. This은 반대의 예입니다 (사용자 정보를 noSQL DB에 저장).

나는 카산드라가 페이스 북을 위해 충분하다면 프로젝트에 충분할 것 같다. 퍼시스턴스 로직을 추상화하여 절대적으로 그럴 경우, 다른 것으로 전환 할 가능성을 가질 수 있습니다.

면책 조항 : noSQL 데이터베이스를 사용해 본 경험이 없습니까? 내가 아는 한 그것에 대한 정보가 있습니다.

+0

NoSQL은 매우 추상적 인 용어로, 일반적인 RDBMS와 기본적으로 동일한 보증 (예 : db4o)과 확장 성 데이터베이스를 포함하고있는 ACID 데이터베이스를 모두 포함합니다. 데이터 일관성과 관련하여 동일한 보증 세트 (예 : 카산드라)를 제공합니다. 이러한 속성은 의사 결정을위한 지침이어야합니다. 이런 종류의 논리를 추상화하는 것은 불가능합니다. 신뢰할 수있는 데이터와 신뢰할 수없는 데이터 간에는 상당한 차이가 있습니다. 트랜잭션이 의미가 없을 수도 있습니다. – mnemosyn

+0

어떤 종류의 논리를 추상화합니까? ACID 거래? DB는 그들을 지원하거나 지원하지 않습니다. DAO 계층 위의 응용 프로그램 부분이 (다른 DB로 이동하여) DAO 구현이 변경되면 다소 손상되지 않도록 데이터베이스 위의 얇은 DAO 계층입니다. Christopher는 프로젝트를 "Facebook과 매우 비슷한 기능"이라고 설명했기 때문에 Christopher가 Facebook이 사용하는 데이터베이스와 다른 데이터베이스를 사용하는 것이 더 좋을 것이라고 밝혀지면 매우 독특 할 것입니다. –

+0

Facebook은 하나의 데이터베이스를 사용하지 않습니다. 그들은 (최소한) Oracle, Cassandra 및 Hadoop을 병렬로 사용합니다. Cassandra는 결제 세부 정보를 저장하지 않고 페이스 북에서받은 편지함을 검색하기 위해 개발되었습니다. 동일한 추상화를 다른 것에 적용 할 수는 없습니다. 즉, 데이터 저장소에 하나의 DAO를 사용하고 일관성있는 데이터 저장소 하나만 사용하십시오. – mnemosyn

4

MySQL과 Cassandra를 사용하여 몇 가지 테스트를 수행 할 것을 제안합니다. PostgreSQL과 MongoDB 중 하나를 선택해야 할 때 우리는 수백만 레코드의 쿼리 시간을 비교하여 약 10M 레코드에서 적절한 응답 시간을 제공한다는 것을 알았습니다.

우리는 적어도 2 년 동안 그 레코드 수에 도달하지 않을 것이며 우리는 Postgres에 대한 경험이 있었지만 (MongoDB는 당시에는 성숙하지 않았지만) Postgres와 함께갔습니다.

필자가 지적한 점은 MySQL 벤치 마크를보고, 성능 테스트를하고, 데이터 세트의 크기를 예측하고, 성장할 방법을 결정하고, 정보에 입각 한 결정을 내릴 수 있다는 것입니다.

관계형 데이터베이스와 비 관계형 데이터베이스를 혼합하는 경우에도 고려해야 할 사항이지만, 두 가지 종류의 소프트웨어를 유지하고 꽤 많은 양의 접착제를 작성하는 것은 너무 번거롭다 고 판단했습니다. 코드에서 데이터를 가져올 수 있습니다. 나는 카산드라가 당신의 모든 데이터를 완벽하게 저장할 수있을 것이라고 생각합니다.

0

카산드라는 좋은 분산 솔루션을 제공하며, MySQL과 비교하면 페이스 북과 같은 플랫폼에 더 적합 할 수 있습니다 (규모가 필요할 경우). 그러나 카산드라는 다 대다 관계에 도전해야하는 데이터 관계에 적합하지 않습니다. Cassandra와 연결된 그래프 데이터베이스는 대용량 볼륨 요구와 함께 매우 빠른 관계 쿼리 기능을 제공합니다. 우리는 두 기술을 결합하여 플랫폼이 제시하는 요구 사항 유형에 항상 관심이있는 것에 중점을두고 있습니다. 특정 데이터 관련 문제를 처리하는 방법에 대해 궁금한 점이 있으시면 해당 내용을 듣고 싶습니다. 아마도 도움이 될 것입니다.

+2

저는 카산드라가 다 대다 관계를 잘 표현하지 못한다는 당신의 주장에 강력히 동의합니다. 카산드라에서 이와 같은 문제를 해결하려면 양방향에서 모든 관계에 대한 색인을 저장하면됩니다. 예를 들어, 사용자 A와 같은 사용자 간의 관계를 사용자 B의 뒤에 저장해야하는 경우 팔로 잉 및 팔로어와 같은 열 패밀리를 만들 수 있습니다. 각 CF의 키는 사용자 ID이며, 각 행은 그 세트의 사용자 ID 당 하나의 열만 갖습니다. 여전히 이러한 관계를 저장할 수 있으며 미리보기를 저장해야합니다. –

관련 문제