Rumah > Artikel > pembangunan bahagian belakang > Bagaimanakah YouTube menyimpan fail video yang besar?
Helo semua, saya Bucai Chen~
YouTube ialah tapak web kedua paling popular selepas Google. Pada Mei 2019, lebih daripada 500 jam kandungan video telah dimuat naik ke platform setiap minit.
Platform perkongsian video mempunyai lebih daripada 2 bilion pengguna, dengan lebih daripada 1 bilion jam video dimainkan setiap hari, menjana berbilion tontonan. Ini adalah nombor yang luar biasa.
Artikel ini akan memberikan penjelasan mendalam tentang pangkalan data dan infrastruktur data belakang yang digunakan oleh YouTube, yang membolehkan platform video menyimpan sejumlah besar data dan skala kepada berbilion pengguna.
Kemudian mari kita mulakan.
Perjalanan YouTube bermula pada tahun 2005. Memandangkan permulaan teknologi yang dibiayai modal teroka terus menemui kejayaan, ia telah diperoleh oleh Google pada November 2006 dengan harga $1.65 bilion.
Sebelum diperoleh oleh Google, pasukan mereka terdiri daripada:
YouTube Perkhidmatan mikro bahagian belakang ditulis dalam Python, pangkalan data, perkakasan, Java (menggunakan rangka kerja Guice) dan Pergi. Antara muka pengguna ditulis menggunakan JavaScript.
Pangkalan data utama adalah MySQL yang disokong oleh Vitess Vitess ialah sistem kluster pangkalan data yang digunakan untuk pengembangan mendatar MySQL. Selain itu, gunakan Memcache untuk caching dan Zookeeper untuk penyelarasan nod.
Video popular disiarkan melalui CDN, manakala video umum yang kurang dimainkan diambil daripada pangkalan data.
Apabila setiap video dimuat naik, ia akan diberikan pengecam unik dan akan diproses oleh tugas kelompok ini akan menjalankan berbilang proses automatik, seperti menjana imej kecil, metadata dan video. menetapkan status pengewangan dan banyak lagi.
Kodek Pengekodan Video Lanjutan AVC VP9 & H.264/MPEG-4 digunakan untuk pemampatan video dan mampu mengekodkan video berkualiti HD dan 4K menggunakan separuh lebar jalur codec lain.
Penstriman video menggunakan Penstriman Adaptif Dinamik berdasarkan protokol HTTP, iaitu teknologi penstriman kadar bit adaptif yang boleh mencapai penstriman video berkualiti tinggi daripada pelayan web HTTP tradisional. Dengan teknologi ini, kandungan boleh disampaikan kepada penonton pada kadar bit yang berbeza. Pelanggan YouTube secara automatik menyesuaikan pemaparan video kepada kelajuan sambungan internet penonton untuk meminimumkan masa penimbalan.
Saya telah membincangkan proses transkoding video YouTube dalam artikel khusus, lihat "Cara YouTube menyediakan video berkualiti tinggi dengan kependaman rendah".
Jadi, berikut ialah pengenalan pantas kepada teknologi bahagian belakang platform. Pangkalan data utama yang digunakan oleh YouTube ialah MySQL. Sekarang, mari kita fahami mengapa pasukan kejuruteraan YouTube merasakan keperluan untuk menulis Vitess? Apakah masalah yang mereka hadapi dengan persekitaran MySQL asal mereka yang menyebabkan mereka melaksanakan rangka kerja tambahan di atasnya?
Tapak web pada mulanya hanya mempunyai satu contoh pangkalan data. Apabila tapak web berkembang, pembangun perlu mengembangkan pangkalan data secara mendatar untuk memenuhi keperluan QPS (pertanyaan sesaat) yang semakin meningkat.
Replika akan ditambahkan pada contoh pangkalan data induk. Permintaan baca dihalakan ke pangkalan data utama dan replika untuk mengurangkan beban pada pangkalan data utama. Menambah replika membantu mengurangkan kesesakan, meningkatkan daya baca dan meningkatkan ketahanan sistem.
Nod induk mengendalikan trafik tulis, dan nod induk dan nod replika mengendalikan trafik baca pada masa yang sama.
Walau bagaimanapun, dalam senario ini, adalah mungkin untuk membaca data basi daripada replika. Jika permintaan membaca data replika sebelum induk mengemas kini maklumat kepada replika, penonton akan mendapat data basi.
Pada masa ini, data nod induk dan nod replika tidak konsisten. Dalam kes ini, data tidak konsisten ialah bilangan tontonan video tertentu pada nod utama dan replika.
Sebenarnya, ini tiada masalah sama sekali. Penonton tidak akan keberatan dengan sedikit ketidakkonsistenan dalam kiraan tontonan, bukan? Apatah lagi, video itu boleh dipaparkan dalam penyemak imbas mereka.
Data antara nod induk dan nod replika akhirnya akan menjadi konsisten.
Jadi jurutera sangat gembira dan penonton juga sangat gembira. Dengan pengenalan replika, semuanya berjalan lancar.
Laman web terus popular dan QPS terus meningkat. Strategi replika tuan-hamba kini menghadapi kesukaran untuk mengikuti pertumbuhan trafik laman web.
Apa yang perlu dilakukan sekarang?
Strategi seterusnya adalah untuk memecah pangkalan data. Sharding ialah salah satu cara untuk melanjutkan pangkalan data hubungan sebagai tambahan kepada replika tuan-hamba, replika tuan-tuan, persekutuan dan penyahnormalan.
Perkongsian pangkalan data bukanlah satu proses yang mudah. Ia sangat meningkatkan kerumitan sistem dan menjadikan pengurusan lebih sukar.
Walau bagaimanapun, pangkalan data mesti dipecahkan untuk memenuhi pertumbuhan QPS. Selepas pembangun memecahkan pangkalan data, data itu tersebar di beberapa mesin. Ini meningkatkan daya pemprosesan sistem. Kini, daripada hanya satu pengendalian contoh induk menulis, operasi tulis boleh berlaku merentas berbilang mesin yang dipecahkan.
Selain itu, salinan berasingan dibuat untuk setiap mesin untuk lebihan dan pemprosesan.
Kepopularan platform terus meningkat, dengan sejumlah besar data ditambahkan pada pangkalan data oleh pencipta kandungan.
Untuk mengelakkan kehilangan data atau ketiadaan perkhidmatan yang disebabkan oleh kegagalan mesin atau peristiwa luaran yang tidak diketahui, fungsi pengurusan bencana perlu ditambahkan pada sistem.
Pengurusan bencana merujuk kepada langkah kecemasan dalam menghadapi gangguan bekalan elektrik dan bencana alam (seperti gempa bumi dan kebakaran). Ia perlu berlebihan dan menyandarkan data pengguna ke pusat data di kawasan geografi yang berbeza di dunia. Kehilangan data pengguna atau ketidaksediaan perkhidmatan adalah tidak dibenarkan.
Mempunyai berbilang pusat data di seluruh dunia juga membantu YouTube mengurangkan kependaman sistem, kerana permintaan pengguna dihalakan ke pusat data terdekat dan bukannya dihalakan ke pelayan asal yang terletak di benua berbeza.
Kini, anda boleh bayangkan betapa kompleksnya infrastruktur itu.
Selalunya terdapat imbasan jadual penuh yang tidak dioptimumkan yang melumpuhkan keseluruhan pangkalan data. Pangkalan data mesti dilindungi daripada pertanyaan buruk. Semua pelayan perlu dijejaki untuk memastikan perkhidmatan yang cekap.
Pembangun memerlukan sistem yang menguraikan kerumitan sistem, membolehkan mereka menyelesaikan cabaran kebolehskalaan dan mengurus sistem dengan kos yang minimum. Semua ini menyebabkan YouTube membangunkan Vitess.
Vitess ialah sistem kluster pangkalan data yang dijalankan pada MySQL, yang membolehkan pengembangan mendatar MySQL. Ia mempunyai ciri sharding terbina dalam yang membolehkan pembangun menskalakan pangkalan data tanpa perlu menambah sebarang logik sharding pada aplikasi. Ini serupa dengan apa yang dilakukan oleh NoSQL.
Vitess juga mengendalikan failover dan sandaran secara automatik. Ia mengurus pelayan dan meningkatkan prestasi pangkalan data dengan menulis semula pertanyaan intensif sumber secara bijak dan melaksanakan caching. Selain YouTube, rangka kerja ini juga digunakan oleh pemain terkenal lain dalam industri, seperti GitHub, Slack, Square, New Relic, dsb.
Vitess memainkan peranan apabila anda memerlukan sokongan untuk transaksi ACID dan konsistensi yang kukuh, tetapi juga ingin menskalakan pangkalan data hubungan secepat pangkalan data NoSQL.
Di YouTube, setiap sambungan MySQL mempunyai overhed 2MB. Setiap sambungan mempunyai kos yang dikira, dan apabila bilangan sambungan meningkat, RAM tambahan mesti ditambah.
Vitess dapat mengurus sambungan ini pada kos yang sangat rendah melalui kumpulan sambungan yang dibina di atas sokongan serentak bahasa pengaturcaraan Go. Ia menggunakan Zookeeper untuk mengurus kluster dan memastikan ia dikemas kini.
Vitess adalah asli awan dan sangat sesuai untuk penggunaan awan, kerana sama seperti model awan, kapasiti ditambah secara beransur-ansur pada pangkalan data. Ia boleh dijalankan sebagai pangkalan data teragih berasaskan awan yang sedar Kubernetes.
Di YouTube, Vitess berjalan dalam persekitaran kontena dan menggunakan Kubernetes sebagai alat orkestrasi kontena.
Dalam era pengkomputeran hari ini, setiap perkhidmatan berskala besar berjalan di awan dalam persekitaran yang diedarkan. Terdapat banyak faedah untuk menjalankan perkhidmatan dalam awan.
Google Cloud Platform ialah satu set perkhidmatan pengkomputeran awan berdasarkan infrastruktur yang sama yang digunakan oleh produk pengguna akhir dalaman Google seperti Carian Google dan YouTube.
Setiap perkhidmatan dalam talian berskala besar mempunyai seni bina kegigihan polyglot kerana model data tunggal, sama ada hubungan atau NoSQL, tidak dapat mengendalikan semua senario penggunaan perkhidmatan.
Semasa penyelidikan untuk artikel ini, saya tidak dapat mencari senarai pangkalan data Google Cloud khusus yang digunakan oleh YouTube, tetapi saya agak pasti ia menggunakan produk khusus GCP seperti Google Cloud Spanner, Cloud SQL, Cloud Datastore , Memorystore, dsb. untuk menjalankan ciri perkhidmatan yang berbeza.
Artikel ini memperincikan pangkalan data yang digunakan oleh perkhidmatan Google yang lain, seperti Google Adwords, Google Finance, Google Trends, dsb.
YouTube menggunakan rangkaian global Google untuk penghantaran kandungan kependaman rendah dan kos rendah. Dengan titik tepi POP yang diedarkan secara global, ia membolehkan pelanggan memperoleh data dengan lebih pantas tanpa perlu mengambilnya daripada pelayan asal.
Jadi, sehingga tahap ini, saya telah bercakap tentang pangkalan data, rangka kerja dan teknologi yang digunakan oleh YouTube. Sekarang, tiba masanya untuk bercakap tentang storan.
Bagaimanakah YouTube menyimpan sejumlah besar data (500 jam kandungan video yang dimuat naik setiap minit)?
Video akan disimpan pada pemacu keras di pusat data Google. Data ini diurus oleh Sistem Fail Google dan BigTable.
Sistem Fail Google GFS ialah sistem fail teragih yang dibangunkan oleh Google untuk mengurus data berskala besar dalam persekitaran teragih.
BigTable ialah sistem storan data teragih kependaman rendah yang dibina pada Sistem Fail Google, digunakan untuk memproses data peringkat PB yang diedarkan pada beribu-ribu mesin. Ia digunakan dalam lebih daripada 60 produk Google.
Oleh itu, video disimpan pada cakera keras. Perhubungan, metadata, pilihan pengguna, maklumat profil, tetapan akaun, data berkaitan yang diperlukan untuk mendapatkan video daripada storan, dsb. semuanya disimpan dalam MySQL.
Pusat data Google mempunyai perkakasan dan perisian yang homogen dibina secara dalaman , mengurus beribu-ribu kluster pelayan bebas.
Pelayan yang digunakan oleh Google boleh meningkatkan keupayaan storan pusat data Kesemuanya adalah pelayan komersil (pelayan komoditi), juga dikenali sebagai pelayan di luar rak komersial (pelayan di luar rak komersial). . Pelayan ini berharga rendah, tersedia secara meluas dan dibeli dalam kuantiti yang banyak, dan boleh menggantikan atau mengkonfigurasi perkakasan yang sama dalam pusat data pada kos dan perbelanjaan yang minimum.
Memandangkan keperluan untuk storan tambahan meningkat, pelayan komoditi baharu dipalamkan ke dalam sistem.
Apabila masalah timbul, pelayan komersial sering diganti dan bukannya dibaiki. Ia tidak dibuat tersuai, dan menggunakannya membolehkan perniagaan mengurangkan kos infrastruktur ke tahap yang ketara berbanding dengan menjalankan pelayan tersuai.
YouTube memerlukan lebih satu petabait storan baharu setiap hari. Pemacu keras berputar adalah medium storan utama kerana kosnya yang rendah dan kebolehpercayaan yang tinggi.
Pemacu keadaan pepejal SSD mempunyai prestasi yang lebih tinggi daripada cakera berputar kerana ia berasaskan semikonduktor, tetapi menggunakan SSD pada skala besar tidak menjimatkan kos.
Ia agak mahal dan terdedah kepada kehilangan data dari semasa ke semasa. Ini menjadikan mereka tidak sesuai untuk penyimpanan data arkib.
Secara berasingan, Google sedang membangunkan siri cakera baharu yang sesuai untuk pusat data berskala besar.
Terdapat lima metrik utama yang boleh digunakan untuk menilai kualiti perkakasan yang dibina untuk penyimpanan data:
Atas ialah kandungan terperinci Bagaimanakah YouTube menyimpan fail video yang besar?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!