面接実践編 | AliExpress の両面、質問は私にとって非常に食欲をそそります (Redis、MySQL、HashMap)

今号は「こんにちは、インタビュアー」シリーズ記事の第 20回目であり、継続的に更新されています。

公式アカウントは「面接ノート」に返信してシャオロンの秋採用ノートを入手し、N 学生が大手工場からの内定を勝ち取るのに役立ちました。

「ハロー、インタビュアー」シリーズはすでに20回連載しており、このシリーズを読んだ友人たちは皆大昌さんからオファーをもらっているそうですよ～

小龍が言いたいことがある

今回は、大規模工場での実際の面接シミュレーションを行います。

ナレッジポイント、Redis、MySQL インデックス、HashMap、左端の一致などを含みます。

本期题改编自 ——2023届春招阿里速卖通二面

インタビューサイト

ディンディンディン…

面接官：「こんにちは、面接官のXXです。こちらは小龍さんですか？」

シャオロン：「こんにちは、面接官、私はシャオロンです」

面接官：「はい、空いていますか？面接を始めましょう。」

シャオロン「はい、準備完了です」

…

その他の質問

…

インタビュアー: 「それでは、早速行きましょう。近くの 50 ワットの加盟店の中から、自分に最も近い 20 軒のレストランをすばやく見つけて表示するように求められたら、どのようにデザインしますか?」

Xiaolong : 「以前のプロジェクトでも同様の機能を実行しました。最も効率的かつ迅速な方法は、Redis を使用することです。Redis はバージョン 3.2 で GEO のサポートを追加し、地理座標情報の保存を可能にし、緯度に基づいて情報を取得できるようにしました。と経度のデータ。」

インタビュアー：「どうやってやるの？」

XiaolongGEOADD : 「基本的なコマンドラインを使用する場合、まず販売者の地理的な緯度と経度の座標をインポートする必要があります。大きさが大きすぎる場合は、スクリプトを使用できます。その後、GEOSEARCH コマンドを使用できますが、これは GEOSEARCH コマンドでのみ使用できます。バージョン 6.2 では、指定された範囲内にある可能性があります。検索を実行し、指定された点からの距離でソートして返します。

インタビュアー: 「あなたのデザインに何か問題はありますか? 第一に、表示する各販売者の特定の情報を取得する方法を説明していません。第二に、クエリはすべての座標データベースから直接フィルタリングされます。最も近いもののいくつかは、でもレストランの方にお願いがあります。」

インタビュアー: 「つまり、あなたが最近審査したのがレストランであること、あるいはあなたのビジネスには 1 種類の業態しかないことはどのようにしてわかりますか?」

モノローグ：「まずはスゴいと思わせるための基本計画を立てて、それから次のことを最適化してスゴイと思ってもらう～【手動犬頭】」

小龍「そうですね、これはシーンに合わせて柔軟に設計できますね。キー値の設計に大騒ぎしたり、加盟店の具体的な情報を問い合わせたいということもできます。ただ、Redis がメモリレベルのデータベースであることを考えると、どちらかというと多数の加盟店の基本情報が保管されているのは、間違いなく大きな損失であり、無駄です。」

Xiaolong : 「同時に、さまざまなタイプのスクリーニングを満たすために、キーとして shop:xx:type を使用し、値として販売者 ID を使用できます。このようにして、渡されたタイプに応じてさまざまなタイプをフィルタリングできます。経度と緯度に従ってクエリを実行します。販売者 ID をソートして距離を取得し、ID に従って販売者の特定の情報をクエリします。」

インタビュアー: 「わかりました、悪くありません。」

インタビュアー: 「についてはよくご存じだと思いますがMySQL、普段どのようにインデックスを設計しているか教えていただけますか?」

Xiaolong : 「インデックスを設計するとき、通常、クエリの速度を向上させるために、できるだけ小さいスペースを使用するように努めます。複雑さを簡素化し、過剰な設計を避けます。ほとんどの場合、主キー ID を使用すると、多くのシナリオに対応できます。さらにニーズがある場合は、 , そうして初めて、インデックスの設計と最適化の方法を検討することになります。」

Xiaolong : 「インデックスは通常、where 条件に基づいて構築されており、一致度は高くなければなりません。ベースはできるだけ大きく、識別度はできるだけ高くなければなりません。そうでない場合は、どちらを使用しても違いはほとんどありません。」同時に、前に述べたように、インデックスにもスペースが必要となるため、スペースはできるだけ小さくする必要があります。短いインデックスを使用するようにし、大きすぎるインデックスは使用しないでください。拡張するには、共同インデックスを使用し、頻繁な更新を避けてください。」

インタビュアー: 「結合インデックスについての話を聞いてください。左端の一致原則をご存知ですか? なぜ右端ではなく左端なのでしょうか?」

Xiaolong : 「とても簡単です。結合インデックス (a、b、c) を構築すると、MySQL Innodb エンジンの最下層は B+ ツリーをインデックスとして使用するため、実際には最初の a に従ってソートされます。 a が同じ、b は順番、a は順番が違う、などです。したがって、マッチングする場合は、左からマッチングすることも効果的です。

インタビュアー: 「わかりました。概念については話してほしくありません。ここで原則が守られるかどうかを分析していただけます。」

インタビュアー: 「今度は結合インデックス (a、b、c) を作成します。」

インタビュアー: 「select * from table_xl where c = '1'、b = '2'、a = '3' はインデックスに移動しますか?」

Xiaolong : 「もちろん、これは完全値一致クエリです。クエリオプティマイザがクエリの順序を自動的に最適化します。」

インタビュアー: 「select * from table_xl ここで、a = 1 および b > 3 はインデックスに移動しますか?」

Xiaolong : 「a が同じ場合、b が順序付けされ、範囲検索ではジョイントインデックスが使用され、ab インデックスが使用されます。」

インタビュアー: 「わかりました、HashMap について理解していますか? HashMap がいつ拡張されたか教えていただけますか?」

Xiaolong : 「わかりました。まず、いつ拡張がトリガーされるかを知る必要があります。最初の拡張はよく知られています。拡張のしきい値に達するとトリガーされます。このしきい値は中間の属性でもあります。使用容量 (表)容量HashMap) threshold*loadFactor (負荷率) が計算されます。」

Xiaolong : 「見落とされがちな 2 番目の点は、HashMap が遅延読み込みを使用していることです。これは、テーブルがHashMap最初に初期化されないことを意味しますが、要素が初めて配置されたとき、つまり呼び出し時にテーブルが初期化されることを意味します。展開メソッドが初期化されています。」

インタビュアー: 「それでは、その全体的な拡大プロセスについて、あなた自身の言葉で簡単に話していただけますか?」

Xiaolong : 「言うのは簡単ですが、実際、容量が拡張されると、2 倍のサイズの新しい配列が作成され、アドレス指定する新しい配列の長さに応じてその値が再ハッシュされます。具体的には、元の配列のリンクリストは上位リンクリストと下位リンクリストに分割され、下位リンクリストは拡張後に格納されます。配列添字が変更されていないノードについては、上位リンクリストに変更されたものを格納し、その後、上位および下位のリンクされたリストを新しい配列に追加します。」

インタビュアー: 「貴社のコンピュータ基盤はかなり充実しているようですね。それでお聞きします。A と B は TCP 通信を行っています。B のネットワークケーブルが抜かれたら、A はどうしますか?」

シャオロン：「この質問はコメント欄に残してください。どう思いますか？」

知識のまとめ

今回は、面接シミュレーションを通して、に関する関連知識を簡単に紹介しReidsましGEOた。フォローアップを続けるには購読+スターを付けてくださいMySQL索引相关HashMap相关

典型的な面接の質問がある場合は、プライベートメッセージで送信できます~