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

nosql DBMSの大きな利点の1つは、より簡単にクラスタリングできることです。NoSQLを使用すると、さまざまなデータを格納する数百台の安価なマシンを作成して、一度にクエリを実行できます。 私の質問はこれです、なぜリレーショナルDBMSはmysqlやsqlサーバーのようにこれを行うことができないのですか？ベンダーが既存の製品でこれを行うための技術的な方法を理解していないだけなのか、それとも実現できないようにするリレーショナルモデルの問題がありますか？データ（キー/値、ドキュメントなど）を保存およびアクセスするNoSQLの方法で、これが本当に正しい場合、クラスタリングを容易にするのは何が素晴らしいですか？

88 clustering  nosql  scalability  relational-theory 

私は、各顧客に独自のデータベースを提供することを計画しているSaaSシステムをセットアップしています。システムは既に設定されているため、負荷が大きくなりすぎた場合に追加のサーバーに簡単にスケールアウトできます。数千、または数万の顧客を獲得したいと考えています。 ご質問 1つのSQL Serverで使用できる/する必要があるマイクロデータベースの数に実際的な制限はありますか？ サーバーのパフォーマンスに影響はありますか？ それぞれ100 MBのデータベースを10,000個、または1 TBのデータベースを1つ持つ方が良いでしょうか？ 追加情報 「マイクロデータベース」と言うとき、「マイクロ」という意味ではありません。私たちは数千の顧客を対象にしているので、個々のデータベースは合計データストレージの1000分の1以下になります。実際には、取得する使用量に応じて、各データベースは100MB程度になります。 10,000個のデータベースを使用する主な理由は、スケーラビリティのためです。事実、システムのV1には1つのデータベースがあり、DBが負荷のかかったときに不快な瞬間がありました。 CPU、メモリ、I / Oに負担をかけていました-上記のすべて。これらの問題を修正したにもかかわらず、ある時点で、世界で最高のインデックス作成を行っていても、望みどおりに成功した場合、すべてのデータを1つの大きなホンキンに入れることはできないことに気付きました'データベース。したがって、V2ではシャーディングを行っているため、複数のDBサーバー間で負荷を分散できます。 昨年、このシャードソリューションの開発に費やしました。サーバーごとに1つのライセンスですが、AzureでVMを使用しているので、とにかく面倒を見てくれます。疑問が生じた理由は、以前は大規模な機関にのみ提供し、各機関を独自に設定していたためです。私たちの次のビジネスは、ブラウザを持っている人なら誰でもサインアップして自分のデータベースを作成できるセルフサービスモデルです。彼らのデータベースは、大規模な機関よりもはるかに小さく、はるかに多くなります。 Azure SQL Database Elastic Poolsを試しました。パフォーマンスは非常に残念でした。そのため、通常のVMに切り替えました。

43 sql-server  scalability  azure-vm 

MySQLやPostgreSQLなどの非シャードリレーショナルデータベースのパフォーマンスは、10 TBを超えると「壊れる」と聞きました。 Netezza、Greenplum、Verticaなどでは思いつかないような制限が存在するのではないかと思いますが、これらの制限が定量化されている研究論文や正式なケーススタディに言及している人がいるかどうかを尋ねたいと思います。

43 mysql  postgresql  scalability 

データベースのコンテキストでは、NOSQLデータベースの利点の1つとして、水平方向の拡張性に出会いました。この用語はどういう意味ですか？ ウィキペディアのCouchDB ウィキペディアのNoSQL 垂直スケーリングと比較してどうですか？

23 nosql  terminology  couchdb  scalability 

ビッグデータの問題は、現在作成されている大量のデータを処理するためにリレーショナルデータベースを拡張できないことであることがしばしば繰り返されます。 しかし、Hadoopのようなビッグデータソリューションが拘束されないこれらのスケーラビリティの制限は何ですか？Oracle RAC、MySQLシャーディング、TeradataなどのMPP RDBMSがこれらの偉業を達成できないのはなぜですか？ 技術的な制限に興味があります-RDBMSのクラスタリングの経済的コストが法外に高くなる可能性があることを認識しています。

17 scalability 

Webアプリケーション用に複数のPostgreSQLサーバーがあります。通常、1つのマスターとホットスタンバイモードの複数のスレーブ（非同期ストリーミングレプリケーション）。 接続プーリングにPGBouncerを使用します：ローカルホスト上のデータベースに接続する各PGサーバー（ポート6432）にインストールされた1つのインスタンス。トランザクションプールモードを使用します。 スレーブ上の読み取り専用接続の負荷を分散するために、HAProxy（v1.5）を次のような設定で使用します： listen pgsql_pool 0.0.0.0:10001 mode tcp option pgsql-check user ha balance roundrobin server master 10.0.0.1:6432 check backup server slave1 10.0.0.2:6432 check server slave2 10.0.0.3:6432 check server slave3 10.0.0.4:6432 check したがって、私のWebアプリケーションはhaproxy（ポート10001）に接続します。これは、各PGスレーブ上に構成された複数のpgbouncerで接続を負荷分散します。 ここに私の現在のアーキテクチャの表現グラフがあります： これは次のように非常にうまく機能しますが、いくつかの実装がまったく異なることを認識しています。Webアプリケーションは、複数のPGサーバーで負荷分散するHAproxyに接続する単一のPGBouncerインスタンスに接続します。 最善のアプローチは何ですか？最初のもの（私の現在のもの）または2番目のものですか？あるソリューションが他のソリューションより優れている点はありますか？ ありがとう

17 postgresql  high-availability  scalability  pgbouncer  load-balancing 

Postgresがメカニズムのスケールをトリガーする方法 PostgreSQLを大規模にインストールしており、ログテーブルとTRIGGERを使用してイベントベースのシステムを実装しようとしています。 基本的に、UPDATE / INSERT / DELETE操作の通知を受け取る各テーブルにTRIGGERを作成します。このトリガーが起動されると、ログテーブルに新しい行を追加する（イベントをエンコードする）関数を実行し、その後、外部サービスからポーリングします。 Postgres TRIGGERを使用する前に、それらがどのようにスケーリングするかを知りたいと思います。単一のPostgresインストールでいくつのトリガーを作成できますか？クエリのパフォーマンスに影響しますか？これを試す前に誰かがしましたか？

14 postgresql  performance  query-performance  scalability 

各ページの読み込みで特定のユーザーの新しいメッセージの数をUIに配信するために呼び出される電子メールアプリケーションがあります。DBレベルでテストしているものにはいくつかのバリエーションがありますが、すべてストアドプロシージャコールによって抽象化されています。 私は、ブレークポイント（1秒あたりのリクエスト数）がどうなるかを確認するために、DBを強打しようとしています。 一言で言えば、このuserId、newMsgCountなどのテーブルとuserIdのクラスター化インデックスがあります。SQLは、1秒あたり数百または数千のこれらの応答を処理できる必要があります。遅れは私の.NETアプリだと思います。 SQLパフォーマンスに基づいてテスト結果を達成するために、これをどのように良いテストにすることができますか？ これには、ストアドプロシージャ名とパラメーターを指定してDBをパンドするツールがありますか？ DBが1分を返すことができるかどうかを見たいです。1秒あたり250応答。

14 sql-server  performance  performance-testing  testing  scalability 

必要な結果を生成するために、いくつかのテーブルをサブ選択ステートメントと一緒に結合する非常に大きなクエリを必要とする状況があります。 私の質問は、複数の小さなクエリを使用することを検討し、複数の呼び出しでDBにクエリを実行して論理演算をアプリケーション層に持ち込む必要がありますか？ たとえば、次のクエリを検討してください。 SELECT * FROM `users` WHERE `user_id` IN (SELECT f2.`friend_user_id` FROM `friends` AS f1 INNER JOIN `friends` AS f2 ON f1.`friend_user_id` = f2.`user_id` WHERE f2.`is_page` = 0 AND f1.`user_id` = "%1$d" AND f2.`friend_user_id` != "%1$d" AND f2.`friend_user_id` NOT IN (SELECT `friend_user_id` FROM `friends` WHERE `user_id` = "%1$d")) AND …

13 mysql  query-performance  join  scalability 

ユースケースを考えます： テナントデータはクロストークしてはいけません。あるテナントは別のテナントのデータを必要としません。 各テナントには、大量の履歴データが潜在的に含まれている可能性があります。 SQL ServerはAWS EC2インスタンスでホストされます。 各テナントは地理的に離れています。 PowerBI Embeddedなどのサードパーティの視覚化ツールを使用する意図があります。 データ量は時間とともに増加すると予想されます システムのコストには制約があります。 ソリューションは、24時間365日の実稼働DBAなしで保守可能でなければなりません。 ソリューションは水平方向にスケーリングできる必要があります。 テナントの総数は50未満です 推奨されるアーキテクチャは何ですか？このユースケースのリファレンス実装はありますか？多くの人がエンタープライズソフトウェア開発のためにすでにこの問題に直面していると思います。 これは、マルチテナントデータベースアーキテクチャで増加するテナントの処理とは異なる状況だと思います。その質問で言及されているユースケースは、より多くのテナントを扱っていますが、これは非常に少数の大きなテナントを持つこととは非常に異なります。ここで説明したアーキテクチャは、ここで解決策になる可能性があります。これは、私がもっと知りたいことです。

12 sql-server  database-design  sharding  scalability  multi-tenant 

夏に始めたい新しいプロジェクトのために、さまざまなデータベースタイプとDBMSを検討しています。 MySQLとpostgreSQLでシステムを構築しましたが、今ではデータベースに関する知識と経験を広げたいと思っています。 私のプロジェクトは一種のソーシャルネットワーク/知識の集合体です。（まだそれを説明する用語を開発していない）。 私が見てきた： Cassandra（独自の種類のクエリ言語を使用）; 機能が豊富なコンテンツと高性能なクエリ実行を実現するのに適しているようです。ただし、Java環境を使用する必要があるため、あまり熱心ではありません。Oracleとは何の関係もありません。 MongoDB（noSQLタイプのDBMS）; 優れたスケーラビリティ。ただし、ビジネス情報クエリなどの実績のあるSQL言語で既に利用可能なすべての機能を失います。 システムの要件： データテキスト、日付、時刻、xml、小さな整数、ブロブ、 構造/動作：正規化された3NF、非リアルタイム、リレーショナル、スケーラブル、堅牢 環境： unix / linux、JAVAなし、できればCで実行 私が研究すべき他のデータベースシステムを教えてくれないかと思っていました。 Object Relational Databasesも見てきましたが、PHPオブジェクト（PDO）で動作するというアイデアはとても気に入っていますが、パフォーマンスは少し悪いようです。 ここにDBAがいるので、あなたが操作したこれらのシステムに関するフィードバックをいただければ幸いです。 ありがとう

12 performance  database-recommendation  nosql  scalability 

Cassandraでは、数千を超える列ファミリーを持つことはお勧めしません。議論のために2,000としましょう。2,000を超えるタイプのデータを保持する必要がある場合、1つのアプローチは、複数の無関係なタイプのデータを各列ファミリーに分割することです。 たとえば、1つのCFにOrders、Invoices、およびCustomersを含めることができます。ただし、行キーが異なる場合（たとえば、オブジェクトタイプの接頭辞、つまり、1つのCFのキーにOrder|1234との両方を含めることができますCustomer|1234）。2番目のCFには、たとえば、Addresses、LineItems、およびOrde​​rTypeを含めることができます。このアプローチの基本的な実現可能性を考えると、それに対する実際的な制限は何ですか？たとえば、10,000種類すべてのオブジェクトを1つのCFに配置することの何が問題になっていますか？Cassandra wikiからわかる限り、CFのサイズに厳密な制限はありません。

10 scalability  cassandra 

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

9 postgresql  architecture  pgpool  scalability  connection-pooling 

私は、センサーアレイからの気象データを保存するソリューションを実装/再設計することを任されています。アレイは約40のタワーで構成され、それぞれに約10のセンサーがあり、未確定の時間（年）にわたって10秒間隔で大気条件をサンプリングします。このタスクのいくつかのアプリケーションと要件は次のとおりです。 タワー/センサー構成を管理および取得して、データ分析を理解します。 気象観測のためのセンサーまたは時間間隔によるデータ可視化。 モデルとセンサーのパフォーマンスを比較するために、信頼性のある永続的なデータリソース/データセットを顧客に提供します（必要な形式で配信するには、いくつかの後処理が必要になる場合があります）。 注：現在のソリューション（5つのタワーを備えた概念実証として実装）では、データをフラットファイル（1時間に1ファイル）として保存します。 これが将来的にビッグデータの問題になるかどうかは当初はわからなかったので、リレーショナルデータベースとNoSQLデータベースの両方についていくつかのソリューションを調査しましたが、データ管理の専門家ではないため、もう少しガイダンスが必要だと思います。 私が考えたソリューションの1つは、タワー、センサー、タイムスタンプでインデックスが付けられたリレーショナルデータベースにデータを保存し、日付でテーブルを分割することでした。 もう1つは、将来のスケーリングに基づいて、MongoDBなどのドキュメントタイプのNoSQLデータベースに保存し、現在のソリューションの構造を模倣することでした。 これらの良いアプローチのいずれかはありますか？そうでない場合、より良い/推奨されるソリューションは何ですか？また、現在のソリューションを再設計する必要があるでしょうか？フラットファイルを使用する理論的根拠は、リレーショナルデータベースはオーバーヘッドがかかりすぎると信じているということです。もしそうなら、これを回避する方法はありますか？

8 database-design  nosql  scalability 

「スケールアウトのためのレプリケーションの使用」を読んだ後、さまざまなクエリをさまざまなサーバーにルーティングする方法を教えてください。たとえば、SELECTスレーブとNON-SELECTマスターにルーティングする必要があります。私はロードバランサーとしてhaproxyを使用できると思いますが、haproxyのレベルでクエリを区別することはできないと思いましたか？さらに、誰かがマスターに直接到達したとします。マスターがこれがSELECTクエリであることを識別し、スレーブまたはロードバランサーに送信されるように表示するにはどうすればよいでしょうか。

8 mysql  replication  scalability