글라발제이션 – 문자 세트 및 인코딩

컴퓨터는 미국이 만들었다!! ASCII 는 쉽다!! 그러나, 우린 한국인이다!! ㅠㅠ

영어는 LTR 이다!! 한국어도 LTR 이다!! 그러나, 난 영어를 못한다!! ㅠㅠ

그런데, 나보고 RTL 을 지원하라고 한다?! ㅠㅠ

http://en.wikipedia.org/wiki/Bi-directional_text

locale

0. 글로발제이션!!

우리는 영어권이 아님에도 불구하고, 저를 포함해서 많은 개발분들이 i18n 이슈에 대해서 잘 모르고 있습니다. 글자가 깨지거나, 제대로 출력되지 않을 때에 참으로 곤란합니다. 제대로 출력이 되었어도, 제대로 인코딩이 되었는지 보장되기 어렵습니다.

http://en.wikipedia.org/wiki/Internationalization_and_localization

이런 어려움에 도움이 되실지 몰라서 정리해보았습니다.

 

1. 로케일 환경변수 ( Locale Environment Variables )

기본 시스템의 locale 에서 korean 와 LCID ( Locale ID ) 지원여부를 확인하고, 만약에 설치가 안되어 있다면 localedef ( locale-gen ) 커맨드로 추가해주시면 됩니다. 그리고, shell 에 맞게 export or set 으로 환경변수를 설정해주시면 되니다.

http://www.microsoft.com/resources/msdn/goglobal/default.mspx

$ locale -a | grep ko_KR

ko_KR

ko_KR.euckr

ko_KR.utf8

$ localedef -f UTF-8 -i ko_KR ko_KR.UTF-8

$ export LANG = ko_KR.utf8

$ export LC_ALL= ko_KR.utf8

 

2. 터미날 케릭터셋 ( Terminal Characterset )

Terminal 의 characterset 을 shell 환경변수와 동일하게 맞추어 줍니다. Putty 의 경우에는 기본적으로 UTF-8 를 포함하여 30여가지 characterset 을 내장하고 있습니다. 그러나,  영문 공식 Putty  에서 지원하지 않는 characterset 을 사용하여 한다면?! 어떻게 해야할까요?!

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

다음과 같이 2가지 방법이 있습니다.

  1. 소스를 수정하여 내가 직접 캐릭터셋을 추가한다.
  2. Google 님께 소원을 빈다. 누군가가 이미…

공식 홈페이지 링크를 참고하시거나, 구글링하셔서 구하시면 됩니다. 단언컨데, Putty 보다 완벽하게 캐릭터셋을 지원하는 Terminal Emulator 는 없습니다. 단, 그 언어를 쓰는 엔지니어, 개발자, 키보드가 있을 때에만…

http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html

Internationalised and localised versions :
PuTTYjp, with ISO-2022 support and other things Japanese
PuTTY DBCS Patched, with a Chinese feel
Arabeyes PuTTY, a project to add Arabic support to PuTTY (this code is now included in our releases)
iPuTTY/HangulPuTTY, an internationalised fork with an emphasis on Korean support
Polish localised version of PuTTY (no source)

Putty ->  Windows -> Translation -> UTF-8

SNAG-0001 2016-08-30 오후 9.19.07

그리고, 매우 중요한! Font 도 설정해주셔야 합니다. 이 부분을 모르시는 분이 상당히 많아서 해당 나라/언어 Window 를 설치하시는 경우도 있습니다. 그냥, 언어지원하는 Font 만 설치하시면 됩니다. ( 간혹 MS Window 에서 실행되는 프로그램의 경우는 MS AppLocale, LanguagePack 으로도 문제가 되는 경우가 있기 때문에 해당 나라별 Window 를 설치하는 경우도 있습니다. )

 

3. 폰트 ( Font )

Putty -> Window -> Appearance -> Font

SNAG-0002 2016-08-30 오후 9.20.10

글꼴 -> 굴림체 -> 스크립트 -> 한글

SNAG-0003 2016-08-30 오후 9.20.38

글꼴 -> Courier New -> 스크립트 -> 영어

SNAG-0004 2016-08-30 오후 9.20.52

그렇다면, CJK ( China Japan Korea ) 중국어는?! 일본어는?!

역시 Google 님께 Font 은총을 내려 달라고 기도합니다.

http://www.google.com/get/noto/

 

4. 파일 인코딩 ( File Encoding )

File Encoding 을 확인하여 합니다. 100% 신뢰하기는 어려울 수도 있습니다. 다국어 ( multilingual ) 를 포함할 경우, 이상한 값들이 포함된 경우가 있기 때문입니다. 추가적으로 file type 에 따라서 BOM ( Byte Order Mark ) 등을 체크해볼 필요가 있습니다.

$ file text.txt

text.txt: UTF-8 Unicode text

file command 로 확인이 어렵거나, 애매할 때, 혹은 전혀 모르는 언어와 인코딩으로 되어 있어 있을 경우에는 어떻게 해야 하나!?

이럴쭐~ 알고~ 내가 준비했지!!

이런 고민은 우리가 매일같이 쓰고 있는 Web Brower 에서 이미 끝난 얘기입니다. ( 그러나, 100% 는 불가능?! )

mozilla

http://www-archive.mozilla.org/projects/intl/chardet.html

https://en.wikipedia.org/wiki/Charset_detection

https://wiki.kldp.org/wiki.php/%B1%E8%C1%A4%B1%D5/CharDet

Python chardetect 2.2.1

$ chardetect text.txt

text.txt: utf-8 with confidence 0.7525

그리고, 원하는 인코딩이 아닐 경우에는 어떻게 해야 하나!? convert 해주면 된다. 그리고, 같은 characterset 으로 convert 함으로써 characterset valid 를 할 수 있습니다.

$ iconv -l | grep UTF-8

$ iconv -f EUC-KR -t UTF-8 -o utf8.txt text.txt

$ iconv -f UTF-8 -t UTF-8 -o utf8.txt text.txt

 

5. 에디터 인코딩 ( Editor Encoding )

Editor Encoding 설정을 해줘야 합니다. 만약에 vim 이 지원하다면?! 다른 Editor 를 써야 합니다.

http://vimdoc.sourceforge.net/htmldoc/mbyte.html

$ vim $HOME/.vimrc

set encoding=utf8

set fileencoding=utf8

RTL ( Right To Left ) Language 라면 ?!

:set rightleft

 

6. 한국사람 인코딩 ( Korean Encoding )

마지막으로 한국어를 읽기쓰기가 가능한 사람이 필요합니다! 만약에 없다고 한다면, Hex Dump 를 해서 값들을 체크하고, Google Translate 를 통해서 확인하는 방법도 있습니다.

그러나, 1회성이나 단순한 문장이면 모르겠지만, 해당 언어와 문화를 아는 사람이 필요합니다.

hello. 안녕하세요. こんにちは

https://translate.google.co.kr/#en/ja/hello.

Advertisements

왜 동네짱은 PostgreSQL에서 MySQL 으로 데이터베이스를 마이그레이션?

이전글

https://mysqlko.wordpress.com/2016/08/05/mysql-vs-postgresql-uber

 

97d37ea1d4a07355a3be45d80001e985
우석고 실질적 짱 : 현상태

Why Uber migrated its databases from Postgres to MySQL?

http://blog.webyog.com/uber-migrated-databases-postgres-mysql

 

Uber 사태?! 에 대한 PostgreSQL 진영!?의 글에 이어서 MySQL 진영?! 글이 올라 왔습니다.

webyog 란?!

SQLyog : MySQL GUI & Admin  과 MONyog : MySQL Monitor 를 만드는 회사입니다. SQLyog Community 버전도 있습니다.

https://www.webyog.com/product/downloads/

PostgreSQL 제한?! 한계?!

  1. Inefficient architecture for writes: A relational database must perform certain key tasks that Postgres were not suited for Uber’s needs.
    • Providing efficient insert/update/delete capabilities
    • Providing capabilities for making schema changes
    • Implementing a MVCC mechanism so that different connections have a transactional view of the data they work with.

  1. 비효율적인 쓰기 구조?! : 우버는 다음과 같은 RDBMS 요건을 필요로 한다. 그러나, PostgreSQL 은…
  • INSERT/UPDATE/DELETE 가 효율적이야 한다. / OLTP 성능이 좋아 한다.
  • 스키마 변경이 되어야 한다. / ALTER 구문이 효율적이야 한다.
  • 서로 다른 연결에 대해서 트랜잭션날 관점에서의 MVCC 메카니즘 구현이 필요하다. / CTID ( OID, RID  동일 ) 값이 물리적 오프셋값(green) 으로 되어 있어서 비효율적이다. CTID 값이 변경시 모든 index 가 변경되어 한다.

With Postgres, the primary index and secondary indexes all point directly to the on-disk tuple offsets. When a tuple location changes, all indexes must be updated.

  • Inefficient data replication: Postgres’ replication required higher bandwidth as compared to MySQL but Postgres replication may not be a problem within a single data center. The real problem with Postgres arises when replication is done between multiple data centers.
  • 비효율적인 데이터 리플리케이션 : PostgreSQL Replication 은 MySQL 대비해서 높은 대역폭(bandwidth) 을 요구하다. 그러나, PostgreSQL Replication 은 데이터센터 내에서는 문제가 되지 않는다. / DC-to-DC 간에는 문제가 될 수 있다?!

  • Issues with table corruption: During one of Uber’s routine master database promotion to increase database capacity, they encountered a Postgres 9.2 bug. This resulted in numerous incorrect timeline switches on replicas that were being undertaken.
  • 테이블 손상 이슈 : 마스터 서버중 하나가 과도한 용량 증가 버그가 PostgreSQL 9.2 에서 있었다. 이 버그는 복제에까지 수많은 영향을 미쳤다. / 마스터서버의 버그가 슬레이브까지 영향을 미쳤다.

  • Poor replica MVCC support: Postgres does not have true replica MVCC support. The fact that replicas apply WAL updates results in having a copy of on-disk data identical to the master at any given point in time.
  • 가난한 리플리카?! MVCC 지원 : PostgreSQL 은 레알 리플리카 MVCC 를 지원하지 않는다. 실제로, 리플리카는 WAL 업데이트가 디스크에 쓰여진 복사본을 가진 시점에서 동일하게 적용된다. / WAL 로그가 디스크에 반영된 후에 복사본을 가지고 이루어지다 보니, 성능이 좋지 않다.

  • Difficulty upgrading to newer releases: With different general available releases of Postgres, it was not possible to replicate the data. Replication records work at the physical level which made it difficult for Uber.
  • 새로운 릴리즈 업그레이드 어려움 : PostgreSQL 은 GA 릴리즈 버전간의 데이터 리플리케이션이 가능하지 않다. 물리적 레벌에서 복제는 우Uber 를 힘들게 했다. / 이중화 구성시 한쪽만 순차적 업그레이드가 불가능하다. downtime 이 불가결하다?!

구글번역기 감사합니다!! ㅠㅠ

이에 반해서 MySQL 은… 생략?!

결국 Uber 가 PostgreSQL 에서 MySQL 로 바꾼 이유는 크게 보면 2가지 입니다.

성능 (Performance)  and 운영, 가용성 ( High Availability, Replication )

예전부터 OLTP : MySQL , OLAP : PostgreSQL 이란 선입견이 일반적이었습니다. 많은 글로벌 서비스가 메인DBMS 를 MySQL 을 채용하고 있는데, 그 이유 중 하나는 글로벌 서비스 자체가 OLTP : high short-request 이기 때문입니다. 거기에, PostgreSQL 이 WAL( Physical Log  ) Replication 을 default 로 하고 있다보니, 그로 인해서 Master-Slave upgrade ( downtime ), Master- Slave incorrect, Replication Performance 등이 뒤따서 이슈가 된 것 같습니다.

결국 Uber 와 같은 글로벌 서비스에서는 운영관리가 편한 자알~ 알려진 Open Source 기반의 OLTP DBMS 가 적합했던 것 같습니다.

PostgreSQL 은 Logical Log Replication 을 지원합니다. 향후에는 default 가 되지 않을까!? 라고 생각됩니다. 그리고, INSERT/UPDATE/DELETE 성능에 대해서는 PostgreSQL 9.x 부터는 성능 이슈에 대해서 EDB 가 크게 기여하고 있기 때문에, 향후 버전업에 따라서 많은 개선이 있으리라 봅니다. 그리고, PostgreSQL 9.6 GA 에는 Parallel Query 가 지원된다면 많은 개선이 되리라 봅니다.

추가적으로, 드루팔 7.x 성능 비교 자료를 보시면 PostgreSQL vs MySQL 성향차이를 이해하는데 도움이 되리라 봅니다.

Comparing PostgreSQL 9.1 vs. MySQL 5.6 using Drupal 7.x

http://posulliv.github.io/2012/06/29/mysql-postgres-bench/

 

MySQL vs PostgreSQL, 뭣이 중헌디 뭣이!?

뭣이 중한지도 모르면서…

image

최근에 이슈가 되고 있는 Uber 사태!?를 아십니까!?

Why Uber Engineering switched from Postgres TO MySQL by Evan Klitzke, 06.26.2016

이전부터 낌새는… ㅠㅠ

Designing Schemaless, Uber Engineering’s  Scalable Datastore Using MySQL BY Jakob Holdgaard Thomsen, 01.12.2016

그런데, 예전에는…

Migrating Uber from MySQL to PostgreSQL by Evan Klitzke, 03.13.2013

MySQL 의 경우는 Google, Twitter, Facebook, … 등 누구나 알만한 글로벌 서비스에서 RDBMS 로 사용되고 있습니다. 2014년에는 MySQL 5.6 Branch 에서 WebScaleSQL 로 fork 하였습니다. 작년에는 Alribaba 도 참여하였습니다.

그에 반해서 PostgreSQL 은 딱히 떠오르는 서비스와 기업이 없습니다. Yahoo, MySpace, Skype 등이 사용한다고 하지만, 공개된 내용들도 별로 없고, MySQL 대비해서는 서비스 및 기업들이 핫하지 못합니다.

거기에 광명같은 존재가 Uber 였는데 최근에 MySQL Migration – Engineering blog 에 장문의 디스같은 디스같지 않은 글을 올려서 Y’s Hacker News 와 PostgreSQL Community 에도 글이 올라 왔습니다.

PostgreSQL 를 리딩하는 2개의 회사의 글도 올라왔습니다. 조금 늦게 올라온 감이 있습니다.

2ndQuadrant’s Simon Riggs

EDB’s Robert Haas

영어가 짧은지라… 대충 훑어봤습니다.

Uber 의 지적질은  디테일합니다. 그리고, 대부분 불편한 진실!?입니다. 그에 반해서 EDB 와 2ndQuadrant 의 항변?!은 딱히 와닿지 않습니다. ㅠㅠ

여기서 맹점은…

We encountered many Postgres limitations:

  • Inefficient architecture for writes
  • Inefficient data replication
  • Issues with table corruption
  • Poor replica MVCC support
  • Difficulty upgrading to newer releases

요약하면…

  1. performance
  2. replication ( shard )

2가지 항목에 대해서 반박글들은 어느 정도 타당하고, 반납득이 가는 내용들입니다. 그러나, 근본적으로 이슈(문제) 자체의 해결책을 제시한 것은 아닌 듯 합니다. 명확하게 더 빠르다라고 주장은 안하고 있습니다. 역시 성능에 관해서는 한풀 접고 들어갑니다.

조금은 지난 글이지만, PostgreSQL vs MySQL 성능이슈에 대한 좋은 블로깅이라고 생각합니다.

추가적으로 비교한다면…

  • PostgreSQL vs MySQL
  • Strict RDBMS vs Non-Strict RDBMS
  • MultiProcessing vs MultiThreading
  • Buffered IO vs Direct IO
  • Logical Replication vs Physical Replication

결론은?!

OLTP is…
MySQL > PostgreSQL

OLAP is…
MySQL < PostgreSQL

슬라이드4

Uber is …

“The early architecture of Uber consisted of a monolithic backend application written in Python that used Postgres for data persistence. Since that time, the architecture of Uber has changed significantly, to a model of microservices and new data platforms. Specifically, in many of the cases where we previously used Postgres, we now use Schemaless, a novel database sharding layer built on top of MySQL. In this article, we’ll explore some of the drawbacks we found with Postgres and explain the decision to build Schemaless and other backend services on top of MySQL.” (Thanks to Dimitri John Ledkov)

 

이 이슈는 MySQL 10.x vs PostgreSQL 10.x 에서 다시 논의해야 할 필요가 있습니다. PostgreSQL 9.6 부터는 Parallel Query 가 지원됩니다. 그래도, insert/update 성능은 크게 달라지지 않으리라 봅니다. ^^;

 

Ref :

중국이 무섭다?! ㅠㅠ

https://yq.aliyun.com/articles/58421

luke 요약글

http://use-the-index-luke.com/blog/2016-07-29/on-ubers-choice-of-databases

Innodb Full-Text Search : Part 1

슬라이드3

 

오늘은 MySQL Server Blog 에 올라온 MySQL FTS ( Full-Text Search ) 에 대해서…

 

FTS ( Full-Text Search ) 란?

https://en.wikipedia.org/wiki/Full_text_search

 

MySQL 5.5 때까지는 MyISAM 만 FTS 를 지원하였지만, MySQL 5.6 부터는 InnoDB 엔진도 지원하고 있습니다.

http://www.drdobbs.com/database/full-text-search-with-innodb/231902587

 

MySQL 5.7.3 부터 CJK ( China, Japan, Korea ) 를 위한 plugin parser in fulltext index 를 지원합니다.

http://mysqlserverteam.com/innodb-supports-plugin-parser-in-fulltext-index/

 

MySQL Server Team Blog 에 올라온 N-gram & MeCab Parser 에 대해서…

 

Category Archives: Full Text Search

http://mysqlserverteam.com/category/full-text-search/

 

InnoDB Full-Text: MeCab Parser ( China )

http://mysqlserverteam.com/innodb-full-text-mecab-parser/

 

InnoDB全文索引:N-gram Parser ( China )

http://mysqlserverteam.com/innodb%E5%85%A8%E6%96%87%E7%B4%A2%E5%BC%95%EF%BC%9An-gram-parser/

 

InnoDB 全文検索 : N-gram Parser ( Japan )

http://mysqlserverteam.com/innodb-%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2-n-gram-parser/

 

InnoDB 全文検索 : MeCab Parser ( Japan )

http://mysqlserverteam.com/innodb-%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2-n-gram-parser/

 

InnoDB 전문 검색 : N-gram Parser ( Korea )

http://mysqlserverteam.com/innodb-%EC%A0%84%EB%AC%B8-%EA%B2%80%EC%83%89-n-gram-parser/

 

 

여기서 잠깐,

N-gram 은 ( n byte or lexim 긴가민가?! ㅠㅠ) 이기 때문에 CJK 문제가 없습니다?! 그런데, MeCab 는 일본어를 위한 엔진인데, Japan 과 Korea 는 어순도 LR 이고, 문법도 비슷한 점이 많아서 엔진과 사전을 조금만 수정해서 쓴다고 하지만, China 는 모르겠습니다. 그리고, 사전도 일본어 IPADIC 를 씁니다?!

우리는 은전한닢이란 MeCab Fork 프로젝트가 있습니다!? 일본이라서 고맙다!? ㅠㅠ

 

Shaohua Wang 란 Oracle China 분인 것 같은데, 아는지 모르는지…

 

“MeCab is a Japanese morphological analyzer, and we now have a full-text plugin parser based on it!”

 

MeCab : Yet Another Part-of-Speech and Morphological Analyzer

http://taku910.github.io/mecab/

http://mecab.googlecode.com/svn/trunk/mecab/doc/feature.html

 

IPADIC

http://parame.mwj.jp/blog/0209

 

은전한닢 프로젝트

http://eunjeon.blogspot.kr/

 

MeCab-Ko-Dic

 

https://bitbucket.org/eunjeon/mecab-ko-dic

 

기타참고

http://d.hatena.ne.jp/studio-m/20091108/1257668762

 

결론은…

N-gram FTS Parser 는 CJK 상관없이 쓰셔도 되지만, MeCAB Parser 는 엄밀히 언어별, 인코딩별 형태소분석기 ( Tokenizer ) + 사전( Dictionary ) 이 필요합니다. 일본과 우리는 문제 없다!? ㅠㅠ

MySQL 5.7.7 에는 기본적으로 libpluginmecab.so 과 ipadic_euc-jp, ipadic_sjis, ipadic_utf-8 이 포함되어 있습니다.

 

MySQL InnoDB is DEAD ?!

슬라이드1

Linkbench for MySQL & MongoDB with a cached database

http://smalldatum.blogspot.kr/2015/07/linkbench-for-mysql-mongodb-with-cached.html

 

Mark Callaghan 옹의 small datum 블로그에 RocksDB, MongoDB 게시글들이 많이 올라오고 있습니다.

언제부터인가 OLTP 에서 MySQL vs PostgreSQL 이 아닌, MySQL vs MongoDB 구도가 되어 버린 탓도 있을거고, MongoDB 가 WireTiger 를 선택해서!? Tim 이 팽당함?! ^^;

RocksDB 는 Facebook 에서 만들고 있는 LevelDB 기반의 key-value storage engine 입니다.

왜 engine 일까요?! MySQL, MongoDB, 등등 engine 을 교체해서 본인들이 원하는 성능과 기능을 추가하고 싶은거겠죠!? 물론 독립적으로도 사용가능합니다. 기능은 모르겠지만, 성능은 좋습니다. LevelDB 기반들의 공통점이죠?!

http://rocksdb.org

 

그런데, 왜 Facebook 은 InnoDB 를 개선하지 않고, RocksDB 를 만들었고, Tokutek 은 TokuDB 를 만들었을까요?!

InnoDB vs TokuDB vs RocksDB

B-Tree, B*Tree, B+Tree 란 자료구조의 근본적인 성능이슈 때문이기도 하고, 스토리지가 spin disk to flash 로 변하는 패러다임에, memory device 의 가격하락, OTLP 부하 증가, 등등으로 인해서 B+Tree 보다는 다른 자료구조를 찾게되었죠. ( HDD to SSD, SSD to MEM 심화때문이죠! )

TokuDB -> fractal tree, RocksDB -> LSM

https://en.wikipedia.org/wiki/Fractal_tree_index

https://en.wikipedia.org/wiki/Log-structured_merge-tree

 

최근에는 InnoDB engine 의 insert 성능, 용량때문에, TokuDB engine 를 혼용해서 사용하는 곳이 많습니다. 그럼에도, Oracle MySQL 5.7 engine list 에 들어가 있지는 않습니다. ( 예전에 InnoDB 범용적으로 많이 쓰임에도 MyISAM 을 제끼고 default engine 으로 되는데 오래 걸리긴 했습니다. ) TokuDB engine 의 안정화 이슈도 있고, 3rd party 와의 호환성, FK 미지원, backup tool 등 많은 이슈가 있긴 합니다.

앞으로 향후에도 Oracle MySQL 은 TokuDB, RocksDB, BlahDB, BlahDB~ 가 나와도 절대로 InnoDB 를 바꾸지 않을겁니다. Oracle 은 SUN 보다 Innobase 를 먼저 인수하였고, 모든건 다 계획대로?!

https://en.wikipedia.org/wiki/Innobase

 

MySQL 은 Oracle 로 인수된 후로 글로벌한 이슈를 못따라가고 있습니다. 아니 안따라가고 있습니다. 물론 enterprise 와 open source 개발은 좀 성격이 달라서 빠르게 따라가기는 힘든 부분이 있긴 합니다. ^^;

향후에도 InnoDB 로 대응하기에는 한계가 있기 때문에 TokuDB, RocksDB, BlahDB, BlahDB~ engine 을 고려된 아키텍처 및 운영이 되어야할 것 같습니다.

 

기승전FB !! 대동단FB !!

Rocks 는 InnoDB 대비해서 insert 성능은 좋으나, TokuDB 보다는 못합니다. 그러나, FB 님이 지속적으로 개선해주시라 보고, 앞으로 어떤 멋진 것들을 내놓으실지 모릅니다?! ( 사실 TokuDB 이 더 앞서나갈 것 같습니다. percona 로 인수 되었기 때문에 MongoDB 미련을 버릴테니… )

용량이슈도 해결되리라 봅니다?!

https://github.com/MySQLOnRocksDB/mysql-5.6/issues/80

Using Cgroups to Limit MySQL and MongoDB, Redis memory usage

슬라이드1

 

PERCONA MYSQL PERFORMANCE BLOG Vadim Tkachenko 님의 게시글 : 

Ref : https://www.percona.com/blog/2015/07/01/using-cgroups-to-limit-mysql-and-mongodb-memory-usage/

 

요즘 많은 솔루션 및 오픈소스 프로젝트들이 In-Memory Processing 이라고 하지만…

실제로 In-Memory Architecture 기반이라고 보기는 힘든 부분이 많습니다. 그 예가 Memory Management 입니다.

MySQL 의 경우에는 my.cnf 를 보시면 대부분의 설정값들은 memory allocate 를 합니다.

innodb_buffer_pool_size + innodb_log_buffer_size + innodb_sort_buffer_size + * _size …

이렇게 할당된 값의 총합 + @ 만큼 메모리가 할당됩니다.

그런데말입니다. 문제는 이 값들이 갈수록 갈수록 늘어난다는 말입니다!! memory fragmentation !!

그래서, cgroup 으로 OS 레벨에서 강제로 limit 를 걸어야 하는 경우가 생깁니다.

또, 다른 방법으로 numactl 로 memory affinity 하는겁니다.

 

Cgroups 란?

Ref : http://www.slideshare.net/sprdd/linux-performan-tuning-part-1

 

MySQL vs NUMA

Ref : http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

 

그리고, 이런 이슈는 MySQL, MongoDB 말고도 대부분의 In-Memory 기반에서 문제가 되고 있습니다.

 

Deview 2014 : ARCUS 차별 기능, 사용 이슈, 그리고 카카오 적용 사례

Ref  : http://deview.kr/2014/session?seq=9

 

How to change mysql time_zone

MySQL Timezone 설정방법입니다.

 

What’s Timezone ?!

시간대(時間帶)는 영국의 그리니치 천문대를 기준으로 (경도 0도) 지역에 따른 시간의 차이, 다시 말해 지구의 자전에 따른 지역 사이에 생기는 낮과 밤의 차이를 인위적으로 조정하기 위해 고안된 시간의 구분선을 일컫는다. 시간대는 협정 세계시(UTC)를 기준으로한 상대적인 차이로 나타낸다.

 

How-to

1.  Timezone 확인

$ date +%Z

KST

$ date +%z

+0900

$ cat /etc/sysconfig/clock

ZONE=”Asia/Seoul”

 

2. Timezone 설정

$ ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime

or

$ ln -sf /usr/share/zoneinfo/UTC  /etc/localtime

$ vi /etc/sysconfig/clock

ZONE=”Asia/Seoul”

UTC=true

ARC=false

or

$ tzselect

or

export TZ=”Asia/Seoul”

 

3. MySQL Timezone Table 설정

$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -D mysql -u root -p

$ mysql -u root -p

mysql> select count(*) from mysql.time_zone;

+———-+
| count(*) |
+———-+
| 1738     |
+———-+
1 row in set (0.00 sec)

 

4. MySQL Timezone 확인

$ mysql -u root -p

mysql> SELECT @@global.time_zone, @@session.time_zone;

+—————————+—————————+
| @@global.time_zone | @@session.time_zone |
+—————————+—————————+
| SYSTEM                  | SYSTEM                    |
+—————————+—————————+
1 row in set (0.00 sec)

 

mysql> show variables like ‘%time_zone%’;
+———————–+———–+
| Variable_name         | Value     |
+———————–+———–+
| system_time_zone | KST       |
| time_zone            | SYSTEM |
+———————–+———–+
2 rows in set (0.00 sec)

 

5. MySQL Timezone 설정

$ mysql -u root -p

mysql> set @@global.time_zone=’Asia/Seoul’;

mysql> set global time_zone =’Asia/Seoul’;

mysql> set @@session.time_zone = “+00:00”;

mysql> set session time_zone =’Asia/Seoul’;

mysql> set time_zone = ‘Europe/Helsinki’;

mysql> set time_zone = “+00:00”;

mysql> select now();

 

set_time_zone

 

MySQL Timezone Support

 

MySQL Server Variables

 

Ref :

MySQL & MariaDB blog list – 14Q3v1

MySQL & MariaDB 관련해서 참고할만한 블로그 또는 사이트를 공유합니다.

 

MySQL Performance Blog

> 제일 유명한 블로그 중 하나일 겁니다. 게시글도 좋지만, 필히 덧글을 추가로 읽어보실 것을 권합니다. 성능에 대한 부분은 100% 신뢰하긴 힘듭니다. 그들은 MySQL Expert 입니다.

 

MySQL Performance Engineer

> 이런 스타일의 그래프는 99% !! dimitrik 블로그의 자료입니다. Oracle MySQL 에 성능문의를 하신다면 dimitrik 의 답변(의견)일 수도 있습니다.

 

MySQL Sandbox & Tungsten Replicator

> sandbox & gearmand 창시자이시며, 지금은 continuent 에 계십니다. tungsten replicator 참고할만 합니다.

 

MySQL Developer

> handlersocket 창시자이시며, 지금은 facebook 에 계십니다. 최근에는 WebScaleSQL 에 참여하시고 계십니다. slideshare 에서 yoshinori matsunobu 슬라이드는 필독입니다.

 

Kakao DB Team

 

ronald bradford blog

 

Mikael Ronstrom

> My name is Mikael Ronstrom and I work for Oracle as Senior MySQL Architect. I am a member of the LDS church. The statements and opinions expressed on this blog are my own and do not necessarily represent those of Oracle Corporation