2014年10月、Mail.Ruグループは16周年を迎えました。 そして、この期間の半分以上（小さな尾を使って最大8年）同僚と一緒に構築および開発し、My World（旧Video Mail.Ru）のビデオホスティングをサポートしています。 長年にわたり、爆発的な成長、再編成、技術と戦略のアーキテクチャの変更、サービスの再設計、合併、買収など、多くのことを経験してきました。 そして今、これらすべてを経て、振り返って、Habrの聴衆と私たちのサービスの簡単な歴史を共有したいと思います。 おもしろいと思います。

1.写真を撮り、ファイルで仕上げます

2006年、オンラインビデオはアメリカのインターネットで確固たる地位を確立し、ネットワークのロシアセグメントで急速に成長し始めました。 当時のMail.Ruは、ロシア最大の郵便サービスであり、最大の写真ホスティング（foto.mail.ru）でもありました。 mail.ruユーザーがビデオホスティングに関心を持っていることが明らかになりましたが、それは言うのがどれほど難しいか、そしてビデオホスティングをできるだけ早くアーキテクチャ上、mail.ru写真ホスティングのサブプロジェクトとして構築することを決定しましたが、ユーザーインターフェイスの観点から別のメールプロジェクトとして選択しました。る。 そこで、Video Mail.Ruのアイデアが生まれました。



そのため、当時のPhoto Host.Photo Mail.Ruはどうでしたか。 写真コンテンツリポジトリは、Mail.Ru Mailリポジトリと同一のエンジン上に構築されました。 各フォトホスティングユーザーは、ストレージサーバーの1つに独自のディレクトリを持ち、その中にファイルは写真と写真のプレビュー、すべての写真のメタデータと写真アカウントの論理構造（ユーザーフォトアルバム）を含むBDBファイルがありました。



ビデオをユーザーの写真と同じディレクトリに保存することにしました。 これにより、個別のビデオストレージインフラストラクチャを展開する時間が節約されました。 しかし、論理的には、ユーザーのビデオは写真から分離されており、ビデオアルバムのリストを持つ別個のインデックスでした。 ビデオアカウントに初めてアクセスすると、フォトアルバムの構造と同一のビデオアルバム構造が作成されます。これは、ユーザーにとってVideo.Ru Videoプロジェクトで別のアカウントを作成するように見えました。 したがって、アカウントのビデオコンテンツを管理するロジック全体（アルバムの作成、コピー、クリップの転送、クリップの名前変更、コメント、投票など）は、実際にコードに既に実装されています（残っているのは、ビデオアカウント属性に追加のフラグを数十の場所に追加することでした）。 最初から記述しなければならないのは、ビデオファイルの非同期ダウンロード（つまり、すぐに表示できる完全に完成した写真とは異なり、ブートローダーの終了時に、トランスコーダーがムービーを入れる空のコンテナーを作成する必要がありました）、トランスコーディングコンポーネント、フラッシュ-ビデオプレーヤーだけでなく、写真を提供するサーバーに教えて、ビデオコンテンツを提供します。



この中で最も難しいのはトランスコーダーでした。 コンテンツ処理ロジックを記述し、トランスコーディングプロセスの終了に関する通知システムを追加する必要がありました。 オンライン再生用のコンテンツを準備する手段として、最も人気のある（おそらく当時唯一の）ビデオ変換パッケージであるFFMPEGが選ばれました。 処理キューは、MySQLテーブルに基づいて構築され、コンテンツを受信する各サーバー（および開始時に2つのみ）で、このテーブルを定期的に読み取り、このサーバーにあるタスクを選択するデーモンが起動されました。ユーザーがアップロードしたファイルが表示されると、トランスコーディングスクリプトが起動されます。 最初の段階のスクリプトはファイル（FFMPEGom）を分析しました。 トランスコードを開始するには、ファイルにビデオトラックと複数のビデオフレームが必要です（ユーザーからのビデオトラックなしではオーディオトラックを受け入れないことをすぐに決定しました）。 元のムービーは、ページ上のプレーヤーのサイズ（約450 x 350ピクセル）に比例するようにサイズを変更せずにサイズ変更され、サイトのページに表示する2つの小さなプレビューと、ビデオに近いサイズの1つの大きなプレビュー（プレーヤーでの表示）をカットします。



一般に、サービス図は次のようになりました。







そして、この形式で、2006年10月10日に正常に起動しました。 私たちは非常に迅速に管理し、ゼロから開発までの開発には2か月以上かかりました。

2.ボタンアコーディオンなしの結婚式

プロジェクトの立ち上げのほぼ直後に、プロジェクトで改善または最適化できるものを探し始めました。 ユーザーがダウンロードしたコンテンツをすばやく分析したところ、ほとんどのビデオが「虐殺」、つまりシステムに既に存在するクリップであることがすぐにわかりました。 トランスコーダーは定期的にアイドル状態になり、同じファイルで同じ変換を数回行うことが判明しました。 私はすぐにこのプロセッサ時間を節約したいと考えました。これにより、ダウンロードが完了した直後にファイルのMD5ハッシュを削除し、処理が成功した後にテーブルに追加するようになりました。 テーブルの分析は、「重複」がすべてのダウンロードの15％以上を占め、最適化が要求されていることを示しました。MD5ビデオを削除した直後にテーブルで検索し、見つかった場合は、リソースを大量に消費するトランスコーディングプロセスを開始する代わりに、完成したビデオを取り出しましたストアからコピーし、コピーをアップロードしたユーザー用に複製しました。 これにより、トランスコーダーのプロセッサー時間の15％を常に節約することが可能になり、MD5ベースの増加に伴い、この割合はゆっくりと確実に増加しました。 しかし、残念なことに、そのような最適化の結果として、リポジトリに重複が出現し、その一意でない文字を考慮して、コンテンツをより効率的に保存する方法を考え出す必要があることは明らかでした。 少し後にこの問題に戻りました。

3.一度に全部しないでください

このプロジェクトは非常に急速に成長し、写真ホスティングのアーキテクチャは多くの面でビデオストレージに非常に不十分に適用されるため、すぐに問題が発生し始めました。 また、多くのリソース（特にストレージとトラフィック）を消費することがすぐに明らかになったため、プロジェクトの収益化を試みる必要があり、何らかの形でそれを取り戻そうとする必要がありました。 現時点でも、ビデオプロジェクトを収益化するための主で唯一の方法は、広告を表示することです。 しかし、写真のあるページに多くのバナーやコンテキスト広告を表示できる写真ホスティングとは異なり、ページ自体のビデオ表示はいずれにしても非常に小さくなります（コンテンツユニットがはるかに小さいため）が、その中にビデオプレーヤーなどのコンポーネントがありますビデオを見ながら、広告のプリロール、ポストロール、オーバーレイなどを表示できます。 つまり、最大の利益を得るためには、ビデオプレーヤーの最大数を表示する必要があります。ここで、写真との違いをすぐに見ることができます。ビデオホスティングの場合、広告表示はプロジェクト内だけでなく、ユーザーがビデオプレーヤーを挿入したページでも実行できます。ビデオのあるページで、プレーヤー挿入コードを追加します。 しかし、この挿入コードの配布を開始すると、すぐに一部の記事の負荷が急激に増加することに直面しました。 ユーザーが要求するファイルを分析し、最も重要なこととして、どのサイトからコンテンツが要求されているかを分析しました。ホットで頻繁にライセンスのないビデオコンテンツをダウンロードして、ビデオをピックアップしているプレーヤーのサイトに表示するサイトの所有者が極端な負荷をかけることが判明しました。まっすぐなURLで。



これと、そして緊急に戦う必要がありました。 通常はライセンス契約に矛盾するため、このようなコンテンツをサイトから安全に削除でき、負荷を軽減できることは明らかです。 また、負荷がほとんど常にサーバー間で均等に分散される写真ホスティングとは異なり、ホットコンテンツをキャッシュするための技術が必要であり、どのコンテンツがホットになるかを事前に予測することは非常に難しいという事実によって状況が複雑になることも明らかになりました。 そして、公開コンテンツが保護なしで何らかの方法で提供される（配信時にまだ公開されていることのみを制御する）写真ホスティングとは異なり、コンテンツ配信をプレーヤーにリンクする技術が必要であり、直接URLでコンテンツをダウンロードする機能が複雑になることが判明しました。 さらに、プロジェクトの収益化の成功はこの技術に依存していたため、後者が最も重要であり、プリロールディスプレイを失わないように、ある種の保護を可能な限り迅速に導入する必要がありました。 コンテンツをrtmpストリームの形式で提供しようとすることもできますが、そのようなソリューションを迅速に実装することは容易ではありませんでした。生成またはプレーヤーに送信される何らかのキーを実装し、コンテンツの送信時に確認する方が簡単でした。



その時点でこの問題を解決する最も簡単で最も効果的な方法は、サーバー上のコンテンツのIDに応じてキーを生成し、コンテンツを送信するサーバーがこのCookieをさらに検証するために、Cookie内のプレーヤーとして設定することでした。 この方法はすぐに実装され、ドメイン内のユーザーに適切なCookieを設定する方法がなかったため、「偽の」プレーヤーの作成者にとっては困難になりました。 このソリューションの主な欠点は、Cookieの操作方法がわからない顧客にコンテンツを配信する機能が失われたことです。 しかし、当時は、Flash Playerを使用してデスクトップでのみビデオを再生する方法を知っていたため、この制限は問題を引き起こしませんでした。 この保護の実装により、すぐにプロジェクトの負荷が軽減され、一時的に軽減されましたが、いずれにしても、プロジェクトの内部アーキテクチャを変更する必要があることが明らかになりました。この目的のために、写真とビデオのホスティングを分離することをお勧めします。

4.離婚、写真を郵便局に送る

分離の主な問題は、両方のプロジェクトにすでに多くの視聴者がいて、長時間のダウンタイムが不可能だったことです。 ゆっくり動くシナリオが選択されました。 データベース、メタデータリポジトリ、ストレージの3つの分離ポイントがありました。 データベースの主なコンポーネントは、保管場所に情報が保存されているユーザーのテーブルであるため、データベースと保管庫の分離は密接に関連していました。



最初の段階では、ビデオプロジェクトのユーザー用に写真ベースにテーブルが作成され、ユーザー写真のテーブルに「ユーザー分割」フラグが表示されました。 ロジックは、ビデオユーザーを作成し、スキーム「1。 ビデオデータベースでユーザーのレコードを探しています。見つからない場合は、分割フラグなしで写真データベースで探します。 テスト後、実際のユーザーに登録が開始され、ビデオホスティングサービスの新しいユーザーはすぐに分割されました。 今では古いものを分ける必要がありました。 エラーがすぐに開かれなかったパーティションコードに忍び込んだ場合、半分に分割されたユーザーが表示され、修正が非常に困難になるため、エラーのリスクを減らすために、手順をできるだけ簡素化および加速する必要がありました。 したがって、転送は次のアルゴリズムに従って行われました：「最初に、ビデオユーザーアカウントが作成され、次に写真アカウントが記録のためにブロックされました」、ディレクトリが転送用のリストでビデオコンテンツをスキャンし、次にすべてのビデオコンテンツが転送され、bdbがすべてのメタデータ（および写真とビデオ）、新しい場所ですべてのコンテンツの可用性を確認し、分割されたユーザーのフラグを立て、写真アカウントからビデオコンテンツを削除し、以前に設定されたロックを削除します。 すべてのアカウントをバイパスした後、写真とビデオのプロジェクトは完全に物理的に分離されました。

5.シールとアコーディオン

ビデオプロジェクトが個別のインフラストラクチャユニットに分離されたほぼ直後に、これでは不十分であり、ビデオコンテンツの保存方法を変更する必要があることが明らかになりました。 いくつかの問題がありました：最初に、最もアクティブなユーザーのアカウントの一部がストレージの物理的な制限に近づきました（つまり、ディスクに収まるのをやめました。特に、標準ディスクよりも大きなディスクをインストールする必要がありました）。数百のコピー）。 第三に、かなり人気のある「お気に入りに追加」機能の実装が非常に失敗しました。「お気に入り」のクリップのメタデータに元のクリップへのリンクが書き込まれました。 このようなスキームでは、元の映画を移動または削除するときに整合性を維持するために複雑なビジネスロジックが必要でした。 各ビデオのインスタンスを1つだけ保存する専用のビデオストレージが必要であることが明らかになりました。 また、ユーザーが好きなビデオの大規模な個人コレクションを収集できるように、アカウント内および異なるアカウント間でビデオをすばやく便利にダビングできる機能も必要でした。



これらすべてを実装するには、追加のストレージが必要でした。 新しいストレージを開発する時間とリソースがなかったため、写真に似たストレージを使用することにしましたが、ストレージユニットがビデオファイルとプレビューのセットになる、さらに単純化されたエンジン（メタデータ付きのbdbハッシュなし）で構築されました。 このキットでは、「dupe」または「acc」という特別な用語も作成しました（誰もが好むように、高度なコンテンツキャッシュまたはアコーディオンを意味します）。 これらのaccsを使用して、md5のインデックスに元のファイルのサイズを加えたテーブルが作成されました（トランスコーディングプロセスを最適化するために同様のテーブルが既に使用されていたため）。 次に、この表と百を記入する必要がありました。 最初の段階の主なタスクは、ユーザーコンテンツを「崩壊」させる（ビデオの2つのコピーを1つに2つのリンクに変換する）ため、この場合のエラーは非常に高価になるため、信頼できる充填プロセスを確立することでした そのため、ストーリーを次のように埋めることにしました：各ストーリーでユーザーアカウントを使用して、新しいストーリーサーバーの個別のインスタンスを作成し、別のディレクトリを探しました。あるユーザーが別のユーザーのパブリックビデオを自分のアカウントに追加したい場合、このビデオはまだありませんでした新しいリポジトリ、次にストアの同じサーバーの新しいリポジトリに新しいインスタンスを作成し、すべてのacc-contentを転送します。そのような「重複」が既にリポジトリにある場合、コンテンツはバックアップディレクトリに転送されます（回避するために エラーの危険性があるため、すぐに削除しないでください）、ローラーがくっついています。



したがって、ホットコンテンツを接着するプロセスは「単独で」機能しました。 新しいタイプのコンテンツ用に個別のストーリーを作成し、そこに「虐殺」を転送するだけで十分でした。ユーザーは、新しいアーキテクチャではオリジナルのビデオのコピーと変わらないため、ビデオのコレクションを組み立てる優れた便利な方法を手に入れました。 すぐに自分自身に追加する機能が一般的になり、コンテンツに対するすべてのリクエストでアクセスされるようになったため、「ファイト」を持つテーブルの上に追加のメモリ内キャッシュが必要になりました。 このために、猫とのビデオに敬意を表して内部名「KOTIKI」を受け取った新しいサービスが作成されました。猫は非常に長い間、コピー数が最大でした。 また、サービスの急速な発展のために、ビデオユーザーを含むテーブルの上に、さらにクリップとアルバムのメタデータのbdbハッシュのキーを含むキャッシュをさらに2つ作成する必要がありました。 そして、2009年半ばまでに、ビデオサービススキームは次のようになり始めました（以前のスキームになかった要素は赤でマークされました）。

6.より良い

私たちは高負荷に苦しみ、アーキテクチャの変更に取り組んでいましたが、進歩は飛躍的であり、突然、再生用のコンテンツを準備する方法が非常に時代遅れであることがわかりました。 私たちが始めたとき、ビデオはほとんど解像度と低ビットレートが小さく、ブロードバンドアクセスの開発と強力なカメラを備えたスマートフォンの出現により、HDビデオがますますダウンロードされるようになりました。 その時点では、まだflv形式でピンチし、圧縮せずにページ上のプレーヤーに収まるように縮小しました（つまり、450x300ピクセル付近）。ダウンロードしたHDムービーは、次の場合に多くの品質を失います。フルスクリーン再生。 そして最も重要なことは、その時までにフラッシュがMPEG4を再生することを学んだことで、その時までにインターネット上でビデオ用の非常に人気のある形式になりました。FLV形式よりも「ビットマップ」の方がはるかに優れていました。 または、同等の画質で、ファイルは大幅に小さいサイズで取得されました。 一般に、技術進歩の蒸気エンジンに追いつき、できればMPEG4のサポートを忘れずにHDビデオをサポートすることが急務でした。 元のビデオの幅が720ピクセル以上の場合にエンコードされたMP4形式の追加のビデオファイルの形式でサポートすることにしました。



彼らはSDビデオ処理ロジックを変更せずに残すことにしましたが、HDビデオを遮断せず、フォーマットとコンテナを変更しただけです。 当時、すべてがうまく機能していたようでした。フルスクリーンでのFULLHDデモは素晴らしく見えました。 未来はすでにここにありました。 しかし、後で判明したように、2つのミスを犯し、その後多くのサーバーレットが必要になりました。 まず、メインプリセットのFLV形式を変更せずに（つまり、FLVコピー以外の非常に多くのビデオにそれ以上の状況がない場合）、フラッシュFlashの人質のままでした。flvビデオの再生は、フラッシュ、それは非常に問題がありました（もちろん、誰もフラッシュなしのタブレットが世界を引き継ぐとは思いませんでしたが、それでももっと普遍的なフォーマットを選ぶ必要がありました）。 第二に、ビデオのビットレートを制限する必要がありました。これは、その後、単純なチャネルシェーピングの導入を許可しなかったためです。 しかし、当時はすべてが素晴らしく、素晴らしかった。

7.合法化

2010年までに、ビデオはインターネット上に真剣かつ永久に定着し、テレビを強力に圧縮し始めました。 ちょうどそのとき、合法的なビデオコンテンツがインターネットに届きました。 ビデオコンテンツ（映画、テレビ番組、クリップ、テレビ番組）の所有者は、広告をぎっしり詰め込んで表示できるサイトの検索を開始し、そのディスプレイからの収益をサイトと共有しました。 大規模なビデオホスティングは、このコンテンツを表示するのに非常に便利な場所であり、同時に、ビデオホスティングのウィンドウを埋める問題、高品質で最も重要なライセンスのコンテンツを表示することが望ましい場所を解決しました。 当時のメインページVideo Mail.Ruは、最後の再設計から2年以上が経過しており、メインページに配置するコンテンツが非常に不足していたため、処理が緊急に必要でした。写真ホスティングに適したコンテストは人気がありませんでしたが、 UGCから優れたトップを構築することはまだ成功していません。



法的なプロフェッショナルビデオコンテンツはここで非常に有用であることが判明しましたが、メインのコンテンツ、トップ、カタログを収集するには、このコンテンツをカタログに配置して再生する方法を学ぶ必要がありました。 コンテンツプロバイダーは、サイトで再生可能なすべての動画のインデックスを提示しました。インデックスには、プロバイダーのプラットフォームがこの動画とカテゴリの見出しをプレーヤーに読み込むためのメタデータとキーを含む動画のリストが含まれていました（シーズンカテゴリのジャンルタイプ）。 このインデックスは定期的に自身にポンプで送られ、以前の状態に関連する変更を取得するためにサーバーに保存されたスナップショットと比較する必要がありました：新しいビデオが表示されたり古いビデオが消えた場合、これらのビデオを削除するかインデックスに追加する必要がありました。



最初は、いくつかのプロバイダーのサポート戦略が選択されました。つまり、特定のアフィリエイトカテゴリに結び付けることは不可能でした。 したがって、独自のルブリケーターと、ルブリックとパートナーのルブリック間のリンクのテーブルが作成されました。 その後、プレーヤーとの多くの作業が必要になり、パートナーから提供されたビデオストリームと広告を使用するように指導する必要がありました。 パートナーには単一の標準がなかったため、パートナーごとに、その形式をサポートするために個別の作業が必要でした。 また、プレーヤーレベルでは、フローリターンプロセスの監視が実装されたため、パートナー側でフローリターンの問題が発生したことがすぐにわかります。 コンテンツへのアクセスに関する地域の制限にも問題がありました：すべてのパートナーはロシアとCISでのみビデオを表示する権利を持っていることが判明したため、1つのクリップを見ることができない海外でショーケースを表示しないように、私はそれを外国のユーザーに残さなければなりませんでした古いショーケース。 Mail.Ru Searchと提携して合法的なビデオコンテンツをより適切に宣伝するために、合法的なコンテンツと別の検索結果用に個別の検索インデックスを作成し、UGCコンテンツの検索結果から分離しました。 また、ユーザーアカウントにクリップを追加できるようになりました。 したがって、私たちは法的コンテンツの表示でお金を稼ぎ始め、Video.Ru Videoサイトのウィンドウの問題を解決しました。

8.ママ、クラスメートと一緒に暮らすことはできますか？

2011年、社内再編成の後、My Worldソーシャルネットワークの開発およびサポートチーム（Photo Hosting Photo Mail.RuとVideo hosting Video Mail.Ruの両方を吸収）は、Odnoklassnikiソーシャルネットワークと共に1つのユニットになりました。 当時、Odnoklassnikiは既に独自のビデオサービスを提供していましたが、アカウントへのカスタムビデオのダウンロードはサポートしていませんでした。 私たちのチームは、第1段階でOdnoklassnikiソーシャルネットワークへのカスタムビデオのアップロードをサポートし、第2段階で両方のソーシャルネットワーク用の大規模な統合ビデオセクションを作成することを任されました。 これらの計画を実現するためには、まず、自分自身をホストするビデオ（つまり、ビデオコンテンツの保存と再生システム）をMy Worldソーシャルネットワークの機能から分離する必要がありました。 ビデオホスティングが両方のソーシャルネットワークから等距離にあり、APIを介してソーシャルネットワークとやり取りできるようにシステムを構築したかったのです。 したがって、トランスコーディングのロジックを変更して、My Worldソーシャルネットワークのエンティティ（ユーザーとその関係、ビデオアルバムなど）に依存しないようにしました。



トランスコーディングクラスタの負荷をより柔軟に管理できるように、新しいトランスコーダを古いトランスコーダの隣に配置することが決定されました。 また、既存のリポジトリはMy Worldのユーザーに関連付けられていたため、ビデオインスタンスのメタデータには新しいリポジトリが必要でした。 Tartantool NoSQLデータベースをリポジトリとして使用することが決定されましたが、その時点ですでに十分に証明されており、My Worldで集中的に使用されていたため、メタデータストレージシステムのアーキテクチャを簡素化することができました。これは、データキャッシュを使用して迅速な読み取りアクセスを提供する必要がないためです（VCached Vfoma）。 また、ブートローダーのアルゴリズムを変更する必要がありました：My Worldのローダーは、Mail.Ruユーザーの認証Cookieで署名された要求で動作しました。ユニバーサルaploaderの場合、このCookieは削除する必要がありました。 さらに、このロジックにより、ロードの開始時に発行されたCookieがロードの終了時に有効でなくなる場合がありました（たとえば、セキュリティ強化モードが有効になっている場合の並列セッションのため）。 この場合、ユーザーはビデオを再度ダウンロードする必要がありました。



したがって、認証の検証は、ビデオの署名の検証に置き換えられました。 キューキューサーバーに基づいて編成された既存のチャンネルを使用して、ビデオの準備状況とトランスコードエラーに関するメッセージを送信しました。ビデオサービスはメッセージをキューに入れるだけで、他はすべて実装済みです。 ビデオストリームを返すために、OdnoklassnikiビデオIDで動作できるサーバーが作成されました。 クリップのデモンストレーションはサービス内でのみ計画されていたため（つまり、ソーシャルネットワークのページから要求されていないクリップはなかった）、すべてのクリップをプライベートと見なし、ビデオストリームを要求するには、クリップでページを表示するときにOdnoklassnikiサーバーによって生成された署名が必要でした。 このようにして、制限されたアクセスでコンテンツを表示するという問題は解決されました。その再生については、Idクリップのみの十分な知識がありませんでした。 My Worldビデオホスティングのインフラストラクチャ全体を変更せずに残しました。 つまり、互いに異なるビデオストリームをロードおよび再生する2つのシステムが、単一のストレージで機能することが判明しました。 このような回路図のように見えましたが、2012年4月4日にOdnoklassniki向けにシステムが開始されました。

9.そして、あなたたちはとても似ています

当時、チームの一部はOdnoklassnikiとの統合に従事していましたが、チームの別の部分は、低血度のMy Worldビデオのインプレッション数を増やすという問題を解決していました。 まず、どのパラメーターを増やすかを決定する必要がありました：カバレッジの幅またはビューの深さ。 状況をすばやく分析した結果、ユーザーあたりのビュー数を増やすためのリソースが十分に活用されておらず、実験のためのフィールドがあることが明らかになりました。 クリップ付きのページをグローバルに再設計することでビューの数を増やすことができます（クリップ間の遷移を簡素化し、プレーヤーとのブロックを損なうことなく他のクリップとブロックの魅力とアクセシビリティを高めます）が、新しいビデオサービスのチームと開発プラットフォームのため、この方法のリソースはありませんでしたMy Worldのインフラストラクチャとの統合が不十分であり、最も簡単な方法は、外部APIを介してMy Worldに接続された別のサービスを開発することでした。 したがって、「類似の動画」ブロックを処理することが決定されました。 当時、類似のビデオの選択は、ビデオの名前によるMail.Ru Searchの検索結果に基づいていました。 この問題の品質はそれほど高くありませんでした。つまり、これらのビデオのクリック数はいくつかの問題のために少なかったことを意味します。多くの場合、名前による検索は同じではなく類似のビデオを返しました。これは検索では正常ですが、ビデオサービスでは非常に悪いです。ユーザーはこれらのビデオを既に見ており、クリックしていません。



この問題を解決するために、最初にすべてのビデオとこれらのビデオに正確に表示されるものに関する情報（クリップ、映画、猫とのジョーク、または子供のパーティーなど）を含むデータベースを作成し、このビデオを他の同様のビデオと関連付けて、アルゴリズムのこのタイプのコンテンツ（つまり、新しいジョークを出す予定のジョーク、クリップ、このアーティストの他の人気のあるクリップなど）。 このリンク方法は非常に有望に見えましたが、実装するのに非常に時間がかかりました：数か月で、ミュージックビデオのみのサンプルを作成することができました。これは、コンテンツベース全体のわずか10％に過ぎませんでした。 計画されたすべてを実装するのに十分なリソースがないことが明らかになりました。さらに、識別できないビデオや類似のものと一致しないビデオをどう処理するかが明確ではありませんでした。 その結果、私はこの考えを捨て、他の何かを考え出さなければなりませんでした。



すぐに、ユーザーセッションに基づいて推奨事項を作成できるという仮説が立てられました。つまり、「類似のビデオ」に、このビデオで他のユーザーが見たものをブロックすることを示します。 ユーザーセッションに関する統計情報は既にあるため、このスキームを非常に迅速に実装することができました。 結果は素晴らしいものでした。クリック数が大幅に増加し、ユーザーが好きな「類似の」動画をクリックすると、最も関連性の高い動画が選択され、新しいより良いセッションが構築されるため、システムは自己調整式であることが判明しました。 問題が1つしかありませんでした。新しくてめったに視聴されないビデオの場合、このアルゴリズムを使用して同様のビデオを選択することはできませんでした。 また、この問題の解決策は、メインアルゴリズムを使用してサンプルを作成する可能性がない場合に、クリップの名前で検索結果を返すことで見つかりました。 このようなスキームにより、利用可能なほぼすべてのコンテンツの「類似したビデオ」のリストを作成することができ、良好なフィードバックが得られました。互いにうまく結合されたビデオは、より頻繁に連続して表示され始め、セッションスキームに分類されました。

10.動員

同様の動画、検索、デザイン、UIの配信品質を改善するためのさらなる研究が目に見える増加をもたらさないことを認識し、サービスの視聴者を拡大することを試みました。 オーディエンスの分析により、モバイルデバイスからリソースにアクセスするオーディエンスの大幅な増加が明らかになりました。 当時（2013年）、視聴者のほぼ6％がiOSおよびAndroidを実行しているデバイスのリソースにアクセスし、このシェアは着実に増加していました。 つまり、リソースを訪れた20人ごとにビデオを見ることができなかったことがわかりました。 それについて何かをする必要がありました。



最もシンプルなものから始めました。 , flash, ( ipad, ) html5- «video» . , . . flash-, , . «iframe», . «iframe» , «video» . , , .



(iOS Android), « ». , : flv-, ( , ). MP4. 30 , , . , , . API- , .



, , . . . html5-. , flash-, , . html5- «flash- , , HTML5-». HTML-5 . «HTML5- , , FLASH-». , , html5- , Flash- , .

11.

2013 . : , . , , . , , . : , , ( ), . :







, , , bdb- ( , ). , ( bdb), ( : ) . , () . , — ( ), ( , ).



«» — . , - , , .



. — , . , . , ( , ), . , , . , , ( ). , « », « », . — bdb-, .



, , .



, : 2 Flash- MySQL queued, . , ( , , ).



, , . : « » « » ( , -, ). ( ), . :







今残されているのは小さいことです。計画を完全に実現し、さらに先へ進むべきかを考えるために、まだ多くの開発計画があり、さらに、人生は常に驚きをもたらします。