많은 문제에는 단 하나의 해결책만 있는 것이 아닙니다. 즉, 이 기법이나 저 기법을 사용할 수 있습니다. 학습의 목적은 무엇이든 될 수 있지만 실제 생산 환경에서는 복잡성을 단순화하고 가장 친숙한 가장 간단한 방법으로 문제를 해결하는 것이 좋습니다. 동일한 문제를 해결하기 위해 2개의 데이터베이스를 사용하는 것이 정말로 필요한지 생각해 보세요.
노래 쿼리 부분을 MongoDB에서 쿼리하면 더 빨라질까 궁금합니다.
아마도, 아닐 수도 있습니다. 보유한 데이터의 양, MongoDB를 사용한 데이터 모델 설계가 합리적인지, 여기에 투자할 하드웨어 리소스의 양에 따라 달라집니다. NoSQL은 수평적 확장에 더 초점을 맞춥니다. 즉, 데이터 양이 계속 증가하더라도 쿼리 속도를 일정 수준으로 유지할 수 있다는 의미입니다. 개인적인 경험으로 볼 때, 수천만, 수억 개의 데이터가 있다면 MongoDB는 실제로 장점을 보여줄 수 있습니다. 데이터가 이 수준에 도달하기 전에는 속도만을 고려한다면 추가적인 데이터베이스를 도입할 필요는 별로 없다고 생각합니다. 이것이 제공하는 이점과 이로 인해 발생하는 복잡성에 비해 비용 효율적이지 않다고 말할 수 있습니다.
향후 노래 정보를 추가하거나 삭제할 때에는 MongoDB와 동시에 동기화를 해줘야겠죠?
데이터 동기화 문제는 "일관성"에 대한 요구 사항이 얼마나 높은지에 따라 달라집니다. 강력한 일관성의 경우 이는 분산 트랜잭션이므로 성능에 좋지 않을 수 있으며 트랜잭션 속도를 높이려는 원래 의도에 어긋납니다. 최종 일관성을 고려하고 있다면 Pentaho와 같은 다양한 MySQL-MongoDB ETL 도구를 살펴볼 수 있습니다. 물론 코드를 통해 직접 구현하는 것도 가능하지만, 다양한 내결함성 문제를 고려하기는 쉽지 않습니다.
먼저 MongoDB는 Redis와 달리 NoSQL의 특정 구현이라는 점을 분명히 알아야 합니다. 저장하는 데이터 구조는 문서 기반입니다.
둘째, 쿼리 속도는 제품이나 엔진 간의 차이에 따라 임의로 결정하기 어렵습니다. 뿐만 아니라 어떤 정보가 저장되어 있는지, 어떻게 저장하는지에 대한 분석도 필요합니다. 연습만 하면 과정이 더 간단해질 수 있습니다.
이전에는 MySQL만 배웠는데, 저장된 일부 데이터의 구조가 불확실하거나 복잡하기 때문에 MySQL을 단독으로 사용하여 저장하려면 많은 테이블을 사용하고 외래 키를 설정해야 하므로 저도 배웠습니다. MongoDB는 이러한 요구를 해결합니다.
제가 하고 있는 일은 독서 연습인데, 어떤 면에서는 노래와도 좀 비슷해요. 예를 들어, 한 책의 저자가 두 명 이상일 수 있습니다. MySQL을 사용하는 경우 구분 기호를 사용하여 여러 저자를 한 필드에 저장하는 것은 이후 쿼리에서 특정 문제(판단 조건의 복잡성 및 심지어 성능까지)가 있을 수 있습니다. ), 그리고 A 노래에는 한 명 이상의 가수가 있을 수도 있습니다.
제 연습은 MySQL + MongoDB입니다. 물론 MongoDB만 사용해도 달성할 수 있지만 구체적인 요구 사항은 그에 따라 분석되어야 한다고 생각합니다. 나의 종합적인 실천은 여전히 진행 중이며, 위에 제공된 아이디어 중 하나를 언제든지 전달할 수 있습니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
많은 문제에는 단 하나의 해결책만 있는 것이 아닙니다. 즉, 이 기법이나 저 기법을 사용할 수 있습니다. 학습의 목적은 무엇이든 될 수 있지만 실제 생산 환경에서는 복잡성을 단순화하고 가장 친숙한 가장 간단한 방법으로 문제를 해결하는 것이 좋습니다. 동일한 문제를 해결하기 위해 2개의 데이터베이스를 사용하는 것이 정말로 필요한지 생각해 보세요.
아마도, 아닐 수도 있습니다. 보유한 데이터의 양, MongoDB를 사용한 데이터 모델 설계가 합리적인지, 여기에 투자할 하드웨어 리소스의 양에 따라 달라집니다. NoSQL은 수평적 확장에 더 초점을 맞춥니다. 즉, 데이터 양이 계속 증가하더라도 쿼리 속도를 일정 수준으로 유지할 수 있다는 의미입니다. 개인적인 경험으로 볼 때, 수천만, 수억 개의 데이터가 있다면 MongoDB는 실제로 장점을 보여줄 수 있습니다. 데이터가 이 수준에 도달하기 전에는 속도만을 고려한다면 추가적인 데이터베이스를 도입할 필요는 별로 없다고 생각합니다. 이것이 제공하는 이점과 이로 인해 발생하는 복잡성에 비해 비용 효율적이지 않다고 말할 수 있습니다.
데이터 동기화 문제는 "일관성"에 대한 요구 사항이 얼마나 높은지에 따라 달라집니다. 강력한 일관성의 경우 이는 분산 트랜잭션이므로 성능에 좋지 않을 수 있으며 트랜잭션 속도를 높이려는 원래 의도에 어긋납니다. 최종 일관성을 고려하고 있다면 Pentaho와 같은 다양한 MySQL-MongoDB ETL 도구를 살펴볼 수 있습니다. 물론 코드를 통해 직접 구현하는 것도 가능하지만, 다양한 내결함성 문제를 고려하기는 쉽지 않습니다.
먼저 MongoDB는 Redis와 달리 NoSQL의 특정 구현이라는 점을 분명히 알아야 합니다. 저장하는 데이터 구조는 문서 기반입니다.
둘째, 쿼리 속도는 제품이나 엔진 간의 차이에 따라 임의로 결정하기 어렵습니다. 뿐만 아니라 어떤 정보가 저장되어 있는지, 어떻게 저장하는지에 대한 분석도 필요합니다. 연습만 하면 과정이 더 간단해질 수 있습니다.
이전에는 MySQL만 배웠는데, 저장된 일부 데이터의 구조가 불확실하거나 복잡하기 때문에 MySQL을 단독으로 사용하여 저장하려면 많은 테이블을 사용하고 외래 키를 설정해야 하므로 저도 배웠습니다. MongoDB는 이러한 요구를 해결합니다.
제가 하고 있는 일은 독서 연습인데, 어떤 면에서는 노래와도 좀 비슷해요. 예를 들어, 한 책의 저자가 두 명 이상일 수 있습니다. MySQL을 사용하는 경우 구분 기호를 사용하여 여러 저자를 한 필드에 저장하는 것은 이후 쿼리에서 특정 문제(판단 조건의 복잡성 및 심지어 성능까지)가 있을 수 있습니다. ), 그리고 A 노래에는 한 명 이상의 가수가 있을 수도 있습니다.
제 연습은 MySQL + MongoDB입니다. 물론 MongoDB만 사용해도 달성할 수 있지만 구체적인 요구 사항은 그에 따라 분석되어야 한다고 생각합니다. 나의 종합적인 실천은 여전히 진행 중이며, 위에 제공된 아이디어 중 하나를 언제든지 전달할 수 있습니다.
Elasticsearch는 mysql 성능에 영향을 주지 않고 더 빠르게 쿼리를 수행합니다
가사를 기준으로 노래를 찾는 등의 기능이 필요할 수도 있겠네요. 위에서 언급한 Elasticsearch는 매우 훌륭하며, 또 다른 옵션인 sphinx도 있는데, 이는 전체 텍스트 검색에도 매우 좋습니다.