우리는 e 러닝 목적으로 소셜 네트워크 응용 프로그램을 만들었습니다. 우리 실험실에서 연구하고있는 실험적인 프로젝트입니다. 일부 사례 연구에서 오랫동안 사용되어 왔으며 관계형 DBMS (SQL Server 2008)의 데이터가 커지고 있습니다. 지금은 몇 기가 바이트이며 테이블은 서로 밀접하게 연결되어 있습니다. 성능은 여전히 양호하지만 언제 다른 옵션을 고려해야합니까? 성능 문제입니까?
답변:
몇 기가 바이트는 그리 크지 않습니다 . 엔터프라이즈 DB의 일반적인 크기와 비슷합니다. 테이블을 조인 할 때 PK를 사용하는 한 미래에도 (하루에 TB 데이터를 얻지 않는 한) 제대로 작동해야합니다.
빅 데이터 환경에서 일하는 대부분의 전문가는 빅 데이터 라는 용어 의 시작 으로 ~ 5TB 를 고려 합니다. 그러나 그때조차도 다음으로 최고의 nosql 데이터베이스를 설치하는 가장 좋은 방법은 아닙니다. 문제를 해결하는 데 가장 적합한 도구를 찾기 위해 항상 데이터 (집계, 읽기, 검색, 광산, ..)로 보관하려는 작업에 대해 생각해야합니다.
즉, 데이터베이스에서 많은 검색을 수행하는 경우 솔러 인스턴스 / 클러스터를 실행하고 Postgres 또는 SQL Server와 같은 DBMS의 데이터를 수시로 비정규 화하고 데이터를 이동하는 대신 solr에 넣는 것이 좋습니다. 지속성 및 성능 측면에서 SQL에서 nosql로.
빅 데이터는 실제로 "얼마나 큰가"에 관한 것이 아닙니다.
첫째, 몇 기가 바이트는 전혀 크지 않습니다. 거의 아무것도 아닙니다. 따라서 귀찮게하지 마십시오. 시스템은 내가 생각하는 한동안 계속 효율적으로 작동 할 것입니다.
그런 다음 데이터를 어떻게 사용하는지 생각해야합니다.
응용 프로그램에서 "기능적"데이터를 저장하는 경우 SQL을 유지하는 것이 좋습니다. 나중에 검색하거나보고하기 위해 데이터를 저장하고이 데이터 양이 빠르게 증가 할 경우 빅 데이터를 제안합니다. 제 생각에는 빅 데이터는 지속적으로 수집 및 분석해야하는 실제 데이터를 처리 할 때 유용합니다.
관계형 vs 문서 (또는 NoSQL) 데이터베이스를 사용하는 것이 적절한시기에 대한 stackoverflow에 대한 자세한 답변을 여기에 게시했습니다.
관계형 데이터베이스 / ORM 또는 문서 데이터베이스 / ODM 사용 동기
요약:
작은 물건의 경우 익숙한 도구를 사용하십시오.
몇 기가 바이트는 확실히 작은 것입니다. 단일 MySQL 클러스터에 맞지 않을 때까지 커지지 않습니다. 합리적인 수의 노드 (16-32)를 가진 커지지 않으므로 8-16TB 데이터와 몇 백만 건의 트랜잭션을 의미합니다 초당 (또는 최대 100 개의 TB 데이터와 초당 수천 개의 트랜잭션이있는보다 일반적인 하드 드라이브 기반 데이터베이스)
다른 데이터베이스 (MySQL Cluster가 아님)에 갇힌 경우 FusionIO 하드웨어를 던져서 더 많은 마일리지를 확보하십시오.
당신은 몇 TB보다 큰 데이터를 일단 및 초당 트랜잭션의 수천보다 더 빨리, 그것은 NoSQL에 먼저 한 다음 응용 프로그램 코드에서 논리적 샤딩로 이동에서보기에 좋은 시간이다.
카산드라 :)
NoSQL로 전환 할 때가 2 가지에 달려 있습니까?
데이터가 잘 구조화되어 있으면 (예 : 테이블, Excel 스프레드 시트 또는 고정 된 수의 열이있는 행 집합으로 모델링 될 수있는 경우) SQL 데이터베이스가 탁월합니다. 테이블 조인을 많이해야 할 때도 좋습니다 (사운드처럼 들립니다).
데이터가 키-값 쌍 이상으로 구조화되지 않은 경우 NoSQL 데이터베이스가 뛰어납니다.
성능면에서 현명한 SQL 솔루션이 느리다는 질문을 하나 스스로 해봐야 합니다 .