행복한 블로그

MYSQL 매뉴얼중 Query cache에 대한 내용만을 Study 하기 위해 비공식적으로 

번역한 것을 도움이 될것 같아 올립니다. Tip&Tech 부분이 가장 적당할 것 같아

Tip&Tech에 올립니다. 저자권에 문제가 되는 경우는 바로 삭제 하겠습니다.

정리하면서 수정해서 다시 올립니다. 허접으로 번역해서 도움이 될지 모르겠습니다.

6.9 MySQL Query Cache

==============================

MYSQL 4.0.1 버전부터 Query Cache 개념이 도입되었다.

Query Cache가 사용되면 SELECT Query문과 SELECT 결과를 캐싱처리하고

나중에 동일한 Query 요청이 들어오면 Query문을 실행하지 않고

Query Cache에서 결과를 전달하는 식으로 동작 한다.

Query Cache는 동적인 내용을 많이 사용하는 웹서버 등에서 데이터 변경이 빈번하지

않는 테이블을 대상으로 동일한 Query를 중복해서 사용하는 경우 

매우 유용하다.

아래는 Query Cache의 성능에 대한 일부 자료 이다.

( OS: Linux Alpha  CPU: 2x500 MHZ  RAM: 2GB  Query Cache:64MB 환경의 

      서버에서 MySQL benchmark 에서 생성되었음)

  . 실행한 모든 쿼리문들이 단순하지만 (ex 한 레코드만 있는 테이블에서 레코드를 선택하는 쿼리)

    쿼리문이 모두 달라 캐시가 될 수 없는 경우는 Query Cache를 하기 위한 오버헤드가 13%

    증가 했다. 이 경우는 최악의 시나리오로 볼 수 있다. 일반적인 경우 현업에서 Query문은 훨씬 

    복잡하기 때문에 오버헤드는 현저히 줄어든다.

  . 레코드가 하나 있는 테이블의 레코드가 캐시된 후 검색은 238% 빨라졌다. 이는 Query가 캐시된 후

    예상할 수 있는 최소한의 성능향상에 근접한 결과라고 볼 수 있다.

  . Query Cache를 사용하지 않고자 하는 경우 Query_Cache_size=0으로 my.cnf 파일에 설정하면

    된다. Query Cache를 사용하지 않으면 눈에 띄는 오버헤드는 없다.

    ( Query Cache는 컴파일시에 --without-Query-Cache 옵션을 사용해서 제외할 수도 있다.)

6.9.1 Query Cache 동작 방식

==============================

동일한 Query문이란?

  MYSQL 서버에 Query문 처리 요청이 들어 오면 Query Cache된 Query문과 같은 Query문 인지 

  비교하는 작업이 먼저 이루어 지는데 이때 Query문의 모든 문자가 일치해야 동일 

  Query문으로 간주 된다.

  따라서 SELECT * FROM TABLE 과 Select * from table 은 다른 쿼리로 간주한다.

  Query문이 일치하더라도 각각 다른 Query문으로 간주되어 따로 캐시 처리 되는 경우도 있는데

  database,프로토콜 버젼,디폴트 character set이 다른 경우이다.

  이때는 각각 다른 Query로 간주되어 각각 캐시 처리 된다.

Query Cache의 제외 대상 

   특정 SELECT문은 Query Cache 대상이 되지 않는 경우도 있는데 

      SELECT CALC_ROWS ... 유형의 쿼리와  

      SELECT FOUND_ROWS () ... 유형의 쿼리는 

   Query Cache의 대상이 되지 않는다.

   아래의 함수를 포함하고 있는 SELECT Query문은 캐시 되지 않는다.

   Function 

   -----------------------

   User-Defined Functions        

   CONNECTION_ID       

   FOUND_ROWS

   GET_LOCK  

   RELEASE_LOCK  

   LOAD_FILE  

   MASTER_POS_WAIT  

   NOW  

   SYSDATE  

   CURRENT_TIMESTAMP  

   CURDATE  

   CURRENT_DATE  

   CURTIME  

   CURRENT_TIME  

   DATABASE  

   ENCRYPT (with one parameter)  

   LAST_INSERT_ID  

   RAND  

   UNIX_TIMESTAMP (without parameters)  

   USER  

   BENCHMARK  

   Query문에 사용자 변수가 있는 경우와

   SELECT ... IN SHARE MODE 유형의 쿼리

   SELECT * FROM AUTOINCREMENT_FIELD IS NULL(마지막 INSERT된 ID를 가져오기 위해)

   유형의 쿼리도 캐시되지 않는다.

   참고로 이전의 Query문의 결과가 캐시에서 가져온 경우라도 FOUND_ROWS()는 정확한 값을 리턴한다.

   또 SELECT Query가 테이블을 대상으로 하지 않는 경우, 

   임시 테이블을 사용하는 경우,

   접속 클라이언트가 Query문 대상의 테이블들중 한 테이블에 대해 컬럼 권한(Column Privilege)을 

   가지고 있는 경우에도 쿼리가 캐시되지 않는다.

Query Cache에 저장된 캐시의 삭제

    테이블이 변경되는 경우(INSERT, UPDATE, DELETE, TRUNCATE, ALTER, DROP TABLE|DATABASE)는 

    해당 테이블(MRG_MyISAM table를 통한 경우도)을 참조한 모든 캐시 데이터가 삭제 되고,

    InnoDb 테이블에서  트랜잭션이 이루어지는 단계에서는 테이블이 변경되는 경우는 

    COMMIT이 실행될때 캐시 데이터가 삭제 된다.

Query Cache 적용시

    Query Cache를 적용시에는 접속클라이언트가 적용할 캐시에 관계된 모든 데이터베이스들과

    테이블들에 대해 SELECT 권한이 있을때만 적용 된다.

6.9.2 Query Cache 환경설정

==============================

Query Cache를 사용하기 위해서는 환경파일의 mysqld 부분이나 mysqld를 커맨트라인에서 실행하는 경우

모두 추가해야 할 사항이 있다.

   . query_qache_limit  결과가 이 값보다 큰 경우 결과를 캐시하지 않는다. ( default 1M)

   . query_qache_size   캐시 하기 위해 메모리상에 확보해야할 메모리 크기

                        이 값이 0이면 Query Cache가 사용되지 않는다.   ( default 0)

   . query_qache_type   숫자형식이며 다음값중 하나가 사용됨

                        0 :  (OFF, 캐시하지 않으며 캐시에서 결과를 가져오지도 않음)

                        1 :  (ON, SELECT SQL_NO_Cache ... 를 제외한 모든 Query 

                                  결과를 캐시함)

                        2 :  (DEMAND, SELECT SQL_Cache ... 쿼리들만 캐시 한다.)

런타임에 thread(connection)에서 동적으로 Query Cache의 기본 동작 방식을 변경할 수도 있는데

문법은 다음과 같다.

Query_Cache_TYPE = OFF | ON | DEMAND 

Query_Cache_TYPE = 0 | 1 | 2 

      (   0 or OFF  : 캐시하지 않으며 캐시에서 결과를 가져오지도 않음

          1 or ON   : SELECT SQL_NO_Cache ... 를 제외한 모든 Query 결과를 캐시함

          2 or DEMAND : SELECT SQL_Cache ... 쿼리들만 캐시 한다.)

6.9.3 SELECT 문에서 Query Cache 옵션들

========================================

SELECT문에 Query Cache와 관련되서 두가지 옵션이 첨가 될 수 있다.

SQL_CACHE : Query_Cache_TYPE이 DEMAND인 경우는 Query를 캐시 한다.

            Query_Cache_TYPE이 ON인 경우 default

            Query_Cache_TYPE이 OFF인 경우 의미 없음

 ex> SELECT SQL_CACHE .....

SQL_NO_CACHE : Query문이 캐시에 저장되지 못하도록 함.

 ex> SELECT SQL_NO_CACHE ...

6.9.4 Query Cache 상태와 유지관리

========================================

FLUSH QUERY CACHE

  FLUSH QUERY CACHE는 Query Cache의 메모리를 조각모음해서 메모리 사용 효율을

  높일때 사용 한다.

FLUSH TABLES

  FLUSH TABLES는 Query Cache를 비운다.

RESET QUERY CACHE

  RESET QUERY CACHE는 Query Cache의 캐시된 모든 쿼리결과를 제거 한다.

Query Cache 지원 여부 확인

  현재 사용하고 있는 MYSQL Version에서 Query Cache가 있는지 여부를 다음과 같이 

  확인 할 수 있다.

  mysql> SHOW VARIABLES LIKE 'have_Query_Cache';

  +------------------+-------+

  | Variable_name    | Value |

  +------------------+-------+

  | have_Query_Cache | YES   |

  +------------------+-------+

  1 row in set (0.00 sec)

Query Cache 성능 모니터

 SHOW STATUS 문을 통해 Query Cache의 성능을 모니터 할 수 있다.

 변수                        설명

 ------------------------    ------------------------------------

 QCache_queries_in_Cache    캐시에 등록된 쿼리 갯수. 

 QCache_inserts             캐시에 추가된 쿼리 갯수. 

 QCache_hits                캐시 Hit(적용된) 갯수. 

 QCache_lowmem_prunes       메모리 부족으로 캐시에서 삭제된 쿼리 갯수. 

 QCache_not_Cached          캐시 불가능한 쿼리 갯수(캐시 불가능 하거나 Query_Cache_TYPE에 의해). 

 QCache_free_memory         Query Cache의 비할당 메모리양. 

 QCache_free_blocks         Query Cache의 비할당 메모리 블럭의 갯수. 

 QCache_total_blocks        Query Cache의 총 메모리 블럭 갯수. 

 총 쿼리 수 = QCache_inserts + QCache_hits + QCache_not_Cached

 Query Cache는 동적인 크기의 블럭을 사용하기 때문에  QCache_total_blocks 과

 QCache_free_blocks은 Query Cache의 메모리의 조각화 현상을 보여 준다.

 FLUSH Query Cache 후에는 QCache_free_blocks의 값이 1이 된다.

 NOTE: 각 Query는 최소한 두 블럭(Query문과 Query결과값)을 사용한다. 

       또, Query에 사용된 각 테이블은 한 블럭을 사용하지만, 여러 Query에서 

       같은 테이블이 사용되는 경우에는 한 블럭만 할당 된다.

 QCache_lowmem_prunes 값을 참조해서 Query Cache의 크기를 튜닝할 수 있다.

 이 값은 새로운 쿼리를 캐시하기 위해 캐시에서 삭제된 쿼리 갯수인데 Query Cache는

 least recently used(LRU : 최근에 가장 사용빈도가 적음) 전략을 통해 Cache에서

 제거할 쿼리를 결정 한다.

유행어는 IT업계에서 피할 수 없는 현실이다. 업계에서 30년을 종사한 사람이나(WYSIWYG을 기억하는가?) 5년을 종사한 사람(‘네티켓’ 아는 사람?) 모두 잘 알지도 못하는 IT 용어가 난무하는 일상적인 대화에 참여하고 있을 것이다. 오늘은 현재 사용되고 있는 최신 유행어 8가지를 살펴보도록 하자. 




1. IoT (사물인터넷) 또는 IoE (만물인터넷(Internet of Everything))

IoT는 우리가 일상적으로 사용하는 자동차, 온도계, 가전제품, 피트니스 밴드, 칫솔 등의 기기와 소위 말하는 "사물"이 임베디드(Embedded) 기술과 웹 연결성을 통해 서로 대화를 나누면서 형성된 복잡한 네트워크이다. 이 용어가 10년 이상 사용되기는 했지만 일반 대중은 최근에야 일상 생황에서 그 영향을 느끼기 시작했다.

애디슨 그룹(Addison Group)의 IT 사업부 지사장 제르 레미스는 "머지 않은 미래에 소비자들은 이동 중에 차 안에서 집이 조명을 끄거나 문을 열거나 차고를 열거나 냉장고에 우유가 얼마나 남아 있는지 보고하도록 명령을 내릴 수 있을 것"이라며, "기술이 계속해서 진화하면서 우리 삶의 모든 면이 더욱 연결되고 자동화될 것”이라고 말했다.

이 때문에 IoT는 업계 전문가들이 "파괴적인" 기술 트렌드를 논할 때 빠지지 않고 항상 등장한다. 에릭슨(Ericsson)의 전략 및 고용 책임자 사무엘 사티아나단은 "에릭슨에서 근무하면서 거의 매일 듣고 있다. 커넥티드 차량, M2M 같은 아이디어와 매우 관련성이 깊다"고 설명했다.

ABI 리서치(ABI Research)에 따르면 2014년 무선 통신 기기가 2013년보다 20% 증가한 160억 개를 초과하면서, 어떤 이들은 ‘사물인터넷’ 대신 ‘만물인터넷’이란 용어를 선호하고 있다. 실제로 ABI는 2020년까지 연결형 기기의 수가 지금의 두 배인 409억 개에 다다를 것으로 전망하고 있다. 하지만 MRE 컨설팅(MRE Consulting)의 CIO 켄 피딩턴은 이 용어가 "휴대폰, 전자제품, 차량부터 동물까지 만물이 연결형 기기화되고 있다는 점을 강조하기 위해 ‘사물인터넷’의 의미를 확장한 것에 지나지 않는다"고 지적했다.

2. BYOE (Bring Your Own Everything) 

물론 직원들이 자신의 개인용 휴대폰, 태블릿, 노트북으로 업무를 처리할 수 있도록 허용하는 기업들의 트렌드인 BYOD(Bring Your Own Device)라는 말은 들어 보았을 것이다. 피딩턴은 “웨어러블 기술을 포함하여 모바일 기기가 성장하고 있는 가운데, 일각에서는 새로운 포괄적인 용어로 BYOE(Bring Your Own Everything)를 주창하고 있다"고 말했다.

실제로, 이미 코그니전트 테크놀로지 솔루션즈(Cognizant Technology Solutions)는 환자가 생명 징후, 유전학, 보건 이력, 건강 정도, 신체 용적 지수, 수면 패턴 등에 관한 데이터를 수집할 수 있는 임베디드형 또는 웨어러블 기기의 숫자가 증가하고 있음을 반영하여 BYOHD(Bring Your Own Health Device)"라는 용어를 만들어 내기까지 했다.

3. 듀얼 페르소나(Dual Persona) 

BYOE 덕분에 사람들이 동일한 기기에서 개인 및 비즈니스 용도를 위한 환경을 분리할 수 있는 휴대폰을 의미하는 "듀얼 페르소나"란 말이 등장하게 되었다. 클라우드 IT 관리 솔루션 업체 베리스믹 소프트웨어(Verismic Software)의 사장 겸 CEO 애슐리 레오나드는 "사용자는 업무 및 가정용 프로필을 동시에 보유할 수 있으며, 2개의 페르소나를 분리함으로써 개인 및 기업용 데이터를 분류하고 보호할 수 있다"고 말했다.

4. 웨어러블(Wearable)

구글이 처음으로 증강현실 안경 구글 글래스(Google Glass)에 관한 계획을 공개했을 때, 회의론과 함께 많은 패러디 영상이 등장했다. 심지어 지금도 많은 이들이 기기를 "이상하지만 흥미로운" 것으로 생각하고 있다. 하지만 오늘날 대부분의 웨어러블 기술이 상업적인 성공을 거두지는 못했지만 자동으로 필수적인 정보를 소비, 공유, 전송, 분석, 제공하는 착용형 기기는 더 이상 비현실적이라는 인식이 사라지게 되었다.

"현재로써는 의료 기기부터 새로운 모바일 기술까지 다각도로 개발되고 있는 기술이며 빠르게 확장 및 발전하고 있다."고 레오나드가 말했다.

손목이 웨어러블을 착용하기에 가장 현실적인 부위로 간주되고 있다. 삼성, 소니, 애플 등의 대기업들이 활동 트랙커와 스마트워치 등을 속속 선보이고 있다. 하지만 기업들이 스마트 귀걸이,깔창 센서, 피부 아래에 삽입하는 혈당 측정기, 자세 감지 핀 등을 개발하면서 신체의 모든 부위가 고려되고 있다. IDC에 따르면 웨어러블은 얼리 어답터의 수준을 넘어 섰으며 2014 년 출고량이 1,900만 대를 넘어 지난 해 대비 3배로 증가했으며 2018년에는 1억1천190만 대로 CAGR 의 78.4% 를 차지할 것이라고 한다.

5. 자가측정(Quantified Self) 

웨어러블 기술을 둘러 싼 유행이 일각에서 말하는 내 일상에 관한 데이터를 수집하고 이 정보를 이용해 행보를 최적화하려는 움직임인 "자가측정"에 대한 관심을 불러 일으키고 있다. 크리스 댄시는 이 트렌드의 지지자로서 수면, 식사, 감정 등을 포함한 자신의 일상에 관한 데이터를 기록하고 분석하여 100 파운드를 감량하고 하루 2갑씩 피우던 담배를 끊었다고 말했다. 많은 모임과 포럼에서 자신의 삶을 측정하는데 관심이 있는 사람들을 지원하고 있다.

6. XaaS (Everything as a Service) 

피딩턴은 "SaaS(Software as a Service)"부터 시작되었지만 서비스형에 관한 트렌드는 곧 서비스형 플랫폼, 인프라, 스토리지, 통신, 네트워크, 모니터링, 비즈니스 프로세스 등 다양한 영역으로 확산되었다. 이제 많은 사람들이 XaaS("자스"로 발음)라고 말하는 것도 당연하다. 기술 외의 부문에서 "'만물'을 서비스로 사용할 수 있게 되면서 이 용어가 더욱 널리 확산될 것이라 생각한다”고 말했다. 이어, "차(ZIP 카스(ZIP Cars)), 주거공간(에어BnB(AirBnB)), 법률(리걸줌(LegalZoom)) 등이 있으며, 계속해서 더 많이 생겨날 것”이라고 덧붙였다.

한편, 어떤 사람들은 XaaS 보다는 더 전통적인 명명법을 선호한다. 사티아나단은 "개인적으로 이 용어를 좋아하지 않으며 SaaS, PaaS 등 좀 더 구체적으로 사용하는 것이 좋다"고 말했다. 피딩턴은 SaaS를 좋아하는 사람들에게 전통적인 직접설치 애플리케이션을 가져다가 클라우드로 이동하거나 서비스로 제공하는 과정인 "SaaS화(SaaSfied)"라는 동사형을 제안하며 "자사의 핵심 제품을 클라우드로 이동하는 것에 대해 설명하는 벤더로부터 이 용어를 처음 들었다. 그 이후로 이 용어를 사용하고 있다"고 강조했다. 최소한 클라우드화보다는 좀 더 구체적이다.

7. 스몰 데이터(Small Data)

유행어가 절정기에 도달하게 되면 업계 전문가들은 해당 용어 이면의 의미를 다시 생각하고 관련된 더 많은 파생어를 만들어 내는 것이 일반적이다. 피딩턴은 “이 때문에 ‘스몰 데이터’ 또는 ‘다크 데이터(Dark Data)’라는 용어를 들어 보았을 것”이라고 덧붙였다. 때로는 빅데이터가 특정 목적에 과분하기 때문에 많은 사람들이 ‘시의 적절하고 유의미하며, 시각적으로 정리 및 패키지화되어 일상 활동에서 접근, 이해, 실행할 수 있는’ 스몰 데이터에 관해 이야기하기 시작했다.

한편, 패딩턴에 따르면 다크 데이터는 기업들이 수집하지만 경쟁을 목적으로 최적화하지 않는 운영 데이터다. 가트너(Gartner)와 기타 출처에 따르면 다크 데이터의 위험은 비즈니스 기회 상실과 필요 이상의 스토리지 비용부터 보안 위험에 까지 이른다고 한다.

8. 랜섬웨어(Ransomware) 

랜섬웨어란 사용자의 컴퓨터를 감염시키고 일반적으로 몸값을 지불할 때까지 민감한 데이터를 암호화하는 악성 소프트웨어를 의미한. 한 예로 크립토록커(CryptoLocker)는 암호화를 이용해 피해 사용자의 소중한 파일 대부분을 잠근다. 레오나드는 “현재 많은 악성 소프트웨어 변종이 개발되고 있기 때문에 가정 사용자 및 기업들에게 랜섬웨어는 계속해서 골칫거리로 남아있을 것"이라고 말했다.

기업들에게 있어서 이런 종류의 공격은 로컬 드라이브 및 기업 네트워크 데이터가 잠재적으로 암호화될 수 있기 때문에 굉장히 치명적이다. 레오나드는 "추후에 대가를 지불한 많은 피해자들이 데이터를 결국 되찾은 적이 없다고 밝혔다. 모든 네트워크 종점을 능동적으로 관리하고 패치할 수 있는 뛰어난 보안 활동과 탄탄한 IT 관리 기술이 필요하다"고 덧붙였다.

다음 유행어는 어디에서 나올까? 기술 마케터들이 아니라면 ‘디지털 유목민(Digital Native)’ 또는 지속적이며 손쉬운 웹 연결성이 없는 세상이 어떤 곳인지 전혀 모르는 젊은 세대에 답이 있을 것이다. 이 부분과 관련하여 피딩턴은 자신의 12살 아들과 친구들의 대화에 귀를 기울이고 있다. 그래서 그는 ‘느린(Laggy)’이라는 말을 사용한다. 패딩턴은 "아들과 친구들이 인터넷 연결이 느릴 때 이 말을 사용한다. 여러 명이 마인크래프트(Minecraft)를 즐길 때 이 말을 여러 번 들었다"고 말했다.

출처 : http://www.rcy.co.kr/xeb/study/8478

PHP에서 GCM 멀티캐스트로 발송하는 방법은 정말 간단하게 구현할 수 있습니다.

GCM에서는 한번 발송에 1000개의 디바이스 토큰을 일괄 발송할 수 있는 멀티캐스트 기능이 포함되어 있어, 무척 편리해 졌는데요

100만건을 발송하더라도, 1000회만 커넥션을 맺으면 되므로 발송 속도가 무척이나 빠르겠죠..

우선, PHP에서 GCM발송 라이브러리를 작성합니다.

아래 라이브러리는 Github에서 가져왔습니다.  

GCMPushMessage.php

<?php /* Class to send push notifications using Google Cloud Messaging for Android Example usage ----------------------- $an = new GCMPushMessage($apiKey); $an->setDevices($devices); $response = $an->send($message); ----------------------- $apiKey Your GCM api key $devices An array or string of registered device tokens $message The mesasge you want to push out @author Matt Grundy Adapted from the code available at: http://stackoverflow.com/questions/11242743/gcm-with-php-google-cloud-messaging */ class GCMPushMessage { var $url = 'https://android.googleapis.com/gcm/send'; var $serverApiKey = ""; var $devices = array(); function GCMPushMessage($apiKeyIn){ $this->serverApiKey = $apiKeyIn; } function setDevices($deviceIds){ if(is_array($deviceIds)){ $this->devices = $deviceIds; } else { $this->devices = array($deviceIds); } } function send($title, $message, $link){ if(!is_array($this->devices) || count($this->devices) == 0){ $this->error("No devices set"); } if(strlen($this->serverApiKey) < 8){ $this->error("Server API Key not set"); } $fields = array( 'registration_ids' => $this->devices, 'data' => array( 'title' => $title, 'message' => $message, 'link' => $link ), ); //echo json_encode($fields); //exit; $headers = array( 'Authorization: key=' . $this->serverApiKey, 'Content-Type: application/json' ); // Open connection $ch = curl_init(); // Set the url, number of POST vars, POST data curl_setopt( $ch, CURLOPT_URL, $this->url ); curl_setopt( $ch, CURLOPT_POST, true ); curl_setopt( $ch, CURLOPT_HTTPHEADER, $headers); curl_setopt( $ch, CURLOPT_RETURNTRANSFER, true ); curl_setopt( $ch, CURLOPT_POSTFIELDS, json_encode( $fields ) ); // Execute post $result = curl_exec($ch); // Close connection curl_close($ch); return $result; } function error($msg){ echo "Android send notification failed with error:"; echo "\t" . $msg; exit(1); } } ?>

발송은 send 페이지에서 다음과 같이 작성합니다.

$devices는 Array변수로 디바이스 토큰값을 담아주면 됩니다. (최대 1000개)

만약, 등록건수가 1만건이다...  어떻게 1000으로 나눌수가 있을까요??

PHP에서는 아주 간단한 Array함수를 가지고 있더군요..

1만건을 $devices에 담아 array_chunk 함수로 나누면 되는거죠... 1000건씩...

array_chunk 함수는 아주 간편하게...나눠주니.. 계산할 필요없이 아주 편리하게 사용하면 됩니당@!!

http://php.net/manual/en/function.array-chunk.php

출처 : http://nonstop.pe.kr/php/1674