PostgreSQLカンファレンス2013 LightningTalk (2013-11-13: migr8.rbの設定箇所を若干修正) (2013-11-14: SQLite3での設定等を修正、「migr8.rb new --table=users」を追加)
Takayuki Shimizukawa @shimizukawa @masa_edw コネクションプールが無い場合、使い終わったコネクションが即解放されない(解放まで多少遅延する)ので実際に使っているコネクションの数より多く存在する。その分メモリを圧迫して効率が悪い。っていう話は聞いたことがあるよ(要出典 2013-09-04 09:27:28 ハイパーむとう @masa_edw @voluntas 現状で必要な状況は理解していますが、なぜそうなるのか理解していないということです。他にもたとえば、bitlyの呼び出しはコネクションプールを使うべきか?なぜ(べき、べきでない)のか?どういう要請でそうなのか?と言う問いに僕は答えられません。 2013-09-04 09:31:22
Tutorials: Learn SQL step by step 0 SELECT basics Some simple queries to get you started 1 SELECT name Some pattern matching queries 2 SELECT from World In which we query the World country profile table. 3 SELECT from Nobel Additional practice of the basic features using a table of Nobel Prize winners. 4 SELECT within SELECT In which we form queries using other queries. 5 SUM and COUNT In which we
平素よりQA@ITをご利用いただき、誠にありがとうございます。 QA@ITは「質問や回答を『共有』し『編集』していくことでベストなQAを蓄積できる、ITエンジニアのための問題解決コミュニティー」として約7年間運営をしてきました。これまでサービスを続けることができたのは、QA@ITのコンセプトに共感をいただき、適切な質問や回答をお寄せいただいた皆さまのご支援があったからこそと考えております。重ねて御礼申し上げます。 しかしながら、エンジニアの情報入手方法の多様化やQAサービス市場の状況、@ITの今後のメディア運営方針などを検討した結果、2020年2月28日(金)15:00をもちましてQA@ITのサービスを終了することにしました。 これまでご利用をいただきました皆さまには残念なお知らせとなり、誠に心苦しく思っております。何とぞ、ご理解をいただけますと幸いです。 QA@ITの7年間で皆さまの知識
@IT Database Expertフォーラムの連載「ゼロからのリレーショナルデータベース入門」の記事一覧です。まとめて読めるPDF「人気連載まとめ読み! @IT eBook(2):ゼロから分かるRDB入門 ~RDBとは?から特徴、設計、運用まで基礎知識を徹底解説~」もご覧ください。 ゼロからのリレーショナルデータベース入門(12): データベースサーバリプレイスの考え方 全12回の連載も今回で最終回です。手間暇かけて構築したデータベースサーバに必ず訪れる「リプレース」という作業について、移行計画を作成するに当たっての考え方と具体的な検討項目を説明します。【更新版】(2021/5/31) ゼロからのリレーショナルデータベース入門(11): データベースセキュリティの必要性とその対策 前回は、データベースシステムの安定稼働を実現するためのデータベースシステムの監視について説明しました。今回
「データベースはブラックボックス。どんなSQL文を投げたらどんな結果が返ってくるかさえ知っていればよい」---そう思っている人も多いかもしれません。 しかし,本物のソフトウエア・エンジニアを目指すのであれば,データベースが動く仕組みを学ぶことは避けて通れません。パフォーマンスなどに問題が生じたときどこから手を付けていいのか皆目見当がつかない,といった事態に陥りかねません。 市販のRDBMSの内部はかなり複雑ですが,基本的な部分を理解するのはそれほど難しくありません。この特集でデータベースの動く仕組みを理解してください。 イントロ ●ブラックボックスのままでいいの? 基礎から理解するデータベースのしくみ(1) Part1 ●SQL文はどのように実行されるのか 基礎から理解するデータベースのしくみ(2) 基礎から理解するデータベースのしくみ(3) 基礎から理解するデータベースのしくみ(4) 基
SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基本的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの
JMongoBrowserはマルチプラットフォームで動作するMongoDB管理ソフトウェア。 JMongoBrowserはWindows/Mac OSX/Linux用のフリーウェア。NoSQLの採用が増えてきた。メインで使う場合もあるが、今のところは補助にシステムで、特にNoSQLが有効に使える場面で採用することが多いようだ。 メイン画面 使われることが増えれば、自ずと管理インタフェースが必要になる。実際に登録されているデータを閲覧したり更新する、そのためのソフトウェアがJMongoBrowserだ。 JMongoBrowserはGUIアプリケーションとして提供されるのが利点と言える。サーバに接続し、DBを一覧したりコレクションを閲覧することができる。ドキュメントをアップデート、複製、削除することももちろん可能だ。コレクション自体の操作もできる。 クエリーウィンドウ さらにJSON/BSO
2006-09-11 近況 今月は貧乏なので慎しく暮らしている. 週末もひきこもりとしてオンラインの記事を読んで過ごすことに. ウェブを眺めているといいタイミングで Google の新作論文が出ていた. ありがとう, Google の中の人. これ. GFS, MapReduce, Sawzall とつづく Google インフラ N 部作の 4 章が幕をあげた. 実はデータベースも作ってるんだぜ, という話. BigTable という名前だけは以前から O'Reilly Radar などに登場していた. ようやく公式な文書があらわれた. BigTable は GFS をはじめとする Google インフラの上に作られた分散データベース. 少し変わったデータモデルと, 運用までワンセットのヘビーな実装を持つ. 実装の話もまあ面白いんだけれど, それよりデータモデルが印象的だった. 先にその
Hello, I’m Kristof, a human being like you, and an easy to work with, friendly guy. I've been a programmer, a consultant, CIO in startups, head of software development in government, and built two software companies. Some days I’m coding Golang in the guts of a system and other days I'm wearing a suit to help clients with their DevOps practices. While SQL databases are insanely useful tools, their
今回は、米Googleのクラウド環境に存在するデータベースBigtableとDatastoreサービスを紹介します。「巨大分散」という新たなデータベースの地平を切り開くためにどのような工夫をしているか、じっくり見ていきましょう。 「Bigtable」は、Googleの主要なサービスを支える独自の巨大分散データストアです*1。Bigtableは、2005年4月から本格的な運用(プロダクション利用)が開始されたもので、Googleの検索サービスをはじめ、Gmail、YouTube、Google Maps、Google日本語入力、そしてApp Engineなど、70以上のプロジェクトで利用されています。その規模は、数P(ペタ)バイト~数十Pバイトに達しているでしょう。 Bigtableは、Google検索サービスにおける膨大なコンテンツやインデックスを保持し、高速に検索するための専用データストア
RDBの復権はしばらくないと思う 最近目にしたのは、「これからRDBが十分速くなっていくので、memcachedに代わってRDBがまた使われるようになる」という意見。これはしばらくの間は無いんじゃないかと思う。全データがオンメモリだったとしても、KVSはRDBより一桁以上速い(Memcachedで100,000req/sec出せるマシンで、MySQLのpkeyによる単純なSELECTをした場合、10,000req/sec出るかどうか)。SQLパーサやらなんやらを捨てない限りこの速さには対抗できない。RDBには、1コネクション1スレッドというモデルが持つ、接続数がスケールしないという制約もある。 また、memcacheプロトコルは、get_multiが使える。get_multiを効果的に活用した場合、RDBとの差はさらに広がると思う。 RDBで大丈夫なアプリも Viewキャッシュが効果的なア
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く