MySQL에서 Cassandra로 전환-장점 / 단점?

MySQL에서 Cassandra로 전환-장점 / 단점?

---

약간의 배경 지식을 위해이 질문은 단일 소규모 EC2 인스턴스에서 실행되는 프로젝트를 다루며 중간 인스턴스로 마이그레이션하려고합니다. 주요 구성 요소는 Django, MySQL 및 Python 및 Java로 작성된 수많은 사용자 지정 분석 도구로,이 도구는 무거운 작업을 수행합니다. 동일한 시스템에서 Apache도 실행됩니다.

데이터 모델은 다음과 같습니다. 많은 양의 실시간 데이터가 다양한 네트워크 센서에서 스트리밍되며, 이상적으로는 15 분마다 현재 폴링 방식보다 긴 폴링 방식을 설정하고 싶습니다. 통계를 계산하고 데이터베이스 자체에 쓰기). 데이터가 들어 오면 원시 버전을 MySQL에 저장하고 분석 도구가이 데이터에 대해 느슨하게하고 통계를 다른 테이블에 저장합니다. 이 모든 것은 Django를 사용하여 렌더링됩니다.

내가 필요한 관계형 기능-

• Order by [Cassandra의 API에서 SliceRange가 만족하는 것 같습니다.]
• 그룹화
• 여러 테이블 간의 Manytomany 관계 [Cassandra SuperColumns는 일대 다에 대해 잘 작동하는 것 같습니다.]
• 이것에 대한 스핑크스는 나에게 멋진 전체 텍스트 엔진을 제공하므로 그것도 필요합니다. [Cassandra에서 Lucandra 프로젝트는 이러한 요구를 충족하는 것 같습니다.]

내 주요 문제는 데이터 읽기가 매우 느리고 쓰기도 그렇게 뜨겁지 않다는 것입니다. 지금 당장은 많은 돈과 하드웨어를 투자하고 싶지 않으며 시간이 지남에 따라 쉽게 확장 할 수있는 것을 선호합니다. MySQL을 수직 확장하는 것은 그런 의미에서 사소한 것이 아닙니다 (또는 저렴합니다).

그래서 본질적으로 NOSQL에 대해 많이 읽고 MongoDB, Cassandra 및 Voldemort와 같은 것을 실험 한 후 제 질문은 다음과 같습니다.

• 중형 EC2 인스턴스에서 Cassandra와 같은 것으로 전환하여 읽기 / 쓰기의 이점을 얻을 수 있습니까? 이 기사 (pdf)는 확실히 그것을 암시하는 것 같습니다. 현재는 분당 수백 개의 쓰기가 표준이라고 말하고 싶습니다. 읽기의 경우-데이터가 약 5 분마다 변경되므로 캐시 무효화가 매우 빠르게 발생해야합니다. 어느 시점에서 많은 동시 사용자도 처리 할 수 ​​있어야합니다. 인덱스가 생성 된 경우에도 대규모 테이블에서 일부 조인을 수행하면 현재 MySQL에서 앱 성능이 저하됩니다. 32k 행 정도의 항목은 렌더링하는 데 1 분 이상 걸립니다. (이것은 EC2 가상화 I / O의 아티팩트 일 수도 있습니다.) 테이블 크기는 약 4 ~ 5 백만 행이며 약 5 개의 테이블이 있습니다.

• 모든 사람들은 CAP 정리와 최종 일관성을 고려할 때 여러 노드에서 Cassandra를 사용하는 것에 대해 이야기합니다. 그러나 막 성장하기 시작한 프로젝트의 경우 단일 노드 카산드라 서버를 배포하는 것이 합리적 입니까? 주의 사항이 있습니까? 예를 들어 MySQL을 Django의 백엔드로 대체 할 수 있습니까? [추천합니까?]

• 시프트를하면 행을 가져 오기 위해 여러 번 조회를해야하므로 더 많은 "관리"를 수행하기 위해 앱의 일부를 다시 작성해야 할 것 같습니다.

• 관계형 엔진이 아닌 키 값 저장소로 MySQL을 사용하는 것이 합리적 일까요? 그렇게하면 안정적인 엔진뿐만 아니라 사용 가능한 많은 안정적인 API를 활용할 수 있습니다 (필요에 따라 관계형으로 전환). (이에 대한 프렌드에서 브렛 테일러의 포스트 - http://bret.appspot.com/entry/how-friendfeed-uses-mysql )

변화를 한 사람들의 통찰력은 크게 감사하겠습니다!

감사.

---

현재 사용 가능한 Cassandra 및 기타 분산 데이터베이스는 SQL에서 익숙한 종류의 임시 쿼리 지원을 제공하지 않습니다. 조인을 사용하여 쿼리를 효율적으로 배포 할 수 없기 때문에 대신 비정규 화에 중점을 둡니다.

그러나 Cassandra 0.6 (베타는 내일 공식적으로 출시되지만 참을성이 없으면 0.6 브랜치에서 직접 빌드 할 수 있음)은 분석을위한 Hadoop 맵 / 축소를 지원합니다.

Cassandra는 새로운 노드를 처음 그룹에 쉽게 추가 할 수 있도록 탁월한 지원을 제공합니다.

즉, 분당 수백 번의 쓰기로 mysql에서 오랫동안 괜찮을 것입니다. Cassandra는 키 / 값 저장소 (키 / 열 제품군)에 훨씬 더 뛰어나지 만 MySQL은 관계형 데이터베이스에 훨씬 더 좋습니다. :)

Cassandra (또는 기타 nosql 데이터베이스)에 대한 django 지원은 아직 없습니다. 그들은 1.2 이후의 다음 버전을 위해 무언가를하는 것에 대해 이야기하고 있지만, pycon의 django 개발자들과 이야기를했을 때 아무도 그것이 어떤 모습 일지 정말로 확신하지 못했습니다.

---

당신이 관계형 데이터베이스 개발자라면 (내가 그렇듯이) 다음을 제안 / 지시하고 싶다.

• 프로덕션 시스템에서 사용하기 전에 Cassandra로 작업 한 경험을 얻으십시오. 특히 해당 프로덕션 시스템의 완료 기한이있는 경우에는 더욱 그렇습니다. 중요하지 않은 것을 먼저 백엔드로 사용하십시오.
• SQL 엔진을 사용한 데이터 조작에 대해 당연한 것으로 생각하는 간단한 작업을 수행 할 것으로 예상했던 것보다 훨씬 더 어려운 작업입니다. 특히 데이터 인덱싱 및 결과 집합 정렬은 중요하지 않습니다.
• 데이터 모델링도 도전적인 것으로 입증되었습니다. 관계형 데이터베이스 개발자로서 당신은 많은 짐을 가지고 테이블에 오게됩니다. 당신은 데이터를 매우 다르게 모델링하는 방법을 기꺼이 배워야합니다.

이것들 은 Cassandra에서 무언가 를 구축하는 것이 좋습니다 . 당신이 저와 같다면 그렇게하면 데이터 스토리지에 대한 이해가 어려워지고 제가 이해하지 못했던 모든 상황에 맞는 관계형 데이터베이스 전망을 다시 생각하게 될 것입니다.

내가 찾은 좋은 리소스는 다음과 같습니다.

• Dominic Williams의 Cassandra 블로그 게시물
• Cassandra의 보조 인덱스
• 인덱싱에 대한 Ed Anuff의 추가 정보
• 카산드라 책 (환상적이지는 않지만 좋은 시작)
• "WTF는 SuperColumn"pdf

---

Django-cassandra는 초기 베타 모드입니다. 또한 Django는 no-sql 데이터베이스 용으로 만들지 않았습니다. Django ORM의 키는 SQL을 기반으로합니다 (Django는 PostgreSQL 사용을 권장합니다). no-sql 만 사용해야하는 경우 (동일한 앱에서 sql과 no-sql을 혼합 할 수 있음) no-sql ORM을 위험하게 사용해야합니다 (기존 SQL orm 또는 No-SQL 스토리지의 직접 사용보다 훨씬 느림). 또는 django ORM을 완전히 다시 작성해야합니다. 하지만이 경우 장고가 필요한 이유를 추측 할 수 없습니다. Tornado와 같은 다른 것을 사용할 수 있습니까?

참고 URL : https://stackoverflow.com/questions/2332113/switching-from-mysql-to-cassandra-pros-cons