全俳句データベースVer.2ぜんぶの俳句のデータベースです
形態素解析とNgramを併用したハイブリッド検索をSolrで実現する方法 - Qiita
この記事はVASILY DEVELOPERS BLOGにも同じ内容で投稿しています。よろしければ他の記事もご覧ください。 こんにちは、バックエンドエンジニアの塩崎です。 今まではiQONの全文検索用のインデックスには形態素解析だけを用いていましたが、先日Ngramも併用することで検索を改善しました。 その結果、検索結果のヒット数が向上し、なおかつ検索ノイズの増加を軽微なものに抑えることができました。 この記事では、Ngramを併用することのメリット、およびそれをApache Solrで利用する方法について紹介します。 欲しい情報が見つからないとは そもそも、「検索したけど欲しい情報が見つからない状態」とはどのような状態でしょうか？ ここではその状態を以下の2つの状態に分解して考えてみます。 欲しい情報の数が少ない 1つ目の状態は「欲しい情報が検索結果中に少ない」状態です。 例えば、旅行情報
メディア芸術データベース アイディアソン (2015/03/29 13:00〜)
【お申し込みは以下のURLよりお願いします】 https://00ea858539019317159b9bc97b.doorkeeper.jp/events/22401 つい先日、文化庁がメディア芸術データベースを公開して話題になりました。 歴代のマンガ、アニメ、ゲーム、メディアアートの情報が、誰でも無料で利用可能になり、 日本のコンテンツ産業における画期的な第一歩を踏み出しました。 このデータベースを最大限活用するインターネットサービスを一緒に考えませんか？ 日本が世界に誇れる文化を、一緒に盛り上げましょう。 「このニュースを聞いてワクワクした」「マンガやアニメが大好き」 こんな方が一同に集まり、白熱した議論が出来ると面白いイベントになると思います！ この日をきっかけに、新しいサービスが生まれる事を願っています。 【テーマ】 メディア芸術データベースを使った、インターネットサービス 【持
NoSQLとしてMySQLを使うDeNAが、memcachedよりも高速な75万クエリ／秒を実現
モバゲーで知られるDeNAは、バックエンドデータベースにNoSQLを使っていません。なぜか？ それはMySQL/InnoDB 5.1の環境で秒間75万クエリという、多くのNoSQLでも実現できないような高性能を実現しているから。DeNAの松信嘉範（まつのぶよしのり）氏は、自身のブログにこんな内容のエントリ「Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server」（英語）をボストしています。 Yoshinori Matsunobu's blog: Using MySQL as a NoSQL - A story for exceeding 750,000 qps on a commodity server 松信氏が指摘するように、大規模なネットサービスを提供している企業の多くは分散環境で
3行でできる超お手軽全文検索 - mixi engineer blog
梅雨。部屋干しした洗濯物による異臭騒ぎに苦しむmikioです。今回は、Tokyo Cabinetのテーブルデータベースで超お手軽に全文検索をする方法について説明します。 使い方 テーブルデータベースについてまずおさらいしておきましょう。PerlやRubyのハッシュのようにコラム名とその値を関連づけた構造を、主キーを識別子として保存するデータベースです。例えばRubyからデータを保存するに以下のように行います。データベースであることをほとんど意識させないというのが素敵ポイントです。APIはCでもPerlでもRubyでもほとんど同じなので、言語にかかわらず同じようにレコードを操作できます。 require 'tokyocabinet' include TokyoCabinet # データベースを開く tdb = TDB::new tdb.open("casket", TDB::OWRITER
Leo's Chronicle: データベースシステム入門：「データベースは体育会系図書館？」
（データベースシステムとその研究の世界を一般の人にわかりやすく伝えるため、「図書館」をモデルにした話を書いてみました。試験に出そうな（？）部分は太字で強調してあります。） 「データベース」という言葉は、データの集まりという意味です。データベースシステムの研究では、例えて言うなら「欲しい本がすぐに見つかる図書館」をいかに作るかという問題を考えます。ここで「データ」は図書館の「本」に相当し、「ハードディスク」は「本棚」がたくさん収められている図書館の建物だと考えてください。 「欲しい本がすぐに見つかる」とはどういうことでしょうか？例えば、図書目録を調べて目的の本棚の番号がわかったとしても、本棚までの距離が遠ければがっかりしてしまいますよね？（高すぎて手が届かない、とか泣けてきます）
DBMによるテーブルデータベース その弐 - mixi engineer blog
インフルエンザで休んだ影響で仕事が鬼のように溜まって消化不良のmikioです（こんな記事を書いている場合じゃない）。さて今回は、Tokyo Cabinetでリレーショナル風データベースを実現したテーブルデータベース（TCTDB）の実装について説明します。 SQLiteとの違いは？ SQLiteはアプリケーション組み込み型のSQL対応リレーショナルデータベースのライブラリです。TCのテーブルデータベースよりもはるかに高機能で、それでいて性能も大変優れています。いわゆるデスクトップアプリケーションに組み込むデータベースをお探しであれば、TCなんかではなく、断然SQLiteがおすすめです。 一方で、TCなどのDBMは、より単純なデータ操作をより高速に実行できるように設計および実装されています。典型的なユースケースとして、大規模Webサイトのアカウント管理や、データマイニングに伴う集計操作が挙げら
DBMによるテーブルデータベース - mixi engineer blog
正月早々インフルエンザにかかって寝込んだmikioです。電車に乗る時や繁華街などに出る時はマスク着用が必須ですね。さて今回は、Tokyo Cabinetで実装したテーブル方式のデータベースについて紹介します。意外にどうして強力な機能なので、このネタは連載することを予告します。 テーブルデータベースとは 簡単に言えば、リレーショナルデータベースのテーブルのように、複数の列からなるレコードを格納できるデータベースです。SQLや表結合などの複雑な機能はサポートしませんが、そのぶん高速に動作します。つまり、DBMの速度で動くリレーショナル風データベースです（厳密にはリレーショナルデータベースではありません）。 TCの基本となるハッシュデータベースは、単純なkey/value型のデータベースであり、つまりキーにも値にもスカラ（数値や文字列などの特に構造を持たない単一の値）しか格納することはできません
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
Inside Tokyo Cabinet その壱 - mixi engineer blog
約半年間の沈黙を破ってOSSの世界に戻ってきつつあるmikioです。先日、Tokyo Cabinet（以下「TC」と呼びます）というデータベースライブラリをリリースしました。今回から数回に分けて、TCの設計と苦労話について連載してみます。 DBMとは TCは、いわゆるDBMの系譜のデータベースライブラリで、単純なハッシュテーブルをファイル上で永続化するだけの機能を提供します。DBMはAT&Tの古代UNIXの時代から受け継がれる伝統芸能なのですが、私はそういう枯れた技術が大好きなのです。 プログラマの皆さんは、PerlやRubyではハッシュ（連想配列）と呼ばれ、JavaやC++ではmapと呼ばれるような、何らかのキーに関連づけてなんらかの値を記録するデータ構造って実によく使いますよね。例えばmixiでは、ユーザアカウントに関連する情報（名前とかニックネームとか）は、ユーザIDをキーにしたハッ
developer0000.jp
Buy this domain. developer0000.jp 2020 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy
SQLで集合演算：CodeZine
はじめに SQLが集合論に立脚する言語であるということは、この連載で一貫して強調してきたテーマの一つです。その特性のゆえに、SQLは「集合指向言語」と呼ばれていますし、実際、集合的な観点から見たときに初めて、その強力さが理解できると私は考えています。しかし現実には、SQLのこの側面は長らく無視されてきました。 その背景には、SQLにも責任の一端があります。というのも、SQLはちょっと前まで、高校で習う程度の基本的な集合演算子すら持っていなかったからです。和（UNION）こそSQL-86からの古参ですが、交差（INTERSECT）と差（EXCEPT）が標準に入ったのはSQL-92ですし、除算（DIVIDE BY）が未だに標準化されていないことは、前にも述べました。だから、SQLが言語として不完全だという批判は、理由のないものではなかったのです。 しかし、現在では標準SQLに基本的な集合演算子
「ちょっと待て」 真・MySQLのクエリを最適化する10のTips：CodeZine
Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言
suVeneのあれ: 俺的コーディングルール SQL編
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[PDF] マッシュアップデータの選択的閲覧における効率的な部分更新 - 日本データベース学会論文誌 Vol.7 No.4
SQLで木と階層構造のデータを扱う――入れ子集合モデル