Downloaded 29 times
HighLoad весна 2014 лекция 6
- 1.
- 2. SATA Емкость: 2 Tb RPM:7200 Cache: 64 Mb Интерфейс: 3Gb/s Чтение/запись: 140MB/s Seek time R/W: 12/6 ms 2 Дисковая подсистема HighLoad. Лекция №6
- 3. HighLoad. Лекция №2 3 Latencynumbers every programmer should know (Jeff Dean) L1 cache reference 0.5 ns Branch mispredict 5 ns L2 cache reference 7 ns Mutex lock/unlock 25 ns Main memory reference 100 ns Compress 1K bytes with Zippy 3,000 ns Send 2K bytes over 1 Gbps network 20,000 ns SSD random read 150,000 ns Read 1 MB sequentially from memory 250,000 ns Round trip within same datacenter 500,000 ns 0.5 ms Read 1 MB sequentially from SSD* 1,000,000 ns 1 ms Disk seek 10,000,000 ns 10 ms Read 1 MB sequentially from disk 20,000,000 ns 20 ms Send packet CA->Netherlands->CA 150,000,000 ns 150 ms
- 4. 4 HighLoad. Лекция №6 •Быстрое линейное чтение • Медленный случайный доступ • Конкуренция за диск уменьшает производительность • SATA – для логов • SAS – для баз данных • SSD – для кеширования
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43.
- 44. HighLoad. Лекция №6 44 Литература http://www.danga.com/words/2005_oscon/oscon-2005.pdf http://www.addsimplicity.com/downloads/eBaySDForum2006-11-29.pdf http://qconlondon.com/dl/qcon-london- 2008/slides/RandyShoup_eBaysArchitecturalPrinciples.pdf http://www.slideshare.net/tcng3716/ebay-architecture http://friendfeed.com/bret/dd79a583/how-friendfeed-uses-mysql-to- store-schema-less
- 45. HighLoad. Лекция №6 45 Домашнеезадание №4
- 46. СПАСИБО ЗА ВНИМАНИЕ БыковАлександр bykov@corp.mail.ru
Editor's Notes
- #3 HDD: Линейное чтение с дисков одного порядка со скоростью памятиHDD: Задержка в 100 дольшечем у ОЗУSSD: Latency - 0.1 msSSD: хорошо подходят для кешей
- #4 http://research.google.com/people/jeff/
- #6 RAID 1-4 – экзотикаRAID 5 – медленный и ненадежный
- #11 В постгресе теперь тоже есть репликация из коробки и починили большинство ранних проблемБольше функций, многие из которых уникальные, например географический индексМускуль уже давно не развивается и так написан что развивать его пробелематично, но все пользуются
- #12 Legacy база, разработчики о ней не помнятПроблемы с конкурентной записьюБлокировки на JOIN, очередь запросовСложно обеспечить консистентность
- #13 Mainstream-направлениеНе любят админы по причине проблем с переносимостью и сложностей с бекапом(LVM)Сложно разделить на несколько серверов если нет file-per-tableБекапы в виде SQLdump не предлагать!Репликации для бекапа и резервирования, это очень важно
- #14 Репликации для бекапа и резервирования, это очень важно
- #15 Блокировка и переключение – несколько секунд, вместо минут и часов обычного альтера
- #16 При небольшом объеме данных для этого лучше использовать in-memory databases
- #18 Большие части проблематично «мувить» и «сплитать»
- #46 Какие проблемы и как решал проектКакие архитектурные решения принимались и почемуКак устроен проект сейчасКак вы оцениваете его устройство и как бы вы могли предложить сделать лучше