У идеалном свету инжењера, архитектура је увек лепа. У стварном свету великих система, морате направити компромисе. trade-off between Write Speed and Read Speed. Обично жртвујете једну за другу, али у нашем случају, радећи са петабајтима података у АВС-у, овај компромис није погодио нашу брзину – погодио је . wallet Изградили смо систем који савршено пише податке, али сваки пут када се чита из архиве, спалио је кроз буџет на најболан начин који се може замислити.На крају крајева, читање петабајта из АВС-а кошта новац за пренос података, бројеве захтева и преузимање класе складишта... Много новца! Ovo je priča o tome kako smo ga optimizovali da bi bio efikasniji i ekonomičniji! Део 0: Како смо на крају потрошили 100.000 долара на AWS накнаде! Istinita priča: pre nekoliko meseci, jedan od naših arhitekata rešenja želeo je da izvede uzorak sa retke, niskotrgovinske veb stranice kako bi predstavio proizvod potencijalnom kupcu. Пошто су подаци за ову "ретку" локацију били раштркани кроз милионе архива заједно са локацијама са високим саобраћајем, систем је покушао да поврати скоро половину нашег читавог историјског складишта да би пронашао те неколико страница. Ta iskrena greška nas je na kraju koštala $100,000 in AWS fees! Сада сам одмах поправио АПИ грешку (и додао строге границе), али архитектонска рањивост је остала. Dozvolite mi da vam ispričam priču o svetlim podacima Архитектура: како сам возио систем у замку "јефтиног" складиштења и како сам изашао користећи . WEB Архива Rearrange Pipeline WEB Архива WEB Архива Део 1: Наслеђе „Првог писања“ Када сам почео да радим на Веб Арцхиве-у, систем је већ узимао огроман ток података: милионе захтева у минути, десетине терабајта дневно. Ослањао се на најтрајнију стратегију за системе високог протока: Append-only Log. 
 
 
 
 
 Подаци (ХТМЛ, ЈСОН) су буферни. Када буфер достигне ~300 МБ, он је "запечаћен" у ТАР архиву. Архива лети до С3. Након 3 дана, датотеке се преносе у С3 Глециер Дееп Арцхиве. За фазу уноса, овај дизајн је био беспрекоран. складиштење података у Дееп Арцхиве кошта пени, а проток писања је практично неограничен. Проблем: та нијанса цена Архитектура је савршено радила за писање... све док клијенти нису тражили историјске податке. 
 
 
 Систем пише по времену: Архив од 12:00 сати садржи мешавину цнн.цом, гоогле.цом и шоп.киз. Систем чита по домену: Клијент тражи: "Дајте ми све странице из цнн.цом за последњу годину." Ево грешке која је инспирисала овај чланак.Као и многи инжењери, навикао сам да размишљам о Ali sam zaboravio na . latency, IOPS, and throughput AWS Glacier billing model Мислио сам: "Па, повраћање неколико хиљада архива је споро (48 сати), али то није тако скупо." AWS naplaćuje ne samo za API poziv, već i za (Долари по ГБ се враћају) The Reality: volume of data restored Ефекат „златног бајта“ Замислите да клијент тражи 1.000 страница из једног домена.Пошто је логика писања била хронолошка, ове странице се могу дистрибуирати преко 1.000 различитих АРТ архива. Да би се клијенту дало ових 50 МБ корисних података, дође до катастрофе: 
 
 
 
 
 Систем мора да покрене рестаурацију за 1000 архива. Он извлачи 300 ГБ података из "замрзивача" (1000 архива × 300 МБ). АВС нас наплаћује за враћање 300 ГБ. Извадим потребних 50 МБ и бацим осталих 299,95 ГБ . Платили смо да обновимо терабајте смећа само да бисмо извукли зрна злата. Проблем који је постао финансијска црна рупа. Data Locality Део 2: Исправљање грешке: Реорганизација цевовода Нисам могао брзо да променим метод уноса - улазни ток је превише паралелан и масиван да би се сортирао "на лету" (иако радим на томе), и требало ми је решење које је радило и за већ архивиране податке. Тако сам дизајнирао , позадински процес који „дефрагментира“ архиву. Rearrange Pipeline Ово је асинхрони ЕТЛ (Ектрацт, Трансформ, Лоад) процес, са неколико критичних кључних компоненти: 
 
 
 
 
 
 
  It makes no sense to sort data that clients aren’t asking for. Thus, I direct all new data into the pipeline, as well as data that clients have specifically asked to restore. We overpay for the retrieval the first time, but it never happens a second time. Selection: 
 
  Multiple workers download unsorted files in parallel and organize buffers by domain. Since the system is asynchronous, I don’t worry about the incoming stream overloading memory. The workers handle the load at their own pace. Shuffling (Grouping): 
 
 
  I write the sorted files back to S3 under a new prefix (to distinguish sorted files from raw ones). Rewriting: 
 
 
 Before:   →  2024/05/05/random_id_ts.tar [cnn, google, zara, cnn] After:   →  2024/05/05/cnn/random_id_ts.tar [cnn, cnn, cnn...]  
 
 
  In Snowflake, the metadata table is append-only. Doing   or   is prohibitively expensive. Metadata Swap: MERGE INTO UPDATE 
 
 The Solution: I found it was far more efficient to take all records for a specific day, write them to a separate table using a JOIN, delete the original day’s records, and insert the entire day back with the modified records. I managed to process   in just a few hours on a 4X-Large Snowflake warehouse. 300+ days and 160+ billion UPDATE operations Резултат Ова промена је радикално променила економију производа: 
 
 
 
 Тачност тачке тачке: Сада, када клијент затражи цнн.цом, систем враћа само податке где цнн.цом живи. Ефикасност: У зависности од грануларности захтјева (уношење домена у односу на специфичне URL-ове преко регекса), постигао сам смањење од 10% до 80% у претраживању "гробних података" (што је директно пропорционално трошковима). Нове могућности: Поред само уштеде новца на отпаду, ово је откључало потпуно нове случајеве пословне употребе. Пошто повраћање историјских података више није агонично скупо, сада можемо приуштити да извучемо масивне скупове података за обуку АИ модела, спроводимо дугорочна истраживања тржишта и градимо базе знања за агентне АИ системе да размишљају (мислите на специјализоване претраживаче). Mi iznajmljujemo Bright Data проширује веб архиву још више. Ако вам се свиђа: 
 
 
 
 
 
 Дистрибуирани системи високог протока, Инжењеринг података у великим размерама, Изградња поузданих гасовода под реалним оптерећењем, Pushing Node.js до својих апсолутних граница, Решавање проблема који се не појављују у уџбеницима ... Tada bih volela da pričam. Mi zapošljavamo snažne Node.js inženjere da pomognemo u izgradnji sledeće generacije Web Arhiva. Imati iskustvo u inženjeringu podataka i ETL-u je veoma povoljno. . Вадимр@брајтдата.цом Вадимр@брајтдата.цом Вадимр@брајтдата.цом Више ажурирања долази док наставим да скалирам архиву - и док стално проналазим нове и креативне начине да га разбијем!

Walkthroughs, tutorials, guides, and tips. This story will teach you how to do something new or how to do something better.

This writer has a vested interest be it monetary, business, or otherwise, with 1 or more of the products or companies mentioned within.

2022 - HackerNoon Contributor of the Year - Amazon

Request Your Own Data

Nominated for 2022 - HackerNoon Contributor of the Year - Amazon

Овај аудио је произведен на оригиналном језику приче!

Изградња веб архиве у скали од петабајта

About Author

КОМЕНТАРИ

ХАНГ ТАГС

ОВАЈ ЧЛАНАК ЈЕ ПРЕДСТАВЉЕН У

Related Stories

Scaling Web Testing with Automation: Srikanth Srinivas’s Digital Strategy Breakthrough

Building a website with React and Bulma

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Scaling Web Testing with Automation: Srikanth Srinivas’s Digital Strategy Breakthrough

Building a website with React and Bulma

Building the Cloud Future: Sreedevi Velagala's Trek in AWS Architecture

Leadership Success Story: Srinath Muralinathan's Transformative Projects at Amazon

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps