はてなブックマーク

先日、Groongaでビットパラレルで高速な編集距離の実装を検証してました。 ビットパラレルを使ってGroongaで高速な編集距離関数の検証 - CreateField Blog 編集距離とは挿入、置換、削除、並び替えの編集操作によって一方の文字列をもう一方の文字列に変形するのに必要な手順の最小回数です。 ちょこっとだけ表記ゆれしている文字列を抽出したりできます。 ちょっとMySQLでもカジュアルに使いたいなぁと思って編集距離を求めるUDFをさくっと作りました。 naoa/mysql-edit-distance · GitHub １バイト文字であればビットパラレル法でそこそこ高速に編集距離を求めることができます。 10万レコードの比較 文字数x文字数 動的計画法 ビットパラレル固定長 62x62 11.6524 sec 0.1811 sec とりあえず、英語で使いたかっただけということもあ

クライアントサイドでPDF出力できればサーバ負荷軽減できていいなぁとか考えることがあると思います。 そんなときは、 bpampuch/pdfmake · GitHub に日本語フォントを導入することにより 日本語でクライアントサイドだけでPDF出力することができます。 NotoSansを使おうと思ったのですが、otf形式でttfに変換してもうまく動きませんでしたので、以下の源真ゴシックのttfファイルを利用させてもらいました。 jikasei.me ただ日本語のフォントは非常にサイズが大きく１つの太さの種類で5Mバイト以上あります。 これでは、クライアントサイドにやらして負荷を下げられればいいなという目論見よりも通信負荷の方が問題になってしまいます。 そこで、あまり使われない漢字等を省いてサブセット化して容量を減らします。 こちらを利用させてもらいました。 サブセットフォントメーカー とり

はじめに Groonga Advent Calendar 2015の11日目の記事です。 GroongaはC/C++で書かれた高速な国産の全文検索エンジンです。 word2vecは、Googleが研究評価用に作った単語の特徴をベクトルで表現しニューラルネットモデルで教師なし学習をさせるツールです。 単語を文脈も考慮させたベクトルで表現しニューラルネットで学習することで、単語の意味的な足し引きができているんじゃないか( kingからman引いてwoman足したらqueenがでてきましたよとか。)ということで少し前に結構流行ったようです。 また、word2vecの作者が簡易的にsentenceのベクトル表現を使えるようにしたword2vecのコードもあるようです。 普段、Groongaを使ったそこそこの規模のデータベースをもっているので、Groongaに格納されたデータからword2vec/s

GitHubのWikiが検索できなくて不便だなぁとか思ったりしてたら、このWikiはGitベースでできており、gollumというオープンソースで公開されていることを知りました。 github.com そこで、ちょろっと試すためにHerokuで動くようにしてみました。 GitHubのトークンとHerokuのアカウントがあれば数分で個人用のWikiがつくれます。既存のGitHubのWikiを指定して開くこともできます。gollumには一応簡単な検索機能はあるようです。 naoa/gollum-on-heroku · GitHub デモ Gollum on Heroku 追加機能 Herokuでの利用を想定して以下の機能を追加しています。 GitHubへの同期 gollumでは更新があるとローカルのgitリポジトリにcommitされます。そのため、Herokuではdynoが再起動されると更新が消

MySQLでデータサイズが非常に大きいような場合、データを圧縮して格納したくなることがあります。 InnoDBではROW_FORMAT=compressedとすることで、テーブルを圧縮することができます。 MyISAMではmyisampackコマンドを利用することにより、テーブル全体を圧縮することができます。ただし、MyISAMでは読み取り専用となります。 通常、主キーやタイトル、メタデータなどのサイズは小さく、bodyなどのサイズが大きいことが多いと思います。そのため、テーブル全体ではなく、特定のカラムのみを圧縮するだけで事足りることが大半だと思います。 MySQLではCOMPRESS関数とUNCOMPRESS関数があります。 MySQL :: MySQL 5.6 Reference Manual :: 12.13 Encryption and Compression Functions

はじめに MySQLでオープンソースの日本語対応の高速な全文検索エンジンGroongaが使えるMroongaを使って簡単に全文検索機能付きのRailsアプリケーションを作成する方法を紹介します。Railsのデモアプリケーションと実際に使えるサンプルの検索用のメソッドを使って具体的に説明します。 前準備 まず、RailsとMySQLとMroongaが使えるようにしてください。 これらはすでに情報がたくさんあると思うので、さほど苦なく用意できると思います。最近のMariaDBであればデフォルトでバンドルされていたりします。 簡単に試すことができるようにRubyとMySQLとMroongaが自動で環境構築されるVagrantファイルを用意しておきました。 naoa/start-mroonga-with-rails · GitHub vagrantとubuntu/trusty64のboxとvagr

はじめに 最近、Web系のエンジニアに転職して、Railsをよく触っています。 Rails界隈では、HerokuかActiveRecordの関係かよくわかりませんがPostgreSQLが利用されていることが多いような気がします。 これまで個人的に全文検索のWebサービスを開発するためにGroongaとよく戯れていたのですが、最近はなかなか戯れることができていません。 最近になってRailsとPostgreSQLを触りはじめたという状況ですが、先日、PostgreSQLでGroongaが使えるPGroonga 0.20がリリースされたようです。 PostgreSQLで簡単に日本語対応で高速な全文検索が使えるようになるなんて素晴らしいじゃないですか。 最近はRailsの使い方ばっかり調べていて、若干知識欲が満たされない感があったので、PostgreSQLの知識向上がてら、PGroongaと、P

はじめに MySQL/MariaDBで高速に全文検索するためのオープンソースのストレージエンジンMroongaは、以下のように、Engine=Mroonga、FULLTEXT INDEX (${source_column})と書くだけで非常に簡単に全文検索を使い始めることができます。 CREATE TABLE memos ( id INT NOT NULL PRIMARY KEY, content TEXT NOT NULL, FULLTEXT INDEX (content) ) Engine=Mroonga DEFAULT CHARSET=utf8; 検索するときも以下のようにMATCH ... AGAINSTを使うだけです。 mysql> INSERT INTO memos VALUES (1, "1日の消費㌍は約2000㌔㌍"); Query OK, 1 row affected (

はじめに 全文検索エンジンGroongaは超高速な全文検索ライブラリとしての機能を有しますが、単純なハッシュ表等のAPIも提供されており、ファイルへの永続化前提のインプロセス型のKVS(key value store)としても利用することができます。 ファイルへの永続化前提のインプロセス型のKVSとしては、Tokyo Cabinetが有名です。 今回は、簡単にGroongaとTokyo Cabinetの速度と容量について比較してみました。 なお、Tokyo Cabinetには、後継のKyoto Cabinetがありますが、メンテナンス性等を重視してC++で実装されており、単純な性能であれば、Tokyo Cabinetの方がやや良いということでしたので、今回はTokyo Cabinetを利用してみました。 検証環境 項目 バージョン/種類 CPU Intel(R) Xeon(R) CPU E

はじめに こちらの記事では、GroongaとElasticsearchの単純な検索性能、更新性能、 ディスク使用効率を比較しました。 その結果では、Groongaの検索速度がElasticsearchよりも数倍ほど速く、Elasticsearchの更新速度がGroongaよりも数倍ほど速かったです。 なお、前回の記事では、Elasticsearchでフレーズ検索がされていなかったり*1、punctuation、whiespaceが転置索引に入っていなかったため、追加検証結果を追記しています。 シーケンシャルなスクリプトではGroongaの更新速度のほうが遅かったですが、これは、GroongaとElasticsearchが利用しているLuceneの転置索引の作成方法や管理方法の違いによるものです。 Groongaにおける転置索引 Groongaでは、即時更新に強く更新にかかる処理コストが低く

はじめに Dockerで簡単に使えるようにしてみた第2弾です。前回は、専門用語を自動抽出してくれるTermExtractをプレーンテキストで簡単に使えるようにしたDockerファイルについて紹介しました。 最近はword2vecが非常に話題になっていますが、word2vecは環境構築周りやテキストの前処理等がなかなかめんどくさいです。 そこで、word2vecと、プレーンテキストをRE2による正規表現フィルタ、ICUによるNFKC正規化（全角文字→半角文字変換等）、MeCabによる分かち書き等を実行してくれる自作のC++プログラムstring-splitterが自動で環境構築されるDockerファイルを作りました。 https://github.com/naoa/docker-word2vec このDockerファイルには、単語間のベクトル距離が近い類義語っぽいものを出力するdistanc

はじめに 品詞のつながりや出現頻度、学習情報から複合語らしきキーワードを自動で抽出するPerlモジュールTermExtractが公開されています。 これを利用すれば、形態素解析済みのテキストを食わせるだけでそこそこそれらしい専門用語をたくさん得ることができます。 このTermExtractは、ソースからインストールする必要があったり、EUC環境であったり形態素解析後のデータを入力に必要としたりなかなかめんどくさいです。 そこで、MeCabとTermExtractが自動で環境構築されるDockerファイルを作りました。 https://github.com/naoa/docker-termextract このDockerファイルでは、正規表現フィルタや形態素解析、コスト推定などを自動でやってくれるPerlスクリプトも自動で導入されるようになっています。 これでDockerを実行できる環境があ

2014/06/27(金)に全文検索エンジンGroongaユーザ勉強会＠神戸を主催しました。 開催のきっかけ 草の根Groongaイベントのお誘いを受けて、関西圏でもGroongaのイベントがあるといいなと思い、神戸でも開催してみることにしました。 会議室の確保 人の集まり具合がどうなるかわからなかったので、三宮近辺でできるだけ費用が抑えられるというポイントで会場を探しました。WordBench神戸などが利用されているような貸会議室ビジネスしているところだと、平日夜間でも1万円を超えるところが多かったです。人が数十人来ることがほぼ確定しているプロダクトの勉強会なら千円徴収すればなんとかなりますが、小規模が想定される勉強会での利用は難しかったです。 そこで、公民館など市営の施設の会議室をこちらから探してみました。公民館等の場合、だいたい10数名規模の部屋で数千円といったところでした。 その他

2014年4月21日は、第4回Elasticsearch勉強会ですね！ http://elasticsearch.doorkeeper.jp/events/8865 第4回Elasticsearch勉強会は、参加希望者が約200名の大反響なようです。 私は勉強会に参加できないので、C言語で書かれた国産の高速な全文検索エンジンGroongaと、Javaで書かれた世界的に勢いのあるElasticsearchについて性能の比較をしたいと思います。 注意事項 今回の検証では1台あたりの馬力を比較するためにサーバ1台での全文検索性能について比較しています。 私は、Groonga(Mroonga)の利用暦が約2年であるのに対し、Elasticsearchの利用暦は2日です。このため、Elasticsearchに対するチューニングの不備や公平な比較になっていない点が含まれている可能性があります。 Ela

前回は、全文検索Webサービスを作ったときにはまったことの第2回として、 Mroongaのラッパーモードからストレージモードに変えた理由という記事を書きました。 今回は、Mroongaのストレージモードにしたことによってはまったことについて書きたいと思います。 Spiderストレージエンジンを使ったMroongaの分散構成の検討 当初、データベースを複数に分割し、Spiderストレージエンジンを使ってデータベースシャーディングする予定でした。 Spiderストレージエンジンは、ストレージエンジンの種類を問わずデータベースを水平分散させることができるMySQL/Mariadbのストレージエンジンです。 Spiderストレージエンジンは、国産で個人の方が開発されたストレージエンジンでMariaDB10.0系にすでにバンドルされています。 Spiderストレージエンジンの開発者の方は、全文検索M

はじめに 先日、2024/4/4 CohereからCommand R+という新たなLLM(大規模言語モデル)が発表されました。 Cohereは、Transformerモデルを提唱した論文共同執筆者の人が立ち上げたカナダのAIベンチャー企業のようです。 https://ascii.jp/elem/000/004/192/4192907/ Command R+とは、最大で128Kトークンが処理が可能で、コストはGPT4Turboの3~5倍ほど安いモデルです(Claude3 Sonnetと同等)。 先日、以下の記事にてGPT, Claude3, Gemini別に審査官による特許引用文献段落の再現率の検証を行いました。 ChatGPT, Claude3, Gemini別に審査官による特許引用文献段落抽出の再現率を検証してみた - CreateField Blog Gemini 1.5 Pro AP

前回のエントリに書いたように、１年半ほどをかけて、独学で特許の全文検索サービスを開発しました。 PatentField | 無料特許検索 最初は、MySQLを使ったこともない状態だったこともあり、かなり紆余曲折しました。Groonga開発チームの懇切な対応もあって、専用サーバ1台で最大で1千万レコード超、400GiB以上のサイズのテキストデータを高速に検索できるようになりました。 今後、何回かにわけて、Mroonga(Groonga)を使って全文検索Webサービスを作ったときにはまったこと、学んだことを全て書き出したいと思います。 全文検索エンジンMroongaとは？ Mroongaは全文検索エンジンであるGroongaをベースとしたMySQL用のストレージエンジンです。Mroongaは、MySQLが使える人であれば、簡単に高速な全文検索機能が使えます。MariaDB10.0系にもバンドル

前回は、全文検索Webサービスを作ったときにはまったことの第1回という記事を書きました。 今回は、Mroongaを使って全文検索Webサービスを作ったときにはまったことの第2回として、ラッパーモードからストレージモードに変えた理由について書きたいと思います。 なお、かなり長く、MySQL、Groongaについて前提知識がないと理解できない部分が多々含まれている可能性があります。 ラッパーモードとは 全文検索Mroongaストレージエンジンでは、全文検索するためにラッパーモードとストレージモードの2つのモードが用意されています。 (引用) ラッパーモードでは全文検索機能のみGroongaの機能を利用し、データストアはInnoDBなど既存のストレージエンジンを利用します。ラッパーモードを利用することにより、ストレージエンジンとして多くの利用実績のあるInnoDBに全文検索エンジンとして実績のあ

はじめに 去年あたりから流行っているらしいword2vecが面白そうだったので日本特許の要約データと米国特許の要約データを使って試してみました。 word2vecは、類語やアナロジー(類推)等を取得することができます。 word2vecの使い方は非常に簡単で、空白区切りのテキストデータをword2vecの学習プログラムに渡すだけです。 アナロジーというのは、ベクトル同士を演算し、A → Bの関係に対し、C→Xに当てはまるXというのを探すことができるようです。 （引用）https://plus.google.com/107334123935896432800/posts/JvXrjzmLVW4 面白いのは、2つのベクトルの差が、2つの単語の関係をよく近似してくれること。 （中略） A B C → X (A → Bの関係に対し、 C → X に当てはまるXを探す) グーグル ヤフー トヨタ →

はてなブログ初投稿です。 大学の授業でＣ言語をかじった程度のサラリーマンですが、１年半ほどをかけて、独学で特許の全文検索サービスを開発しました。 PatentField | 無料特許検索 １年半前は、データベースもサーバサイドの言語もJavaScriptもまったく触ったことがなく、Ajaxって何？ってぐらいの技術レベルでしたが、ようやく先月公開することができました。 まだまだ未完成ですが、最大で1千万レコード以上、400GiB以上のサイズのテキストデータを高速に全文検索することができます。 このサービスでは、ただ公報データを全文検索するだけではなく、整理標準化データと呼ばれる権利の死活情報等を含む数十種類の項目を組み合わせて検索することができます。これにより、一般の利用者が特許を侵害していないかどうかを確認し易く、また、特許期限切れのフリ―な技術情報を簡単に参照できるようにしています。 ま