InnoDB がテーブルをフォーマットする最良の方法であるかどうか疑問に思っていましたか? テーブルには 1 つのフィールド (主キー) が含まれており、テーブルには 1 日あたり 816,000 行 (概算) が含まれます。これは非常に速く非常に大きくなります！私はファイルストレージの方法に取り組んでいます (これはより高速でしょうか)? テーブルには、処理済みの Twitter ID の ID 番号が格納されますか?
また、SELECT min('id')ステートメントの推定メモリ使用量はありますか? 他のアイデアは大歓迎です！
ID または日付でテーブルのパーティション分割を開始することをお勧めします。パーティショニングは、定義されたロジック (日付範囲による分割など) に従って大きなテーブルをいくつかの小さなテーブルに分割します。MySQL 5.1 にはこの機能が組み込まれていますが、カスタム ソリューションを使用して実装することもできます。
フラットファイルにストレージを実装すると、データベースのすべての利点が失われ、データに関するクエリを実行できなくなります。
唯一の決定的な答えは、両方を試してテストし、何が起こるかを確認することです。
一般に、MyISAM は書き込みと読み取りで高速ですが、同時に両方ではありません。MyISAM テーブルに書き込むと、挿入が完了するまでテーブル全体がロックされます。InnoDB はオーバーヘッドが大きくなりますが、行レベルのロックを使用するため、MyISAM のテーブル ロックで発生する問題が発生することなく、読み取りと書き込みを同時に行うことができます。
しかし、あなたの問題は、私が正しく理解していれば、少し異なります。MyISAM と InnoDB が主キー インデックスを処理するさまざまな方法において、列が 1 つしかなく、その列が主キーであることは重要な考慮事項です。
MyISAM では、プライマリ キー インデックスは他のセカンダリ インデックスと同じです。内部的には、各行には行 ID があり、インデックス ノードはデータ ページの行 ID を指すだけです。主キー インデックスは、他のインデックスと異なる方法で処理されることはありません。
ただし、InnoDB では、主キーはクラスター化されます。つまり、主キーはデータ ページにアタッチされたままになり、行の内容が主キーに従ってディスク上で物理的に並べ替えられた順序で保持されます (ただし、単一のデータ ページ内のみで、それ自体が分散している可能性があります)。任意の順序。)
この場合、InnoDB には、MyISAM が本質的に二重の作業を行う必要があるという利点があると予想されます。データ ページに整数を 1 回書き込み、次にインデックス ページに再度書き込みます。InnoDB はこれを行いません。主キー インデックスはデータ ページと同一であり、一度だけ書き込む必要があります。MyISAM が不必要に 2 つのコピーを管理する必要がある場合、データを 1 か所で管理するだけで済みます。
どちらのストレージ エンジンでも、インデックス付きの列に対して min() や max() などを実行するか、インデックス内の数値の存在を確認するだけで簡単に実行できます。テーブルは 1 つの列にすぎないため、データは完全にインデックス自体の中で表現されるため、ブックマーク ルックアップは必要ありません。これは非常に効率的なインデックスになるはずです。
また、テーブルのサイズについてもそれほど心配する必要はありません。行の幅が 1 つの整数のみの場合、インデックス/データ ページごとに膨大な数の行を収めることができます。
これらの ID 番号が単調に増加し、書き込みがデータを追加するだけである (決して変更しない) 場合、単一のファイルを使用する方がおそらくはるかに高速です。次にSELECT min('id')、ファイルの最初の行を読み取るだけになり、それ以外はバイナリ検索になります。
また、いくつかの商社がティックデータベースを使用しているのを見てきました。kdb+ http://kx.com/
id 列にインデックスがある場合は、min(id) を O(1) にする必要があります。これには多くのメモリが必要ではありません。
主キーが twitter id にある場合は、それにインデックスがあります。
MySQL Dev ゾーンでのストレージ エンジンの比較は次のとおりです。
あなたの説明から、MyISAM の方が優れていると言えますが、アプリの読み書きパターンの比較に大きく依存します。
単一のフィールドが主キーであり、レコードを追加するだけなので、通常のデータベースにはあまり適していません。
まず、必要な情報の 2 倍の情報を格納し、すべてのフィールドをデータ テーブルとインデックスに格納します。
余談ですが、リレーショナルデータベースは、関連するデータを単一の行に格納するため、そう呼ばれています。データがどのように修飾されるかを確認するのは困難です:-) 他のものも保存している場合、データベースはそれだけの価値があります.
一度に複数のプロセスがデータにアクセスするかどうかについては言及していません。そうでない場合は、データベース ACID の原則によってもたらされるすべての利点は必要ありません。ACID が必要な場合でも、本格的なデータベースがなくても実現できます。
ただし、データの重複を避けるために、独自の B-tree または B+-tree データ ファイルを作成して Twitter ID を保存することをお勧めします。（質問に基づいて）あなたがしているのを見ることができる唯一のクエリは次のとおりです。
最初のものは、B ツリー構造の外側の別のファイルに最小値を格納するだけで O(1) にすることができます (そして、下位のものを取得したらそれを置き換えます)。特定の Twitter ID がテーブルにないことをすぐに確認する場合を除き、このケースのビジネス ケースについてはわかりません (したがって、その場合はおそらく max も必要になるでしょう)。
2 つ目は、標準的なツリー検索手法です。これは、データベースが一般的に内部で使用するものです。