2週間ほど前に「インメモリデータベースがクラウド時代の主流になるという期待」というエントリを書きました。ハードディスクに代わり、メモリをデータベースの永続化手段とするインメモリデータベースは、超高速なアクセスとスケールアウトを実現する、クラウド時代のデータベースの主役になるのではないか、という内容です。 この記事に関して、TechVisorの栗原さんと次のようなやりとりをしました。 確かに、Oracle Real Application Cluster（以下、Oracle RAC）でデータベースが全部載るくらい十分にキャッシュ用のメモリを割り当てれば、メモリ上でデータベースを操作するインメモリデータベースと同じことではないのか、とも思います。 両者の違いは何かあるのでしょうか？ 調べてみることにしました。 インメモリデータベースは1000倍速い 調べてみるとすぐに、両者には明確な性能差があ
はじめに 検索エンジンと聞くと、みなさんは何を思い浮かべるでしょうか？ GoogleやYahoo!などの検索ページを思い浮かべる方がほとんどだと思います。近年は、それら企業の努力によって検索エンジンというものが非常に身近になり、私たちの生活に欠かせないものとなりつつあります。 しかし、検索エンジンと一言で言っても、上記のような一般の方々へのUI（ユーザインターフェース）を指す場合もあれば、そのUIの裏側（バックエンド）にあるシステムを指す場合もあります。 本連載では、Google,Yahoo!などを代表とする検索エンジンの裏側のしくみに着目し、検索エンジンというシステムのアーキテクチャやその内部で使われているデータ構造やアルゴリズムを、近年の手法や研究事例などを交えて解説していきたいと思っています。 検索エンジンとは 検索エンジンには、さまざまな種類があります。GoogleのWeb検索のよ
検索技術を使うなら知ってないと損する6つのこと～クックパッド、グリー、ぐるなび、CROOZは検索技術をどう使っているのか（1/2） - ＠IT
クックパッド、グリー、ぐるなび、CROOZは検索技術を どう使っているのか 有限会社オングス 杉山貴章 2012/2/9 2012年1月26日、CROOZ主催の勉強会「モーショノロジー2012 ＃1」が開催された。今回のテーマは「全文検索」。検索技術の開発や活用に携わる6名の発表者によって、検索エンジンの実装やプロダクトの活用事例などが紹介された。 全文検索の歴史とgroongaの索引構築の実装 ソーシャル連携などに広がるECサイトでの全文検索 KVSの膨大なKeyを見つけるための全文検索 groongaのRuby実装「rroonga」による検索サービス モバイルに欠かせない位置情報検索で使うgroonga レシピ検索のプロトタイピングにApache Solrを使う そもそも、「モーショノロジー」って何？ そもそも、「モーショノロジー」とは何だろうか。総合司会を務めたCROOZの小俣泰明氏
【グーグル創業者の論文要約】SEO対策の前に知っておきたいGoogle検索エンジンの仕組み - LITERALLY
Google検索エンジン初期の仕組みは論文で書かれている Googleの創業者はご存知の通り「ラリー・ペイジ」と「セルゲイ・ブリン」の２人である。 ２人はスタンフォード大学での博士課程在籍中に知り合い『検索エンジン』について共通の関心があったことから、1998年に共著で論文を執筆した。論文タイトルは『The Anatomy of a Large-Scale Hypertextual Web Search Engine（大規模なハイパーテキスト的なウェブ検索エンジンに関する解剖）』。 この論文では、Googleの検索エンジンのインデックスや検索順位決定のベースとなった考え方が詳しく解説されている。「こんなに載せてしまっていいの？」と不安になるレベルで詳しく書かれている。 SEO対策の前に論文を読んでおこう この論文は、スタンフォード大学の情報研究室のWebサイトから参照することができる。名論
今回から，全文検索システムの「Kabayaki」を紹介します。Kabayakiは，日本語文書用に作られた全文検索システムです。オープンソースの全文検索エンジン「Namazu」に対してWebブラウザで各種設定を可能にするなど，使いやすく改良したものです。 全文検索は，文書の全情報が検索対象となります。ファイル名や見出し，文書中の特定の要素に限定しません。また，ファイル内の文字列検索が単一ファイルを対象にしているのに対し，全文検索は複数の文書が対象となります。操作は，検索キーワードを入力し「検索」ボタンを押すのみです。 Kabayakiは誰でも簡単に使えることを目指して開発されています。“Namazuをおいしくする”という意味からKabayakiと名付けられました。Linux対応のKabayaki-1.0.0が2001年6月に公開され，2003年6月にはWindows版のKabayakiも発表
平民的プログラミングのススメ
■ [Comp] [Security] 自動quoteつきERBの実験 高木さんの日記で、 そうすると、「h」付きと「h」無しを逆にしたらよかったのにと思えてくる。 ということだったので、ERB を改造してサクッと作ってみた。 rerb。 とりあえず、h の意味を逆転させてしまうと（hを流用してしまうと）それはそれで 混乱すると思ってそれは避けたのだが、高木さんは「hの逆」を命名してくれなかったので、 とりあえず "raw html" ということで r を使った。何かいいアイディアはないものか。 ついでに、rerb-cgi という名前で起動された場合は CGI モジュールを内包して、 ローカル変数 cgi, header 経由で引数や出力ヘッダにアクセスできるようにしてみた。 そういうわけで、test.ehtml は (rerb-cgi という実行ファイルを用意すれば) 単独でcgiとして
転置インデックス - Wikipedia
転置インデックス（てんちインデックス、Inverted index）とは、全文検索を行う対象となる文書群から単語の位置情報を格納するための索引構造をいう。転置索引、転置ファイル、逆引き索引などとも呼ばれる。 情報処理テクノロジにおける転置インデックスとは、単語や数字といった内容から、それが含まれているデータベースやドキュメント群へのマッピングを保持するという、インデックス型データ構造である。ドキュメント群へのマッピングの場合、検索エンジンが実現される。転置インデックスファイルは、インデックスというよりはデータベースと呼んだほうがふさわしい場合もある。また、検索キーが単語（文字列）であり、連想配列の値が位置情報である場合、ハッシュテーブルの形態を取ることもある。 転置インデックスには大きく分けて2通りの手法がある。レコード単位転置インデックス（record level inverted in
Compressed Permuterm Index: キーワード辞書検索のための多機能＆省メモリなデータ構造 - Preferred Networks Research & Development
はじめましてこんにちわ。 4月からPFIで働いているまるまる（丸山）です。最近のマイブームはスダチです。 リサーチブログの更新が再開されたので、私も流れに乗って初ブログを書いてみようと思います。 今回は社内の情報検索輪講で少し話題にあがったCompressed Permuterm Indexを紹介したいと思います。 Paolo Ferragina and Rossano Venturini. “The compressed permuterm index”, ACM Transactions on Algorithms 7(1): 10 (2010). [pdf] これを実装したので以下のgoogle codeに晒してみることにします。 http://code.google.com/p/cpi00/ 修正BSDライセンスです。ソースコードは好きにしてもらって構いませんが、完成度はまだまだな
言語処理学会年次大会で文法圧縮チュートリアル講義をしてきました - Preferred Networks Research & Development
まるまるです。春がきてますね。東京はだいぶ暖かくなってきました。 先週（3/17〜3/20）行われた言語処理学会第２０回年次大会（NLP2014）において「文法圧縮入門：超高速テキスト処理のためのデータ圧縮」というタイトルでチュートリアル講義をさせて頂きました。 講義資料はSlideShareで公開しています。 文法圧縮とは、文字列を木構造に変換し、その木構造に含まれる冗長部分を文脈自由文法の生成規則として集約させて表現する圧縮法です。この圧縮法は近年の文字列アルゴリズム業界で注目を集めており、主に以下の様な特徴があります。 冗長度の高いデータ（例えばゲノム集合、バージョン管理文書、ウェブアーカイブなど）を効果的に圧縮できる。 圧縮したまま高速に検索処理などを行える（圧縮文字列処理）。 木構造などのデータ構造の圧縮にも使われる（圧縮データ構造）。 NLPとは直接結びつかない内容ですが、文字
はじめに 前回は、検索エンジンとはどういうもなのか？について簡単に触れました。今回は、システムとしての検索エンジンの概要を見ていきます。 検索エンジンの構成 検索エンジンは他のシステムと同様に、複数のコンポーネントから構成されています。ざっくり分けると以下のようなコンポーネントから構成されています（図1）。 索引構築部（Indexer, インデクサー） 検索部（Searcher, サーチャー） 索引（Index, インデックス） 図1 検索エンジンの構成 たった3つ？と思うかもしれませんが、これは大きな枠組みで分けているからです。もちろん、各コンポーネントは複数のサブコンポーネントから構成されていますので、実際はもう少し複雑になりますが、基本はこの構成となります。 次は、それぞれのコンポーネントで具体的に何を行っているかを見てみましょう。 各コンポーネントの概要 ●索引構築部（Inde
はじめに 前回までは、検索エンジンの概要を見てきました。今回からは、全文検索の中核となる索引構造について見ていきます。 第1回の復習になりますが、全文検索には主に2種類の方法がありました。検索したいデータに対して前処理をせず、検索時に文書を走査するgrep型と、あらかじめ索引を作っておいて検索時にその索引を利用する索引型です。今回から数回にわたり、索引型において最も普及している転置索引という索引構造について解説していきます。 転置索引とは さて、転置索引とは何なのでしょうか？ 身近な所で例にあげると、書籍（専門書など）の巻末にある索引は、本における転置索引といえます。巻末には通常、キーワード（単語）とそのキーワードが出てくるページが記載されています。キーワードはアイウエオ順やアルファベット順に並べられているので、探したいキーワードを簡単に見つけることができ、そのキーワードがどのページで言及
はじめに これまで、転置索引の構造や具体的なデータ構造を見てきました。今回は、検索したいテキスト文書から、どのようにこの構造を構築するかを説明していきます。 ディスクベースの構築方法 第3回では、表を作成しそれを転置させることで転置索引を構築しました。実際にコンピュータに処理をさせる場合も、メモリ上の2次元配列で同様に構築することが可能となります。しかし、通常の転置索引は非常に疎な表となるため、この方法ではメモリを使いすぎてしまいます。また、リンクリストなどのメモリ上でのデータ構造を用いることにより、上記の方法と比較して少ないメモリ量で構築することもできます。 これらの方法はいずれも、対象とする文書集合を変換した転置索引が実メモリに収まる場合にのみ可能となる方法となります。しかし多くの場合、転置索引は実メモリよりも大きくなります。そのような場合はディスクを用いた構築方法が必要となり、効率的
はじめに 前回までで、検索エンジンの基本となる仕組みの大枠は説明しました。 今回は、復習を兼ねてこれまでの連載全体を見ていき、検索エンジンを作る上で説明が足りなかった部分を補足していこうと思います。本連載では実際のコードはあまり載せられませんが、ぜひこの際に簡単な検索エンジンを作ってみることをお勧めします。 全体の構成 第2回で紹介した検索エンジンの構成をもう一度見てみましょう。 図1 検索エンジンの構成 検索エンジンは索引とその索引を構築する部分、そしてその索引を検索する部分の3つに分けられることを説明しました。本連載では、索引に関しては第3～6回、構築方法に関しては第7回、そして検索方法に関しては前回の第8回でそれぞれ説明してきました。各項目をとても足早に説明してきましたが、一応全部の要素がカバーされていますので、これまでの知識を使って簡単な検索エンジンを作ることはできてしまいます。
これはLINE Advent Calendar 2018の14日目の記事です。 LINEの上村です。今日は文字列です。 はじめに トライ (trie)は文字列の集合を索引化し高速な検索を可能にするデータ構造であり、領域効率や高速性を向上させた多様なアルゴリズムが提案され種々の実装が公開されています。 IPアドレスの検索、形態素解析器における辞書からの候補の列挙、キー入力時のオートコンプリートといった有益な応用があり、文字列業界以外でもご存知の方は多いかもしれません。 この記事で紹介するsftrieは簡単で効率よい新たなトライ表現とそのC++実装です。 主な特徴は以下の通りです: 大きなアルファベットをサポートします。また、いわゆるNULL文字も必要としないため、バイト列やASCIIコードからUnicode、単語等に割り振ったIDのような一般の整数まで、様々な値を文字型として扱えます ノード
第２回から３回目の参加。 http://atnd.org/events/9458 1.Lucene Revolution 参加報告 Basis Technology 平賀一昭 (日本支社)さま, 黒坂輝彦(サンフランシスコ支社)さま Lucene Revolutionとは Lucid Imagination社主催によるLucene/Solrに関するユーザ会議 Lucid Imagination社 LuceneとSolrの商用利用促進のために設立 コミッタが多数参加 エンジニア向けトレーニング Luceneのソースコードを確認しながら、理解する BASISさん主催 Solrアプリケーション開発３日間コース 「Solr勉強会で聞いた」で10% Off ! 本年度中に申し込みで20% Off! Lucene & Solr User Conferenceについて ハイアットハーバーサイド（ボストン
Lucene と Solr のスケーラビリティー | Lucid Imagination by Basis Technology
本記事は、Mark Miller 著「Scaling Lucene and Solr」の日本語訳である。 日本語訳 © 2011 Basis Technology 訳注：原典が書かれた2009年前半の時点では、Solr 1.4 は開発中であったため、単に Solr と書かれているものは、Solr 1.3 を指します。本記事の内容の一部は、Solr 1.4 またはそれ以降の版には適用できない可能性があることをご承知置き下さい。 目次 はじめに 単一サーバーの最適化 索引の管理 索引の最適化 メモリーの管理 クエリー スループットの最大化 JVM の設定 サーバーの他の機能 多量のクエリー Lucene のレプリケーション機能 Solr のレプリケーション機能 大規模な索引 分散 Lucene 分散 Solr 大規模の索引と大量のクエリー まとめ リンク集 はじめに Lucene は非常に複雑
「情報環境の変化に適切に対応する目録規則の在り方に関する研究」 最終更新：2014.2.14 科学研究費基盤研究（C)「情報環境の変化に適切に対応する目録規則の在り方に関する研究」に関わる情報を本ページにまとめます。 概要 ／ 最終報告書 ／ 実績報告 ／ 研究会記録 ／ 成果発表 ／ 連絡先 概要 種目・番号： 科学研究費基盤研究(C) 22500223 研究課題名： 情報環境の変化に適切に対応する目録規則の在り方に関する研究 研究年度： 平成22年度～平成24年度 研究代表者： 渡邊隆弘（帝塚山学院大学人間科学部） 研究分担者： 田窪直規（近畿大学短期大学部） 松井純子（大阪芸術大学芸術学部） 吉田暁史（大手前大学総合文化学部） 研谷紀夫（東京大学大学院情報学環→H24より関西大学総合情報学部） 和中幹雄（H24～ 大阪学院大学国際学部） 本研究は、目録規則（図書館の情報資源に関わるメ
多層トライの実験結果 - やた＠はてな日記
概要 ux-trie に影響されて，複数のトライを使った辞書の実験をしてみました．具体的には，「トライの数」，「TAIL の有無」，「ノード順序（ラベル順・頻度順）」を切り替えて，辞書のサイズや構築・検索にかかる時間を比較しました． 実験に使ったソースコードは公開するつもりですが，パッケージ化したり，ドキュメントを用意したり…ということを考えると，しばらく先になると思います． トライの数 トライの数というのは，辞書を構成するトライの数です．通常の辞書であれば，トライの数は 1 になります．ux-trie であれば，トライの数はデフォルトで 2 つになります． （追記 2010-12-24）トライを複数にすると，TAIL に相当する部分をトライとして持つことになります．トライが 2 つの場合，1 つ目のトライは TAIL を持たせたときのトライと同じになり，2 つ目のトライは TAIL に格
: 目次 目次 データベースシステム (後半) 市川 哲彦 平成13年12月8日 教科書: 北川 博之,「データベースシステム」, 昭晃堂, 1996. 注意: できるだけ教科書を活用しますが，必ずしも一致しません．予めご了承下さい． 講義予定: 全6回を予定で以下の内容を説明する予定です．それぞれのトピックス毎に SQ (short quiz) を出し，これに試験の結果を加味して成績を付けます． なお，時間の関係で適宜取捨選択をしますので，全部は話せないと思います． 予めご了承下さい． 1. 物理的データ格納方式 記憶媒体，ファイル構造，索引構造，SQL での索引指定方式 2. 問合せ最適化 問合せの実行プラン，経験的知識と式の等価姓による最適化， コストに基づく最適化 3. トランザクションの概念 トランザクション，ACID 特性，履歴(あるいはスケジュール)， 直列可能性 4. 同
画像2。配電網のスイッチ構成の例。この例は、変電所から同色の家庭に正しく給電できる配電網構成(スイッチのON/OFFの組合せ)の1つを表している。色のつかない(電気が届かない)家や、色の混ざった(異なる配電系統がつながれた)家が存在してはならない 停電などを回避し、適正な品質の電力を供給するためには、複雑な制約条件を満たさなければならない。しかし、林教授らが調査し公表している日本の実用規模の標準的な配電網モデルでは、制御可能なスイッチは468個に及び、その構成(組合せ)の総数は10進数で141桁の天文学的な数にのぼり、この中から制約条件を満たす最適な構成を探索することは非常に難しい問題となっている。 このため、従来は経験則(ヒューリスティック)に基づく手法によって、ごく一部の構成からなるべく良い構成を探索するに留まっており、制約条件を満たす構成が全部で何通りあるか、またその中のどの構成が最
ActiveRecord - takt@Wiki
Rails という非正統的パーシスタンス・フレームワークで必要となりそうな、重要な最適化のいくつかについて解説します。 スキーマに裏付けられたモデルを生成するのは簡単で、script/generate model model_name を使ってちょっとしたコードを生成するだけです。ご存じの通り、このコマンドは、モデルやマイグレーション、ユニット・テスト、さらにはデフォルトのフィクスチャーまで生成します。マイグレーションのいくつかのデータ列にデータを入力し、ちょっとしたテスト・データを入力し、テストをいくつか作成し、検証をいくつか追加し、そしてそれで終わり、というのは非常に魅力的です。しかし、注意しなければなりません。データベース全体の設計も考慮する必要があるのです。次のことを念頭に置いてください。 Rails によってデータベースの基本的なパフォーマンスの問題から解放されるわけではありませ
Lucene と Solr のスケーラビリティー | Lucid Imagination by Basis Technology
本記事は、Mark Miller 著「Scaling Lucene and Solr」の日本語訳である。 日本語訳 © 2011 Basis Technology 訳注：原典が書かれた2009年前半の時点では、Solr 1.4 は開発中であったため、単に Solr と書かれているものは、Solr 1.3 を指します。本記事の内容の一部は、Solr 1.4 またはそれ以降の版には適用できない可能性があることをご承知置き下さい。 目次 はじめに 単一サーバーの最適化 索引の管理 索引の最適化 メモリーの管理 クエリー スループットの最大化 JVM の設定 サーバーの他の機能 多量のクエリー Lucene のレプリケーション機能 Solr のレプリケーション機能 大規模な索引 分散 Lucene 分散 Solr 大規模の索引と大量のクエリー まとめ リンク集 はじめに Lucene は非常に複雑
使いやすいデジタル版のシソーラスがほしい 使いやすいシソーラスがあったら便利だと思っています。 シソーラスとは、類義語辞典のことです。「声高」「朗朗」「玲瓏」「絹を裂く」などが、同じようなジャンルとして並べられていて、文章を書く場合に、いろいろな言葉を探して、表現を豊かにするときに使います。 辞書モノの電子化は、電子書籍のなかでもひときわ相性がよく、すでにいろいろなシソーラスがあるのではないかと思うのですが、なにぶん使い慣れた紙の辞書に愛着があり、どうしたらうまくデジタル化できるか、と夢想し始めました。 ちなみに、インターネット上のシソーラス・サービスには、ざっと見たところで、次の3つがあるようです。 Weblio｜類語辞典＜シソーラス・同意語辞書・同義語辞典＞ 類語.jp 言語工学研究所類語辞書検索サイト 英和・英英・類義語辞典(シソーラス)・反対語辞典一括検索（英単語のみ） ひ
Linux/Unix/Open Source Software related Mailing-List Log http://MLog.euqset.org/ 試験運用中 [mysql 14353] Re: InnoDBテーブルのテーブルスペース容量計算 木下と申します。。。 私自身4.0以前は利用したことが無いので、正確な原因は分りませんが、 Data_lengthが見積もりよりもかなり大きくなってしまう主な原因は、 レコードを主キーに対してランダムな順番で挿入しているからだと思います。 InnoDBにおける表の構造は主キーの索引構造になっていますので、 ランダムな順番での挿入はフラグメンテーションが多発してしまい、 Data_lengthは無用に大きくなってしまいます。 また、挿入自体の性能も索引構造の更新やレコードの再配置なども伴うため、 良くありません。
Takeshi Yamada's page
IEEE: Senior Member, 電子情報通信学会: シニアメンバ 情報処理学会: 会員、ACM: Member IEEE Kansai Section: Technical Program Committee Chair (2009年〜2010年) (Past Chair: 2011年〜） 電子情報通信学会 和文論文誌Ｄ編集委員会 副委員長（2011年〜2012年） 電子情報通信学会 和文論文誌Ｄ編集委員会 幹事（2010年〜2011年） 電子情報通信学会 和文論文誌Ｄ編集委員会 委員（2007年〜2010年） 電子情報通信学会 人工知能と知識処理研究専門委員会 委員(1997年〜) 情報処理学会 関西支部 幹事 (2007年〜2008年) 電子情報通信学会 ソサイエティ誌編集委員会 査読委員（2003年〜2006年） 電子情報通信学会 査読委員（1999年〜） Tomoharu
<4D6963726F736F667420506F776572506F696E74202D2090B695A88A778CA48B868ED282CC82BD82DF82CC8FEE95F189C88A7793FC96E5205B8CDD8AB78382815B83685D>
生物学研究者のための情報科学入門 清水謙多郎 アグリバイオインフォマティクス人材養成プログラム バイオインフォマティクスリテラシーⅡ バイオインフォマティクス標準カリキュラム（情報科学の基礎） 大項目 内容（＝技術） 判別分析、クラスタ分析、重回帰分析、回帰木、正準相関分析、主成分分析、因子分析、独立成 分分析、次元縮小、共分散構造解析（構造方程式モデリング） 計算統計 マルコフ連鎖モンテカルロ(MCMC)法、ブートストラップ法、平均場近似、EM法、変分ベイズ法 統計モデル 情報幾何、グラフィカルモデル（ベイジアンネットワーク） 時系列解析 マルコフモデル、確率過程、生存時間解析 モデル選択 変数選択、情報量基準、交差検証法、ブートストラップ法 実験計画 実験計画法、分散分析、能動学習 情報理論と符号理論 情報理論、符号理論、データ圧縮、情報量基準、乱択アルゴリズム 数理計画法（線
索引構成表の概要 索引構成表のデータはBツリーの索引構造に主キー・ソート方式で格納される。索引構造の各リーフ・ブロックには、キー列と非キー列の両方が格納される。 利点 主キーに対して高速にランダム・アクセスできる。 主キーに対して高速にレンジ・アクセスできる。 索引構造以外に表記憶域がないため、新しい行の追加、行の更新、行の削除などにより表データを変更すると、索引構造の更新のみが実行される。 主キーの複製が回避されるため、記憶域の所要量を低く抑えられる。 索引構成表の機能 制約、トリガー（ヒップ表と共通） LOB列とオブジェクト列（ヒップ表と共通） パーティション化、パラレル操作、オンライン再編成（ヒップ表と共通） レプリケーション機能（ヒップ表と共通） キー圧縮 オーバーフロー記憶域と固有の列配置 ビットマップ索引を含めた2次索引 索引構成表の作成 構文 CREATE TABLE … O
Thesis.dvi
ISSN 0918-2802 Technical Report L 文字列索引法とその自然言語処理への応用 伊東 秀夫 TR00-0003 March Department of Computer Science Tokyo Institute of Technology ˆ Ookayama 2-12-1 Meguro Tokyo 152-8552, Japan http://www.cs.titech.ac.jp/ c The author(s) of this report reserves all the rights. 目次 第1章 序章 1 1 2 2 3 3 5 5 9 9 1.1 背景と目的 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 成果の概要 . . . . . . .
計算機科学 – String Matching 文字列照合 – Yoshitsugu Yamamoto 山本 芳嗣 3F1007 (029-853-5001), 3E410 (029-853-5395) yamamoto@sk.tsukuba.ac.jp revised January 2006 T [s + 1..s + m] P [1.. m] s+1s s+m T 1 1 定義 Σ：finite alphabet 有限アルファベット、Σ = {0, 1}, {0, 1, 2, . . . , 9}, {a, b, c, . . . , z} Σ∗ ：set of all finite length strings of characters in Σ、アルファベットの有限長さの列の全体 T = T[1..n] ∈ Σ∗ ：text、テキスト P = P[1..m] ∈ Σ∗ ：patt
データ・ウェアハウスのメンテナンス
15 データ・ウェアハウスのメンテナンス この章では、データ・ウェアハウスのロードおよびリフレッシュ方法について説明します。内容は次のとおりです。 パーティション化によるデータ・ウェアハウス・リフレッシュの改善 リフレッシュ中のDML操作の最適化 マテリアライズド・ビューのリフレッシュ パーティション表付きマテリアライズド・ビューの使用 パーティション化によるデータ・ウェアハウス・リフレッシュの改善 ETL（抽出、変換、ロード）がスケジュールに基づいて実行され、オリジナルのソース・システムに対して行われた変更が反映されます。このステップ中に、新しいクリーン・データを本番データ・ウェアハウス・スキーマに物理的に挿入し、この新しいデータがエンド・ユーザーにも利用できるように、必要に応じてその他のステップ（索引の作成、制約の妥当性チェック、データのバックアップ作成など）をすべて実行します。このデ
Oracle Databaseパフォーマンスチューニング入門者向けの資料 - kitayama_t's blog
初心者向けの資料をまとめてみます。Wiki的に随時更新が入る予定です(と書いてみた)。 【セミナー動画/資料】今さら聞けない!? パフォーマンス・チューニング入門 PDF資料：http://www.oracle.com/technetwork/jp/content/091210tuning-beginner-250541-ja.pdf パフォーマンス・チューニングとは ボトルネック箇所の特定 代表的なチューニング項目 / メモリ割り当てのチューニング、ディスクI/Oのチューニング、SQL文のチューニング 【セミナー動画/資料】実践!! パフォーマンス・チューニング 〜Statspack解析〜 PDF資料：http://www.oracle.com/technetwork/jp/content/20100728statspack-tips-251843-ja.pdf Statspack とは
修士論文 メモリ上の転置索引による 高速全文検索システムに関する研究 A Study on High Throughput Query Processing using Inverted Index on Main Memory 渡辺 健太郎 東京大学大学院 情報理工学系研究
修士論文 メモリ上の転置索引による 高速全文検索システムに関する研究 A Study on High Throughput Query Processing using Inverted Index on Main Memory 渡辺 健太郎 東京大学大学院 情報理工学系研究科 電子情報学専攻 指導教員 安達 淳 2011 年 2 月 9 日提出 i 概要 メモリサイズが増大し低価格化が進んだことから，メモリ上でのデータベース の運用は珍しいものではなくなった．そのようなシステムではかつてのディスク I/O ではなく，プロセッサやメインメモリのリソースがボトルネックとなる．本研 究では，転置索引を用いた全文検索システムをメモリ上で運用することを前提に， 圧縮データ構造の処理効率を改善することを検討する．多くの圧縮スキームにお いて重要な要素技術である Prefix Sum 処理
postgresql の gin インデックスについてメモっておく。 - たなかれいなとあややとおっぱい。
最近、pgsql-jp のメーリングリストで、gin インデックスを使って、xml の中から高速に値を取り出す例が示されていました。 恥ずかしながら、btree はともかくとして、gin ってなんだ？と思ったのでググってみた。 http://neta.ywcafe.net/000800.html ほうほう、要は、配列に対してよく効くインデックスらしい。 でも、これだけだと何となくわかった気がするだけでうまく活用できなさそうなのでちゃんと調べてみた。 http://www.postgresql.jp/document/current/html/indexes-types.html GINは転置インデックスであり、例えば配列など複数のキーを持つ値を扱うことができます。 GiST同様、GINも多くの異なるユーザ定義のインデックス戦略を持つことができ、GINが使用できる具体的な演算子はインデックス
sub usuilog;
今年も去年に引き続きgihyo.jpのレポータとして参加させていただきました。下記公開されていますので是非ブクマなどしていただけると嬉しいです。 前夜祭: http://gihyo.jp/news/report/01/yapcasia2014/0000 1日目: http://gihyo.jp/news/report/01/yapcasia2014/0001 2日目: http://gihyo.jp/news/report/01/yapcasia2014/0002 レポータについて レポータ自体は今回で3回目ですが初めて英語セッションも担当できたのは個人的にはチャレンジでした。単に同時通訳++なんですが。。。でもいざやってみるととりあえずスライドだけ写真にとって残しておけばセッション中それほどメモとれなくてもなんとかなるのは発見でした。*1 いつも人手不足で声をかけていただく形で参加させて
＜Oracle 11g 不可視索引に関する検証 その１＞ ペンネーム： グリーンペペ パフォーマンスチューニングの一環として索引を追加する際に、その効果につ いて事前に評価する必要がある場合があります。そんな時に便利な機能が11g より実装されました。”不可視索引”です。 ■”不可視索引”とは? “不可視索引”の詳細は「Oracle Database 管理者ガイド 11gリリース1(11.1)」 に詳細が記載されていますので抜粋します。 リリース11gからは、不可視索引を作成できます。不可視索引とは、セッシ ョンまたはシステム・レベルでOPTIMIZER_USE_INVISIBLE_INDEXES初期化パ ラメータを明示的にTRUEに設定しないかぎり、オプティマイザで無視される 索引です。索引を使用禁止にしたり削除するかわりに、索引を不可視にでき ます。 不可視索引を使用すると、次の操作を
<Insert Picture Here> 入門！Oracleデータベース・解決パフォーマンスチューニング 夜な夜な! なにわオラクル塾 Presented By アシスト #14 Copyright© 2012, Oracle. & K.K.Ashisuto All rights reserved. 目次 2 • パフォーマンス・チューニングの5W+1H 1. Why ～なぜ実施するの？～ 2. When ～いつ実施するの？～ 3. Who ～誰が実施するの？～ 4. Where ～どこでボトルネックがおこるの？～ 5. What&How ～何をどうすれば早くなるの～ 5-1. ボトルネックの特定 5-2. 対処 • SQLチューニング • 索引の使用 • チューニング効果の確認 5-3. 分析の自動化とアドバイス機能 • まとめ Copyright© 2012, Oracle. & K
株式会社富士通研究所(注1)と富士通研究開発中心有限公司(注2)は、Web上の掲示板、ブログ、SNS(Social Networking Service）などに書き込まれる企業や製品についての大量かつ多様な風評情報をリアルタイムに検知する技術の開発に成功しました。この技術により、Web上の風評リスクへの対策を迅速に行なうことが可能になります。 開発の背景 CSR（Corporate Social Responsibility）の積極的な推進が企業に求められる中、企業や製品の風評情報などを迅速に把握し対策を行なうことで、ブランドイメージの低下や社会的信頼性の失墜による経営危機を避けるための風評リスク管理の重要性が高まっています。特に、Web上における風評は、不特定多数の人々に即座に伝播するため、風評に対する対応の遅れなど、リスク管理に失敗した場合の経営ダメージは甚大になりかねません。このよう
なにやらムツカシそうなタイトルですが、中身はそれほどでもないです。簡単に言うと、 複雑なデータがたくさんあるデータベースから、どれだけ速く類似検索できるか というものです。あんまり簡単にならなかった… 今回は、このテーマを実現するために以下の手法を使いました。 たくさんのデータを高速に扱うために：空間索引技法 複雑なデータを高速に扱うために：空間射影技法 これらを使って動画像から取り込んだ 64,000 枚の画像データに対して実験を 行った結果、線形探索法（シラミ潰し法）と比べて平均 30 倍、通常使われる 条件下でなら 100 倍を越える高速化が実現できました。 類似検索とは？ 空間索引とは？ 空間射影とは？ 問題点など 参考文献 論文概要のページへ ●類似検索とは？ 類似検索とは、サンプルから一定の距離内にあるデータをデータベースから 持ってくることです。たとえば、点Ｐから距離ｄ
斉藤 和巳 [連絡先] 〒259-1293 平塚市土屋2946 神奈川大学 理学部 情報科学科 2号棟219号室 ゼミでの主な研究テーマ（予定） ソーシャルネットワークでの情報拡散や意見形成の基本数理モデルの構築 大規模空間ネットワーク分析手法の構築と防災減災などへの応用 社会影響推定のための数理モデルの構築と株価データ分析等への応用 農業環境などの時系列センサーデータ分析法の構築 教員の略歴 学歴 1985年慶應義塾大学 理工学部 数理科学科 数学専攻 卒業 理学士 1998年東京大学 博士(工学) 職歴 1985年NTT入社 機械学習 ニューラルネット 複雑ネットワークの研究に従事 (2007年6月まで） 1991年9月より1年間 カナダOttawa大学 客員研究員 (1992年8月まで） 1994年NTTコミュニケーション科学研究所 主任研究員 (1997年2月まで） 1997年NT
Oracleホワイト・ペーパー 2009年9月 Oracle Database 11g Release 2 におけるパーティション化 Oracleホワイト・ペーパー - Oracle Database 11g Release 2におけるパーティション化 Oracle Partitioning - 概要................................................................................................... 3 はじめに ........................................................................................................................ 3 パーティション化の利点 ......
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
キャッシュの大きいRDB vs インメモリデータベース、性能がどれだけ違うのか調べてみると
第1回 検索エンジンとは | gihyo.jp
第10回 全文検索システムの「Kabayaki」と「Namazu」の特徴
第2回 検索エンジンを形作るもの | gihyo.jp
検索エンジンはいかにして動くのか？：第3回 転置索引とは何か？｜gihyo.jp … 技術評論社
第7回 転置索引の構築 | gihyo.jp
第9回 検索エンジンの開発にあたって | gihyo.jp
簡単なトライ - LINE ENGINEERING
第４回Solr勉強会 - sub usuilog;
「情報環境の変化に適切に対応する目録規則の在り方に関する研究」
データベースシステム (後半)
早大など、スマートグリッド用の効率的な送電を実現するアルゴリズムを開発
第51回 ハイブリッド・シソーラス・システム | gihyo.jp
MLog: [mysql 14353] Re: InnoDBテーブルのテーブルスペース容量計算
索引構成表の管理(IOT表) - Oracle Pub
計算機科学 – String Matching 文字列照合– (PDF)
Oracle 11g 不可視索引に関する検証 その１ - InsightTechnology 旧ブログ
入門！ Oracleデータベース・パフォーマンスチューニング
Web上の風評をリアルタイムに検知する技術を開発 : 富士通
Ruiji-kensaku
K. Saito's Homepage(Japanese)
Oracle Database 11g Release 2におけるパラレル実行の基盤