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

3
現在の年を除くすべてをアーカイブし、同時にテーブルをパーティション分割する最良の方法は何ですか
仕事 大きなテーブルのグループから、13か月のローリング期間を除くすべてをアーカイブします。アーカイブされたデータは別のデータベースに保存する必要があります。 データベースは単純復旧モードです テーブルは50ミリ行から数十億行で、場合によってはそれぞれ数百GBを占有します。 テーブルは現在パーティション化されていません 各テーブルには、増え続ける日付列に1つのクラスター化インデックスがあります 各テーブルには、さらに1つの非クラスター化インデックスがあります テーブルに対するすべてのデータ変更は挿入です 目標は、プライマリデータベースのダウンタイムを最小限に抑えることです。 サーバーは2008 R2 Enterpriseです 「アーカイブ」テーブルには約11億行、「ライブ」テーブルには約4億行が含まれます。明らかに、アーカイブテーブルは時間とともに増加しますが、ライブテーブルも合理的に急速に増加することを期待しています。少なくとも次の数年で50%と言います。 Azureストレッチデータベースについて考えていましたが、残念ながら2008 R2にあり、しばらくそこに留まる可能性があります。 現在の計画 新しいデータベースを作成する 新しいデータベースに(変更日を使用して)月ごとにパーティション分割された新しいテーブルを作成します。 直近の12〜13か月分のデータをパーティションテーブルに移動します。 2つのデータベースの名前変更スワップを行う 移動したデータを現在の「アーカイブ」データベースから削除します。 「アーカイブ」データベースの各テーブルをパーティション分割します。 パーティションスワップを使用して、将来データをアーカイブします。 アーカイブするデータをスワップアウトし、そのテーブルをアーカイブデータベースにコピーし、それをアーカイブテーブルにスワップする必要があることを理解しています。これは許容範囲です。 問題: データを初期パーティションテーブルに移動しようとしています(実際、まだデータの概念実証を行っています)。私はTF 610(データロードパフォーマンスガイドに従って)とINSERT...SELECTステートメントを使用して、データを最小限に記録されると最初に考えて移動しようとしています。残念ながら、私が試すたびに完全にログに記録されます。 この時点で、SSISパッケージを使用してデータを移動することが最善の策だと考えています。200個のテーブルと、スクリプトでできることはすべて簡単に生成して実行できるため、これを回避しようとしています。 私の一般的な計画で不足しているものはありますか?SSISは、ログを最小限に抑えてデータをすばやく移動するための最善の策です(スペースの問題)? データなしのデモコード -- Existing structure USE [Audit] GO CREATE TABLE [dbo].[AuditTable]( [Col1] [bigint] NULL, [Col2] [int] NULL, [Col3] [int] NULL, [Col4] [int] …

2
時系列データを保存する方法
一連の関連する値を持つ時系列データセット(間違っている場合は修正してください)と思われるものがあります。 例としては、旅行中に車をモデル化し、そのさまざまな属性を追跡します。例えば: タイムスタンプ| スピード| 走行距離| 温度| 等 Webアプリケーションがフィールドを効率的に照会して、最大、最小、および各データセットを経時的にプロットできるように、このデータを保存する最良の方法は何でしょうか? データダンプを解析し、結果をキャッシュして、保存する必要がないようにする単純なアプローチを開始しました。ただし、少し試してみたところ、このソリューションはメモリの制約のために長期的に拡張できず、キャッシュをクリアする場合は、すべてのデータを再解析および再キャッシュする必要があります。 また、データが10時間以上のデータセットというまれな可能性で毎秒追跡されると仮定すると、N秒ごとにサンプリングしてデータセットを切り捨てることが一般的に推奨されますか?

4
可変列を使用したテーブル設計の処理方法
私はテーブル設計シナリオを持っていますが、非DBAタイプとして、よりスケーラブルな意見を求めています。 メトロエリアの家に関する情報を記録するように求められたとします。小さな近所(200の家)から始まり、最終的には5000000以上の家に成長します。 基本情報を保存する必要があります:ID#(一意のインデックスとして使用できる一意のロット番号)、Addr、City、State、Zip。素晴らしくシンプルなテーブルがそれを処理します。 しかし、毎年、すべての家に関する追加情報を記録するように求められます-そして、何の情報は毎年変わります。したがって、たとえば、最初の年には、所有者の姓と面積を記録するように求められます。2年目は、姓を残すよう求められますが、面積を捨てて、代わりに所有者の名の収集を開始します。 最後に-毎年、追加の列の数が変更されます。余分な2つの列から始めて、来年は6に、その後2に戻すことができます。 そのため、テーブルのアプローチの1つは、ハウステーブルの列としてカスタム情報を追加して、テーブルが1つだけになるようにすることです。 しかし、私は誰かがこれのためにテーブルを次のようにレイアウトする状況を持っています: 「House Table」列:ID、Addr、City、State、Zip-家ごとに1行 ID Addr City State Zip ------------------------------------------- 1 10 Maple Street Boston MA 11203 2 144 South Street Chelmsford MA 11304 3 1 Main Avenue Lowell MA 11280 「カスタム情報テーブル」列:ID、名前、値-テーブルは次のようになります。 ID Name Value 1 Last Name Smith 2 Last Name Harrison 3 Last …

5
複数のデータベースを使用する場合と単一のデータベースを使用する場合の長所/短所
私は、7つのデータベースを使用する必要がある新しいプロジェクトに取り組んでおり、パフォーマンス、安定性、最適化をより簡単に実装できると主張していました。 私は同意しませんが、単一のデータベースを使用する(テーブルを論理ドメインに分割する)ための適切な引数を収集するのに問題があります。 これまでの議論の1つは、データの整合性です(データベース間で外部キーを使用することはできません)。 単一または複数のデータベースを使用する場合の長所と短所は何ですか? [これまでの概要] 複数のデータベースに対する引数: データの整合性が失われます(データベースで外部キーを使用できません) 復元の整合性を失う 複雑化(dbユーザー/ロール) 小さなオッズのサーバー/データベースがダウンします ソリューション: スキーマを使用してドメインを分離します。 POC:ダミーデータを使用して7/1 dbの実行計画のポイントを証明する

2
データベースエンジンとは正確には何ですか?
私はhttp://en.wikipedia.org/wiki/Database_engineの定義を数回繰り返しました。 データベースエンジン(または「ストレージエンジン」)は、データベースからデータを作成、読み取り、更新、削除(CRUD)するためにデータベース管理システム(DBMS)が使用する基礎となるソフトウェアコンポーネントです。 私が理解していないのは、やらなければならないことです。データベースが行うすべてのことをCRUDではありませんか? データベースエンジンがこれらの機能を実行する場合、データベースの残りの部分は何をしますか?


4
ドライブvsマウントポイント?
以前のシニアDBAは、会社全体のすべてのSQL Serverのすべてのドライブにマウントポイントを設定しました。新しいシニアDBA は、マウントポイントが私たちの標準を変更したいので怖がっています(主に、経験がないためだと思います)。 多数のインターネット検索の結果に基づいて、マウントポイントを使用しない理由(SQL Server 2000以降)が見つかりません。 このトピックに関するWindows OSの制限を知っている人はいますか? 最近、「OSはマウントポイントを認識しない」という主張をよく耳にします。(私たちが使用しているWindows Serverのバージョンに関する私の調査に基づいて、真実ではありません)。 SQL Serverでマウントポイントを使用しない証拠または経験に基づいた理由はありますか? ドライブ文字の不足は問題ではないと仮定します。 マウントポイントは、ワークロードの分離に非常に役立つことを理解しています。 マウントポイントは、データファイル、ログファイル、およびtempdbの各ドライブよりも効率的に、さまざまな種類のデータおよびログファイル(システムデータベースファイル、ユーザーデータベースファイル、tempDB)のワークロードを実際に分離/分離するという理解を確認または反論できますか? ?

1
高度な並行ストレージシステム
たとえば、それぞれ300億行(合計サイズ4TB)の3つの巨大なテーブル(構造化データ)があり、多数の同時ユーザー(リモートLANマシンの並列osスレッド)が一部を読み取る必要があることを想像してくださいSELELCT WHERE GROUPBYクエリと非常に同時、たとえば10,000同時読み取りによるデータと、ユーザーがこれらのテーブルにデータを挿入する必要があります(更新なし)2000同時書き込み(データセンターLANネットワーク全体) 。ユーザーは、このストレージから可能な限り高速で読み取りと挿入を行い、各読み取りと書き込みが行われる場所はms〜1秒の範囲です。 そのような要件を満たすために、どのテクノロジーをお勧めしますか?これを実行できるデータストレージまたはキーバリューストアはありますか?クラウドはオプションではありません。 いくつかの明確化: ユーザーはデータをすぐに見る必要はなく、最終的な一貫性は許容されます。データはストレージが提供できるドライバーを介してアクセスされ、ユーザーは再びデータセンターのリモートマシンで実行される単なるスレッドになります。クエリは、主にSELECT WHERE GROUPBYに似ています。 データは表形式で、各行は約60バイトです。 DynamoDBまたは同様のソリューションを使用できないクラウドオプションはありません。データセンターで内部的にホストできる必要があります。 テーブルのすべてのデータを常に読み取ることができ、使用パターンは予測できません。結合または超長いクエリはありません。DRは必要ありませんが、合理的なHAは必要ですが、空想である必要はありません。すべての読者は、where句に基づいて行のバッチを取得しており、行は実際には関連していません。各行の長さを固定することもできますが、ストレージレイヤーが心配することを期待しています。 また、私の最大の懸念は、同時読み取りで発生するすべての同時書き込みです。 これに対するあなたの洞察は非常に高く評価されています。 さらに、これらのテーブルのうち3つにそれぞれ300億行の異なるオブジェクトタイプがあります

1
Postgresの2000万行の「最新」クエリを最適化する
私のテーブルは次のようになります: Column | Type | -----------------------+-------------------+ id | integer | source_id | integer | timestamp | integer | observation_timestamp | integer | value | double precision | インデックスは、source_id、timestamp、およびtimestampとidの組み合わせに存在します(CREATE INDEX timeseries_id_timestamp_combo_idx ON timeseries (id, timeseries DESC NULLS LAST)) そこには20M行あります(OK、120Mありますが、source_id = 1で20Mです)。それは同じのために多くのエントリを持ってtimestamp変化させてobservation_timestamp説明した、valueで発生したtimestamp報告かで観察しますobservation_timestamp。たとえば、今日の午前12時に予測されるように、明日の午後2時に予測される気温。 理想的には、このテーブルはいくつかのことをうまく行います: 新しいエントリのバッチ挿入、時には一度に100K 時間範囲で観測されたデータを選択する(「1月から3月までの気温予測は」) 特定の時点から観測された時間範囲で観測されたデータを選択する(「11月1日に考えたように、1月から3月までの気温予測のビューは何ですか」) 2つ目は、この質問の中心となるものです。 テーブルのデータは次のようになります id source_id timestamp observation_timestamp …

2
pgpoolアーキテクチャを備えたPostgres
以下はpgpoolアーキテクチャの例です: これは、単一のサーバーにpgpoolを置くだけでよいことを意味します。これは本当ですか?構成を見ると、内でバックエンドを構成していることもわかりますpgpool.conf。これはさらにこれを意味します。ただし、バックエンドサーバーでもpgpoolが表示される理由は説明されていません。 見ているときのドキュメント私はまた、以下を参照してください。 PostgreSQL 8.0以降を使用している場合は、pgpool-IIが内部で使用するため、pgpool-regclass関数をpgpool-IIがアクセスするすべてのPostgreSQLにインストールすることを強くお勧めします。 だから私は何を考えればいいのかわかりません。すべてのバックエンドまたは専用サーバーにpgpoolを配置することがベストプラクティスである場合

1
MySQLの高可用性、フェイルオーバー、およびレイテンシを伴うレプリケーション
MySQLで実行される新しいCMS(Drupal 6.x)の実装を進めています。プライマリとセカンダリの2つのデータセンターがあり、それらの間のレイテンシは既知です。MySQLのどのバージョンを実行するか不明です。コミュニティまたはエンタープライズのいずれかですが、それは未定です。InnoDBエンジンを実行するように見えます。OSはRedHat EL 5.5になります。セカンダリサーバーはパッシブまたはホットスタンバイですが、プライマリサーバーはアクティブになります。 MySQLのレプリケーション、高可用性、自動フェイルオーバーを2つのデータセンターに実装したいと考えています。 セカンダリサーバーへのフェールオーバー後、プライマリサーバーにフェールバックするとき、プライマリサーバーからコンテンツを引き続き提供できるように、セカンダリDBからプライマリDBにデータを迅速かつ完全に同期させたいと考えています。 これらの問題を解決/解決するために使用できるテクノロジー/ツール/ベストプラクティスを知ることに興味があります。また、落とし穴やああは瞬間も同様に高く評価されます。MySQLのレプリケーション、クラスタリング、TungstenやDolphinicsなどのサードパーティツールについては読んだことがありますが、どのようなアクションが最適かわかりません。 お時間をいただきありがとうございます! KM
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.