リレーショナルモデルとして設計された大量のデータ（約100GB）を処理するアプリケーションを書き直しています。
アプリケーションは非常に複雑です。これは、巨大なサイズ（全世界）のオープンストリートマップデータ用のある種の変換ツールであり、独自のルートプランニングソフトウェア用のマップファイルに変換します。たとえば、コンバーターアプリケーションは、オープンストリートマップ内のノードをその座標とそのすべてのタグとともに保持します（それ以上のものがたくさんありますが、これはこの質問の例として役立つはずです）。
現在の状況：
このデータは非常に大きいため、いくつかのファイルに分割します。各ファイルはIDからアトミック値へのマップです（ノードのタグのリストがアトミック値であると仮定します。そうではありませんが、データストレージはそのように扱ってください）。したがって、ノードの場合、ノードの座標を保持するファイルがあります。1つはノードの名前を保持し、もう1つはノードのタグを保持します。ノードは（非連続）IDで識別されます。
アプリケーションはかつていくつかのアプリケーションに分割されていました。各アプリケーションは、変換の1つのステップを処理します。したがって、このようなアプリケーションは、ファイルに保存されているデータの一部のみを処理する必要があります。たとえば、すべてのアプリケーションがノードのタグを必要とするわけではありませんが、多くのアプリケーションはノードの座標を必要とします。これが、リレーションをファイルに分割する理由です。「列」ごとに1つのファイルです。
各処理ステップでは、ファイル全体を一度にRAM内のデータ構造に読み込むことができます。これにより、ルックアップが非常に効率的になります（データ構造がハッシュマップの場合）。
現在、コンバーターを書き直しています。これで、単一のアプリケーションになります。また、「列」ごとに個別のファイルを使用しないようにする必要があります。むしろ、データベースのようにリレーショナルな方法で外部データを保持するために、いくつかのよく知られたアーキテクチャを使用する必要がありますが、はるかに高速です。
=>次の機能を提供できるライブラリはどれですか？
要件：
既存のデータの反復処理を非常に高速にする必要があります（行のセットは変更しませんが、現在の行の一部の値は変更します）。
ハッシュマップと同様に、一定またはほぼ一定のルックアップを提供する必要があります（ただし、関係全体をまったく変更しません）。
ほとんどのタイプの列は常にサイズ設定されていますが、一般的にはそうではありません。
行ごとに一定時間または対数時間でリレーションに新しい行を追加できる必要があります。ある種の検索インデックスをライブ更新する必要はありません。インデックスの更新（再構築）は、処理ステップ全体が完了した後に発生する可能性があります。
一部のリレーションはKey-Valueベースですが、他のリレーションは（継続的にインデックス付けされた）配列です。どちらも高速ルックアップを提供する必要があります。
MySQLのようなDBMSのように、別個のプロセスであってはなりません。クエリの数は膨大になり（約100億）、完全にパフォーマンスのボトルネックになります。ただし、クエリのキャッシュは回避策として考えられます。テーブルへの書き込み（同じ処理ステップでデータが読み取られない）をバッチクエリで実行しながら、テーブル全体の反復を1つのクエリで実行できます。しかし、それでも、SQLクエリのシリアル化、プロセス間送信、および逆シリアル化がボトルネックになると思います。
持ちやすい：使いやすい。リレーションをC++標準およびQtコンテナクラスと同様の方法で使用できると非常に便利です。
非要件 （DBMSが必要ない理由）：
同じ関係から/への書き込みと読み取りを同期します。アプリケーションは複数の処理ステップに分割されます。すべてのステップには、読み取り元の「入力関係」と書き込み先の「出力関係」のセットがあります。ただし、一部の手順では、同じリレーションの他の列に書き込むときに、リレーションのいくつかの列を読み取る必要があります。
関係を結合します。異なるリレーション間にはいくつかの相互参照がありますが、ルックアップが十分に高速であれば、アプリケーション内で解決できます。
永続ストレージ。変換が完了すると、すべてのデータは不要になります。
キーと値に基づく関係は、キーが再生成されることはありません。配列ベースの関係は、インデックスが再作成されることはありません。