xRef - Database$ sqlplus $ sqlplus myuser@myhost $ sqlplus myuser/xxxxx@myhost $ sqlplus myuser/xxxxx@myhost/xe
第4回 RDBMSマジック、インデックス（2） | gihyo.jp
前回から間が空いてしまいましたが、ペースを上げての第4回です。前回からの続きでインデックスを扱います。その中でも特に、手品の種の部分にあたるインデックスのアルゴリズムに焦点を当てます。難しい話になるのではと心配されるかもしれませんが、大丈夫です。ここではアルゴリズムの特徴と特性を理解していただくのが目的で、その詳細についての難しい話はありません。ここで読んでいる皆さんはDBMSの開発者ではなく使用者でしょうから、特徴・特性をふまえてどのような使い方をするべきかを学んでください。 利用されるアルゴリズム まずは、実際にどのようなアルゴリズムがどのくらい使われているか、というのを以下に示します。 この図はあくまでもイメージです。しかし、B-Treeのみが圧倒的に使われているというのは本当に現実です。確かに、インデックス作成時に標準のままアルゴリズムをなにも指定しない場合、B-Treeで作られる
AmazonEC2＋Postgres-XCでDBクラスタリングを試してみる。 - Taste of Tech Topics
こんにちは。上田です。 最近DBクラスタリング周りの構築パターンとして、 AmazonEC2＋Postgres-XCを試してみたので、 その辺のところを書いてみようと思います。 プロジェクトでも分散環境の構築を行うことはありますが、 分散環境の構築は色々面倒な印象が強いです。 特に ・検証するのに複数マシンを確保しなければいけない。 ・分散環境の管理システムの設定に癖があり設定が大変。 そこで、 ・複数マシンリソースを簡単に確保 →AmazonEC2 ・DBクラスタリングを簡単に実現(すると私が思い込んでいる) →Postgres-XC を試してみることにしました。 構成は以下をイメージ。 Postgres-XC1.0.1の構成要素として以下を構築します。 gtm:各ノードのtransaction/タプル管理用 gtm_proxy：gtm通信用 coordinator：アプリケーションイン
PostgreSQL columnar store benchmarks on SSDs
POSETTE 2025 is a wrap! 🎁 Thanks for joining the fun. Missed it? Watch all 42 talks online. In April we released cstore_fdw, the first columnar store foreign data wrapper for PostgreSQL. Our initial blog post received lots of interest in cstore_fdw but also lots of questions. In this blog post we're going to attempt to answer some of the more common performance related questions: How much disk sp
フルパワーで加速するGPUの咆哮を聞け!最先端GPUでPostgreSQLを20倍高速化!?:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
GPUってあるだろ? グラフィックス・プロセッシング・ユニット。 コンピュータの中で最も高速な部品はなんといってもGPUだ。 たとえばnViditaの最新SoCであるTegra K1。 CPU部は単精度で73.6ギガFLOPS(フロップス)、だがGPU部は364.8ギガFLOPSだ。 これが30万円する最新のGPUボード、GeForce GTX TITAN Zになると、なんとびっくり、8テラFLOPSだ。 これはIntelの最高級IA-64チップ、Xeon ES-2687Wの198.4ギガFLOPSを大きく上回る。 Core i7は92ギガFLOPSに過ぎない。 ちなみにかつて数億円したスーパーコンピュータ、Cray-2はわずか1.9ギガFLOPSに過ぎず、今のコンピュータがどれだけ速いか窺い知れる。JAMSTECの地球シミュレータは131テラFLOPSだが、追いつかれるのは時間の問題だろ
Docker 1.0 でDBを動かすときの共有メモリの設定 - 技術野郎の復習
Docker長らくブログ書いてなかったので、どうでもいい話をちょっと書こう。Blue-Greenでチヤホヤされる運命のDockerで、DBを動かすという需要はあんまりないとは思いますが、コンテナでDBを動かすというのもそれはまた一興です。DBを動かすとなると共有メモリをたくさん使うことになるかと思います。そういう共有メモリの設定に関して、バージョン1.0が出てからいままでのやり方が通用しなくなったので、それについて書きます。これまでこれまで、僕はDockerでPostgreSQLコンテナを動かすとき、まずコンテナ内で起動スクリプト的なシェルを実行するようにしていました。そのなかで、以下のようにカーネルパラメータshmmaxの値を大きくしていました。 sysctl -w kernel.shmmax=4418740224 なぜならコンテナ内のshmmaxの値がなぜか小さく設定されているために、
FreeBSD、PostgreSQL性能を最大36倍高速化
FreeBSDプロジェクトの開発者は6月28日(協定世界時)、「PostgreSQL/FreeBSD performance and scalability on a 40-core machine」において、40コア/80スレッドのマシンにおけるPostgreSQLの性能を最大で36倍ほど高速化するパッチを発表した。同パッチは現在も議論されており、FreeBSD 11.0-RELEASEやFreeBSD 10.1-RELEASEに取り込まれるものとみられる。 開発者はメニーコアマシンで動作するPostgreSQLの性能がスケールしないという指摘を受けて問題の調査を開始。分析を進めたところ、共有メモリに並列アクセスするタイミングで大量のコンテンションが発生していることを発見したと指摘。ほかにも改善の余地のあるキャッシュ利用、性能の悪いセマフォの利用、コンパイラの違いによるスケジューラコード
東大・喜連川研、地理空間DB「PostGIS」を100倍以上に高速化
東京大学生産技術研究所喜連川研究室がオープンソースソフトウエア（OSS）の地理空間データベース（DB）「PostGIS」に、喜連川優教授の研究チームが開発した「非順序型実行原理に基づく超高速DBエンジン技術」を実装し、従来に比べて処理速度を100倍以上高速化した。2014年7月9日に東京都内で開催する「FIRST喜連川プロジェクトの報告とビッグデータの今後に関するシンポジウム」で詳細を発表する。 PostGISはOSSのリレーショナルDBである「PostgreSQL」をベースにした地理空間DBである。PostGISに対して、非順序（アウト・オブ・オーダー）型実行原理に基づく超高速DBエンジン技術（非順序型DBエンジン技術）を適用することで、地図上の特定エリアにターゲットを絞って解析を行うようなクエリー処理が、従来に比べて100倍以上高速化したという。9日に開催するシンポジウムでは「渋谷にい
PostgreSQL High Availability/Scalability using HAProxy and PGBouncer
I have multiple PostgreSQL servers for a web application. Typically one master and multiple slaves in hot standby mode (asynchronous streaming replication). I use PGBouncer for connection pooling: one instance installed on each PG server (port 6432) connecting to database on localhost. I use transaction pool mode. In order to load-balance my read-only connections on slaves, I use HAProxy (v1.5) wi
PHPでデータベースに接続するときのまとめ - Qiita
【2021/10/15 追記】 この記事は更新が停止されています。現在では筆者の思想が変化している面もありますので，過去の記事として参考程度にご覧ください。PDO に関しては大きく変わっていない部分が多いとは思いますが， PHP 8.x 以降での動作保証はありません。 あらかじめ読んでおきたい記事 Qiita - 【PHP超入門】クラス～例外処理～PDOの基礎 by @7968 初心者がやりがちなミス 以下のどれかに1つでも当てはまるコードは見直す必要があります．付録にリンクを貼っておきましたので，「該当するかも？」という人はクリックして飛んで読んでください．太字にしてあるものは脆弱性に直結する危険度の高いものです． mysql_query などの非推奨関数を利用している SET NAMES あるいは SET CHARACTER SET などで文字コードを指定している そもそもデータベース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[B23] PostgreSQLのインデックス・チューニング by Tomonari Katsumata![[B23] PostgreSQLのインデックス・チューニング by Tomonari Katsumata](https://cdn-ak-scissors.b.st-hatena.com/image/square/3fc40c4e7746cfe2f400d0737ec5997275100d06/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fb23ntt-140624233630-phpapp02-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)