코어 데이터로부터 전환


코어 데이터로부터의 전환

https://inessential.com/2010/02/26/on_switching_away_from_core_data

지난 몇 달간 NetNewsWire를 위해 많은 성능개선을 수행했다. 아직 변화는 건내지 않은건 아직 충분히 완성되지 않았기 때문이다. 다른 개발자들이 아마도 관심둘 것으로 생각되어 이곳에 정리한다.

할 수 있는 많은 부분을 개선했다. 샤크에서 많은 시간을 소비하고, 코어 데이터로 모든 다중 스레딩 처리를 했으며 자체 큐 시스템에서 NSOperationQueue 로 바꿨으며, XML파싱을 수정하는 등의 작업을 수행했다. 하지만 퍼포먼스와 메모리 사용은 충분히 개선되지 않았다.

남은 것은 확실히 코어데이터이다. 

여기에 직접적인 데이터 베이스 엑세스가 코어 데이터를 사용하는 것보다 나은 경우를 나열한다.

1. 많은 뉴스 아이템을 읽은것/읽지 않은것으로 마크할때
Google Reader API로 부터 아이템 아이디의 큰 리스트를 얻는다. 

코어 데이터에서는 이 리스트 각 아이템에 대해 상태를 변경한다. 리스트는 10000개가 될 수 도 있다. 좋은 방식은 아니다.

이 것은 아주 데이터베이스스러운 연산으로서 한 번의 쿼리로 동작한다

2. 많은 아이템을 삭제할 때

코어 데이터는 하나하나 처리한다.

3. 외부 시스템으로부터 유일 아이디로 작업할 때

코어 데이터는 유일키 처리를 하지만 이 게 그것을 의미하지는 않는다. 뉴스 아이템은 유일 키가 있고 다른 데이터베이스에서 얻는다. 

새로고침을 하면 앱이 이전에 본 것을 알고 있다. 이전에 다운로드 된 것도 있고 변화된 것도 있다. (물론 이전것을 피한다.)

이 의미는 피드에서 각 아이템에 대해 이전에 저장된 것이면 앱은 존재하는 뉴스 아이템을 얻어야 한다. 이 것이 느리다. (다양한 기법을 시도했다. : 프리패칭, 필요할 때만 패칭, 피드에 대해서 존재하는 아이템의 아이디만 패팅, 셋이나 딕셔너리내의 존재하는 아이딤나 저장, 어떤 것도 도움이 되지 않았다.) 보통 해결책은 원본보다 더 안좋았다.

아이템의 수천개는 새로고침 세션동안 수천 아이템이 나올 수 있거 모든 아이템이 이미 존재하는지 확인해야하며 이 것은 큰 성능 히트이다. 페치하는 것보다 나아야 한다. 

더 직접적인 접근으로 INSERT or REPLACE INTO 로 처리 할 수 있다. 이 것은 아이템을 추가하거나 존재하는 아이템을 뒤바꾸는 것으로 빠르다.

4. 존재하는 아이템 테스팅하기

간혹 앱은 데이터베이스에 이미 존재하는지 확인해야 할 때가 있다. 코어데이터에서는 페치이다.
SQLite는 SELECT 1 FROM someTable WHERE uniqueID = whatever

이론상 인덱스만 확인한다 테이블 자체에서 어떤것도 얻지 않으므로 빠르다.



코어 데이터와 SQLite의 차이는 무엇인가



https://cocoacasts.com/what-is-the-difference-between-core-data-and-sqlite/

코어 데이터와 SQLite의 차이는 무엇인가? 비록 이 것이 보통의 질문이지만, 질문이 잘 못 되었다. 코어 데이터와 SQLite간의 비교는 사과와 오렌지 간의 차이와 같다. 어째서인가?

대답은 간단하다. 코어데이터는 객체 그래프를 관리하기 위한 프레임웍이고 SQLite는 관계형 데이터베이스이다. 관심이 있다면 긴 답변을 계속 읽기바란다.

SQLite는 무엇인가?

SQLite는 가벼운 데이터베이스 엔진으로서 아주 성능이 좋고 그래서 임베디드 시스템에 적합하다. SQLite이 관계형 데이터베이스라고 하지만, 개발자는 데이터베이스에 저장된 레코드 사이의 관계를 알아야 한다.

다른 많은 데이터베이스와 같이 SQLite는 데이터를 저장하기 위한 것이다. 

코어데이터는 무엇인가?

코어 데이터와 SQLite사이의 가장 큰 차잇점은 SQLite는 데이터베이스이지만 코어 데이터는 아니라는 점이다. 이 것이 가장 결정적인 차이점이다. 코어데이터와 SQLite는 다른 문제에 대한 해결책이다.

코어 데이터는 SQLite를 저장소로 쓸 수 있지만 프레임워크 자체는 데이터베이스가 아니다.

코어 데이터는 데이터베이스가 아니다.

코어 데이터는 객체 그래프를 관리하기 위한 프레임워크이다. 객체 그래프는 상호 연결 객체의 콜렉션이라고 할 수 있다. 프레임워크는 복합 객체 그래프를 관리하는데 탁월하다.

코어 데이터는 객체 그래프를 관리한다.

프레임워크는 객체 그래프내의 객체의 생명 주기를 관리한다. 디스크에 객체 그래프를 선택적으로 저장할 수 있고, 관리하는 객체 그래프를 검색하는 강력한 인터페이스를 제공한다.

하지만 코어데이터는 더 많은 기능을 제공한다. 프레임워크는 입력 무결성, 데이터 모델 버저닝, 변화 추적과 같은 기능을 제공한다.

저장소 형식

코어 데이터가 SQLite 데이터베이스를 저장소로 사용할 수 있다고 언급했지만, 다른 저장 형식인 이진 저장소와 메모리 저장소도 지원한다.

코어 데이터가 SQLite 데이터베이스를 어떻게 사용하는지 알고 있지만, 이 것이 모든 SQLite 데이터베이스를 다룰 수 있음을 의미하지는 않는다. SQLite 데이터베이스 스키마는 프레임워크에서 세부적으로 관리하며 공개적으로 문서화되어 있지 않다.

코어 데이터 또는 SQLite

어떤 것을 사용하는 것이 좋을까? 코어 데이터 또는 SQLite? 이는 잘못된 질문이다. 코어 데이터를 사용하지 않는 가벼운 해결책을 찾는다면 SQLite면 충분하다. C를 좋아하지 않는다면 커스 뮐러의 FMDB 라이브러리를 사용할 수 도 있다. 이 는 Objective-C 래퍼의 객체 지향적 래퍼를 제공한다.

만약 다중 엔티티, 속성, 그리고 관계와 같은 복잡한 객체 그래프를 관리한다면 코어데이터가 고려할만한 가치가 있다. 코어 데이터는 생각보다 쉽다.

만약 코어 데이터를 고른다면 프레임워크의 기본을 건너뛰지 않는 것이 좋다. 코어데이터는 학습 커브가 있다. 



MySQL Full-Text Search 7 MySQL

7. 풀텍스트 인덱싱을 위한 데이터 정렬 추가

이 섹션에서는 전체 텍스트 검색을 위해 새로운 데이터 정렬을 추가하는 방법을 설명합니다. 샘플 데이터 정렬은 latin1_swedish_ci와 비슷하지만 구두점 문자가 아닌 문자로 '-'문자를 처리하므로 단어 문자로 색인 할 수 있습니다. 데이터 정렬 추가에 대한 일반적인 정보는 10.13 절. "문자 집합에 데이터 정렬 추가"에 있습니다. 당신이 그것을 읽고 관련 파일에 익숙하다고 가정합니다.

전체 텍스트 인덱싱에 대한 데이터 정렬을 추가하려면 다음 절차를 사용하십시오. 이 단원에서는 10.13 절. "문자 집합에 데이터 정렬 추가"에서 설명했듯이 문자 집합 속성을 설명하는 구성 파일을 사용하여 간단한 문자 집합에 대한 데이터 정렬을 추가 할 수 있습니다. 유니 코드와 같은 복잡한 문자 집합의 경우 문자 집합 속성을 설명하는 C 소스 파일을 사용하여 데이터 정렬을 만듭니다.

1. Index.xml 파일에 데이터 정렬을 추가합니다. 대조 ID는 사용하지 않아야하므로 해당 ID가 시스템에서 이미 사용 된 경우 62와 다른 값을 선택하십시오.

  1. <charset name="latin1">...<collation name="latin1_fulltext_ci" id="62"/></charset>
2. latin1.xml 파일에서 데이터 정렬의 정렬 순서를 선언하십시오. 이 경우 latin1_swedish_ci에서 주문을 복사 할 수 있습니다.
<collation name="latin1_fulltext_ci"><map>00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F60 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F50 51 52 53 54 55 56 57 58 59 5A 7B 7C 7D 7E 7F80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9FA0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AFB0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF41 41 41 41 5C 5B 5C 43 45 45 45 45 49 49 49 4944 4E 4F 4F 4F 4F 5D D7 D8 55 55 55 59 59 DE DF41 41 41 41 5C 5B 5C 43 45 45 45 45 49 49 49 4944 4E 4F 4F 4F 4F 5D F7 D8 55 55 55 59 59 DE FF</map></collation>

latin1.xml에서 ctype 배열을 수정하십시오. 0x2D ( '-'문자의 코드)에 해당하는 값을 10 (문장 부호)에서 01 (대문자)으로 변경하십시오. 다음 배열에서 이것은 네 번째 행 아래 요소이며 끝에서 세 번째 값입니다.

  1. <ctype><map>0020 20 20 20 20 20 20 20 20 28 28 28 28 28 20 2020 20 20 20 20 20 20 20 20 20 20 20 20 20 20 2048 10 10 10 10 10 10 10 10 10 10 10 10 01 10 1084 84 84 84 84 84 84 84 84 84 10 10 10 10 10 1010 81 81 81 81 81 81 01 01 01 01 01 01 01 01 0101 01 01 01 01 01 01 01 01 01 01 10 10 10 10 1010 82 82 82 82 82 82 02 02 02 02 02 02 02 02 0202 02 02 02 02 02 02 02 02 02 02 10 10 10 10 2010 00 10 02 10 10 10 10 10 10 01 10 01 00 01 0000 10 10 10 10 10 10 10 10 10 02 10 02 00 02 0148 10 10 10 10 10 10 10 10 10 10 10 10 10 10 1010 10 10 10 10 10 10 10 10 10 10 10 10 10 10 1001 01 01 01 01 01 01 01 01 01 01 01 01 01 01 0101 01 01 01 01 01 01 10 01 01 01 01 01 01 01 0202 02 02 02 02 02 02 02 02 02 02 02 02 02 02 0202 02 02 02 02 02 02 10 02 02 02 02 02 02 02 02</map></ctype>

4. 서버를 다시 시작하십시오.

5. 새 데이터 정렬을 사용하려면 데이터 정렬을 사용할 열 정의에 포함시킵니다.

mysql> DROP TABLE IF EXISTS t1;Query OK, 0 rows affected (0.13 sec)mysql> CREATE TABLE t1 ( -> a TEXT CHARACTER SET latin1 COLLATE latin1_fulltext_ci, -> FULLTEXT INDEX(a) -> ) ENGINE=MyISAM;Query OK, 0 rows affected (0.47 sec)


하이픈이 단어 문자로 간주되는지 확인하려면 데이터 정렬을 테스트하십시오.

mysql> INSERT INTO t1 VALUEs ('----'),('....'),('abcd');Query OK, 3 rows affected (0.22 sec)Records: 3 Duplicates: 0 Warnings: 0mysql> SELECT * FROM t1 WHERE MATCH a AGAINST ('----' IN BOOLEAN MODE);+------+| a |+------+| ---- |+------+1 row in set (0.00 sec)


MySQL Full-Text Search 6 MySQL

6. 파인 튜닝 MySQL 풀텍스트 검색

MySQL의 전체 텍스트 검색 기능에는 사용자가 조정할 수있는 매개 변수가 거의 없습니다. MySQL 소스 배포판을 사용하는 경우 전체 텍스트 검색 동작을보다 강력하게 제어 할 수 있습니다. 일부 변경 사항에는 소스 코드 수정이 필요하기 때문입니다. Section 2.9, "소스에서 MySQL 설치하기"를 참조하십시오.

전체 텍스트 검색은 신중하게 조정되어 가장 효과적입니다. 대부분의 경우 기본 동작을 수정하면 실제로 효과가 줄어들 수 있습니다. 자신이하는 일을 모르는 경우 MySQL 소스를 변경하지 마십시오.

이 절에서 설명하는 대부분의 전체 텍스트 변수는 서버 시작시 설정해야합니다. 서버를 다시 시작하려면 서버를 다시 시작해야합니다. 서버가 실행 중일 때는 수정할 수 없습니다.

변수를 변경하려면 테이블에서 FULLTEXT 인덱스를 다시 작성해야합니다. 이렇게하기위한 지침은이 섹션의 뒷부분에 나와 있습니다.

- 인덱싱 할 단어의 최소 및 최대 길이는 시스템 변수 ft_min_word_len 및 ft_max_word_len에 의해 정의됩니다. (5.1.7 절. "서버 시스템 변수"를 참조하십시오.) 기본 최소값은 4 자입니다. 기본 최대 값은 버전에 따라 다릅니다. 두 값 중 하나를 변경하면 FULLTEXT 인덱스를 다시 작성해야합니다. 예를 들어, 3 문자 단어를 검색 할 수있게하려면 다음 행을 옵션 파일에 넣어 ft_min_word_len 변수를 설정할 수 있습니다.
[mysqld]ft_min_word_len=3
그런 다음 서버를 다시 시작하고 FULLTEXT 인덱스를 다시 작성하십시오. 이 목록에 나오는 지침에서 myisamchk과 관련된주의 사항에 특히 유의하십시오.

- 기본 중지 단어 목록을 무시하려면 ft_stopword_file 시스템 변수를 설정하십시오. (5.1.7 절. "서버 시스템 변수"참조) 변수 값은 스톱 워드 목록을 포함하는 파일의 경로 이름이거나 스톱 워드 필터링을 비활성화하는 빈 문자열이어야합니다. 다른 디렉토리를 지정하기 위해 절대 경로 이름이 제공되지 않으면 서버는 데이터 디렉토리에서 파일을 찾습니다. 이 변수의 값이나 stopword 파일의 내용을 변경 한 후 서버를 다시 시작하고 FULLTEXT 인덱스를 다시 작성하십시오.

정지 단어 목록은 자유 형식입니다. 즉, 개행 문자, 스페이스 또는 쉼표와 같은 영숫자가 아닌 문자를 사용하여 불용어를 구분할 수 있습니다. 예외는 단어의 일부로 취급되는 밑줄 문자 (_)와 단일 아포스트로피 ( ')입니다. 중지 단어 목록의 문자 집합은 서버의 기본 문자 집합입니다. 10.3.2 절. "서버 문자 집합과 데이터 정렬"부분을 참조하십시오.
- 자연 언어 검색의 50 % 임계 값은 선택한 특정 가중치 체계에 의해 결정됩니다. 이것을 사용하지 않으려면 storage / myisam / ftdefs.h에서 다음 라인을 찾으십시오 :
#define GWS_IN_USE GWS_PROB

Change that line to this:

#define GWS_IN_USE GWS_FREQ

그런 다음 MySQL을 다시 컴파일하십시오. 이 경우 색인을 다시 작성할 필요가 없습니다.

노트
이 변경을하면 MATCH () 함수에 대한 적절한 관련성 값을 제공하는 MySQL의 기능이 심각하게 저하됩니다. 그러한 일반적인 단어를 정말로 검색해야하는 경우 대신 IN BOOLEAN MODE를 사용하여 검색하는 것이 좋으며 50 % 임계 값을 준수하지 않습니다.

- 부울 전체 텍스트 검색에 사용되는 연산자를 변경하려면 ft_boolean_syntax 시스템 변수를 설정하십시오. 이 변수는 서버가 실행 중일 때 변경할 수 있지만 전역 시스템 변수를 설정할 수있는 권한이 있어야합니다 (5.1.8.1 절. "시스템 변수 권한"참조). 이 경우 색인을 다시 작성할 필요가 없습니다. 이 변수를 설정하는 방법을 설명하는 규칙을 설명하는 5.1.7 절. "서버 시스템 변수"를 참조하십시오.
- 단어 문자로 간주되는 문자 집합을 변경하려면 다음 목록에서 설명하는 것처럼 여러 가지 방법으로 변경할 수 있습니다. 수정 한 후에는 FULLTEXT 인덱스를 포함하는 각 테이블의 인덱스를 다시 빌드해야합니다. 하이픈 문자 ( '-')를 단어 문자로 취급한다고 가정합니다. 다음 방법 중 하나를 사용하십시오.
. MySQL 소스 수정 : storage / myisam / ftdefs.h에서 true_word_char () 및 misc_word_char () 매크로를 참조하십시오. 해당 매크로 중 하나에 '-'를 추가하고 MySQL을 다시 컴파일하십시오.

. 문자 집합 파일 수정 : 다시 컴파일 할 필요가 없습니다. true_word_char () 매크로는 "문자 유형"테이블을 사용하여 다른 문자와 문자 및 숫자를 구별합니다. . 문자 세트 XML 파일 중 하나에서 <ctype> <map> 배열의 내용을 편집하여 '-'가 "문자"임을 지정할 수 있습니다. 그런 다음 FULLTEXT 색인에 주어진 문자 세트를 사용하십시오. <ctype> <map> 배열 형식에 대한 정보는 10.12.1 절. "문자 정의 배열"에서 참조하십시오.

. 인덱스 된 열에서 사용하는 문자 집합에 대해 새 데이터 정렬을 추가하고 해당 데이터 정렬을 사용하도록 열을 변경합니다. 데이터 정렬 추가에 대한 일반적인 정보는 10.13 절. "문자 집합에 데이터 정렬 추가"에서 참조하십시오. 전체 텍스트 인덱싱 관련 예제는 12.9.7 절. "전체 텍스트 인덱싱을위한 데이터 정렬 추가"에서 참조하십시오.

인덱싱 (ft_min_word_len, ft_max_word_len 또는 ft_stopword_file)에 영향을 미치는 전체 텍스트 변수를 수정하거나 중지 단어 파일 자체를 변경하는 경우 변경 한 후 서버를 다시 시작한 후에 FULLTEXT 인덱스를 다시 작성해야합니다. 이 경우 인덱스를 다시 작성하려면 QUICK 복구 작업을 수행하면 충분합니다.
mysql> REPAIR TABLE tbl_name QUICK;

또는 ALTER TABLE에 DROP INDEX 및 ADD INDEX 옵션을 사용하여 각 FULLTEXT 인덱스를 삭제하고 다시 작성하십시오. 경우에 따라 수리 작업보다 빠를 수도 있습니다.

FULLTEXT 인덱스를 포함하는 각 테이블은 표시된 것처럼 복구해야합니다. 그렇지 않으면 테이블에 대한 쿼리가 잘못된 결과를 초래할 수 있으며 테이블을 수정하면 서버가 테이블을 손상되어 복구가 필요한 것으로 간주합니다.

myisamchk를 사용하여 복구 또는 분석과 같은 테이블 인덱스를 수정하는 작업을 수행하는 경우 별도로 지정하지 않으면 FULLTEXT 인덱스가 최소 단어 길이, 최대 단어 길이 및 중지 단어 파일에 대한 기본 전체 텍스트 매개 변수 값을 사용하여 재구성됩니다. 이로 인해 쿼리가 실패 할 수 있습니다.

이 매개 변수는 서버에서만 인식되기 때문에 문제가 발생합니다. 그들은 MyISAM 인덱스 파일에 저장되지 않습니다. 서버가 사용하는 최소 또는 최대 단어 길이 또는 중지 단어 파일 값을 수정 한 경우 문제가 발생하지 않도록하려면 mysqld에 사용하는 myisamchk에 대해 동일한 ft_min_word_len, ft_max_word_len 및 ft_stopword_file 값을 지정하십시오. 예를 들어, 최소 단어 길이를 3으로 설정 한 경우 다음과 같이 myisamchk를 사용하여 테이블을 복구 할 수 있습니다.

shell> myisamchk --recover --ft_min_word_len=3 tbl_name.MYI
myisamchk와 서버가 전체 텍스트 매개 변수에 동일한 값을 사용하게하려면 옵션 파일의 [mysqld]와 [myisamchk] 섹션에 각각을 넣으십시오 :

[mysqld]ft_min_word_len=3[myisamchk]ft_min_word_len=3

인덱스 수정에 myisamchk를 사용하는 대신 REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE 또는 ALTER TABLE 문을 사용할 수 있습니다. 이 문은 사용할 전체 텍스트 매개 변수 값을 알고있는 서버에서 수행합니다.



MySQL Full-Text Search 5 MySQL

5. 풀텍스트 제한 사항들

전체 텍스트 검색은 MyISAM 테이블에서만 지원됩니다. (MySQL 5.6 이상에서는 InnoDB 테이블과 함께 사용할 수도 있습니다.)

파티션 된 테이블에서는 전체 텍스트 검색이 지원되지 않습니다. 19.5 절. "분할에 관한 제한 사항"을 참조하십시오.

전체 텍스트 검색은 대부분의 멀티 바이트 문자 집합과 함께 사용할 수 있습니다. 예외는 유니 코드의 경우 utf8 문자 집합을 사용할 수 있지만 ucs2 문자 집합은 사용할 수 없습니다. 그러나 ucs2 열의 FULLTEXT 인덱스는 사용할 수 없지만 이러한 인덱스가없는 ucs2 열에서 IN BOOLEAN MODE 검색을 수행 할 수 있습니다.

utf8에 대한 설명은 utf8mb4에도 적용되며 utcs16 및 utf32에도 적용됩니다.

중국어 및 일본어와 같은 표의 언어에는 단어 분리 문자가 없습니다. 따라서 FULLTEXT 파서는 이러한 언어 및 다른 언어에서 단어의 시작과 끝을 판별 할 수 없습니다. 이 문제에 대한 의미와 문제에 대한 해결 방법은 12.9 절. "전체 텍스트 검색 함수"에서 설명합니다.

단일 테이블 내에서 여러 문자 집합을 사용할 수 있지만 FULLTEXT 인덱스의 모든 열은 동일한 문자 집합과 데이터 정렬을 사용해야합니다.

이 MATCH ()가 BOOLEAN MODE에 있지 않는 한 MATCH () 열 목록은 테이블에 대한 일부 FULLTEXT 색인 정의의 열 목록과 정확히 일치해야합니다. 부울 모드 검색은 색인화되지 않은 열에서 수행 될 수 있지만 속도가 느릴 수 있습니다.

AGAINST ()의 인수는 쿼리 평가 중 상수 인 문자열 값이어야합니다. 예를 들어 테이블 열은 각 행마다 다를 수 있기 때문에이 규칙은 제외됩니다.

FULLTEXT 검색의 경우 인덱스 힌트가 FULLTEXT가 아닌 검색보다 더 제한적입니다. 8.9.3 절. "색인 힌트"를 참조하십시오.

'%'문자는 전체 텍스트 검색을 위해 지원되는 와일드 카드 문자가 아닙니다.



1 2 3 4 5 6 7 8 9 10 다음