사전 웹 사이트에 MySQL을 사용하는 것이 나쁜 생각 인 이유는 무엇입니까?

사전 항목 (보통 단일 단어)과 그 의미를 다른 언어로 저장할 데이터베이스를 설계하고 설정하려고합니다. 예를 들어, 용어집 테이블 에는 항목 과 정의 가 있어야 하고 각 테이블 레코드에는 저장된 레코드 의 ID 에 대한 참조가 있습니다 Tag(각 항목에는 태그 또는 범주가 있어야 함).

내 데이터에는 구조가 있기 때문에 MySQL과 같은 SQL 데이터베이스를 사용하는 것은 나쁜 생각이 아니라고 생각했습니다. 그러나 사람들은 MongoDB가 성능면에서 훨씬 우수하다고 말합니다.

클라이언트 측에서 애플리케이션은 백엔드가 제공하는 REST API를 사용하는 자동 완성 기능이있는 검색 상자를 제공 할 수 있어야합니다. 이러한 시나리오에서 MySQL을 사용하는 것이 안전합니까? 또는 이것을 위해 다른 솔루션의 MongoDB 또는 ElasticSearch를 사용해야합니까? 이 방법으로 수백 개의 레코드를 저장하고 액세스해야합니다.

왜 그것이 나쁜 생각인지 말할 수 없습니다. 관계형 데이터베이스가 좋은 아이디어 인 이유는 여러 가지가 있습니다.

1. 모든 사람이 정의를 위해 사전을 참고하는 것은 아닙니다. 여러 번, 올바른 철자를 찾기 위해 사전이 사용됩니다. 이것은 단지 건초 더미에서 바늘을 찾는 것이 아니라 사용자가 설명 한 것과 비슷한 바늘을 건초 더미에서 검색하고 있음을 의미합니다 (관용구를 사용할 수있는 경우).

   기본 키 조회 만 수행하지는 않습니다. 당신은 키워드 검색을 할거야

2. 단어는 의미 또는 철자 ( 읽기, 읽기 , 빨간색 및 갈대 ) 로 관련 될 수 있습니다.

   "관련"이라는 단어를 볼 때마다 "관계형 데이터베이스"를 생각하십시오

3. 속도가 필요한 경우 깨진 관계형 데이터 모델이 아니라 관계형 데이터베이스 위에 캐싱해야합니다.

4. 적절하게 표준화 된 데이터베이스는 1 차 키 조회 및 검색 속도를 높입니다.

5. 표준화 된 데이터베이스가 느리다고 말하는 사람들은 이것이 사실 인 경우의 0.1 %를 말합니다. 다른 경우의 99.9 %는 실제로 정규화 된 데이터베이스를 사용하여 성능을 직접 확인 하지 않았 으므로 무시하십시오. 표준화 된 데이터베이스로 작업했습니다. 그것을 사랑하십시오. 돌아가고 싶지 않아 그리고 나는 데이터베이스 사람이 아닙니다. 저는 C # / JavaScript / HTML / Ruby입니다.

6. 단어에는 기원이 있습니다. 실제로, 같은 언어의 많은 단어가 같은 원점을 가질 수 있는데, 이는 다른 언어의 다른 단어입니다. 예를 들어, résumé (채용 웹 사이트에 업로드하여 향후 7 년 동안 끊임없는 전화 및 이메일을받을 수있는 것)는 프랑스어입니다.

7. 사전은 또한 어떤 종류의 단어 (명사, 동사, 형용사)를 정의합니다. 이것은 단순한 텍스트가 아닙니다. "명사"라는 의미도 있습니다. 또한 관계형 데이터베이스를 사용하면 "영어의 모든 명사를 제공"과 같은 말을 할 수 있으며 정규화 된 데이터베이스는 외래 키를 사용하고 외래 키에는 인덱스가 있거나 있어야하므로 조회가 간단합니다.

8. 단어가 어떻게 발음되는지 생각하십시오. 특히 영어에서는 많은 단어가 같은 발음을가집니다 (위의 예제를 읽고 리드하거나 읽거나 빨간색으로 표시하십시오).

   단어의 발음 자체는 다른 단어입니다. 관계형 데이터베이스를 사용하면 발음에 외래 키를 사용할 수 있습니다. 해당 정보는 관계형 데이터베이스에 복제되지 않습니다. SQL이없는 데이터베이스에서는 미친 것처럼 복제됩니다.

9. 이제 복수 및 단수형 단어에 대해 이야기 해 봅시다. :) "보트"와 "보트"를 생각하십시오. 또는 단어가 "단수"또는 "복수"라는 사실.

10. 오! 그리고 이제 과거 시제, 현재 시제, 미래 시제 및 현재 분사에 대해 이야기합시다. 영어 등).

    "실행"을 찾으면 실행, 실행, 실행 등 다른 시제가 표시됩니다.

    실제로 "시제"는 또 다른 관계 자체입니다.

11. 영어는 그렇게 많이하지 않지만 성별은 단어를 정의하는 또 다른 것입니다. 스페인어와 같은 언어는 명사의 주제가 남성인지 여성인지를 정의하는 접미사를 갖습니다. 문장을 위해 빈칸을 채워야하는 경우 많은 언어에서 성별이 매우 중요합니다.

    성별을 결정하기 위해 언어 규칙에 항상 의존 할 수는 없으므로 (스페인어에서 "o"로 끝나는 단어는 남성 / 남성이지만 모든 단어에 해당되는 것은 아닙니다) 남성 또는 여성의 식별 값이 필요합니다. 이것은 표준화 된 데이터베이스가 수백만 개의 레코드에서도 정상적으로 처리하는 또 다른 관계입니다.

단어와 언어 사이의 모든 비틀린 규칙과 관계로 인해이 데이터 저장소를 SQL이 아닌 솔루션이 제공하는 "문서 저장소"로 상상하기가 어렵습니다. 단어와 그 구성 요소 사이에는 관계형 데이터베이스가 유일하게 현명한 해결책이 될 정도로 많은 관계가 존재합니다.

키-값 저장소 (보다 빈약 한 프로그래밍 모델을 제공)를 사용하고 더 많은 구조 (예 : 제 3 언어 추가)가 필요하거나 조인과 관련된보다 복잡한 쿼리를 수행해야하는 경우 키를 재구성하고 데이터를 비정규 화하거나 모든 데이터를 반복하여 필요한 것을 찾는 데 많은 시간을 할애합니다.

관계형 데이터베이스로 시작하면 응용 프로그램의 디자인, 코드를 통해 작업하여 키-값 형식으로 분류하는 대신 응용 프로그램의 자연 데이터 모델에 더 집중할 수 있습니다.

응용 프로그램이 정해지면 다양한 옵션을 측정하여 성능 작업을 수행 할 수 있습니다. 기술을 전환하기 전에 SQL에서 수행해야 할 몇 가지 성능 트릭이 있습니다. 응용 프로그램에 대해 많은 것을 배웠으며 관계형이 자신에게 해를 끼치는 지 여부와 키-값이 데이터 모델에 적합한 지 결정하는 데 훨씬 유리한 위치에있게됩니다.

키-값이 응용 프로그램에 정확히 필요한 것으로 판명되면 관계형 모델에 상당한 투자를 낭비하지 않고 전환 할 수 있지만 다른 방법으로 키-값 모델이 수행하는 작업을 수행하는 데 시간을 낭비 할 수 있습니다 관계형 모델에서 사소한.

도메인과 사용자에 대해 더 많이 배우면서 끊임없이 변화하는 요구 사항에 직면하여 응용 프로그램을 설계, 작성 및 실행하는 데있어 가속기로서 관계형 데이터베이스를 고려하십시오.

수백만 명의 사용자가있는 경우, 시작하기 위해 키-값을 선택한 경우에도 디자인을 리팩터링해야합니다.

이 데이터베이스의 경우 성능에 큰 차이가 없을 것입니다. 아마도 표준 RDBMS는 끔찍한 생각이 아닙니다. 아마도 주어진 항목의 쓰기보다 훨씬 더 많은 읽기가 있어야하기 때문입니다. 이것에 대한 성능은 기본 드라이버가 아닌 것 같습니다. 응용 계층에서의 캐싱도 이러한 문제를 완화합니다.

다른 고려 사항은 복제 및 복원력입니다. 관계형 데이터베이스는 단일 인스턴스를 중심으로 설계되는 경향이 있습니다. CAP 정리를 읽고 가장 중요한 것을 고려해야합니다.

이러한 NoSQL 데이터베이스는 처음부터 항상 좋은 생각처럼 들리지만, 예를 들어 키워드를 가치 (또는 일부)로 조회해야하는 경우와 같은 문제를 처리 할 때 문제가 발생할 수 있습니다.

관계형 데이터베이스와 함께 시작한 다음 나중에 비정규 화하는 것이 더 안전한 옵션입니다. MySQL은 이런 종류의 목적 (텍스트 기반 검색을 사용하는 간단한 관계형 데이터베이스)에 적합합니다. 이런 종류의 데이터로 어려움을 겪는 유스 케이스는 그리 많지 않습니다. 인덱스가 올바르게 설정되어 있는지 확인하면 NoSQL 데이터베이스와 비슷한 수준 (또는 텍스트 검색을 수행 할 때 더 나은 수준)에서 수행되며 앱 논리를 수정하지 않고도 유연성을 제공 할 수 있습니다. 구체적인 데이터 구조에 바인딩됩니다.

데이터의 가장 일반적인 사용법을 찾은 후 (성능 요구를 충족하지 않는 경우)로드 및 검색 할 수있는 설정된 형식으로 출력하여 데이터를 비정규화할 수 있습니다. NoSQL 스키마.