[MARIADB] COLLATE 관련 설정..

기존 MS 에서 LIKE '%keyword%' 로 동작하는 기능을 MARIADB 의 mroonga(전문검색) 으로 사용하기 위해 테스트 중에 발생한 일들은 기록함.

 

 

CREATE TABLE `TEST` (

  `COM_CODE` varchar(6) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL,

  `HID` bigint(20) DEFAULT NULL,

.....

  PRIMARY KEY (`COM_CODE`,`PROD_CD`)

) ENGINE=Mroonga DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='ENGINE "INNODB", flags "TABLE_HASH_KEY|KEY_LARGE"';

 

다국어 테스트 검색

• 문제가 발생한 원인은 collation 과 관련있다. 

• 기본적으로 maria 는 utf8_general_ci 를 사용한다.

• 이 utf8_general_ci 는 일본어 가타카타/히나가라 그리고 전각/반각을 모두 다른 문자로 인식한다. 

• ms 는 별도로 구분하지 않는다. like 검색을 수행하면 모두 동일한 문자로 인식하고 검색된다..

• 일본어 검색 이슈로 collation를 utf8_unicode_ci 으로 변경했는데

• MARIADB 를 utf8_unicode_ci 으로 구성함으로써 다음 문제들이 발생했다. 

• 서로 다른 collation 인 테이블 조인시 에러 발생

• 이미 서비스중인 다른 테이블은 utf8_general_ci 으로 생성되었기 때문에 변경이 어렵다.

• 해결책으로 on 절의 드라이빙 테이블의 조건에 COLLATE utf8_general_ci 으로 드리븐 테이블의 collate 에 맞게 변경해주면 된다.. 하지만. 통계에 따라 조인 순서가 변경되어야 하는 경우 문제가 될 수 있다.

• Procedure 호출시 session 레벨의 collation은 utf8_general_ci인데 테이블이 utf8_unicode_ci 라면, input parameter 가 조건으로 사용될 때 에러 발생

• input param 에COLLATE utf8_unicode_ci 를 붙여주면 해결된다. 

• 사용자는 utf8_general_ci으로 호출했지만, procedure 내부에서 utf8_unicode_ci 으로 변환해서 사용한다.

• 하지만, 위 두가지 문제로 그냥 utf8_general_ci으로 결정되었다.

• 일본어의 경우 매우 까다롭기 때문에, 아에 처음부터 히라가나/가타카나 중 하나만 사용하게 제한해야 하며, 전각과 반각도 동일하게 제한해야 한다. 

• 만약 일본 고객이 증가하면, 기존 데이터 마이그레이션도 고려해야 할 것 같다. 

• [MARIA] 전문검색 (COLLATE, MS비교, BULK DML, 악센트, 대소문자,전각/반각, 일본어 가나)

 

데이터 마이그레이션 이슈

• ms 에서는 ⓐ와 a 를 다른 문자로 인식하지만, utf8_unicode_ci 에서는 같은 문자로 인식한다. 따라서 ms 의 데이터를 maria 으로 마이그레이션을 진행하는데 충돌키 오류가 발생한다. 

• ①, 1 도 마찬가지이다. 애초에 pk 컬럼에 이런 데이터를 허용한것도 문제지만;;;;;;;;;;;

• 이것도 unicode 으로 못간 이유 중에 하나다. 

 

 

collation 설정은 대/소문자 구분에나 영향이 있는 줄 알았는데

단순히 정렬순서만 영향이 있는게 아니라서 함부로 결정할 수 있는 속성이 아니다. 

 

 

이런 면에서 MS 에서 이해가 안되는 점이 있다. 

• 먼저 기본적으로 MS 는 일본어의 가타카나/히라가나 그리고 전각/반각을 구분하지 않고 검색해준다. 그런데 ⓐ와 a 는 다른문자로 검색된다 ;;;; 뭔 차이일까..

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

&