Downloaded 11 times
Uploaded byAlexander Tokarev
Cloud dwh
The document outlines strategies for optimizing cloud databases, particularly focusing on performance tuning and effective data modeling for various platforms like Redshift, BigQuery, and Snowflake. Key topics include common failures during data migration, pricing models, optimal data structures, and the importance of constraints. The content emphasizes that while cloud solutions offer scalability and cost-effectiveness, they require careful management and understanding of infrastructure to avoid excessive costs and inefficiencies.
More Related Content
Cloud dwh
- 1. Cloud databases datamodeling and optimization Alexander Tokarev (DataArt)
- 2. Who am I •Database performance architect at DataArt: 1. Solution design 2. Performance tuning 3. POCs and crazy ideas • Enterprise databases Oracle - 2001, Oracle 8.1.7 – 19c • Cloud databases: Redshift, Athena, BigQuery, SnowFlake • Hobbies: spearfishing, drums
- 3.
- 4. Cartoon time DWH audit New ExtraCool Super Fast Cloud Vendor
- 5. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 6. Agenda • Cloud offering •Customer data model • Refactorings • Final metrics • Extreme DWH tuning • Q&A
- 7. Cloud promises • On-demandscalability • Reliability • No infrastructure support • Very simplified tuning • No internals database knowledge for design • No physical storage knowledge for design • Low-cost
- 8. Cloud promises • On-demandscalability • Reliability • No infrastructure support • Very simplified tuning • No internals database knowledge for design • No physical storage knowledge for design • Low-cost It isn’t true sometimes!
- 9. Cloud DWH mainplayers • Amazon • Snowflake • Google • Hundreds of others…
- 10. Cloud DWH approaches Processingtype: • All-in-one cluster node • Separated storage and compute Ability to manage: • No management (BigQuery, Athena) • Fine-grain management (Redshift, Snowflake)
- 11. Cloud DWH approaches •Managed open-source solutions (Athena - Presto) • Opensource forks (Redshift - Postgres) • Own products (BigQuery, Snowflake)
- 12. Pricing model • Percompute • Per storage • Per scan • Mixed
- 13. Pricing model Redshift classic: 2CPU, 0.16 Tb SSD, 15 Gb RAM – 0.25 USD/Hour .. 36 CPU, 16 Tb HDD, 244 Gb RAM – 6,8 USD/Hour Redshift Spectrum: Redshift cluster price 1 Tb scan 5 USD 10 Mb min scan 1 Tb 23 USD/Month S3 storage price Athena: 1 Tb scan 5 USD 10 Mb min scan 1 Tb 23 USD/Month S3 storage price Compute + storage + processing Compute Storage Processing Processing Storage
- 14. Pricing model BigQuery: 1 Tbscan 5 USD 10 Mb min scan 1 Tb 20 USD/Month active storage price 1 Tb 10 USD/Month passive storage price Storage Processing
- 15. Pricing model BigQuery: 1 Tbscan 5 USD 10 Mb min scan 1 Tb 20 USD/Month active storage price 1 Tb 10 USD/Month passive storage price No changes in 90 days Unique BigQuery cloud feature! Storage Processing
- 16. Pricing model BigQuery: 1 Tbscan 5 USD 10 Mb min scan 1 Tb 20 USD/Month active storage price 1 Tb 10 USD/Month passive storage price SnowFlake: X-Small cluster 1 machine 2 USD/Compute Hour .. 4X-Large cluster 128 machine 256 USD/Compute Hour 60 seconds min run 1 Tb 40 USD/Month storage price Storage Processing Compute + Processing Storage
- 17. Columnar and rowdifferences
- 18. Columnar pros&cons Pros - Perfectfor analytic workload - Widely supported by opensource: 1. Parquet 2. Orc - Good for compression Cons - Complicated update strategy - Bad in concurrent workload Less cloud storage price!
- 19. Cloud DWH columnarformat • Redshift classical – own • BigQuery – own Capacitor/former ColumnIO • Redshift Spectrum – Parquet, Orc • Athena/Presto – Parquet, Orc
- 20. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 21. Cloud price trap •Too normalized data model -> A lot of joins -> Pay for compute • Too normalized data model -> A lot of joins -> Not used DB features -> Redistribute between nodes -> Pay for compute • Too Denormalized data model -> Extra disk space -> Pay for storage • Too Denormalized data model -> Extra disk space -> Pay for scan • Too Denormalized data model -> Extra disk space -> Pay for compute • Not proper compression -> Extra disk space -> Pay for storage • Not proper compression -> Extra disk space -> Pay for scan • Not proper compression -> Extra disk space -> Pay for compute Unbalanced design = pay for everything!!!
- 22. Redistribute/Reshuffle Extra network trafficand CPU consumption! Node 1 Node 2
- 23. Cost metrics • Initialnodes count: 4 • Initial year price: 238 000 USD • Final nodes count: 11 • Initial year price: 655 000 USD
- 24. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 25. Customer’s DWH model 1record per repair item
- 26. Common customer’s queries •Manufactories count by state • Manufactories count by state and counties • Ranks by profit inside state by year and month • Profit by state and counties • Random queries like counts by ZIP
- 27. Performance metrics Query Seconds Manufactoriescount by state 2 Manufactories count by state and counties 6 Ranks by profit inside state by year and month 12 Profit by state and counties 9 Сount by ZIP 7
- 28. Fact merging • Checkfacts dimensions • If they are equal check measure • If they are close merge with fact type
- 29. Customer’s DWH model 1record per repair item
- 30. Fact merging 1 recordper repair item 1. Deal 2. Discount 3. Payment
- 31. Dimensions merging • Checkdimensions • If they are different for different fact types move next • If they have a lot of common attributes merge • Be happy with: – simplified BI model – better dimension compression – better performance because of collocate joins
- 32.
- 33. Dimensions merging 1 recordper repair item
- 34. Denormalized facts • Aggregatedimensions which changes not often to fact
- 35. Denormalized facts 1 recordper repair item
- 36. Final performance metrics QueryMerged facts + dimensions Redshift Old STAR model Manufactories count by state 1,6 2 Manufactories count by state and counties 5 6 Ranks by profit inside state by year and month 9 12 Profit by state and counties 6 9 Сount by ZIP 6 7 Performance profit ~20%!!!
- 37. Are you crazyenough? Let’s feed all data in a big flat table!!!
- 38. No dimension warehouse 1record per item EVEN distribution for Redshift 4 Tb dataset
- 39. Performance Query No dimension Redshift Nodimension BigQuery Old STAR model Manufactories count by state 1,4 1,1 2 Manufactories count by state and counties 4 3,3 6 Ranks by profit inside state by year and month 11 6 12 Profit by state and counties 6 5 9 Сount by ZIP 5 3,8 7
- 40. Performance • Redshift –20-30% performance profit • BigQuery – 35-50% performance profit
- 41. Semi/Full Nested facts •Unique feature of BigQuery • Very good where nested data aren’t used in calculations • Recommendation from Google: flatten or nest
- 42. Semi/Full Nested facts 1record per full order
- 43.
- 44.
- 45. Performance Query Semi-nested facts BigQuery No dimension Redshift No dimension BigQuery Old STAR model Manufactories countby state 0,9 1,4 1,1 2 Manufactories count by state and counties 3 4 3,3 6 Ranks by profit inside state by year and month 5 11 6 12 Profit by state and counties 4 6 5 9 Сount by ZIP 3 5 3,8 7
- 46. Data models comparison Datamodel Performance ETL simplicity Dimension changes BI simplicity Space consumption Pure STAR - + + ++ + Merged facts + - + +- - Merged dimensions + - - + - Denormalized fact ++ -- -- +- -- Semi/Full Nested facts +++ --- --- - - No dimensions +++ --- --- --- ---
- 47. Data models comparison Datamodel Performance ETL simplicity Dimension changes BI simplicity Space consumption Pure STAR - + + ++ + Merged facts + - + +- - Merged dimensions + - - + - Denormalized fact ++ -- -- +- -- Semi/Full Nested facts +++ --- --- - - No dimensions +++ --- --- --- ---
- 48. Redshift magic • Chooseproper distribution style • Choose proper sort keys
- 49. Distribution • ALL distributionstyle – for reference data (10000 rows) • KEY for joins • EVEN distribution is default • AUTO isn’t smart enough AUTO After threshold
- 50. Sort keys • Physicallyorder data on disk by a field/fields set • Degrades ingestion • Improve join/search/grouping • 2 types: 1. Compound 2. Interleaved (Z-ordered)
- 51. Sort keys Key typeIngestion degradation Search degradation Random searches Compound Not big No WHERE in Key order Interleaved Decent Yes WHERE in Random order
- 52. Redshift housekeeping • Dedicatedworkload queues (WLM) • Regular VACUUM to free space and sort order • Regular ANALYZE to relevant statistics
- 53. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 54. Cloud DWH compression Nocompression management No compression management
- 55.
- 56. Redshift compression • Measuretable column size • Check suggested encoding via ANALYZE COMPRESSION • Apply suggested and re-measure • If not happy change suggested • Be happy with I/O performance and lower database size • We love ZSTD
- 57. BigQuery tricks • Wildcardtables • Partitioned tables • Clustered tables Don’t forget – no result cache!
- 58. BigQuery clustered tables •Ordered data • Up to 3-4x performance profit • Up to 400x costs reduction sometimes • No more LIMIT anti-pattern • Possible with non-partitioned
- 59. BigQuery clustered tables 1.Slow ingestion 2. manual recluster as CREATE TABLE AS SELECT * $$$ for cloud provider!
- 60. BigQuery clustered tables Lessprice to cloud!!! 333x less payment! 3x faster 0,4 USD 0,0012 USD
- 61. SnowFlake clustered tables 1.Automatic reclustering processes 2. Extra space consumption No chance to abstract from physical storage layer!!! $$$ for cloud provider!
- 62. Hardware removal • SetupWLM queues properly • Check concurrency • Estimate disk utilization • Check disk-based queries • Estimate loading parallelism
- 63. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 64. WLM • Mechanism tobalance workload via FIFO queue • Queries wait until there is no place in queue • Default values are too low • Only one queue is configured
- 65. WLM • Setup usersper workload: 1. Adhoc 2. BI 3. ETL 4. housekeeping • Create Redshift groups per workload • Assign groups to users
- 66. WLM • For eachqueue: • Consider Concurrency Scaling • Controlled by max_concurrency_scaling_cluster • Set static slots count • Set memory percentage from node • Max query memory = queue memory/slots count Parameter wlm_slot_count overrides it! Query will consume more than 1 slot. ANALIZE and VACUUM will be faster. Unique Redshift cloud feature!
- 67. WLM • Consider ShortQuery Acceleration • Leave default queue with 1% memory and 1 slot count for DBA for the sake of emergency
- 68. Concurrency • Check queuewait time in 1 week dynamic • Wait time changes proportionally slots count and nodes count • Estimate new wait time in case of slots reduction
- 69. Disk utilization • Checkdisk space consumption in 1 week dynamic • Disk space should 70-80% from total cluster space • Disk space changes proportionally nodes count • Estimate new disk space utilization
- 70. Disk utilization Doesn’t includequery buffers, temporary tables and etc!!!
- 71. Disk queries 1. Measuredisk queries count 2. If more 10% - re-tune WLM 3. If fine-tuned – no options to retire a node
- 72. Disk queries 1. Ifless 10% then 2. Disk queries count changes proportionally memory in cluster 3. Estimate new WLM queue memory size 4. Compare with AVG queries memory
- 73. Loading parallelism • CheckLOADs time in 1 week dynamic • LOAD performance changes proportionally nodes count • Estimate new wait time in case of node retirement
- 74. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 75. Node elimination process ParameterToo many nodes Node count 11 Queue count 1 Waits in queues, second per working day 500 Disk-based queries, % 20 Disk consumption, Tb/% from total 159/91 Average LOAD operation, seconds 20 Cost of ownership, USD, per year 655 000
- 76. Node elimination process ParameterToo many nodes Optimal nodes count Node count 11 8 Queue count 1 5 Waits in queues, second per working day 500 150 Disk-based queries, % 20 5 Disk consumption, Tb/% from total 159/91 98/80 Average LOAD operation, seconds 20 26 Cost of ownership, USD, per year 655 000 476 000 180 000 USD profit!!!
- 77. Why failure • Transitionvia migration tool • Bad compression selection • No queues management • Data structure moved as-is • No constraints defined • Cluster is too big
- 78. Constraints • 3 types: 1.Uniqueness 2. Primary key 3. Foreign key 4. Not null - enforced • Must be adhered by ETL process • Used by optimizer not enforced by Redshift!
- 79. Constraints Used in: • Joinorder calculation • Join elimination process • Count(distinct <field>) operation
- 80. Constraints risks Without constraint: WithPRIMARY KEY constraint: Dupe but very fast!!!
- 81. Constraints risks Without constraint: WithFOREIGN KEY constraint: Wrong but very fast!!!
- 82. Constraints • We douse constraints • We trust our ETL • But there is integrity check job • We help optimizer • So reports are very fast
- 83. Conclusion • Cloud isn’ta silver bullet • No chance to abstract from data storage layer • Optimize data model first • Approaches are fine with others cloud DWH • Use DBMS unique features • Remove hardware – it works sometimes • Adding hardware – last chance • Don’t trust migration wizards • No cloud DWHs in Russia
- 84. THANK YOU FORYOUR TIME! Alexander Tokarev Database expert DataArt shtock@mail.ru
Editor's Notes
- #2 Всем привет. Меня зовут Александр и сегодня мы поговорим об оптимизации модели данных для облачных хранилищ. К сожалению, в процессе подготовки докладу я пришёл к выводу, что на одной оптимизации логической структуры не затрагивая физическое хранение далеко не продвинуться, поэтому поговорим и об этом тоже.
- #3 Я работаю архитектором по производительности в компании Датаарт, где занимаюсь вопросами, связанными с общим дизайном системы, настройками производительности и различными исследовательскими проектами. Изначала я из мира Oracle, но сейчас всё более увлекаюсь облачными системами обработки данных.
- #4 Перед тем как я расскажу вам сценарий мультфильма у меня вопрос. Кто из вас работает с хранилищами данных? А у кого используются облачные хранилища? Редшифт? Гугл? Жили были бояре и было у них небольшое хранилище в оракле, но они считали, что его владельцы купаются в деньгах. Они нанняли консультантов и внедрили облачную базу. С каждым моментом ей становилось всё хуже и хуже, но лечили это добавление нод кластера, пока не поняли, что и владельцы клауда продолжают купаться в деньгах
- #5 Пришла компания датаарт, провела аудит и пришли мы к выводу, что с хранилищем ситуация плачевна. Кажется, что можно было бы поставить еще более модную новую клаудную систему, но мы решили пойти иначе.
- #6 В чем же причина провала. Ключевое, что смена бд была с использованием мастера меграции, что привело К плохому выбору компрессии Отсутствию управления очередьми Структура данных была перемещена как ест Констрейнты отсутствовали Что привело к неоправданно большому кластеру
- #7 Итак, мы поговорим о том, что есть в облаках Модели данных заказчика Как мы её меняли Итоговые метрики производительности Также обсудим экстремальные подходу к тюнингу хранилищ И я с удовольствием отвечу на ваши вопросы.
- #8 Клауд обещает масштабируемость по запросу Надёжность Отсутствие необходимости поддержки инфраструктуры Упрощенный тюнинг. Причём вендоры рекомендуют просто добавлять железо Конечно же утверждается, что не надо знать как работает СУБД изнутри и особенно слой хранения данных Ну и ключевое, что обещается, что облака значительно дешевле
- #9 Хотелось бы обратить внимание, что последние пункты далеко не всегда правдивы.
- #10 Ключевыми игрокамами на рынке облаков является Амазон Сноуфлей Гугл И сотни других. Только ленивый сейчас не пишет клаудные субд. Думаю, даже яндекс так думает.
- #11 Итак, хранилища отличаются по типу обработки И Детализацией процессов управления Иногда расчёты и хранение сконцентрированы в одной ноде Иногда разделено хранение и расчё Бывают как абсолютно serverless системы, такие как бигквери и афина Так и системы с довольно глубокими настройками такие как Редшифт и Сноуфлейк
- #12 Облачные хранилища обычно создают либо на базе Управляемых опенсурсных решений Либо на базе их форков Ну или пишут с нуля
- #13 Модель ценообразования формируется на основе стоимости Вычисления Хранения Объема отсканированнных данных И их комбинации
- #14 При расчётах цены Редшифта цена считается за ноду, т.е. за расчёт, хранение и обработку Редшифт спектрум оценивается по стоимости обработки, объему отпроцешенных данных и стоимости хранения Стоимость работы с афиной складывает от обхема отпроцешенных данных и стоимости хранения
- #15 Цена бигквери аналогична – она складывается из объема отпроцешенных данных и стоимости хранения.
- #16 Тут важно подчеркнуть, что в гугле есть понятие активного и пассивного хранения. Пассивным считаются те таблицы и партиции, данные в которых не менялись 90 дней и такое хранение стоит в 2 раза дешевле. Соответственно это уникальная клаудная фишка, предлагаемая только гуглом.
- #17 Сноуфлейк разделяет стоимость вычислительных ресурсов и стоимость хранения.
- #18 Собственно разница между колоночным и столбчатым форматами ясна: в одном хранятся строки, в другом колонки
- #19 Ключевыми достоинствами колоночного формата является его работа В условиях аналитической нагрузки Есть множество опенсурсных форматов, таких как Паркет Орк И они очень хороши для компрессии, что приводим к меньшим затратам на хранение в облаке Недостатки: Сложный процесс обновления данных и Нюансы при работе в многопользовательском режиме
- #20 Редшифт использует свой формат данных Бигквери свой под названием Капастор, а раньше КолумнИо Редшифт спектрум использует паркет и орк Ровно как афина и престо
- #21 Собственно то, что перенос был сделан средствами миграции мы устранить уже не сможем
- #22 При работе с клаудными базами данных многие попадают в ловушку Слишком нормализованная система – много джоинов и много оплаты cpu Если же при этом не используются фишки субд, то это приводит к перераспределеннию данных между нодами, что опять таки приводит к оплате cpu. Слишком денормализованная модель приводи к росту оплаты за стоимость, сканирование и cpu Если неправильно подобрана компрессия, то ситуация полностью аналогична. Таким образом, если система имеет несбалансированный дизайн, то платить придётся за всё и много.
- #23 Что же такое редистрюбьют или решафл в терминах гугла. Это когда для выполнения джоинов или других операциях на ноде одного кластера недостаточно информации и необходимо её переслать с другой ноды.
- #24 Изначальное количество нод было 4, а стоило это порядка 230 тысяч долларов, Тогда как финальное количество нод было 11, а их итоговая цена была около 650 тысяч долларов.
- #25 Поэтому начнём работать по пунктам, Начнём с модели данных.
- #26 Заказчик это франчайзинговая сеть автостанций. Рассмотрим одну из витрин, которая посвящена ремонту. На ней есть набор измеренений и факты, в которых хранятся данные по объектам ремонта, скидкам и оплатам Важно что строчка единицы ремонта это одна строка в таблице фактов
- #27 Запросы, которые идут из BI довольно типовые и сводятся к различным подсчётам агрегатов, таким как Количество станцией по штатам Разрезы по штатам и областям Рейтинги по прибы внутри штатов с разбивкой по датам Прибыли по штатам и областям И адхок запросы а-ля количество продаж по почтовым кодам
- #28 Рассмотрим метрики производительности. Кажется, что цифры малые, но так как в качестве системы отчётности используется табло, которое вызывает в параллель до 20 запросов на вкладку дэшборда суммарные цифры получались весьма значительные
- #29 Для того, чтобы выполнить рефакторин Слияние фактов небходимо проверить какие есть ссылки на измерения в факте и не одинаковы ли они. Если они одинаковы, то проверить меры. Если меры близки друг другу, то объединить их в одну таблицу с указанием типа факта.
- #30 Мы видим, что у фактов абсолютно одинаковые измерения, а отличаются они только смысловым значением идинственной меры, которая в одной таблице это стоимость ремонта, Во второй величина скидки, а в третье стоимость оплаты
- #31 Таким образом мы оставляем одну таблицу, вводим поле тип записи со значениями Сделка, скидка и оплата. Из-за компресси значительно уменьшилось место, стало надо делать радикально меньше джоинов с разными таблицами, но усложнилась модель BI
- #32 Попробуем сделать что-то с измерениями. Если они абсолютно свои для каждого типа фактов необходимо проверить не одинаковые ли у них атрибуты. Если да или количество отличающихся атрибутов невелико, то сливаем их в одно измерение Что приводит к значительному упрощению модели BI, лучшей компрессии и скорости, так как джоины могут стать collocated – данные лежат на одной ноде.
- #33 Как мы видим, у нас во всех измерения есть одинаковые 4 поля и небольшие отличия
- #34 Сливаем их в единую таблицу
- #35 Денормализация фактов очевидна – сливаем в факты те измерения, которые редко меняются
- #36 Собственно вот так
- #37 Мы выбрали модель merged facts и dimension и получили прирост производительности около 20 процентов. Вчера с утра я погуглил не изобрели ли мы велосипед и обнаружил, что при подобных оптимизациях народ получал прирост производительности до 90 %
- #38 Вы готовы к экстриму? А давайте возьмём и накормим большую плоскую таблицу всеми данными.
- #39 Сделаем равномерное распределение в редшфте и зальём около 4 Тб данных.
- #40 Замерив производительность мы видим, что гугл бигквери в два раза быстрее на данной модели данных.
- #41 Обобщая, видно что на редшифте мы получаем около 30% прироста производительности, А у биг квери до 50
- #42 Вложенные факты это уникальная фишка Она особенно хороша, когда вложенные данные не учавствуют в вычислениях, а нужны для показа Собственно сам гугл рекомендует этот подход. Что денормализация это хорошо, а схемы звезда и снежинка не должны использоваться
- #43 Мы указываем, что у нас детали чека будут вложены в сам чек и мы получаем одну строчку на чек в таблице фактов
- #44 У гугла модель данных описывается в json схеме и в ней мы объявляем тип данных record и указываем, что он повторяется. Так мы можем вложить в чек его детали и скидки
- #45 Работать с вложенными объектами весьма просто. Мы просто указываем команду unnest и далее работаем с данными как с обычной таблицей
- #46 Как мы видим во многих случаях nested/flatten модель показывает более чем двухкратный прирост производительности
- #47 Можно довольно долго смотреть на модели с точки зрения плюсов и минусов по различным параметрам, таким как скорость, простота етл, стойкость к изменениям данных в измерения и занимаемое место
- #48 Но так как я уже говорил ранее основа клаудной оптимизации это баланс, для нашего хранилища мы выбрали merged dimensions, тогда как для гугла я бы выбрал semi-nested модель
- #49 Несмотря на то, что доклад в целом про модели данных, к сожалению оптимизацию хранилищ данных невозможно осуществлять без понимания нюансов конкретных баз данных, как бы от этого не пытались абстрагироваться поставщики клаудных решений. Я специально не затрагиваю вопросы подходов к обновлению и добавлению данных, а акцентирую внимание на статичных вещах именно при дизайне таблиц. Итак, необходимо выбрать правильный стиль распределения и правильные ключи сортировки.
- #50 Есть следующие типы распределения: По ключу, когда на каждом шарде лежит определённый набор ключей, All когда на шард полностью реплицируются таблица Или even, когда данные равномерно размазываются алгоритмом round-robin Есть ещё тип АВТО, который вначале присвает тип all, а потом по достижению определённой границы тип even Я ремомендую тип олл для справочников до 10000 значений Кей для джоинов, а ивен если нет явного ключа распределения
- #51 Ключи сортировки упорядочивают данные по полю, набору полей Что уменьшает скорость вставки Но увеличивает джоины, поиск, группировки Естть 2 типа ключей сортировки Составные и interleaved
- #52 Составные ключи имеют два недостатка – уменьшение скорости вставки и неускорение поиска по полям, перечисленным в произвольном порядке Interleaved ключи серьёзно роняют скорость вставки, при этом их скорость поиска меньше составных ключей, но зато они не зависят от порядка полей и всё равно быстрее поиска без них
- #53 Для того, чтобы редшифт работал чётко, необходимо иметь правильно настроенные очереди Выполнять vacuum для очистки места и поддержания порядка сортировки Ну и проводить сбор статистики для корректно работы оптимизатора в новой версии редшифта есть автоматический analyze, который запускается сам.
- #54 Поговорим о компрессии
- #55 Как вы думаете как управляется компрессия в бигквери? А как в сноуфлейке? А теперь загадка – с какой субд эта табличка. Нет, с гринплама
- #56 У редшифта огромнейший выбор алгорирмтов компрессии, поэтому их выбор это целый процесс
- #57 Необходимо опреелить размер колонок Проверить что предлагает сам редшифт с использованием analyze compression Применить и перемерить После этого возрадоваться скоростью операций ввода-вывода и меньшим размером базы данных Кстати, мы любим алгоритм ZSTD
- #58 Изначальная идея гугла была абстрагироваться от физики хранения, ровно как и у всех современных клаудных хранилищ, но идея не взлетела, поэтому первыми появились Вайлдкард таблицы. Знаете что это? Это когда в имени таблицы захардкожена дата и можно писать регэкспы в секции from. Кстати, с ними не работает резалт кэш. Потом партиционирование и кластерные таблицы. Кто знаком с кластерными таблицами в гугле?
- #59 В целом это упорядоченые таблицы, при этом их использование может дать прирост скорости до 4 раз И до 400 раз уменьшить стоимость владения Наконец, исчезает ограничения по тому, что LIMIT приводит к полному сканированию таблицы Ну и при наличии магии можно обойтись даже без партиций.
- #60 При создании таблицы мы указываем поле по какому она кластеризована К сожалению партиция обязательна, но мы указываем ненастоящее поле И подаём туда левую дату. Конечно, это приводит к уменьшению скорости вставки и Требует ручной рекластеризации, что приводит конечно же к оплате этого
- #61 Посмотрим на запрос к обычной и кластеризованной таблице Мы видим, что из-за огромнейшей разницы в просканированном объеме цена падает более чем в 300 раз, при этом сам запрос работает в 3 раза быстрее
- #62 У сноуфлейка можно аналогично указать порядок упорядочивания данных, Который поддерживается автоматическим процессом рекластеризации, который стоит отдельных денег и приводит к увеличению потребления места, что также стоит денег. Таким образом, мы видим, что любые вещи, связанные с увеличением производительности в облачных базах данных, особенно в которых мало возможностей по ручной конфигурации, связаны с серьёзными расходами и всё равно нет шансов абстрагироваться от физического способа хранения данных.
- #63 Для удаления лишнего оборудования нам необходимо Настроить правильно очереди Поработать с работой в многопользовательском режиме Разобраться использованием диска и Дисковыми запросами и понять как изменится Параллелизм загрузки
- #64 Собственно управление очередями
- #65 Очередь это механизм балансировки нагрузки по фифо-принципу Т.е. запросы ждут пока не освободится место после выполнения запроса в очереди Значения по умолчанию слишком малы И сконфигурирована только одна очередь
- #66 Для начала настройки необходимо создать пользователей под виды нагрузок Произвольные запросы Bi Etl Поддержка Создать группы для данной загрузки Присвоить группы пользователям
- #67 Соответственно для каждой очереди обдумать факт использования concurrency scaling. Знаете что это такое? Когда редшифт поднимает дополнительные кластеры в случае возникновения дополнительной нагрузки. Количество кластеров определяется параметром Необходимо установить количество слотов в очереди. Упрощённо говорят слот это запрос. Всего может быть на всю систему 50 слотов. Установить количество памяти в процентах от всей ноды При этом важно понимать, что эти проценты будут использованы для расчёта максималной памяти по запросу как память очереди полделить на слоты. Если необходимо дать больше одного слота на один запрос используйте параметр wlm_slot_count. Это удобно для ускорения запросов и процессов хаузкипинга базы
- #68 Также можно включить опцию шорт квери акс – это фишка создаёт отдельную очередь для коротких мелких запросов. В дефорлтной очереди надо оставить один слот и хоть сколько-то памяти чтобы в случае проблемы с кластером дба мог его починить
- #69 Для работы с конкурентностью необходимо пронаблюдать сколько в течении недели запросы проводят в очеред ожидания. Время ожидания пропорционально количеству слотов. Пересчитайте новое время ожидания с учетом изменения количества слотов
- #70 Утилизация диска Проверьте утилизацию диска в динамике за неделю Важно, чтобы потребление диска было не более 70-80 процентов Объем диска меняется пропорционально количеству нод. Собтвенно оцените с этим условием утилизацию.
- #71 Вообще есть метрика про утилизацию, но ей верить нельзя, так как она не учитывает кучу параметров, таких как буфера, временные таблицы и т.д.
- #72 Для борьбы с дисковыми запросами необходимо понять сколько их Если их более 10 процентов необходим тюнинг очередей. Если их количество не уменьшилось убирать ноды невозможно
- #73 Если же их действительно мало, то надо учитывать, что количество дисковых запросов пропорционально количеству памяти в слотах. Оцените новый размер очередей и сравните со средним ожиданием запросов в очереди
- #74 Со скоростью загрузи тоже всё понятно. Проверяем время загрузку в течении недели Скорость загрузки прямо пропорциональна количеству нод Соответственно оцените скорость при уменьшении нод
- #75 Ну что ж Начинаем уменьшать кластер
- #76 У нас 11 нод, Одна очередь В день запросы висят по 500 секунд в ожидании Есть около 20 процентов дисковых запросов и мы потребляем 91 процент диска Загрузка занимает в среднем 20 секунд и Стоит это 655 тысяч
- #77 Итак, выкидываем три ноды Добавляем и настраиваем 5 очередей Время ожидания падает до 150 секунд Из-за грамотной настройки количество дисковых запросов падает до 5 процентов Грамотная компрессия даётс утилизацию диска 80% Пострадала только загрузка, но 26 секунд это приемлемо Итого получаем экономию 180 тысяч долларов
- #78 Остаются констрейнты
- #79 Существуют три типа констрейнтов Уникальные Первичные Внешние ключи При этом редшифт их не проверяет. Они чисто декларативные. Нот нал реально проверяются Соответственно первые 3 должны быть гарантированы етл процессом И используются они оптимизатором
- #80 В процесс определения порядка джоинов Исключения ненужных таблиц Расчёта количества уникальных значений
- #81 Рассмотрим запрос который считает количество уникальных значений с констрейнтом Без констрейнта И мы видим, что в случае с констрейнтом есть реальные двойники, зато бычтро. Это происходит по причине использования последовательного сканирования, чтобы не тратить cpu на исключение дубликатов Тогда как при использовании без констрейнтов дубликатов нет так как в плане появляется операция Юник
- #82 Посчитаем обычное количество записей для двух таблиц с джоином. Для плана без констрейнтов у нас довольно сложный план В то время как для плана с констрейнтом план сверхпростой. Произошло исключение таблицы parents из-за констрейнта, Но поэтому мы имеем неправильный результат. В то время как без констрейтов результат правилен, ибо происходит честный джоин 2 таблиц. Но зато быстро выдаем неправильны
- #83 Мы используем констрейнты Потому что верим в етл Но на всякий случай у нас есть недельные джобы проверки данных Тем самым мы помогаем оптимизатору и у нас очень быстрые отчёты
- #84 Ну что же, пора подводить выводы Клауд это не панацея, которая позволяет абстрагироваться от уровня хранения Начинайте работу с хранилищем с модели данных, причём Данные подходы могут подойти для многих клаудных баз данных Верьте в уникальные фишки ваших баз данных И не бойтесь выкидывать железо – не всегда это плохо Добавление нового железа должно быть только в крайнем случае Конечно же не верьте мастерам миграций и те кто работает в россии порадуйтесь – у нас нет клаудных хранилищ Ну и повторюсь ещё раз – правильная модель данных это важно
- #85 Всем спасибо за внимание