МАСШТАБИРОВАНИЕБАЗДАННЫХ

commonsense

ЕвгенийШишкинDBA,wargaming.neteshishki@gmail.com

—WedefineaDBMSasacompletesoftwaresystemusedtodefine,create,manage,updateandqueryadatabase.

©Gartner

БДобщегоназначения,OldSQL:MySQL,PostgreSQL

Специализированные,NewSQL:VoltDB,Vertica,Clustrix

NoSQL:HBase,Cassandra,CouchDB,Aerospark,MongoDB

SCALABILITYISAFUNCTIONМыхотимдобавитьресурсовиработатьбыстрее

илиобрабатыватьбольше.

Amdahl'slawGustafson-Barsis'LawNeilJ.Gunther'sUniversalScalabilityLaw

Amdahl'slawУнасестьалгоритм,которыйоднопоточноработаетзавремяT1.МыхотимдобавитьPпроцессоровирешитьзадачубыстрее.КакоеувеличениепроизводительностиSмыможемполучить?

«Вслучае,когдазадачаразделяетсянанесколькочастей,суммарноевремяеёвыполненияна

параллельнойсистеменеможетбытьменьшевременивыполнениясамогодлинногофрагмента»

Amdahl'slaw

Ускорениеограниченотойчастьюработы,котораянепараллелизуется.

Например,еслисериализованнаячастьалгоритмасоставляеттолько0.1%,при2048процессорах

ускорениебудеттольков672раза.

Gustafson-Barsis'Law…speedupshouldbemeasuredbyscalingtheproblemtothe

numberofprocessors,notbyfixingtheproblemsize.—JohnGustafson

Вреальности,добившисьнужноговремениответасистемы,насвсёустраивает.Имыужедобавляеммощностиподрастущийразмер,анедлясокращениялатенси.

Gustafson-Barsis'Law

Еслиобъемданныхувеличиваетсявместесувеличениемчислапроцессоров,асериализованнячастьрастетмедленноилификсирована,ускорениерастетпропорциональноростуресурсов.

ЯНИЧЕГОНЕПОНЯЛРазницавтом,хотителивыускоренияпритойженагрузкеилитогожевремениответаприувеличениинагрузки.

ВреальнойжизнибольшеприменимзаконGustafson.

Но,есливамнадодобитьсяболеебыстройработыалгоритмапритехжеданных,руководствуйтесьзакономАмдала.

ТАККАКАЯЖЕБАЗАМАСШТАБИРУЕТСЯ

ЛУЧШЕ?Масштабироватьнадонебазу,асервис.Бессмысленнорассматриватьбазуданныхвотрывеотпрофилянагрузкииприложения.

Масштабированиеэтоспециализация.Базыданныхобщегоназначениявобщемслучаенемасштабируются.

UNIVERSALSCALABILITYLAW

CostofsharingresourcesDiminishingreturnsfromcontentionNegativereturnsfromincoherency

ТИПИЧНЫЕПРОФИЛИНАГРУЗКИ

oltpshort-requestprocessingwebolap/dwh

OLTPбукваTэтотранзакции-забылиnosqlсразужеможнонабитьлюбимуюбазуданныхдоотказапамятьюиssd,ноэтобудетпечальноинеэффективнокакнамсделать500kTPSнаодномсервере?никакпошардили?добропожаловатьвдивныймиралгоритмовраспределенногокоммита

Почемувсётакплохоработает?Вотredisжеделает200кнаодномядре!

OLTPобычнаябазаданных

OLTPПрорывнойресерчH-Storehttp://hstore.cs.brown.edu/ГотовыйпродуктVoltDB

mainmemorydatabase->nobufferpoolmanagementкаждомуcpuсвойкусочекпамятииоднопоточноевыполнение->нетлоковвсяработавхранимыхпроцедурахикучаресерча->

2pcиногданенуженивовремяожиданияможновыполнятьдругиетранзакции

Подробнеетутhttp://hstore.cs.brown.edu/publications/

OLTPВсеосновныесложностисраспределеннымитранзакциями.Рецепт-детерминизм.

Знаянапередвкакойпоследовательностибудутвыполнятьсятранзакции,унаснетожидания.Базаданныхвсегдаделаетполезнуюработу.

Подробноститутhttp://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf

SHORT-REQUESTPK/INDEXLOOKUP

Такаянагрузкамасштабируетсячемугодно.Ненадобытьсемипядейволбу,чтобыпошардитьPKРечьобэффективностииудобстве.

MySQLделает200krps,PostgreSQL120krps.Невероятно,норедкаяnosqlсистемапокажеттакиечисла.ЕстьMysqlCluster(NDB,негалера),естьPostgres-xc.NoSQL,которыеAP,работаютмедленнейCP.

WEBshort-request+joins+tonsoforderby+orm95%+чтенияпочтинеттранзакцийнебольшойобъемгорячихданныхdataskew(zipfiandistribution)

Намхватаетодногосервера,покаунегонекончаетсяCPU.MySQLCluster,Postgres-xc,Pgpoolипрочиешардяттолькопоодномуатрибуту.

WEBПредставьтесебетабличкуспостами

Идвапопулярныхзапроса:

Хочетсяпошардитьипоthread_id,post_idипоuser_id,posted_onВыбираятолькоодно,далеконеуехать.

createtablethread_posts(post_idbigint,thread_idbigint,user_idbigint,posted_ontimestamp,contentstext,primarykey(thread_id,post_id),key(user_id,posted_on));

select*fromthread_postswherethread_id=314orderbypost_id;select*fromthread_postswhereuser_id=546orderbyposted_ondesclimit10;

WEBНамнадо:отправлятьзапросытолькотуда,гдележатнашиданныеизбегатьраспределенныхзапросовбалансироватьнагрузку

Хорошийспособ:отвязатьлогическуюсхемуотфизической,чтобышардитьпоразныматрибутамиспользоватьconsistenthashingдлябалансированияданныхэтосделановClustrix

WEBСоветики

чтобыизбежатьзапросовнаноды,гдеданныхнетlookupтаблицаbloomfilter

можношардитьподвуматрибутамруками,делаядветаблицыможноденормализовать,помняпроupdate,deleteаномалииможноматериализовыватьданныепризаписи(pushмодель)длясверхпопулярныхпользователей(лента)

WEBЕслизаморочиться

Проблемаэффективногораспределенияданныхпонодамэтолокальностьданныхиоверхедрепликацииданных.

Научныйподходэтоположитьданныевместе,непохешу,ате,которыереальнозапрашиваютсявместе.Schism:aWorkload-DrivenApproachtoDatabaseReplicationandPartitioningTheLittleEngine(s)ThatCould:ScalingOnlineSocialNetworks

OLAP

огромныйобъемданныхогромныевыборкикучасортировокиджойноводнотипныерепортыхорошошардитсяхорошосжимается

OLAP

Можно:пошардитьрукамивзятьpostgres-xc,mysqlcluster,любойавтоматическийшардингидажеможноиспользоватьmaterializedview(аляpush)иможнодажечто-тоденормализовать

OLAPНужно:1.хранитьданныевколонкахсжатиевекторизованныйпроцессингэффективныйдоступкданным

2.оперироватьнадсжатымиданнымивпамяти3.делатьrowreconstructureтолькокогдаэтонеобходимо4.делатьjoinиндексыилиprejoinпроекции5.хранитьданныеужеотсортированными(mergejoinбесплатный)

OLAPВсеэти"нужно"сделанывVertica.ЧастьсделанавClouderaImpala.

Greenplumнеумеетcolumnstorage.Oracleнеумеетcolumnstorage.NoSQLнеумеетcolumnstorage.

DB2иMSSQLумеют,нонеMPP.

ПоловинаNewSQL,которыепроонлайнаналитику,этопростоinmemoryбазы.ОченьчастодажебезdictionaryкомпрессиииRLE.

SQLVSNOSQLПредставьтесебеnosqlбазуданных,котораяумеетsecondaryindexesумеетэффективновыполнятьчастьзапросовусебяумееттранзакциидаетгарантии,когдаэтонеобходимо

Божемой,даэтожеRDBMS!

ВЫВОДЫИспользуйтенужнуюбазуданныхдлясвоейнагрузкиНемасштабируйтебазувотрывеотприложенияЕсливызнаете,какрешитьсвоюпроблемуNoSQLбазой,значитвызнаете,какрешитьпроблемуивRDBMSНеленитесьдуматьичитать