To si od SGI objednas kamion, a ten je plnej blejd serveru v rakach, a kazdej ma treba 8 disku, a tvari se ten kamion jako jeden velkej 1000 procesorovej stroj napriklad. Maj to vychytany natolik, ze ty blejd servery nemaji ani zdroje, je k nim rovnou privedenych potrebnych X voltu, chlazeni maji vymyslene aby co nejlip chladilo celej rack prirozenym proudenim vzduchu, proste to maj vychytane :) Videl jsem o tom prednasku na nejakem Linux Expu nebo necem takovem. Nerikam ze to tak dela google, jen ze ty moznosti jsou daleko nekde jinde nez u jednoserverovych krabic s jednim diskem.
Kdyz vezmu ze jedno 15ti minutove video je treba 100MB, tak za 1 vterinu musej ulozit 400MB, coz je cca 35TB za den. A to je 'pouhych' 18 dvouterovych disku, plus nejaka ta parita. Kdyz beru ceny na ktere dosahnu ja (3000,- za disk) tak to dela nejakych 60000 CZK nakladu denne, kdyz nepocitam ze ty disky musej byt do neceho pripojeny. Ale velkoodberatel jako google urcite ma ceny uplne jine, a urcite neplati 20% DPH jako ja :)
Pokud má organizace 50 a víc vývojářů, které může dedikovat na infrastrukturu, tak se takové věci už dělají jinak. U webových technologií není potřeba, aby se operační systém nebo úložiště tvářilo jako jeden systém nebo jedno úložiště.
Ta architektura bude poměrně jednoduchá - nějaké clusteříky s lokálnimi disky apod. Vše se zjednodušší, když si uvědomíte, že význam jednotlivých videí není stejný a v čase se navíc mění k lepšímu. Stojí to v podstatě na tom, že se musí vyřešit úzká hrdla operačního systému, serverů (HW), aplikací a I/O systému. A to jde vždy lépe nějakou inteligentní SW politikou než hrubou HW silou. Navíc tu SW politiku můžete časem adaptovat, což se s HW dělá dost blbě.
A k těm výpočtům kapacity: + repliky na úrovni základního úložiště + repliky na úrovni CDN + každé video se, pokud se nepletu, generuje do 3(?) formátů + videa se připravují v několika rozlišeních (nevím jaké má YT politiky). Takže ona kapacita roste daleko rychleji.