_{画像ソース： www.nikonsmallworld.com}

盗作防止は専門の検索エンジンで、すでに以前に書かれています。 また、どの検索エンジンでも、どのように回転させても迅速に動作するには、検索領域のすべての機能を考慮した独自のインデックスが必要です。 Habréに関する最初の記事では、検索インデックスの現在の実装、その開発の歴史、および1つまたは別のソリューションを選択する理由について説明します。 効果的な.NETアルゴリズムは神話ではなく、困難で生産的な現実です。 ハッシュ、ビット単位の圧縮、マルチレベルの優先度キャッシュの世界に突入します。 O（1）よりも高速な検索が必要な場合はどうなりますか？

他の誰かがこの写真の帯状疱疹の位置を知らない場合、ようこそ...

帯状疱疹、インデックスおよびそれらを探す理由

シングルは、サイズが数ワードのテキストです。 帯状疱疹は互いに重なり合っているため、名前（英語、帯状疱疹-鱗、タイル）。 それらの特定のサイズは公開秘密です-4ワード。 それとも5？ まあ、それは依存します。 ただし、この値でもほとんど意味がなく、ストップワードの構成、ワードを正規化するアルゴリズム、およびこの記事のフレームワークでは重要ではないその他の詳細に依存します。 最後に、このシングルに基づいて64ビットハッシュを計算します。これを将来シングルと呼びます。

ドキュメントのテキストによると、多くの帯状疱疹を作成できます。帯状疱疹の数は、ドキュメント内の単語の数に匹敵します。

テキスト：文字列→帯状疱疹：uint64 []

複数の帯状疱疹が一致する場合、2つのドキュメントはドキュメントが交差すると想定します。 一致する帯状疱疹の数が多いほど、このドキュメントペア内のテキストは同じになります。 インデックスは、チェック対象のドキュメントとの共通部分が最も多いドキュメントを検索します。

_{画像ソース： ウィキペディア}

帯状疱疹インデックスを使用すると、2つの主要な操作を実行できます。

1. ドキュメントの帯状疱疹に識別子を付けてインデックスを作成します。

   
   
   
   
   
   
   

   index.Add（docId、帯状疱疹）

   
   
   
   
   

2. 重複するドキュメントの識別子のランク付きリストを検索して表示します。

   
   
   
   
   
   
   

   index.Search（シングル）→（docId、スコア）[]

   
   
   
   
   

ランキングアルゴリズムは、一般に別の記事として価値があると思うので、ここでは説明しません。

帯状疱疹のインデックスは、Sphinx、Elastic、またはそれ以上のGoogle、Yandexなどのよく知られているフルテキストのインデックスとは大きく異なります。 すべてのテキスト処理が取り除かれ、プロセス、およびテキスト内の帯状疱疹のシーケンスには影響しません。 一方、検索クエリは、単語または複数の単語のフレーズではなく、最大数十万個のハッシュであり、すべてが個別にではなく、全体として重要です。

仮説的には、帯状疱疹インデックスの代わりにフルテキストインデックスを使用できますが、違いは大きすぎます。 いくつかのよく知られているキー値ストレージを使用する最も簡単な方法は、以下で説明します。 私たちは、ShingleIndexと呼ばれる自転車の実装を見ています。

なぜそうするのですか？ しかし、なぜ。

• ボリューム ：
  
  
  1. たくさんのドキュメントがあります。 現在、約6億5,000万台がありますが、今年は明らかにそれよりも多くなります。
  2. ユニークな帯状疱疹の数は飛躍的に増加しており、すでに数千億に達しています。 私たちは1兆を待っています。
• スピード
  
  
  1. 日中、夏のセッション中に、30万件以上の文書が反パラギアリズムシステムを通じてチェックされます。 これは人気のある検索エンジンの標準では少しですが、調子は変わりません。
  2. ドキュメントの一意性の検証を成功させるには、インデックス付きドキュメントの数をチェック対象のドキュメントの数よりも大きくする必要があります。 インデックスの現在のバージョンは、平均して1秒あたり4000を超える中程度のドキュメントの速度でいっぱいになります。

そして、それはすべて1台のマシン上にあります！ はい、 複製できます。クラスターの動的シャーディングに徐々に近づいていますが、2005年から今日まで、1台のマシンのインデックスは慎重に注意して上記のすべての問題に対処できました。

奇妙な経験

しかし、私たちは今とても経験を積んでいます。 好むと好まざるとにかかわらず、私たちも成長し、成長の過程でさまざまなことを試してきました。

_{画像ソース： ウィキペディア}

まず第一に、経験の浅い読者はSQLデータベースを使用したいと思うでしょう。 そう考えるのはあなただけではありません。SQLの実装は、数年にわたって非常に小さなコレクションを実装するのに役立ってきました。 それにもかかわらず、すぐに何百万ものドキュメントに焦点が当てられたので、さらに先へ進む必要がありました。

ご存知のように、誰も自転車を愛しておらず、LevelDBはまだ公開されていないため、2010年にBerkeleyDBに注目しました。 すべてがクールです-適切なbtreeおよびハッシュアクセスメソッドと長い履歴を持つ永続的な組み込みキー値ベース。 彼女とのすべては素晴らしいものでしたが、

• ハッシュ実装の場合、2GBのボリュームに達すると、単純に減少しました。 はい、まだ32ビットモードで作業していました。
• B +ツリーの実装は安定して機能しましたが、数ギガバイトを超えるボリュームでは、検索速度が大幅に低下し始めました。

タスクに合わせて調整する方法を見つけられなかったことを認めなければなりません。 たぶん問題は.net-bindingsにあり、それはまだ終わらなければなりませんでした。 最終的に、BDB実装は、メインインデックスを埋める前に、中間インデックスとしてSQLの代わりとして使用されました。

時間が経ちました。 2014年、彼らはLMDBとLevelDBを試しましたが、それを実装しませんでした。 私たちの反平和主義研究部門のメンバーは、RocksDBをインデックスとして使用しました。 一見、発見でした。 しかし、少量の補充であっても遅い補充と平凡な検索速度は、すべてを無に帰しました。

独自のカスタムインデックスを開発しながら、上記のすべてを行いました。 その結果、彼は問題の解決に非常に優れたものになったため、以前の「プラグ」を放棄し、それを改善することに集中しました。

インデックスレイヤー

最後に、私たちは今何を持っていますか？ 実際、帯状疱疹のインデックスは、一定の長さ（0〜128ビット）の要素を持つ複数の層（配列）で構成されます。これは、層だけでなく、必ずしも8の倍数ではありません。

各レイヤーが役割を果たします。 検索を高速化するもの、スペースを節約するもの、使用されないが本当に必要なものがあります。 検索での全体的な効果を高めるために、それらを説明しようとします。

_{画像ソース： ウィキペディア}

1.インデックス配列

一般性を失うことなく、単一のシングルがドキュメントに割り当てられていると考えます。

（docId→シングル）

ペアの要素を場所ごとに入れ替えます（インデックスは実際には「反転」しているため、反転します）。

（シングル→docId）

帯状疱疹の値でソートし、レイヤーを形成します。 なぜなら シングルとドキュメント識別子のサイズは一定であるため、 バイナリ検索を理解している人は誰でもファイルのO（logn）読み取り値のペアを見つけることができます。 本当にたくさん しかし、これはO（n）よりも優れています。

ドキュメントに複数の帯状疱疹がある場合、ドキュメントからそのようなペアがいくつかあります。 同じ鉄片を持つ複数のドキュメントがある場合、これもあまり変化しません。同じ鉄片を持つ複数のペアが連続して存在します。 どちらの場合も、検索は同等の時間で行われます。

2.グループの配列

前のステップのインデックスの要素を、便利な方法で慎重にグループに分けます。 たとえば、クラスターセクターに収まるように、ビット数やその他のトリックを考慮したアロケーションユニットブロック （読み取り、4096バイト）が効果的な辞書を形成します。 このようなグループの位置の単純な配列を取得します。

group_map（ハッシュ（シングル））-> group_position。

シングルを検索する場合、最初にこの辞書でグループの位置を検索し、次にグループをアンロードしてメモリで直接検索します。 操作全体には2回の読み取りが必要です。

グループ位置のディクショナリは、インデックス自体よりも数桁少ないスペースしか必要としません。多くの場合、単純にメモリにアンロードできます。 したがって、読み取り値は2つではなく、1つになります。 合計、 O（1） 。

3.ブルームフィルター

面接では、候補者はO（n ^ 2）またはO（2 ^ n）で一意のソリューションを発行することで問題を解決することがよくあります。 しかし、私たちは愚かなことをしません。 世界にO（0）がありますか？それは質問ですか？ 結果を期待せずに試してみましょう...

主題領域に目を向けます。 生徒がよくやったので自分で作品を書いた場合、または単にテキストではなくゴミがあった場合、帯状疱疹の重要な部分は一意であり、索引には見つかりません。 ブルームフィルターなどのデータ構造は、世界的によく知られています。 検索する前に、屋根板を確認してください。 インデックスに鉄片がない場合は、さらに調べることはできません。

ブルームフィルター自体は非常に単純ですが、ボリュームでハッシュ関数のベクトルを使用することは意味がありません。 ブルームフィルターからの読み取り値を+1するだけで十分です。 これは、シングルが一意であり、フィルターに誤検出がなかった場合に、後続のステージから-1または-2の読み取り値を提供します。 手を見てください！

ブルームフィルターエラーの確率は構築中に設定され、未知の鉄片の確率は生徒の誠実さによって決まります。 単純な計算は、次の依存関係になります。

• 人の誠実さを信じる（つまり、実際にドキュメントがオリジナルである）場合、検索速度は低下します。
• ドキュメントが明確につながれている場合、検索速度は向上しますが、多くのメモリが必要です。

学生を信頼することで、「信頼するが検証する」という原則があり、実践はブルームフィルターからの利益があることを示しています。

このデータ構造はインデックス自体よりも小さく、キャッシュできるので、最良の場合、ディスクにアクセスせずにシングルを削除できます。

4.重い尾

ほとんどどこにでも見られる帯状疱疹があります。 総数に占める割合はわずかですが、最初のステップでインデックスを作成するとき、2番目のステップでは、数十および数百MBのサイズのグループを取得できます。 それらを個別に記憶し、検索クエリからすぐに破棄します。

この些細な手順が2011年に初めて使用されたとき、インデックスのサイズは半分になり、検索自体が加速されました。

5.その他の尾

それでも、シングルには多くのドキュメントを含めることができます。 これは正常です。 数十、数百、数千...それらをメインインデックス内に保持することは採算が取れなくなり、グループにも収まらず、そこからグループ位置の辞書のボリュームが膨らみます。 より効率的なストレージを備えた別のシーケンスに配置します。 統計によると、そのような決定は正当化される以上のものです。 さらに、さまざまなビット単位のパッケージにより、ディスクアクセスの回数を減らし、インデックスサイズを減らすことができます。

その結果、メンテナンスを容易にするために、これらすべてのレイヤーを1つの大きなファイル（チャンク）に印刷します。 そのような層が10個あります。 ただし、一部は検索で使用されず、一部は非常に小さく、常にメモリに格納されます。一部は必要に応じて/可能な限りアクティブにキャッシュされます。

戦闘では、ほとんどの場合、シングルの検索はファイルの1つまたは2つのランダムな読み取りになります。 最悪の場合、3つを実行する必要があります。 すべてのレイヤーは、効果的に（場合によってはビット単位で）固定長の要素のパックされた配列です。 これが正規化です。 解凍中の時間は、保管中の合計ボリュームの価格と比較して重要ではなく、キャッシュ機能が向上します。

構築時には、レイヤーのサイズは主に事前に計算され、順番に書き込まれるため、この手順は非常に高速です。

どのようにしてそこにたどり着いたのか

2010 , . , . , .

_{画像ソース： ウィキペディア}

当初、インデックスは2つの部分で構成されていました。上記の定数と、SQL、BDB、または独自の更新ログの役割を持つ一時的な部分です。 たとえば、月に1回（場合によっては1年に1回）、一時的なものがソートされ、フィルタリングされて、メインのものとマージされることがあります。 結果は統一されたものであり、2つの古いものは削除されました。 一時的なものがRAMに収まらない場合、手順は外部ソートを通過しました。

この手順はかなり面倒で、セミマニュアルモードで開始され、インデックスファイル全体を最初から書き直す必要がありました。 数百万のドキュメントのために数百ギガバイトの書き換え-まあ、まあまあの喜び、私はあなたに言います...

SSDが緊張しすぎず、インデックスがより頻繁に更新されるように、2012年に次のスキームに従ってチャンクのいくつかのピースのチェーンが関与しました。

ここでは、インデックスは、最初のものを除き、同じタイプのチャンクのチェーンで構成されています。 最初のアドオンは、RAMにインデックスがある追加専用ログでした。 後続のチャンクは、最後（ゼロ、メイン、ルートなど）までサイズ（および経過時間）が増加しました。

ドキュメントを追加するとき、最初にアドオンに折り畳まれました。 オーバーフローまたは他の基準により、永続的なチャンクが構築されました。 必要に応じて、隣接するいくつかのチャンクは新しいものにマージされ、元のチャンクは削除されました。 ドキュメントの更新または削除も同じように機能しました。

マージ基準、チェーンの長さ、バイパスアルゴリズム、削除されたアイテムと更新のアカウンティング、その他のパラメーターが調整されました。 アプローチ自体は、いくつかの同様のタスクに関与しており、クリーンな.net上の別個の内部LSMフレームワークとして形になりました。 同じ頃、LevelDBが人気を博しました。

この場合のLSMアルゴリズムには、非常に適した機能があります。

1. インスタント挿入/削除/更新、
2. 更新中のSSDの負荷の軽減、
3. 簡略化されたチャンク形式、
4. 古い/新しいチャンクのみの選択的検索、
5. 些細なバックアップ
6. 魂は他に何を望んでいますか。
7. ...

一般的に、自己開発のために自転車を発明することは時々有用です。

マクロ、マイクロ、ナノの最適化

そして最後に、 対盗作の私たちが.Netで（そしてそれだけでなく）そのようなことを行う方法に関する技術的なヒントを共有します。

多くの場合、すべてが特定のハードウェア、データ、または使用モードに大きく依存することに事前に注意してください。 ある場所でねじれた後、CPUキャッシュから飛び出し、別の場所で-SATAインターフェースの帯域幅にぶつかって、3番目に-GCでハングし始めます。 そして、特定のシステムコールの実装の非効率性のどこかに。

_{画像ソース： ウィキペディア}

ファイルを操作する

ファイルへのアクセスの問題は、私たちだけではありません。 テラバイトエクサバイトの大きなファイルがあり、その容量はRAMの量の何倍にもなります。 タスクは、周囲に散らばっている数百万個の小さなランダム値を読み取ることです。 そして、それを迅速、効率的かつ安価に行うために。 絞り込み、ベンチマークし、よく考えなければなりません。

簡単なものから始めましょう。 大切なバイトを読むには、次のものが必要です。

1. ファイルを開く（新しいFileStream）;
2. 目的の位置に移動します（位置またはシーク、差なし）。
3. 目的のバイト配列を読み取ります（読み取り）。
4. ファイルを閉じます（破棄）。

そして、これは長くて退屈だからです。 試行錯誤し、レーキを繰り返し踏むことで、次のアクションアルゴリズムを特定しました。

• シングルオープン、マルチリード

  
  
  
  
  
  
  

  このシーケンスを額で行うと、ディスクへのすべての要求に対して、すぐに曲がります。 これらの各項目は、OSカーネルへの要求になりますが、これは高価です。

  
  
  
  
  
  
  

  明らかに、ファイルを一度開き、そこから何百万ものすべての値を順番に読み取る必要があります。

  
  
  
  
  

• 余分なものはありません

  
  
  
  
  
  
  

  ファイルサイズ、その中の現在の位置を取得することも非常に難しい操作です。 ファイルが変更されなかった場合でも。

  
  
  
  
  
  
  

  ファイルサイズや現在の位置を取得するなどのクエリは避けてください。

  
  
  
  
  

• Filestreampool

  
  
  
  
  
  
  

  次。 残念ながら、FileStreamは基本的にシングルスレッドです。 ファイルを並行して読み取りたい場合は、新しいファイルストリームを作成/閉じる必要があります。

  
  
  
  
  
  
  

  aiosyncのようなものを作成するまで、独自の自転車を発明する必要があります。

  
  
  
  
  
  
  

  私のアドバイスは、ファイルごとにファイルストリームのプールを作成することです。 これにより、ファイルを開いたり閉じたりする時間を無駄にすることがなくなります。 そして、それをThreadPoolと組み合わせて、SSDが強力なマルチスレッドでmegaIOPSを発行することを考慮に入れると...そうですね、私を理解しています。

  
  
  
  
  

• 配分単位

  
  
  
  
  
  
  

  次。 ストレージデバイス（HDD、SSD、Optane）およびファイルシステムは、ブロックレベル（クラスター、セクター、割り当て単位）のファイルで動作します。 一致しない場合もありますが、現在ではほとんどの場合4096バイトです。 SSD内のこのような2つのブロックの境界で1または2バイトを読み取ることは、ブロック自体の内部よりも約1.5倍遅くなります。

  
  
  
  
  
  
  

  減算した要素がクラスターセクターブロックの境界内に収まるように、データを整理する必要があります。

  
  
  
  
  

• バッファなし。

  
  
  
  
  
  
  

  次。 FileStreamはデフォルトで4096バイトのバッファーを使用します。 そして悪いニュースは、それをオフにできないことです。 ただし、バッファのサイズよりも多くのデータを読み込んでいる場合、後者は無視されます。

  
  
  
  
  
  
  

  ランダム読み取りの場合は、バッファーを1バイトに設定し（これより少ない場合は機能しません）、使用しないと想定します。

  
  
  
  
  

• バッファを使用します。

  
  
  
  
  
  
  

  ランダムな読み取りに加えて、順次読み取りもあります。 ここで、一度にすべてを読みたくない場合は、バッファがすでに役立つかもしれません。 この記事から始めることをお勧めします。 設定するバッファサイズは、ファイルがHDDにあるかSSDにあるかによって異なります。 最初のケースでは1MBが最適で、2番目のケースでは標準の4kBで十分です。 読み取られるデータ領域のサイズがこれらの値に匹敵する場合は、ランダム読み取りの場合のように、バッファーをスキップして一度に減算することをお勧めします。 バッファが大きいと、速度は向上しませんが、GCにヒットし始めます。

  
  
  
  
  
  
  

  ファイルの大きな部分を連続して読み取るときは、バッファをHDD用に1MB、SSD用に4kBに設定する必要があります。 まあ、それは依存します。

  
  
  
  
  

MMF vs FileStream

このメカニズムは.Net Framework v4.0以降で実装されたため、2011年にMemoryMappedFileにヒントがありました。 最初に、彼らはブルームフィルターをキャッシュするときにそれを使用しました。これは、4GBの制限のために32ビットモードでは既に不便でした。 しかし、64ビットの世界に移行するとき、もっと欲しいと思いました。 最初のテストは印象的でした。 無料のキャッシュ、異常な速度、便利な構造読み取りインターフェイス。 しかし、問題がありました：

• まず、奇妙なことに、速度。 データがすでにキャッシュされている場合は、すべて問題ありません。 しかし、そうでない場合、ファイルから1バイトを読み取るには、通常の読み取りよりもはるかに多くのデータの「リフトアップ」が伴います。
• 第二に、奇妙なことに、メモリ。 加熱すると、共有メモリが増加し、workingset-いいえ、論理的です。 しかし、その後、隣接するプロセスはあまりうまく動作しなくなります。 彼らはスワップに入るか、OoMから誤って落ちる可能性があります。 悲しいかな、RAMのMMFが占めるボリュームは制御できません。 また、読み取りファイル自体がメモリよりも数桁大きい場合のキャッシュからの利益は無意味になります。

2番目の問題はまだ解決できません。 インデックスがdockerまたは専用の仮想マシンで機能する場合は表示されません。 しかし、速度の問題は致命的でした。

その結果、MMFは完全に放棄されました。 可能な場合は、指定された優先度と制限で最も頻繁に使用されるレイヤーをメモリに保持し、明示的な形式で反薬物主義のキャッシングが行われ始めました。

_{画像ソース： ウィキペディア}

ビット/バイト

世界は1バイトではありません。 時々、ビットレベルまで下げる必要があります。

たとえば、1兆個の部分的に順序付けられた番号があり、保存と頻繁な読み取りに熱心であるとします。 これらすべてをどのように使用しますか？

• シンプルなBinaryWriter.Write？ -速いが遅い。 サイズは重要です。 コールドリーディングは主にファイルサイズに依存します。
• VarIntの別のバリエーションは？ -速いが遅い。 一貫性が重要です。 ボリュームはデータに依存し始めるため、位置決めには追加のメモリが必要です。
• ビットパッキング？ -速いが遅い。 あなたはもっと注意深く手を制御しなければなりません。

理想的な解決策はありませんが、特定の場合、32ビットからテールを格納するのに必要な範囲までの単純な圧縮は、VarIntよりも12％（もちろん、隣接するものの違いのみを保存）節約し、それは数倍です基本オプション。

別の例。 ファイル内のいくつかの配列へのリンクがあります。 64ビットのリンク、テラバイトごとのファイル。 すべてが大丈夫のようです。 配列に多くの数字がある場合もあれば、少ない場合もあります。 しばしば少し。 非常に頻繁に。 その後、配列全体を取得してリンク自体に保存します。 利益 慎重に梱包しますが、忘れないでください。

構造、安全でない、バッチ処理、マイクロオプト

さて、他のマイクロ最適化。 ここでは、「ループの配列の長さを保存する価値がある」または「高速、forまたはforeach」という平凡については書きません。

2つの単純なルールがあり、それらを順守します：1.「すべてをベンチマークする」、2。「より多くのベンチマーク」。

• 構造体 。 どこでも使用されます。 GCを出荷しないでください。 また、今日流行しているため、独自の超高速ValueListもあります。

  
  
  
  
  

• 安全でない 。 使用時にバイトの配列へのmapit（およびunmap）構造を許可します。 したがって、シリアル化の個別の手段は必要ありません。 確かに、ヒープのピン留めとデフラグには疑問がありますが、これまでのところ示されていません。 まあ、それは依存します。

  
  
  
  
  

• バッチ処理 。 多くの要素を扱うには、パック/グループ/ブロックを使用する必要があります。 ファイルの読み取り/書き込み、機能間の転送。 別の問題は、これらのパックのサイズです。 通常、最適なサイズがあり、そのサイズは1kB〜8MB（CPUキャッシュサイズ、クラスターサイズ、ページサイズなど）の範囲にあることがよくあります。 IEnumerable <byte>またはIEnumerable <byte [1024]>関数を使用してみて、違いを感じてください。

  
  
  
  
  

• プーリング 。 「新規」と書くたびに、子猫はどこかで死にます。 一度新しいバイト[ 85000 ]-そしてトラクターはガチョウのトンに乗った。 stackallocを使用できない場合は、オブジェクトのプールを作成して再利用します。

  
  
  
  
  

• インライン化 。 1つではなく2つの関数を作成すると、すべてを10倍高速化できますか？ シンプル。 関数（メソッド）の本体のサイズが小さいほど、インラインになる可能性が高くなります。 残念ながら、ドットネットの世界では部分的なインライン化を行う方法がまだないため、最初の数行を処理した後に99％のケースで出てくるホット関数があり、残りの100行が残りの1％を処理してから、それを安全に分割します2（または3）、重い尾を別の機能に運びます。

  
  
  
  
  

他に何？

• スパン<T> 、 メモリ<T> -有望です。 コードはよりシンプルになり、少し速くなります。 .Net Core v3.0およびStd v2.1のリリースを待っています。 通常、スパンをサポートしない.Net Std v2.0のカーネル。

  
  
  
  
  

• 非同期/待機 -今のところ物議を醸す。 最も単純なランダム読み取りベンチマークは、CPU消費量が実際に低下していることを示しましたが、読み取り速度も低下しています。 見なければなりません。 インデックスはまだ使用していません。

  
  
  
  
  

おわりに

私の遠隔性が、いくつかの決定の美しさを理解する喜びをあなたに与えることを願っています。 インデックスが本当に気に入っています。 それは効率的で美しいコードであり、素晴らしい働きをします。 作業の重要な場所であるシステムのコアにおける高度に専門化されたソリューションは、一般的なソリューションよりも優れています。 バージョン管理システムは、C ++コードでのアセンブラの挿入を記憶しています。 現在、4つのプラスがあります-純粋なC＃のみ、.Netのみです。 その上に、私たちは最も複雑な検索アルゴリズムでさえも書き、まったく後悔しません。 Dockerへの移行である.Net Coreの出現により、DevOpsのより明るい未来への道がより簡単かつ明確になりました。 今後は、ソリューションの有効性と美しさを損なうことなく、動的なシャーディングとレプリケーションの問題を解決します。

最後まで読んでくれたみんなに感謝します。 すべての不一致およびその他の矛盾については、コメントを記入してください。 コメントでの合理的なアドバイスと反論を歓迎します。