話の内容は、自然言語処理が実世界で具体的にどのように応用されているのか、またその時に感じた課題についてです。 後半の「何が必要とされているか」、あたりの話からは私や会社が特に重点的に取り組んでいる事そのものの話もなります。
大規模データ時代に求められる自然言語処理 - Preferred Networks Research & Development
話の内容は、自然言語処理が実世界で具体的にどのように応用されているのか、またその時に感じた課題についてです。 後半の「何が必要とされているか」、あたりの話からは私や会社が特に重点的に取り組んでいる事そのものの話もなります。
MongoDBの信頼性に疑問
原文(投稿日：2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が２つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命－もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい－容易にメモリーに収まる(~15 GB) 二次索引－キ
高速な安定ソートアルゴリズム "TimSort" の解説 - Preferred Networks Research & Development
先日、TimSortというソートアルゴリズムが話題になりました。TimSortは、高速な安定ソートで、Python(>=2.3)やJava SE 7、およびAndroidでの標準ソートアルゴリズムとして採用されているそうです。 C++のstd::sort()よりも高速であるというベンチマーク結果1が話題になり(後にベンチマークの誤りと判明)、私もそれで存在を知りました。実際のところ、ランダムなデータに対してはクイックソート(IntroSort)ほど速くないようですが、ソートというシンプルなタスクのアルゴリズムが今もなお改良され続けていて、なおかつ人々の関心を引くというのは興味深いものです。 しかしながら、オリジナルのTimSortのコードは若干複雑で、実際のところどういうアルゴリズムなのかわかりづらいところがあると思います。そこで今回はTimSortのアルゴリズムをできるだけわかりやすく解
averaged stochastic gradient descentのご紹介 - Preferred Networks Research & Development
そろそろ寒くなってきましたね。早速風邪を引きました。徳永です。 今日は私の使っている自作の足置き（制作費600円）の紹介でお茶を濁そうと思っていたのですが、途中で方向転換しました。今日は機械学習の話をします。 Léon Bottouという研究者（彼はまたDjVuというドキュメントフォーマットの開発者でもあります）が開発・公開しているsgdというソフトウェアのバージョン2.0が公開されました。sgd 2.0ではaveraged stochastic gradient descent（ASGD）という手法が実装され、これまでのSGDと比べて性能が向上しました。今日はこのASGDを紹介したいと思います。日本語に訳すと平均化確率的勾配降下法でしょうか。漢字が多くて読みづらいので以下ではASGDと呼びます。 もともと、SGD（確率的勾配降下法）はNLPのような高次元かつスパースなタスクではうまく行く
アルゴリズムの勉強のしかた - きしだのHatena
この記事で、アルゴリズムの勉強はアルゴリズムカタログを覚えることじゃないよということを書きました。 プログラムの理論とはなにか アルゴリズムの勉強というのは、スポーツで言えば腕立て伏せや走り込みみたいな基礎体力を養うようなもので、「ソートなんか実際に自分で書くことないだろう」とかいうのは「サッカーは腕つかわないのに腕立ていらないだろう」とか「野球で1kmも走ることなんかないのに長距離の走り込みいらないだろう」とか言うようなものです。 Twitterでアルゴリズムの勉強とはなにかと尋ねられて、「アルゴリズムの基本的なパターンを知って、それらの性質の分析のしかたをしって、いろいろなアルゴリズムでどのように応用されているか知って、自分が組むアルゴリズムの性質を判断できるようになることだと思います。 」と答えたのですが、じゃあ実際どういう本で勉強すればいいか、ぼくの知ってる本からまとめてみました。
セールスフォースのクラウドデータベース「Database.com」が正式サービス開始。無料で10万件まで利用可能、セキュリティポリシー対応機能も開発中。Dreamforce'11
セールスフォースのクラウドデータベース「Database.com」が正式サービス開始。無料で10万件まで利用可能、セキュリティポリシー対応機能も開発中。Dreamforce'11 セールスフォース・ドットコムは、「Database.com」の正式なサービス開始を発表しました。 Database.comは、クラウド上で運用されるビジネスアプリケーション向けのリレーショナルデータベースサービス。REST APIなどでアクセス可能で、障害時の自動フェイルオーバー、データのバックアップ、ディザスタリカバリなどの運用をすべてクラウドに任せることができます。 3ユーザー、10万件、月間5万トランザクションまでは無料で利用可能（Database.comの詳細は「セールスフォース、無料で使えるクラウドデータベース「Database.com」を発表。Dreamforce '10」をご参照ください）。 重要な
シバタツ流！ DWHチューニングの極意 第5回 統計情報と実行計画 | oracletech.jp
この連載もついに最終回となりました。今までの連載で紹介したテクニックを使えば、ほとんどのデータウェアハウスは大幅に高速になるはずですが、統計情報の取得方法に問題があって想定どおりに動いていなかったら元も子もありません。「SQLが遅い」という理由の一つに「実行計画が悪い」ということがありますが、オプティマイザは統計情報を基にして実行計画を作ります。なので、正しくない統計情報を使っていると正しくない実行計画が作られてしまい、その結果、SQLが遅いという結果になってしまいます。ある程度のコストが掛かる統計情報収集はデータの変更とリアルタイムで行われるわけではないので、統計情報を収集するタイミングや方法によっては現在のデータの実態を反映していない、正しくない統計情報になってしまいます。そこで今回は正しい統計情報の取り方と、その統計情報で正しい実行計画が作られたかどうかの監視の仕方についてご紹介しま
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
最近傍探索2011 - Preferred Networks Research & Development
こんにちは、二台目のmbaを買うのをためらっている岡野原です。 アイテム集合に対し、与えられたアイテムと似ているアイテムを求める、という近傍探索問題は古典的な問題でありながら、現在でも多くの改善がされています。特に言語情報、画像情報、行動履歴情報、生物情報、購買情報などありとあらゆるデータが高次元中の点として表現されるようになってきており、こうしたデータの最近傍探索は広い分野で応用範囲がある技術になっています。 アイテムが低次元（例えば2, 3次元）の場合はkd木や最近だとwavelet木を使う方法がありますが、今回扱うケースは各アイテムが高次元（数百万次元）中の点であったり、アイテム間の距離のみが定義されている場合（カーネル関数など）です。アイテム数は数万から数億ぐらいを想定しています。 最近傍探索問題はいくつかありますが、例えばk近傍グラフ構築問題では、 「アイテム集合X = x1,
はじめての MySQL で100万件のデータを管理する時に行ったチューニングまとめ
MySQL の勉強をせずにフレームワーク等で SQL を書かずに Web サイトを構築していました。データ数も2万件程度でしたので、そこまで困ることはありませんでしたが、今回100万弱の商品データを扱う機会ができたので、MySQL のチューニングや発行する SQL について見直す機会がありました。 この記事では MySQL を高速化するのに行った対策など勉強したものを自分用にメモしておきました。 条件式で比較するカラムにインデックスを使用して高速化 商品コードで存在しない商品を見つけて、商品をDBに登録するという処理を行っている場合、4万件超えたころから処理に2秒以上かかるようになってきます。12万件超えた頃には10秒程度かかるようになってしまいましたが、商品コードのフィールドに対してカラムインデックスを貼ることで0.2秒に短縮することができました。 MySQL のリファレンスにも以下のよ
複合主キーを避けるべき理由 - 虎塚
データベース設計の話をしていて、「連番の主キーは業務上意味のないデータだから、テーブルに持たせるのはムダだ。複合主キーにするべき」という意見を聞く機会がありました。 脊髄反射で「ないわー」と思ったものの、理由を上手く説明できなかったので、改めて考えてみました。 その結果、次のような結論に至りました。 単一の連番カラムによる主キーと、複合カラムによる主キーとで迷ったら 実装をシンプルにし、業務変更の影響範囲を小さくするために、複合主キーを避ける というわけで、調べたことや考えたことをメモしておきます。# 間違っている部分があれば、教えていただけると嬉しいです。 （2011/07/25 追記）複合主キーとサロゲートキーについては、要件やシステムに依存して多様な判断がありうると思います。にもかかわらず、「避けるべき」というタイトルにしたのは極端でした。申し訳ありません。ご指摘下さった皆さん、あり
Googleのリアルタイム検索が無くなった余波 » SEO Japan
Googleのリアルタイム検索が知らない間に消え去ってしまったことに驚いた人も多いでしょう。SEO Japanでもその経緯について一度説明しましたが、経緯はともかく、リアルタイム検索ができなくなったことで困っている人も意外と多いのではないでしょうか。今回、サーチエンジンランドがGoogleのリアルタイム検索終了の余波や、他に使えるリアルタイム検索サービスについてレビューした記事を見つけたので早速紹介します。 — SEO Japan 先週の金曜日、ツイッターは密かにグーグルにつながれていたツイートのデータの“ファイヤーホース”を抜いていた（日本語）。ガソリンの供給をやめたガソリンスタンドのように、グーグルは、事実上グーグルのリアルタイム検索サービスに「閉店」の張り紙を掲載しなければならなくなった。その結果、ツイッターと言う名のガソリンを得るためにグーグルに頼っていた人達に何が起きたのだろうか
大規模データを無料で手に入れることのできるサイトまとめ - nokunoの日記
大規模データが公開されているサイトについて以下のQuoraでid:makimotoさんが質問していました。Data: Where can I get large datasets open to the public? - Quora以下、紹介されているサイトの一覧です。一部有料のものもあるようです。UCI Machine Learning RepositoryPublic Data Sets : Amazon Web ServicesCRAWDADno titleCity of Chicago | Data PortalGovLoop | Social Data Network for Governmentdata.gov.uk | Opening up governmentData.Medicare.GovData.Seattle.Gov | Seattle’s Data SiteOp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
IBM Developer
高速データ通信四つ巴。Xi/ULTRA SPEED/WiMAX/EMOBILEどれにすべきか悩んでいる人のためのまとめ｜男子ハック
NTT Com、堅牢性99.9999999999％のクラウドストレージ「Bizシンプルディスク」
http://blog.av-jyo.com/2011-07/how-to-develop-porn-website-with-nodejs.html