データベースについてのそもそも論
先月のはじめのほうで、「リレーショナルデータベースとの上手な付き合い方」というタイトルで、2回発表をした。ひとつは「まべ☆てっく Vol.1」であり、もうひとつは「Hacker Tackle（ハカタクル？）」である。 「リレーショナルデータベースの開発・運用に纏わるもろもろの話をして欲しい」というような内容の話をしてくれないかという同じような依頼を、ちょうど2日違いのイベントで頂いた。9/8のまべ☆てっくと、9/10のHacker Tackleである。そうなると必然的に話す内容も、同じようなものになってくる。同じ人物（＝私）が話すのだから、テーマも同じで時期も同じであれば、内容が同じようなものになるのが自然である。もし違うものになってしまっているのであれば、片方はウソをついているということになるはずだ。今日は発表に使用したスライドを紹介しつつ、なぜデータベースを使うべきなのか（あるいは使う
MySQL 5.7の罠があなたを狙っている
31. レプリケーションスレーブに注意 (FIXED by 5.7.9) REPLICATION SLAVE権限の *他に* SELECT ON performance̲schema.* が必要 mysql> show slave statusG *************************** 1. row *************************** .. Last_IO_Errno: 1142 Last_IO_Error: The slave I/O thread stops becaus e a fatal error is encountered when it try to get the value of SE RVER_ID variable from master. Error: SELECT command denied to use r 'replic
Kibana + ElasticSearch + fluentd でDBスロークエリログなどを集計し表示したい - Tatsuya Takamura
最近、Fluentd + ElasticSearch + Kibana 3 の構成でお試し運用を始めました。 すると下記のような事をやりたくなったが Apache アクセスログをURL毎に集計したい DB スロークエリログをクエリ毎に集計したい 単純に文字列のフィールドで pie/bar チャートなどを利用すると、期待を打ち砕かれる（打ち砕かれた） ふむふむ、遅いクエリーには select, where, from が多いのか.... orz 見事に単語毎に集計されてしまった。 どうもトークナイズを止めるには ElasticSearch の multi field を利用するのが良さそう。（Solr で言うと copy field？） fluentd + ElasticSearch + Kibana + logstash フォーマットを下記の構成で利用する場合 fluentd のタグは m
データベースの内部動作を知る
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの？ Part 1：SQL文はどのように実行されるのか SQL実行までの
Not Only NoSQL!! 驚異的なまでにWRITE性能をスケールさせるSPIDERストレージエンジン
Webサービスでは、世界中からのトラフィックを捌く必要があるため、いくらチューニングしようとも一台のRDBMSでは捌ききることが出来ないのが常だ。MySQLは最初からマスター・スレーブ型のレプリケーション機能が搭載されており、スレーブをたくさんぶら下げることによって参照の負荷をスレーブに割り振るというスケールアウトによってその問題に対処してきた。スレーブによるスケールアウトは、参照（＝PV）が多いWebサイトと非常に相性が良く、幾多のWebサイトにおいて実績を作ってきているし、まだまだ利用されている。 しかしながら、サイトのトラフィックが劇的に増加してくるようになると、レプリケーションによる負荷分散では追いつかなくなってきた。そこで人々がとった選択肢は、memcachedを利用することである。memcachedはインメモリ型の高速なKVSであり、参照・更新性能はMySQLより格段に高い。M
Project Voldemort
Voldemort is a distributed key-value storage system Data is automatically replicated over multiple servers. Data is automatically partitioned so each server contains only a subset of the total data Server failure is handled transparently Pluggable serialization is supported to allow rich keys and values including lists and tuples with named fields, as well as to integrate with common serialization
DB設計の神ツール「ERMaster」なら、ここまでできる
DB設計の神ツール「ERMaster」なら、ここまでできる：ユカイ、ツーカイ、カイハツ環境！（11）（1/3 ページ） 無料のEclipseプラグイン「ERMaster」とは データベースのテーブル設計を行うときに皆さんは、どのようにしているでしょうか？ いくつかの無料で利用できるツールが提供されているので、筆者はそれらを利用していましたが、最近「ERMaster」と呼ばれるEclipseプラグインの存在を知りました。 ERMasterは、ほかのツールに比べ、直感的で分かりやすいUI（ユーザーインターフェイス）に、カスタマイズ可能な、Excelで出力できるテーブル定義書、辞書機能など痒いところに手が届くERモデリングのツールです。本稿では、このERMasterについてご紹介します。 ERMasterの主な特徴、8つ ERMasterには、主に次のような特徴があります。 【1】直感的で使いや
分散Key-Valueストア「kumofs」を公開しました！ - Blog by Sadayuki Furuhashi
分散Key-Valueストア kumofs を、本日オープンソースソフトウェアとしてリリースしました！ kumofs@SourceForge kumofs関連資料まとめ kumofsとは？ kumofs（クモエフエス）は、実用性を重視した分散データストアです。レプリケーション機能を備え、一部のサーバーに障害が発生しても動作し続けます。単体でも高い性能を持ちながら、サーバーを追加することで読み・書き両方の性能が向上する特徴を持ち、低コストで極めて高速なストレージシステムを構築・運用できます。 kumofsの大きな特徴は、システムの構成の簡単に変更できる点です。システムを止めることなく、簡単な手順でサーバーを追加したり復旧したりできます。アプリケーションには一切影響を与えません。 またkumofsは、広く利用されている分散キャッシュシステムの「memcached」と互換性のあるプロトコルを実装
PostgreSQLで半角カナを全角カナに変換する関数 | dTblog | デザインとプログラムの境界をさまようブログ
半角カナでの登録を拒否するために、自動で全角カナに変換したいときってあるじゃないですか。アプリケーション側で、AOPやFilterといった仕組みで変換してあげる方がスマートだと思ってるんだけど、DB側でやらないといけないケースもあるでしょう。 ということで、こんな関数を用意してみました。 CREATE OR REPLACE FUNCTION h2z_kana(text) RETURNS text AS $BODY$ DECLARE zenkaku alias FOR $1; result text; i int; zt varchar[] = ARRAY['ガ', 'ギ', 'グ', 'ゲ', 'ゴ', 'ザ', 'ジ', 'ズ', 'ゼ', 'ゾ', 'ダ', 'ヂ', 'ヅ', 'デ', 'ド', 'バ', 'ビ', 'ブ', 'ベ', 'ボ', 'パ', 'ピ', 'プ', 'ペ',
カラムナデータベース（列指向データベース）とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること
カラムナデータベース（列指向データベース）とデータベースの圧縮機能について、マイケル・ストーンブレイカー氏が語っていること データベースの高速化技術の1つに、データの圧縮があります。データを圧縮して扱うことでディスクアクセスとI/Oが減少し、データへのアクセス速度が向上するのです。最近のCPUコア数の増大やメモリ単価の下落はデータ圧縮と伸長にかかるオーバーヘッドのコストを相対的に小さくしており、それもこの技術に有利に働いています。 Ingresの開発者であり、InformixのCTOなどデータベースベンダの要職を歴任、データベース研究者として大御所ともいえるマイケル・ストーンブレイカー氏が、データベースにおけるこのデータ圧縮と伸長処理について、ブログ「The Database Column」のエントリ「"Just in Time" Decompression in Analytic Dat
Ywcafe.net
Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy
最短かつ最速にアクセスする「DB高速化技術」（前編）：ITpro
ポイント ・高度なインデックスやジョインを利用し，最短経路でデータにアクセス ・メモリー不足を自律的に解消し，キャッシュのヒット率を高める ・インメモリーDBは全データをメモリーで処理し，高速化を図る 目的地に早く到着したいなら，最短の経路を最速で行けばよい。これはデータベース（DB）でも同様だ（図1）。インデックスなどを使ってデータへの最短経路を見つけ，メモリー・アクセスを増やして，最速でたどり着く。DBにはそんな技術が詰まっている。 図1●データベース高速化技術のポイント ビットマップ・インデックスなどを使い、データにたどり着く最短の道を選ぶ。また、できるだけメモリーにデータをキャッシュさせておくことで、アクセスのスピードを上げる、という二つのポイントがある [画像のクリックで拡大表示] 以下では，（1）データにたどり着く最短の道を選ぶ仕組みと，（2）アクセスのスピードを上げる仕組みの
「MySQL，PostgreSQLとFirebirdの性能をユーザー会メンバーが徹底比較，判明...
「更新とJOINが多ければMySQL，シンプルなSELECT主体ならPostgreSQLが向いている。ストアド・プロシージャでシングル・コネクションならFirebirdは非常に速い」---6月23日に開催された「オープンソースカンファレンス2007.DB（OSC2007.DB）」で，各オープンソースDBのコミュニティのメンバーによる性能比較が披露され，従来の一般的なイメージとは異なる“意外な結果”が明らかにされた。 オープンソースカンファレンスは，オープンソース関連コミュニティが主催するイベントで，OSC2007.DBはデータベース関連のコミュニティが集まったイベントである。性能比較セッションを担当したのは，日本MySQLユーザ会の堤井泰志氏，日本PostgreSQLユーザ会の片岡裕生氏，Firebird日本ユーザー会の木村明治氏。「あくまでボランティアによる性能比較であって，最速，最新マ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設定ファイル無しで手軽・シンプルに使えるJava O/Rマッパー ICIQLの使い方 : NETBUFFALO
scalaquery-examples/src/main/scala/org/scalaquery/examples/FirstExample.scala at master · szeiger/scalaquery-examples
導入 - DSN
PostGIS Manual