タグ

databaseに関するLeighのブックマーク (53)

  • MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記

    いちいさんにお誘いいただいて、勉強会で発表をすることになりました。 InnoDB Deep Talk #1 : ATND おそらく初見では内容が難しいと思いますので、先に資料を公開しておきます。 プレゼンテーション資料 (PDF) テストデータ生成スクリプト (JdbcRunnerで利用します。) プレゼンテーション資料からリンクしているウェブサイトの一覧です。 MySQL Bugs: #64567: Last_query_cost is not updated when executing an unique key lookup Understanding and Control of MySQL Query Optimizer: Traditional and Novel Tools and Techniques: MySQL Conference & Expo 2009 - O'R

    MySQL SQLオプティマイザのコスト計算アルゴリズム - SH2の日記
  • 「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog

    このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー(後述)を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH

    「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
  • MySQLにおけるJOINのチューニングの定石

    EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

    MySQLにおけるJOINのチューニングの定石
  • Neo4j -- or why graph dbs kick ass

    A presentation of the Neo4j graph database given at QCon SF 2008. It describes why relational databases are increasingly unfit for many applications today and why graphs may be a good fit. It also covers the fundamentals of how to program with Neo4j.Read less

    Neo4j -- or why graph dbs kick ass
  • neo4j open source nosql graph database

    NODES 2024 Online Developer Conference | November 7, 2024 | Save the Date

    neo4j open source nosql graph database
    Leigh
    Leigh 2011/07/24
    グラフデータベース
  • 「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜

    The document discusses graph databases and their properties. Graph databases are structured to store graph-based data by using nodes and edges to represent entities and their relationships. They are well-suited for applications with complex relationships between entities that can be modeled as graphs, such as social networks. Key graph database technologies mentioned include Neo4j, OrientDB, and T

    「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜
    Leigh
    Leigh 2011/07/23
    これか。#DSIRNLP
  • DBサーバーの負荷分散

    MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する

  • FacebookがHBaseを大規模リアルタイム処理に利用している理由(前編)

    Facebookは大規模なデータ処理の基盤としてHBaseを利用しています。なぜFacebookはHBaseを用いているのか、どのように利用しているのでしょうか? 7月1日に都内で行われた勉強会で、Facebookのソフトウェアエンジニアであるジョナサン・グレイ(Jonathan Gray)氏による解説が行われました。 解説はほぼスライドの内容そのままでした。当日使われた日語訳されたスライドが公開されているので、ポイントとなるページを紹介しましょう。 Realtime Apache Hadoop at Facebook なぜリアルタイムデータの分析に、Hadoop/HBaseを使うのか? MySQLは安定しているが、分散システムとして設計されておらず、サイズにも上限がある。一方、Hadoopはスケーラブルだがプログラミングが難しく、ランダムな書き込みや読み込みに向いていない。 Faceb

    FacebookがHBaseを大規模リアルタイム処理に利用している理由(前編)
  • データベースの内部動作を知る

    SQLのプログラミングは奥が深い。特にパフォーマンスの観点から、そう言えるだろう。 みなさんご承知の通り、同じ結果を出すプログラムでも、SQLの書き方次第で処理時間に何倍もの差が生じ得る。効率の悪いSQLを書いてしまう原因は、多くの場合、リレーショナルデータベースの内部動作やアプリケーションに関する理解不足である。両者をよく知った上で最適なSQLを書けるようになることは、システムエンジニアとしての重要なスキルの一つである。 特集『基礎から理解するデータベースのしくみ』では、リレーショナルデータベースの内部動作について、基的な部分を分かりやすく解説している。SQLプログラミングに役立つことはもちろん、SQLチューニングやデータベース設計のための基礎知識としても不可欠だ。 イントロダクション ブラックボックスのままでいいの? Part 1:SQL文はどのように実行されるのか SQL実行までの

    データベースの内部動作を知る
  • アプリ開発者よりのDB勉強会をやりたい、というかやる - 分け入ってもコード

    結論 SQLがどーのデータの持ち方がこーのというアプリ開発側の話題がメインのDB勉強会をやりたいからやるよという話 以下補足 コンテンツ アプリ開発者がDBを握らなければならない時代 DBを握るということ 勉強会について アプリ開発者がDBを握らなければならない時代 データ爆発の時代 データ爆発の時代がくると言われて久しいです。扱うデータの量が増えてきているだけでなく、データの構造も多種多様になってきていると感じています。これまではOne Size Fits AllでRDBが対応してきたのが、増加し複雑化していくデータにRDBのみでは対応しきれなくなってきている為にNoSQLのようなプロダクトが盛んに開発され利用されています。 アプリ開発者としてやるべきこと そういった時代を迎えるにあたって、アプリ開発者は何も備えなくていいんでしょうか?DBはインフラ/サーバーエンジニアのもの? 僕は「D

    アプリ開発者よりのDB勉強会をやりたい、というかやる - 分け入ってもコード
  • O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して

    一般的な業務アプリケーションではデータを永続化するために、RDBMS(関係データベース管理システム)を利用します。RDBMSでは大量のデータを効率的に検索したり、集約してレポートを作ったりすることが得意ですし、一般的に業務システムで求められるトランザクションのACID特性*1を満たすことも容易です。また、適切にテーブル設計の正規化を行うことにより、運用面においてデータの管理コストを下げることもできます。最近ではスケーラビリティの問題などもあり、RDBMS以外のデータベースについても注目されるようになってきていますが、今後も業務アプリケーションの主流としてRDBMSは使われていくだろうと思われます。 従って、Javaなどのオブジェクト指向言語で開発を行い、DDDのようなオブジェクト指向の設計技法を利用する場合に必ず考えなくてはならない問題は、オブジェクト指向と関係モデルとのインピーダンスダン

    O/Rマッピングで緩和されるインピーダンスミスマッチには静的と動的の側面がある - 達人プログラマーを目指して
  • ドキュメント指向データベースと列指向データベース

    ドキュメント指向データベースの概要 リレーショナルデータベースでは、データを表形式で保存します。そのため、表にしやすいデータであれば、効率よく管理することができます。 しかし、世の中全てのデータを表にできるかと言えば、そうではありません。そのようなデータをリレーショナルデータベースで管理しようとすると、どうしても無理が生じてしまいます。その結果、プログラムを組むのが難しくなったり、処理に時間がかかるようになったりしてしまいます。 このような中で、柔軟な構造でデータを扱えるようなデータベースとして、「ドキュメント指向データベース」と呼ばれるデータベースが出てきました。 ドキュメント指向データベースでは、1件分のデータを「ドキュメント」と呼びます。また、個々のドキュメントのデータ構造は自由で、データを追加する都度変えることができます(図1)。リレーショナルデータベースとは違って、事前にテーブル

  • 「優れたMySQL DBAを見分ける27+3の質問」に対する回答例

    随分と更新が空いてしまったが、「優れたMySQL DBAを見分ける27+3の質問」に対する回答例(漢バージョン)を紹介しよう。実は質問を掲載した際「難しい!」というコメントが非常に多く、もう少し易しい質問にするべきだったかと思って次のように呟いてみたのだが・・・ 非常に心強くて安心した。さすがに日を代表するMySQLのエキスパートである。出題のレベルは間違ってはいなかった!! そんなわけで、回答の方に移ろう。 MySQLのサーバープロセスはいくつある?ひとつ。mysqldはシングルプロセス・マルチスレッドモデルを採用しているので、"サーバー"プロセスはひとつである。多くの場合、Linuxなどでmysqldを動かす場合には、お供にmysqld_safeも常に動いていることが多いが、mysqld_safeはサーバーではなく、mysqldのためのラッパーであるので数には含めない。 rootユー

    「優れたMySQL DBAを見分ける27+3の質問」に対する回答例
  • 開発メモ: IndexDB: 転置インデックスのためのDB

    大震災の時分に何だが、Kyoto Cabinetベースで検索エンジンの核となる転置インデックスを作るのに適したDBを実装したという話。 転置インデックスとappend操作 多くの検索エンジンの核となる転置インデックスとは、検索語に一致する表現がどこに出てきたかという位置情報のリストを保持するものであり、検索語をキーとして位置情報リストを値とする連想配列である(転置インデックスを使わない検索エンジンもあるが)。この位置情報リストをposting listとか呼んだりするらしい。転置インデックスにもいくつか流儀があり、検索語をどのように切り分けるかで単語(分かち書き)方式とか文字N-gram方式とか呼ばれるものがあったりするが、いずれにせよ、小さいキーと、非常にでかい値を保持する連想配列を作ることには変わりない。 で、素朴に転置インデックスを作ろうとすると、検索対象の文書を解析しながら、得られ

  • SQLite Database Speed Comparison

    Leigh
    Leigh 2011/04/06
    SQLiteの速度比較。意外と遅くない。しかし、Mysql速いな。
  • https://blogs.oracle.com/oracle4engineer/post/column/technical/026176.html

  • Fast fulltext search for all languages on MySQL

    About Mroonga Mroonga is a storage engine for MySQL. It provides fast fulltext search feature for all languages including Chinese, Japanese and Korean to all MySQL users. Mroonga was called Groonga storage engine. Characteristic The latest release 14.12 is the latest release. It had been released at 2024-12-25. Install The latest posts Mroonga 14.12 has been released! (2024-12-25) Mroonga 14.10 ha

    Fast fulltext search for all languages on MySQL
    Leigh
    Leigh 2011/03/30
    いつのまにかMysqlの前文検索エンジンのsennaがgroongaになってた。パッチではなく、一つのストレージエンジンとして動作するとのこと。
  • cl.pocari.org - 拡張され続ける InnoDB のデータファイルのサイズを小さくする方法

    拡張され続ける InnoDB のデータファイルのサイズを小さくする方法 2006-07-07-2: [MySQL] MySQL でトランザクションを可能にするストレージエンジンとして InnoDB があります. InnoDB のデータファイルは,MyISAM テーブルと異なって,デフォルトでは ibdata1 というファイルにデータが蓄積されていくとこになります. MySQL の datadir に自動拡張する 10 MB の ibdata1 ファイルが 1 つと、5 MB の ib_logfile ログファイルが 2 つ作成されます - 7.5.3. InnoDB 起動オプション http://dev.mysql.com/doc/refman/4.1/ja/innodb-start.html この ibdata1 は,大量のデータを追加していくと,自動的にサイズを拡張していきます. ただ

    Leigh
    Leigh 2011/03/27
    InnoDBのデータファイルはすぐ大きくなってしまうんだよな。
  • クラウドに最適化したMySQLのフォーク「Drizzle」が正式版公開

    MySQLからフォークし、クラウド用途に最適化して開発された「Drizzle」が3月15日に最初の正式版を公開しました。 MySQLはよく知られたオープンソースのリレーショナルデータベースです。そのMySQLを、トランザクション機能を維持したままクラウドのような大規模分散環境での並列処理とマルチコアCPUに最適化したのが「Drizzle」です。 多くのWebサービスのバックエンドでは、高速なデータベース処理を実現するために多数のMySQLサーバを用いた分散処理をしていますが、Drizzleではそうした用途に特化して設計されています。 NoSQLに対するSQLからの回答 Drizzleは、大規模なWebサービスのバックエンドデータベースとして利用することを想定しているため、Web系サービスのバックエンドとしてはほとんど使われないだろう機能が省かれています。例えば、ACL(アクセス制御リスト)

    クラウドに最適化したMySQLのフォーク「Drizzle」が正式版公開
  • 優れたMySQL DBAを見分ける27+3の質問

    「優れたPerlプログラマを見分ける27の質問」の日語訳というエントリが人気だったので、MySQL版をやってみた。題して、「優れたMySQL DBAを見分ける27+3の質問(漢バージョン)」。腕に覚えのある人はぜひ試してみて欲しい。 MySQLのサーバープロセスはいくつある? rootユーザーのパスワードを忘れたときの回復手順 MySQLをオンラインバックアップする方法を3つ。(もっとでも可) InnoDBのデータファイルが作成可能な場所はどこか。 InnoDBのデフォルトの分離レベルは? ネクストキーロックについて説明せよ。 ロールバックセグメントにはどのようなデータが格納されるか? InnoDBでデッドロックが発生したときの挙動、および詳細な状態を確認する方法。 MyISAMがサポートしている特殊なインデックス2つ。 MySQLにおけるテーブル1行あたりの最大サイズ。 構成可能なレプ

    優れたMySQL DBAを見分ける27+3の質問