2

アーカイブ機能とクエリ機能の両方のために、MySQL データベースにインポートしたいアーカイブ ログ ファイルがいくつかあります。

これらのログ ファイルの各行は、特定の種類のイベントを表します。これを説明するために、各行が異なるイベント タイプである例を次に示します。

2013-01-15 03:30:08 - Failed login attempt for user 'helloworld' by 1.2.3.4
2013-01-15 03:30:08 - User 'helloworld' successfully logged in from 1.2.3.4
2013-01-15 03:30:08 - User 'helloworld' issued command 'randomcommand'

質問に関連するタイムスタンプに注意してください。

failed_logins私が最初に考えたのは、イベントごとにテーブルを作成することでしsuccessful_loginsたcommands。

そのアプローチの問題は、同じ秒に複数のイベントが発生した場合 (タイムスタンプの精度は 2 番目のレベルのみ)、それらが異なるテーブルにあるため、発生した実際の順序を知る方法がないことです。

次に考えたのは、1 つのテーブルを使用し、主キーで順序を維持することでしたが、これはすべてのイベント タイプですぐに手に負えなくなります。(これ以外にもあります。)

CREATE TABLE log_lines (
    id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    type INT, // 1 = failed_login, 2 = command, ...
    failed_logins_user VARCHAR(32),
    failed_logins_ip VARCHAR(15),
    commands_user VARCHAR(32),
    commands_command VARCHAR(128)
);

これを達成するためのより良い方法があるように感じます。

要約すると、私の目標は、ログ ファイルで発生した各イベントの順序を維持しながら、データをクエリ可能にすることです。これについてどうすればよいですか？

4

1 に答える 1

0

考えられる解決策の 1 つ: 行ごとに 2 つのテーブルを使用します。1 つは、シーケンス番号 (AUTO_INCREMENT列) やタイムスタンプなど、すべてのイベントに共通の列を格納するためのもので、もう 1 つはイベントに固有のその他の詳細を提供するためのものです。最初に共通テーブルに挿入し、そこで生成された ID を他のテーブルで一意の外部キーとして使用できます。

ただし、通常、値はデータの 1 ビットしか占めないことも忘れないでNULLください。そのため、一部のイベント タイプにのみ必要な多数の列を含む 1 つのテーブルがより適切なソリューションになる可能性があります。クエリによって異なります。通常、すべてのタイプのイベントを順番にクエリする場合は、単一のテーブルの方が適していますが、特定の種類の特定のイベントを抽出するには、別のテーブルを使用する方が適している場合があります。

type INT, // 1 = failed_login, 2 = command, ...

enumこの種の列にはを使用したほうがよい場合があります。

于 2013-02-25T12:32:15.187 に答える