Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

DBMS에게 SSD란?

Database System과 SSD의 관계, 그리고 장단점
by

Kieun Park

on 12 March 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of DBMS에게 SSD란?

HDD vs SSD SSD를 쓰면 DB 성능이 올라간다!? NoSQL과 SSD 그래서 결론은? 그럴 수도 그렇지 않을 수도 있다. 왜 그럴까?
DB 성능에 I/O는 critical point이고, 그렇다면 I/O가 월등히 빠른 SSD를 쓰면 DB 성능이 올라가야 하는 것이 맞지 않을까? RDBMS에서는 어떤 상황일 때 SSD가 좋은가? SSD는 random read에 강하다. Random write도 어느 정도. 그러나 sequential write에는 약하다. (HDD보다는 낫지만)

SSD가 HDD를 완전히 대체하지는 않을 것이다. SSD는 계속 HDD와 메모리 사이에 위치할 것이다. (why? 가격 대비 용량)

DB에게는 아직도 메모리가 가장 중요한, 가장 빠른 리소스임을 잊지 말아야 한다. 예를 들어 MySQL을 NoSQL처럼 쓰는 법 등의 경우를 생각해 보자.

RDBMS의 성능 형상을 위한 노력(예. index, query tuning, partitioning, sharding)을 SSD로 대체하려고 하지 말아야 한다.

모든 SSD에서의 DB 테스트 결과에는 꼭 이런 말이 붙는다.
"Sophisticated caching system letting the HDD perform or even top the SSD under certain limited circumstances." DBMS에게 SSD란? Database System과 SSD의 관계, 그리고 장단점 2013.3.8 박기은 SSD가 HDD보다 빠르니 DB 성능이 올라가겠지?
아닌가? RDBMS와 SSD의 궁합이 맞는 경우와 맞지 않는 경우
그 이유는? NoSQL에서는 SSD가 좋을까 나쁠까?
뭐가 다르길래... 참고 자료
MySQL Performance Blog > SSD Benchmark
MySQL and SSD (Percona)
SSD Deployment Strategies for MySQL
TechNet Magazine > SQL Server Q&A
Pythian > De-Confusing SSD for Oracle Databases
nPlatform 12년 9월호
myNoSQL > Cassandra and SSD Q1. SSD는 항상 HDD보다 빠른가? 어떤 I/O pattern에서도?
Q2. HDD 대비 SSD가 빨라진 성능이 몇 % DB 성능 향상으로 나타날까? 50%? 100% 150%?

Q3. 메모리를 늘리는 것이 좋은가? HDD를 SSD로 바꾸는 것이 좋은가? http://it.donga.com/241/ http://blog.naver.com/shcsis/100152802660

SSD는 플래시 메모리 칩을 6개에서 10개 정도 연결해서 만든다. RAID 기술과 유사하게 다수의 메모리에 동시에 기록하고 읽어들여 속도를 높인 것이다.
(인텔은 플래시 메모리 10개를 연결했고, 플래시 메모리 한개당 27MB/s 정도의 10배 속도인 260MB/s 정도의 속도를 낸다.)

Samsung SSD 840 PRO는 540MB/s의 random read/write 속도를 자랑!
http://samsungsemiconstory.com/212 그렇지만 HDD도 많이 느린 것은 아니다! SAS 10Krpm, RAID 0 SAS 15Krpm, RAID 0 SAS 10Krpm, RAID 5 SAS 15Krpm, RAID 5 SSD의 장점은 HDD와 달리 데이터를 찾기 위해 디스크를 회전시키고 헤드를 이동하는 mechanical overhead가 없다는 것이다.
(*) HDD에서 I/O wait는 seek time! 4~15ms vs 0.1ms SSD의 치명적인 단점은 데이터의 기록 과정이 단순하지 않다는 것,
그리고, write 가능 회수가 정해져 있다는 것. http://blog.naver.com/shcsis/100152802660)
USB 메모리와 SSD 등 플래시 메모리를 저장소로 쓰는 기기는 4KB(페이지) 단위로 데이터를 쓰고, 512KB(블록) 단위로 삭제한다. 문제는 비어있는 페이지에만 데이터를 쓸 수 있다는 것이다. 하드디스크는 데이터가 있어도 쓰기 헤드가 자기 배열을 바꿔 새로운 데이터를 덮어씌울 수 있지만 SSD는 남아 있는 데이터를 삭제해야, 즉 셀을 비운 뒤에야 새로운 데이터를 채워 넣을 수 있다.
(*) 요즘 SSD는 8K 페이지에 256 페이지 블럭(2M)도 사용

SSD에 비어있는 셀이 충분하다면 이를 찾아 데이터를 채워 넣으면 그만이지만 비어 있는 셀이 모자랄 때는 쓰지 않는 데이터가 남아있는 셀부터 비워야 한다. 512KB 단위로 지워야 하는데 이 가운데 아직 지우면 안 되는 데이터가 포함되어 있다면 이를 캐시 메모리로 복사해두고 블록을 삭제한 뒤 기존 데이터와 새로운 데이터를 채워 넣어야 하는 복잡한 과정이 필요하다. 하지만 초기 SSD 중 상당수가 캐시 용량이 부족했을 뿐 아니라 읽기/쓰기 알고리즘을 정밀하게 제어하지 못하는 컨트롤러를 달아 제 속도를 내지 못했다.

복잡한 데이터 쓰기 과정은 SSD의 태생적인 한계라서 요즘 나온 SSD 역시 문제가 어느 정도 개선되었을 뿐 완전히 해결한 것은 아니다. SSD 속도를 잴 때는 데이터를 100% 채운 뒤 포맷을 하고 측정해야 진정한 속도를 알 수 있다는 주장도 있다. SSD에 데이터를 복사하면 초기 상태에서는 초당 100MB 이상으로 담지만, 데이터를 꽉 채웠다가 삭제하고 다시 복사해 보면 초당 60MB 수준으로 떨어지는 것을 볼 수 있다. SSD에서도 역시 컨트롤러에 있는 cache가 성능을 많이 좌우할 수 있다! 일반적인 파일 작업에서의 SSD 효과가 RDBMS에서는 그대로 나타나지 않을 수도 있다.

물론 많은 경우 SSD를 쓰면 성능 향상 효과가 있다.
그러나 RDBMS는 Primary Storage인 RAM과 Secondary Storage인 Disk가 있는 상태에서 어떻게 하면 최적의 속도를 낼 수 있는지 20년 이상 연구되어 온 시스템 소프트웨어이다.

RDBMS는 메모리를 디스크에 대한 버퍼로 사용한다. RDBMS는 메모리에 비해 수백 배 느린 HDD를 가정하고 이를 보완할 수 있는 다양한 알고리즘들을 가지고 있다.

예) direct i/o, page clustering, read ahead (prefetch), adaptive flushing, ...

HDD가 최고 성능을 내는 경우는 sequential read/write이다. 그러므로 RDBMS는 임의로 들어오는 데이터들을 어떻게 연속된 디스크 페이지에 배치해서 한번에 최대한 많은 데이터를 읽고 쓸 것이냐를 연구해왔다.

요즘 RDBMS에서도 SSD 특성에 적합한 알고리즘과 기법들이 연구 개발되고 있지만, 아직 대세는 아니다. 그리고 아직은 소량 고성능 보다는 대용량 데이터를 관리하는 DB가 더 일반적이다.

예) IBM의 SSD Buffer Pool Extensions for Database Systems
Oracle의 Database Smart Flash Cache

그리고 RDBMS는 random r/w인 data file이외에 sequential write인 transaction log file을 사용한다는 점이 SSD 사용에서는 아주 중요하다. Sequential write에서는 SSD가 HDD보다 낫다고 할 수가 없기 때문이다. SSD가 아직은 가격대비 성능이 높지 않고, 상황에 따라 버퍼 메모리를 늘려주는 것이 I/O를 더 향상시키는 방법이므로,
적절한 판단을 하려면 RDBMS의 구조와 동작 방식에 대한 이해가 필요하다. SSD 기반의 DB 성능 시험 결과들 SSD Performance BlogPercona's blog about SSD performance and MySQL Write Amplication!
Flash writes more than application On Benchmarks on SSD; July 15, 2010
Free space and write performance; July 18, 2010
Write performance on Virident tachIOn card; December 13, 2010
MySQL 5.5.8 and Percona Server on Fast Flash card (Virident tachIOn); December 21, 2010
Intel 320 SSD random write performance; June 23, 2011
FusionIO 320GB MLC random write performance; June 23, 2011
Intel 320 SSD read performance; July 29, 2011
Intel 320 SSD write performance – contd.; September 29, 2011
Multiple MySQL instances on Fusion-io ioDrive; October 7, 2011
MLC SSD card lifetime and write amplification; November 15, 2011
Benchmarks of Intel 320 SSD 600GB; February 23, 2012
ext4 vs xfs on SSD; March 15, 2012
Testing Samsung SSD SATA 256GB 830 – not all SSD created equal; April 25, 2012
Testing STEC SSD MACH16 200GB SLC; April 26, 2012
Testing Intel SSD 520; May 2, 2012
Testing Fusion-io ioDrive; May 3, 2012
Testing Virident FlashMAX 1400; May 5, 2012
Testing Fusion-io ioDrive – now with driver 3.1; May 7, 2012
Testing Fusion-io ioDrive2 Duo; May 10, 2012
Intel 520 SSD in MySQL sysbench oltp benchmark; May 22, 2012
Testing Intel® SSD 910; September 5, 2012
Intel SSD 910 in tpcc-mysql benchmark; September 7, 2012
Intel SSD 910 vs HDD RAID in tpcc-mysql benchmark; September 12, 2012
On SSDs – Lifespans, Health Measurement and RAID; October 12, 2012 시간이 지남에 따라 SSD의 성능은 GC 발생 Freespace에 따른 SSD의 성능은 13G innodb_buffer_pool_size 52G innodb_buffer_pool_size 144G innodb_buffer_pool_size innodb_io_capacity 500, 20000, 4000 페이지 버퍼 크기에 따른 SSD 성능은 SSD와 HDD의 read 성능은 CPU를 다 쓰기 위해 MySQL instance를 늘리면 MySQL sysbench oltp benchmark SSD 910 vs HDD RAID in tpcc-mysql benchmark http://technet.microsoft.com/en-us/magazine/hh334997.aspx http://www.slideshare.net/matsunobu/ssd-deployment-strategies-for-mysql http://www.percona.com/files/presentations/WEBINAR-MySQL-SSD.pdf http://www.pythian.com/blog/de-confusing-ssd-for-oracle-databases/ http://guyharrison.squarespace.com/blog/2010/1/24/flash-tablespace-vs-db-flash-cache.html NoSQL의
근원적 특성이 무엇일까?

RDBMS와의 차이 1. SQL을 포기했다. 왜?

맨날 쓰는 쿼리가 다 PK기반의 간단한 SELECT이더라

그러니 SQL parsing, optimizing 등에 뭐하러 시간을 들이냐

SQL processor를 제대로 만들려면 한 10년을 해 봐야... 2. Storage layout을 바꿨다. 왜?

빠른 속도를 위해서, 그리고 분산 구조를 위해서

RDBMS는 데이터 보장을 위해서 너무 많은 짓을 하는데 실은 이 데이터 별로 안 중요하다.

어차피 서버 한대로는 죽었다 깨어나도 필요한 성능이 안되니 여러대에 분산해야 겠다.

대량 SELECT하는 꼴이 해당 column의 데이터를 모아 놓으면 I/O가 더 빠를 것 같다. (column-oriented)

Record, page 방식의 storage layout은 random I/O를 많이 불러일으킨다. 이를 memory chunk 방식으로 뭉텡이로 하고, 파일에 append only로 쓰면 I/O가 굉장히 빨라진다. (log structured file)

단점이 주기적인 file compaction이 필요하다는 것! NoSQL, Toolbox 25 Years of Commercial Database Systems NoSQL, NewSQL and Beyond NewSQL “One Size Fits All”: An Idea Whose Time Has Come and Gone

The End of an Architectural Era (It's Time for a Complete Rewrite) Not Only SQL Cache Key Value Document-oriented Graph-oriented Big Data no-join distributed
large scale eventual
consistency CAP theorem scalability Column-
oriented Google Spanner's Most Surprising Revelation: NoSQL Is Out And NewSQL Is In Sequential write의 장점을 살렸던 NoSQL에서 SSD가 기대만큼 효과를 낼까?

AWS은 Dynamo를 상품화하면서 SSD 기반으로 선보였는데, 왜 그랬을까? http://www.slideshare.net/rbranson/cassandra-and-solid-state-drives
Full transcript