Go のビットマップ インデックス: 高速検索

開会の挨拶

私はこのレポートをモスクワで開催された GopherCon Russia 2019 カンファレンスでは英語で、ニジニ ノヴゴロドでの交流会ではロシア語で発表しました。 ここではビットマップ インデックスについて説明します。B ツリーほど一般的ではありませんが、興味深いものではありません。 共有 記録 会議でのスピーチは英語で、テキストのトランスクリプトはロシア語で書かれています。

ビットマップ インデックスがどのように機能するか、他のインデックスよりも優れている場合と劣っている場合、そしてどのような場合に他のインデックスよりも大幅に高速であるかを見ていきます。 どの人気の DBMS がすでにビットマップ インデックスを備えているかを見てみましょう。 Go で独自のコードを書いてみましょう。 そして「デザートとして」、既製のライブラリを使用して、独自の超高速の特殊データベースを作成します。

私の作品が皆さんにとって有益で興味深いものであることを心から願っています。 行く！

導入

http://bit.ly/bitmapindexes
https://github.com/mkevac/gopherconrussia2019

こんにちは、みんな！ もう夕方XNUMX時ですが、私たちはみんなとても疲れています。 退屈なデータベース インデックス理論について話す絶好の機会ですよね? 心配しないでください。ところどころに数行のソース コードがあります。 🙂

冗談はさておき、このレポートには情報がぎっしり詰まっているので、あまり時間がありません。 それでは始めましょう。

今日は次のことについてお話します。

• インデックスとは何ですか。
• ビットマップインデックスとは何ですか。
• どこで使用され、どこで使用されないか、またその理由。
• Go での簡単な実装とコンパイラでの少しの苦労。
• 若干単純さは劣りますが、Go アセンブラーでの実装はより生産的です。
• ビットマップインデックスの「問題」。
• 既存の実装。

では、インデックスとは何でしょうか?

インデックスは、メイン データとは別に維持および更新される別のデータ構造です。 検索を高速化するために使用されます。 インデックスがなければ、検索にはデータを完全に調べる必要があり (フル スキャンと呼ばれるプロセス)、このプロセスには線形のアルゴリズムの複雑さが伴います。 しかし、データベースには通常、膨大な量のデータが含まれており、線形の複雑さでは遅すぎます。 理想的には、対数または定数を取得します。

これは非常に複雑なテーマであり、微妙な点やトレードオフがたくさんありますが、数十年にわたるデータベースの開発と研究を振り返ってみると、データベースのインデックスを作成するために広く使用されているアプローチはほんのわずかであると言えます。

最初のアプローチは、検索スペースをより小さな部分に分割して、検索スペースを階層的に削減することです。

私たちは通常、さまざまな種類の木を使用してこれを行います。 例としては、クローゼットの中に資料が入った大きな箱があり、その中にさまざまなトピックに分けられた資料が入った小さな箱が含まれているとします。 材料が必要な場合、「クッキー」と書かれた箱ではなく、「材料」と書かれた箱から探すでしょう?

XNUMX 番目の方法は、目的の要素または要素のグループをすぐに選択することです。 これはハッシュ マップまたは逆インデックスで行います。 ハッシュ マップの使用は前の例と非常に似ていますが、箱の代わりに、最終アイテムが入った小さな箱がクローゼットにたくさんあります。

XNUMX 番目のアプローチは、検索の必要性を排除することです。 これは、ブルーム フィルターまたはカッコー フィルターを使用して行います。 最初のものは即座に答えを提供し、検索の手間を省きます。

最後のアプローチは、最新のハードウェアが提供するすべての能力を最大限に活用することです。 これはまさにビットマップ インデックスで行うことです。 はい、それらを使用するときはインデックス全体を調べる必要がある場合がありますが、それを非常に効率的に実行します。

先ほども述べたように、データベース インデックスのテーマは広大であり、妥協点がたくさんあります。 これは、検索をさらに高速化する必要がある場合や、考えられるすべての検索タイプをカバーする必要がある場合など、複数のアプローチを同時に使用できることを意味します。

今日は、これらのアプローチのうち最も知られていない、ビットマップ インデックスについて説明します。

このテーマについて話す私は誰ですか?

私は Badoo でチーム リーダーとして働いています (おそらく、当社の別の製品である Bumble の方がよく知られているでしょう)。 すでに世界中で 400 億人を超えるユーザーがおり、ユーザーに最適なものを選択する多くの機能を備えています。 これは、ビットマップ インデックスなどのカスタム サービスを使用して行われます。

では、ビットマップインデックスとは何でしょうか?

ビットマップ インデックスは、その名前が示すように、ビットマップまたはビットセットを使用して検索インデックスを実装します。 鳥瞰図から見ると、このインデックスは、エンティティ (人など) とそのプロパティまたはパラメータ (年齢、目の色など) を表す XNUMX つまたは複数のビットマップ、およびビット演算 (AND、OR、NOT) を使用するアルゴリズムで構成されます。 ) 検索クエリに答えます。

ビットマップ インデックスは、多くのカーディナリティの低い列 (「市内中心部からの距離」などと比べて「目の色」や「婚姻状況」を考えてください) にわたるクエリを組み合わせた検索がある場合に最適で、非常にパフォーマンスが高いと言われています。 ただし、カーディナリティの高い列でも問題なく機能することを後で示します。

ビットマップ インデックスの最も単純な例を見てみましょう。

次のようなバイナリ プロパティを持つモスクワのレストランのリストがあると想像してください。

• 地下鉄の近く。
• 専用駐車場があります。
• ベランダあり（テラスあり）。
• テーブルを予約できます（予約を受け付けます）。
• ベジタリアンに適しています（ビーガンフレンドリー）。
• 高価（高価）。

各レストランに 0 から始まるシーケンス番号を与え、6 つのビットマップ (特性ごとに 4 つ) にメモリを割り当てましょう。 次に、レストランにこのプロパティがあるかどうかに応じて、これらのビットマップを設定します。 レストラン 4 にベランダがある場合、「ベランダあり」ビットマップのビット 1 が 0 に設定されます (ベランダがない場合は XNUMX)。

これで、可能な限り最も単純なビットマップ インデックスが完成し、それを使用して次のようなクエリに答えることができます。

• 「ベジタリアンフレンドリーなレストランを教えてください」;
• 「ベランダがあり、テーブルを予約できる安いレストランを教えてください。」

どうやって？ 見てみましょう。 最初のリクエストは非常に簡単です。 私たちがする必要があるのは、「ベジタリアン フレンドリー」ビットマップを取得し、それをビットが公開されているレストランのリストに変換することだけです。


XNUMX 番目のリクエストは少し複雑です。 「高価な」ビットマップの NOT ビットマップを使用して安価なレストランのリストを取得し、それから「テーブルを予約できますか」ビットマップと AND 演算し、その結果と「ベランダがあります」ビットマップと AND 演算する必要があります。 結果として得られるビットマップには、すべての基準を満たす施設のリストが含まれます。 この例では、これは Yunost レストランのみです。


多くの理論が関係していますが、心配しないでください。すぐにコードが表示されます。

ビットマップインデックスはどこで使用されますか?

Google でビットマップ インデックスを検索すると、回答の 90% が何らかの形で Oracle DB に関連するものになります。 しかし、他の DBMS もおそらくこのような優れた機能をサポートしているのではないでしょうか? あまり。

主な容疑者のリストを見てみましょう。

MySQL はまだビットマップ インデックスをサポートしていませんが、このオプションの追加を提案する提案があります (https://dev.mysql.com/worklog/task/?id=1524).

PostgreSQL はビットマップ インデックスをサポートしませんが、単純なビットマップとビット操作を使用して、他の複数のインデックスにわたる検索結果を結合します。

Tarantool にはビットセット インデックスがあり、それらに対する簡単な検索をサポートしています。

Redis には単純なビットフィールドがあります (https://redis.io/commands/bitfield）それらを検索する機能がありません。

MongoDB はまだビットマップ インデックスをサポートしていませんが、このオプションを追加することを提案する提案もあります。 https://jira.mongodb.org/browse/SERVER-1723

Elasticsearch は内部でビットマップを使用します (https://www.elastic.co/blog/frame-of-reference-and-roaring-bitmaps).

• しかし、私たちの家に新しい隣人が現れました：ピロサ。 これは、Go で書かれた新しい非リレーショナル データベースです。 これにはビットマップ インデックスのみが含まれており、すべてはビットマップ インデックスに基づいています。 それについては少し後で話します。

Goでの実装

しかし、ビットマップ インデックスがあまり使用されないのはなぜでしょうか? この質問に答える前に、Go で非常に単純なビットマップ インデックスを実装する方法を説明したいと思います。

ビットマップは本質的に単なるデータの一部です。 Go では、これにバイト スライスを使用しましょう。

XNUMX つのレストランの特性に対して XNUMX つのビットマップがあり、ビットマップ内の各ビットは、特定のレストランにこの特性があるかどうかを示します。

20 つのヘルパー関数が必要になります。 XNUMX つはビットマップをランダム データで埋めるために使用されます。 ランダムですが、一定の確率でレストランがそれぞれの特性を持っています。 例えば、モスクワでは予約の取れないレストランはほとんどないと思いますし、ベジタリアン向けの店はXNUMX割程度ではないかと思います。

XNUMX 番目の関数は、ビットマップをレストランのリストに変換します。


「パティオがあり、予約できる安価なレストランを教えてください」というクエリに答えるには、NOT と AND という XNUMX つのビット演算が必要です。

より複雑な AND NOT 演算子を使用すると、コードを少し簡素化できます。

これらの操作ごとに関数があります。 どちらもスライスを調べて、それぞれから対応する要素を取り出し、それらをビット演算と組み合わせて、結果を結果のスライスに入れます。

これで、ビットマップと関数を使用して検索クエリに答えることができるようになりました。

関数は非常に単純ですが、関数が呼び出されるたびに新しい結果のスライスを返さなかったため、パフォーマンスはそれほど高くありませんでした。

pprof で少しプロファイリングを行った後、Go コンパイラには、関数のインライン化という非常に単純だが非常に重要な最適化が欠けていることに気付きました。

実際のところ、Go コンパイラーはスライスを通過するループを非常に恐れており、そのようなループを含む関数のインライン化を断固として拒否します。

しかし、私は恐れることはありません。古き良き時代のように、ループの代わりに goto を使用してコンパイラーをだますことができます。

そして、ご覧のとおり、コンパイラは関数を喜んでインライン化します。 その結果、約 2 マイクロ秒を節約することができました。 悪くない！

XNUMX 番目のボトルネックは、アセンブリ出力をよく見ると簡単にわかります。 コンパイラは、最もホットなループ内にスライス境界チェックを追加しました。 実際のところ、Go は安全な言語であり、コンパイラーは、私の XNUMX つの引数 (XNUMX つのスライス) のサイズが異なることを恐れています。 結局のところ、理論的には、いわゆるバッファ オーバーフローが発生する可能性があります。

すべてのスライスが同じサイズであることを示してコンパイラーを安心させましょう。 これを行うには、関数の先頭に簡単なチェックを追加します。

これを見て、コンパイラーは喜んでチェックをスキップし、最終的にさらに 500 ナノ秒を節約することになります。

大きな枝

さて、単純な実装からある程度のパフォーマンスを引き出すことができましたが、この結果は実際には現在のハードウェアで可能なものよりもはるかに悪いです。

私たちが行うのは基本的なビット演算だけであり、プロセッサーはそれらを非常に効率的に実行します。 しかし、残念ながら、私たちはプロセッサに非常に小さな作業を「供給」します。 私たちの関数はバイトごとに操作を実行します。 UInt8 スライスを使用して、64 バイトのチャンクを処理できるようにコードを非常に簡単に調整できます。

ご覧のとおり、この小さな変更により、バッチ サイズが XNUMX 倍になり、プログラムが XNUMX 倍高速化されました。 ゲインは線形であると言えます。

アセンブラでの実装

しかし、これで終わりではありません。 当社のプロセッサは、16、32、さらには 64 バイトのチャンクを処理できます。 このような「広範な」演算は、単一命令複数データ (SIMD、XNUMX つの命令、多数のデータ) と呼ばれ、そのような演算を使用するようにコードを変換するプロセスはベクトル化と呼ばれます。

残念ながら、Go コンパイラーはベクトル化に関しては決して優れています。 現在、Go コードをベクトル化する唯一の方法は、Go アセンブラーを使用してこれらの操作を手動で取得して配置することです。

Go アセンブラーは奇妙な野獣です。 おそらく、アセンブリ言語は、作成対象のコンピューターのアーキテクチャに大きく関係していることをご存知でしょうが、Go ではそうではありません。 Go アセンブラーは、IRL (中間表現言語) または中間言語に似ており、実質的にプラットフォームに依存しません。 ロブ・パイクは素晴らしいパフォーマンスを見せた 報告 このテーマについては数年前、デンバーで開催された GopherCon で取り上げられました。

さらに、Go は、一般に受け入れられている AT&T および Intel 形式とは異なる、珍しい Plan 9 形式を使用します。

Go アセンブラを手作業で書くことは、最も楽しいことではないと言っても過言ではありません。

しかし幸いなことに、Go アセンブラの作成に役立つ XNUMX つの高レベル ツール、PeachPy と avo がすでに存在します。 どちらのユーティリティも、それぞれ Python と Go で書かれた高レベルのコードから Go アセンブラーを生成します。

これらのユーティリティは、レジスタの割り当てやループの作成などを簡素化し、一般的に Go でアセンブリ プログラミングの世界に入るプロセスを簡素化します。

avo を使用するので、プログラムはほぼ通常の Go プログラムになります。

avo プログラムの最も単純な例は次のようになります。 main() 関数があり、その中に Add() 関数が定義されています。この関数の意味は XNUMX つの数値を加算することです。 ここには、名前でパラメータを取得し、空きの適切なプロセッサ レジスタの XNUMX つを取得するためのヘルパー関数があります。 ADDQ に見られるように、各プロセッサー操作には avo 上の対応する機能があります。 最後に、結果の値を保存するためのヘルパー関数を示します。

gogenerate を呼び出すと、avo でプログラムが実行され、その結果、XNUMX つのファイルが生成されます。

• add.s を Go アセンブラーの結果のコードに追加します。
• stub.go には、Go とアセンブラーの XNUMX つの世界を接続する関数ヘッダーが含まれています。

avo が何をどのように行うかを見てきたので、関数を見てみましょう。 関数のスカラー バージョンとベクトル (SIMD) バージョンの両方を実装しました。

まずスカラーバージョンを見てみましょう。

前の例と同様に、無料で有効な汎用レジスタを要求しているため、引数のオフセットとサイズを計算する必要はありません。 avo はこれらすべてを私たちのためにやってくれます。

以前はラベルと goto (またはジャンプ) を使用してパフォーマンスを向上させ、Go コンパイラーを騙していましたが、現在は最初から使用しています。 重要なのは、サイクルはより高いレベルの概念であるということです。 アセンブラではラベルとジャンプしかありません。

残りのコードはすでに馴染みがあり、理解できるはずです。 ラベルとジャンプを使用してループをエミュレートし、XNUMX つのスライスから小さなデータを取り出し、それらをビット演算 (この場合は AND NOT) と組み合わせて、結果を結果のスライスに入れます。 全て。

最終的なアセンブラー コードは次のようになります。 オフセットとサイズを計算したり (緑色で強調表示)、使用されたレジスターを追跡したり (赤色で強調表示) する必要はありませんでした。

アセンブリ言語実装のパフォーマンスを Go の最良の実装のパフォーマンスと比較すると、同じであることがわかります。 そしてこれは予想通りです。 結局のところ、私たちは特別なことは何もしていません。Go コンパイラーが行うことを再現しただけです。

残念ながら、アセンブリ言語で記述された関数をコンパイラに強制的にインライン化することはできません。 Go コンパイラには現在そのような機能がありませんが、かなり前から追加の要望がありました。

これが、アセンブリ言語の小さな関数から利点を得ることができない理由です。 大規模な関数を作成するか、新しい math/bits パッケージを使用するか、アセンブラー言語をバイパスする必要があります。

次に、関数のベクトル バージョンを見てみましょう。

この例では、AVX2 を使用することにしたため、32 バイトのチャンクで動作する操作を使用します。 コードの構造は、パラメータのロード、空き共有レジスタの要求など、スカラー バージョンと非常に似ています。

革新の 32 つは、より広範なベクトル演算で特殊なワイド レジスタを使用することです。 512 バイトのチャンクの場合、これらは Y という接頭辞が付けられたレジスタです。これが、コード内に YMM() 関数が表示される理由です。 64 ビット チャンクで AVX-XNUMX を使用している場合、プレフィックスは Z になります。

XNUMX 番目の革新は、ループ アンローリングと呼ばれる最適化を使用することにしたことです。これは、ループの先頭にジャンプする前に XNUMX つのループ操作を手動で実行することを意味します。 この最適化によりコード内の分岐の数が減りますが、利用可能な空きレジスタの数によって制限されます。

さて、パフォーマンスについてはどうでしょうか？ 彼女はきれいだ！ 最良の Go ソリューションと比較して約 XNUMX 倍の高速化を達成しました。 印象的ですよね？

ただし、この実装でも、AVX-512、プリフェッチ、またはクエリ スケジューラの JIT (ジャストインタイム コンパイラ) を使用することで高速化できる可能性があります。 しかし、これは確かに別のレポートのトピックです。

ビットマップインデックスの問題

Go でのビットマップ インデックスの簡単な実装と、アセンブリ言語でのより生産的な実装をすでに見てきました。最後に、なぜビットマップ インデックスがめったに使用されないのかについて話しましょう。

古い論文ではビットマップ インデックスに関する XNUMX つの問題について言及していますが、新しい論文と私はそれらはもはや関連性がないと主張しています。 これらの問題のそれぞれには深く立ち入りませんが、表面的に見ていきます。

高カーディナリティの問題

したがって、ビットマップ インデックスはカーディナリティの低いフィールド、つまり値がほとんどないフィールド (性別や目の色など) にのみ適していると言われています。その理由は、そのようなフィールドの通常の表現 (XNUMX つの値) であるためです。値あたりのビット数)、カーディナリティが高い場合、多くのスペースを占有し、さらに、これらのビットマップ インデックスが十分に (ほとんど) 埋められなくなります。


場合によっては、数値を表すために使用する標準的な表現など、別の表現を使用することがあります。 しかし、すべてを変えたのは圧縮アルゴリズムの出現でした。 過去数十年にわたり、科学者や研究者はビットマップ用の多数の圧縮アルゴリズムを考案してきました。 その主な利点は、ビット操作を実行するためにビットマップを解凍する必要がないことです。圧縮されたビットマップに対して直接ビット操作を実行できます。

最近では、轟音ビットマップなどのハイブリッド アプローチが登場し始めています。 これらは、ビットマップの XNUMX つの異なる表現 (ビットマップ自体、配列、いわゆるビットラン) を同時に使用し、それらの間でバランスをとることで、パフォーマンスを最大化し、メモリ消費を最小限に抑えます。

最も人気のあるアプリケーションには、轟音ビットマップが含まれています。 さまざまなプログラミング言語の実装がすでに膨大な数にあり、Go の実装も XNUMX つ以上あります。

高いカーディナリティに対処するのに役立つもう 185,2 つのアプローチは、ビニングと呼ばれます。 人の身長を表すフィールドがあると想像してください。 身長は浮動小数点数ですが、私たち人間はそのようには考えません。 私たちにとって、身長 185,3 cm と XNUMX cm に違いはありません。

類似した値を 1 cm 以内のグループにグループ化できることがわかります。

また、身長が 50 cm 未満で身長が 250 cm を超える人はほとんどいないということもわかっている場合、基本的に、無限のカーディナリティを持つフィールドを、約 200 個の値のカーディナリティを持つフィールドに変換できます。

もちろん、必要に応じて、後で追加のフィルタリングを行うこともできます。

高帯域幅の問題

ビットマップ インデックスに関する次の問題は、インデックスの更新に非常にコストがかかることです。

データベースは、潜在的に何百もの他のクエリがデータを検索している間にデータを更新できなければなりません。 同時データ アクセスやその他の共有の問題を回避するには、ロックが必要です。 そして、大きなロックが XNUMX つある場合、このロックがボトルネックになると、ロックの競合という問題が発生します。

この問題は、シャーディングまたはバージョン管理されたインデックスを使用することで解決または回避できます。

シャーディングはシンプルでよく知られたものです。 他のデータと同様に、ビットマップ インデックスをシャーディングできます。 XNUMX つの大きなロックの代わりに、多数の小さなロックを取得できるため、ロックの競合がなくなります。

この問題を解決する 100 番目の方法は、バージョン管理されたインデックスを使用することです。 検索または読み取りに使用するインデックスのコピーを 500 つと、書き込みまたは更新に使用するインデックスのコピーを XNUMX つ作成できます。 そして、一定期間に XNUMX 回 (たとえば、XNUMX ミリ秒または XNUMX ミリ秒に XNUMX 回)、それらを複製して交換します。 もちろん、このアプローチは、アプリケーションがわずかに遅れている検索インデックスを処理できる場合にのみ適用できます。

これら XNUMX つのアプローチは同時に使用できます。シャードされたバージョン対応のインデックスを使用できます。

より複雑なクエリ

ビットマップ インデックスに関する最後の問題は、ビットマップ インデックスがスパン クエリなどのより複雑な種類のクエリにはあまり適していないと言われていることです。

確かに、よく考えてみると、AND や OR などのビット演算は、「200 泊あたりの宿泊料金が 300 ～ XNUMX ドルのホテルを教えてください」といったクエリにはあまり適していません。

素朴で非常に賢明ではない解決策は、各ドル値の結果を取得し、それらをビット単位の OR 演算で結合することです。

もう少し良い解決策は、グループ化を使用することです。 たとえば、50 ドルのグループです。 これにより、プロセスが 50 倍高速化されます。

ただし、この問題は、このタイプのリクエスト専用に作成されたビューを使用することで簡単に解決することもできます。 科学論文では、これは範囲エンコードされたビットマップと呼ばれます。

この表現では、ある値 (たとえば 200) に 200 ビットを設定するだけではなく、この値とすべての値をそれより高い値に設定します。 300以上。 300:XNUMX以上も同様。 等々。

この表現を使用すると、インデックスを 300 回走査するだけで、この種の検索クエリに答えることができます。 まず、部屋の料金が 199 ドル以下のホテルのリストを取得し、次に部屋の料金が XNUMX ドル以下のホテルをリストから削除します。 準備ができて。

驚かれるかもしれませんが、ビットマップ インデックスを使用するとジオクエリさえも可能です。 コツは、座標を幾何学的図形で囲む幾何学的表現を使用することです。 たとえば、Google の S2。 図は、番号を付けることができる XNUMX 本以上の交差する線の形式で表現できる必要があります。 このようにして、ジオクエリを「ギャップに沿って」(これらの番号の付いた行に沿って) 複数のクエリに変換できます。

レディーソリューション

少しでも興味を持っていただければ幸いです。また便利なツールがあなたの武器庫に加わりました。 このようなことを行う必要がある場合、どちらを見ればよいかがわかります。

ただし、誰もがビットマップ インデックスを最初から作成するための時間、忍耐力、またはリソースを持っているわけではありません。 特に、SIMD を使用するなど、より高度なものです。

幸いなことに、役立つ既製のソリューションがいくつかあります。

轟音ビットマップ

まず、すでに話したのと同じ轟音ビットマップ ライブラリがあります。 これには、本格的なビットマップ インデックスを作成するために必要なコンテナとビット操作がすべて含まれています。

残念ながら、現時点ではどの Go 実装も SIMD を使用していません。つまり、Go 実装は、たとえば C 実装よりもパフォーマンスが低いことになります。

ピローサ

役立つもう XNUMX つの製品は Pilosa DBMS です。これには実際にはビットマップ インデックスしかありません。 これは比較的新しいソリューションですが、急速に人々の心を掴んでいます。

Pilosa は内部で轟音ビットマップを使用し、それらを使用する機能を提供し、グループ化、範囲エンコードされたビットマップ、フィールドの概念など、上で説明したすべてのことを簡素化して説明します。

すでによく知っている質問に答えるために Pilosa を使用する例を簡単に見てみましょう。

この例は、前に見たものと非常によく似ています。 Pilosa サーバーへのクライアントを作成し、インデックスと必要なフィールドを作成してから、フィールドに確率を含むランダム データを入力して、最後に使い慣れたクエリを実行します。

その後、「expensive」フィールドで NOT を使用し、その結果を「terrace」フィールドおよび「reservations」フィールドと交差 (または AND) します。 そして最後に、最終結果が得られます。

近い将来、この新しいタイプのインデックス、つまりビットマップ インデックスが MySQL や PostgreSQL のような DBMS にも登場することを私は心から願っています。

まとめ

まだ寝ていない方は、よろしくお願いします。 時間が限られていたため、多くのトピックについて簡単に触れなければなりませんでしたが、この講演が有益であり、おそらくモチベーションさえも高められたことを願っています。

ビットマップ インデックスは、今すぐ必要ない場合でも知っておくとよいでしょう。 あなたのツールボックスのもう一つのツールとして活用しましょう。

Go のさまざまなパフォーマンス トリックや、Go コンパイラーがまだうまく処理できないことについて検討してきました。 しかし、これはすべての Go プログラマーが知っておくと絶対に役立ちます。

私が言いたかったのはそれだけです。 ありがとう！

出所： habr.com