タグ付けされた質問 「vldb」

1
10億行を処理してカウントするためのデータベース設計
リアルタイムのGPSデータを約5000 prのレートで受信します。分(4つのTCPサーバーから)。各サーバーは単一の接続を使用してデータを挿入し、挿入と挿入の間でデータをバッファーします。15分ほどごとに、サービスがこのデータをフェッチし、それをトリップに処理します。旅行が生成されたら、実際のGPSデータは通常、それほど重要ではありません。ユーザーが地図上でルートを確認したい場合のみです。 問題は、データベースが挿入されるデータの速度に追いつくのに苦労しているように見えることです。負荷が増加すると、挿入時間が急激に増加し(> 30秒)、その結果、より多くのデータをバッファリングできるようになり、その結果、挿入が大きくなり、挿入時間が長くなります。 現在のデザイン、パフォーマンスを改善するために必要ないくつかのアイデア、いくつかの質問への回答、および人々が持っている可能性のあるその他のヒントについて、いくつかコメントをいただければ幸いです。 現在のデザイン 現在、データは1週間を表すテーブルに分割されており、1年以上経過したデータはセカンダリデータベースにアーカイブされます。挿入と読み取りの両方に使用される編集可能なビューで全体が結合されます。 テーブルデザイン Id(PK、uniqueidentifier) DeviceId(FK、int) PersonId(FK、int) VehicleId(FK、int) TokenId(FK、int) UtcTime(PK、datetime2(3)) 緯度(float) 経度(float) 速度(smallint) 見出し(smallint) 衛星(tinyint) IOData(varbinary(100)) IgnitionState(tinyint) UserInput(tinyint) CreateTimeUtc(datetime2(3)) 指数 DeviceId_CreateTimeUtc_Desc DeviceId_UtcTime_Desc(クラスター化) PersonId_UtcTime_Desc TokenId_UtcTime_Desc VehicleId_UtcTime_Desc 現在、毎週、インデックスを含めて約10 GBを占めています。現在、メインデータベースには約300 GBのデータがあります。 メインデータベースのデータテーブルには、1つのファイルを持つ独自のファイルグループがありますが、メインデータベースの他のすべてのテーブルと同じディスク上にあります。セカンダリデータベースは別のディスクにありますが、同じマシン上にあります。 新しいテーブルパーティション(週)が使用されるときに、インデックスの再構築ジョブも毎週実行していると思います。縮小は行われません。 マシンは12 GBのメモリを搭載した8コアHPであり、メインデータベースを保持するディスクはRAID 10を実行しています。 アイデア プライマリデータベースに保存されるデータの量を、たとえば最大1か月に制限します。少なくとも、データベースをバックアップ/復元用に管理しやすくなりますが、これによりパフォーマンスの向上が見込めますか? 現在のデータのファイルグループに2つのファイルを作成し、それらを2つの異なる物理パーティションに配布する 現在のデータを保持するマスタースレーブデータベースを作成して、挿入と読み取りが異なるデータベースで実行されるようにする 現在のデータのファイルをSSDディスクに配置します(ミラーリングによりSSDディスクとのパフォーマンスに違いが生じますか?) さらに情報が必要な場合はお知らせください。パフォーマンスに影響を与える恐ろしいほど多くの要因があり、おそらくそれを調整する多くの方法があります。

2
複数日にわたるDBCC CHECKDBの分割
Paul Randal がDBCC CHECKDBを手動で数日間に渡って分散する、非常に大規模なデータベースの実装に取り​​組んでいます。 データベース内のテーブルを7つのバケット間でほぼ均等に分割する 週2回のDBCC CHECKALLOCの実行 週に1回、DBCC CHECKCATALOGを実行する 曜日ごとに1つのバケットでDBCC CHECKTABLEを実行する 誰かがこのテクニックを使用しましたか?既存のスクリプトはありますか? これが実際にCHECKDBが行うすべてをカバーしていないのではないかと心配しています。CHECKDBのBooks Onlineドキュメントでは、CHECKALLOC、CHECKCATALOG、およびCHECKTABLEに加えて、次のことも述べられています。 データベース内のすべてのインデックス付きビューの内容を検証します。 FILESTREAMを使用してファイルシステムにvarbinary(max)データを格納するときに、テーブルメタデータとファイルシステムディレクトリおよびファイルの間のリンクレベルの整合性を検証します。(SQL 2008のみ) データベース内のService Brokerデータを検証します。 だからここに私の質問があります: これらの追加のチェックは必要ですか/重要ですか?(インデックス付きビューは、おそらく私にとっては少し心配です。まだService BrokerやFILESTREAMを使用しているとは思いません。) もしそうなら、これらの追加のチェックを個別に実行する方法はありますか? CHECKALLOCとCHECKCATALOGは、大きなdbでも非常に高速に実行されるようです。これらを毎日実行しない理由はありますか? (注:これは、数百のサーバーにわたる数千の既存のデータベース、または少なくとも特定のサイズを超えるすべてのデータベースの標準ルーチンになります。つまり、CHECKFILEGROUPを使用するようにすべてのデータベースを再構築するようなオプションは、実際には実用的ではありません。)
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.