ＤＢ改造屋雑記: Webサイトの導線について 〜大量のコンテンツを興味ある人に効率よく届けるために〜
今回のエントリは、今までと同じことを別の視点から書くことになってるだけかもしれないけど、今まで良く理解できなかった人にも分かりやすくなっていると幸いです。 社内社外問わず、どうも問題意識がサービスの提供側ほど漠然として希薄な印象なので、確認の為にメモを残しておきます。 ※以下はあくまで私見であり、所属組織や他のメンバーとは関係ありませんが、一般論として十分な説明となっているかとは思います。 AI系技術は、ちゃんと適用分野の深い理解がないと最適に利用することは難しそうな例でもあります。 ＜Webサイトの導線基本構造＞ 現在の一般的なWeb上のコンテンツ閲覧と、実世界、例えば実店舗で商品を見て回ることで、Web側がが劣ることは結構ある。現物が見られないことは永遠に超えられなさそうな壁ではあるけども、 「広範囲の俯瞰を伴う自由な導線」 これが、Webサイト全般に欠けているものかと思う。訪問者は正
【速報】TensorFlowの性能問題が解決しました。（今日）
いろいろ理解を深めたり、いろいろなハードウェア構成で学習や処理を試していましたが、TensorFlowはどうもCPUリソースを先に使い切ってしまう傾向があり最近困っていました。 調べてみると、TensorFlowのcifar10のサンプルなんかもそうかも知れませんが、 LRNOp、LRNGradOp クラス絡みがCPU側で重くボトルネックになっているみたいでした。 TensorFlowでは、各xxxOpに対して勾配を求めるクラスxxxGradOpも存在しています。 それは、学習の際に使われることになります。 従来、LRN(tf.nn.lrn()又は名前が変わってtf.nn.local_response_normalization())を含むモデルは、そこがどうしてもCPU処理になってしまい、 特に学習の際は、LRNGradOp の計算処理が重くなり、その計算中のGPU負荷は0%で、GPUを
MySQLではできないことができるデータベース(広義)達
自分は一応暫くMySQLの開発者だったので、MySQLでできることできないことはすぐわかる訳です。現実的な問題と対峙すること１年間、MySQLは使えることにしか使わないわけで、そうすると構築してしまうと、アラートメールが全く来ないので、水や空気のように存在を忘れてしまいます。でも、使えないことには全く使う気がしないわけで…。というわけでMySQLは結局逆にあまり触れていません。限られた範囲では完成を見ているというわけでしょうか。 データを処理して何か貯めて利用できるものをデータベースとするならば、MySQLを適用する気も起きないような領域があって、近年はそのような領域に挑む別の道具が出てきています。 今回は趣向を変えて、いろいろ現状MySQLでは扱えない問題の解決法を模索したことについて少し触れます。MySQLを離れた話題ですが、いつか遠い未来にMySQLの世界に持って帰る事柄かも知れませ
DBT-2 で MySQL と他のRDBMSの性能比較をしている人に騙されないように注意
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、３年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
MySQLプラグイン作成時のWindows版だけにある「シンボルの壁」
また、需要が無いかも知れない情報かもですけど、嵌ったのでメモ代わりに残しておきます。ちなみに、コンパイラの種類、バージョン、オプションをちゃんと合わせないとアライメントずれでバイナリ互換が無くなる等のプラグイン作成基礎知識には触れません。普段Linuxの人が、気楽にWindows版も対応しようとした場合の落とし穴についてのみです。あと、私のon Windows開発歴はほぼ０なので間違っていたらごめんなさい。 MySQLプラグインは基本的に、プラグイン側からmysqld側のシンボルを参照することが多いです。例えばストレージエンジンプラグインならmysqldの中のhandlerクラスを継承して実装する必要があったり、プラグインからmysqldの状態を知ろうとすれば、そのグローバル変数やら、保護しているmutexやらも必要になります。 基本的にLinuxでは、同じヘッダファイルさえ読めば公式配布
MySQL + jemalloc on Windows
需要が無いかもしれませんが、産まれて初めて、MySQL on Windows について触れます(起動したのも初めて)。 私自身はWindows上のMySQLを性能評価できる環境には無いのですが、 敢えてSQL ServerとWindowsという相手のホームグラウンドでアウェイ対決させよう、 という猛者のためにこのエントリを残します。 猛者向けですし、私は無責任でおねがいします。陰ながら応援します。 MySQL on Windows MySQLの性能・スケールを追求・普及していく上で、Windows上での性能評価はやはり避けては通れないと思います。 （実際にどこまで使うかは別として、正確な要素比較は必要でしょう。） しかし、標準APIを使わなければいけない「地の利が無い」状態では不安が残ります。 できるだけ不安要素は予め解消しておきたいものです。 経験上、不安要素は３つあります。 (1) メ
InnoDB Deep Talk #2 (仮) に引っ張りだされました。
先日、「InnoDB Deep Talk #2 (仮)」というイベントでお話ししてきました。 「事前情報は講演者の名前のみ(内容未定)」という、振り返ってみると異常な状況にも関わらずお集まりいただきありがとうございました。 今回は、前回とは違って少しだけ公開を意識して作ったあったので公開してみます。 これで手持ちのネタは出し尽くしたので、また暫くブログの更新は無いかもしれませんがご容赦を。。。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
