2

現在、SQL ServerとLuceneの組み合わせを使用して、ドメイン名に関するいくつかのリレーショナルデータにインデックスを付けています。ドメインテーブルと、ドメインについて計算して保存するさまざまなメトリックの履歴用の他のさまざまなテーブルが約10個あります。例えば：

ドメイン

  • IdBIGINT
  • ドメインNVARCHAR
  • IsTracked BIT

SeoScore

  • IdBIGINT
  • DomainId BIGINT
  • INTを獲得する
  • タイムスタンプDATETIME

主要なゾーンファイルのすべてのドメインをデータベースに含めようとしているため、最終的には約6億件のレコードを調べています。これは、SQLServerで拡張するのは少し面倒な作業になると思われます。かなり高度なクエリを実行するためにLuceneに依存していることを考えると、Solandraはそれが適しているように思われます。リレーショナルデータベースの用語でデータについて考えないのに苦労しています。

SeoScoreテーブルは、1つを多数のドメインにマップします（スコアを計算するたびに1つのレコード）。Solandraの用語では、これを実現するための最良の方法は、ドメイン用とSeoScore用の2つのインデックスを使用することだと思います。

達成する必要のあるクエリシナリオは次のとおりです。

  1. 各ドメインの最新のメトリックの「現在のスナップショット」（つまり、特定のドメインの最新のSeoScore。最初に必要なドメインレコードを見つけてから、さらにクエリを実行して、各メトリックの最新のスナップショットを個別に取得すると想定しています。 。

  2. SeoScoresがx日時以降にチェックされておらず、IsTracked = 1であるドメイン。したがって、どのドメインを再計算する必要があるかがわかります。ここでは、作業を重複させることなくドメインを「チェックアウト」して計算を実行できるように、ある種のバッチシステムが必要になります。

私はここで軌道から外れていますか？この場合、基本的にテーブルをsolandraの個別のインデックスにマッピングするのは正しいでしょうか？

アップデート

これが私が考えていることのJSON表記です：

Domains : { //Index
    domain1.com : { //Document ID
        Middle : "domain1", //Field
        Extension : "com",
        Created : '2011-01-01 01:01:01.000',
        ContainsDashes : false,
        ContainsNumbers : false,
        IsIDNA : false,
    },
    domain2.com {
        ...
    }
}

SeoScores : { //Index
    domain1.com { //Document ID
        '2011-02-01 01:01:01.000' : { 
            SeoScore: 3 
        },
        '2011-01-01 01:01:01.000' : {
            SeoScore: -1
        }
    },
    domain2.com {
        ...
    }
}
4

1 に答える 1

2

SeoScoresの場合、仮想コアの使用を検討することをお勧めします。

https://github.com/tjake/Solandra/wiki/ManagingCores

これにより、データをドメインごとに分割できるため、SeoScores.domain1を使用して、各ドキュメントを1つのタイムスタンプで表すことができます。

残りはうまく聞こえます。

于 2011-08-17T01:09:42.323 に答える