PythonでMySQLのスロークエリログを集計 | 外道父の匠
久々に溜まったブログネタ放出をしようかなと、その前に下書きから掘り起こしてきた、いまさらなスロークエリ関連で準備運動です。 RDSのスロークエリ情報は当然、集計を自動化していつでも見れるようにしてあるのですが、ちょいと必要があったので、今回はあえて単発ログを集計する形に切り出したものを用意してみました。 スロークエリログの必要性 最近はNewRelicとかで、アプリケーションの処理を分別して処理時間などを集計するので、それで課題となるクエリを確認したりもします。 非常に便利な仕組みですが、アプリケーション外のジョブなどが実行したクエリは集計されないことや、負荷試験で課題を炙り出すときだとテスト環境にエージェントやライブラリを仕込む必要がある、といったデメリットとまでは言わないまでも面倒さがあります。 その点、スロークエリはサーバー側で記録するものなので、0.1秒とかでONにしておけば、対象
Pythonで省メモリに大量の文字列を扱う工夫 - MNTSQ Techブログ
たくさんの文字列（や離散的な符号列）をメモリに載せないといけないんだけど、いろんな制約があって通常のList[str]では載らない…ということありませんか？（まぁあんまりなさそうですね） たまたまそういうことがあったので、その際に検討した内容をまとめておきます TL;DR メモリをもっと増やしましょう 富豪的に解決できるならいつでもそれが最高です しかし、世の中それでなんとかならんこともたくさんあります 用途があうのであれば専用のデータ構造を採用する 例えばもし共通のprefixやsuffixが存在し、順序に興味がなければtrie treeなどが使えます 例えば、弊社であれば、法人名をメモリに持ちたいなんてときもあります。そういうときに法人名の辞書をtrieで持ったりすることがあります 「株式会社」「一般財団法人」や「銀行」といった共通語がたくさんでてくるのでtrie treeでごりごり削
たった数行でpandasを高速化する2つのライブラリ(pandarallel/swifter) - フリーランチ食べたい
pandas はデータ解析やデータ加工に非常に便利なPythonライブラリですが、並列化されている処理とされていない処理があり、注意が必要です。例えば pd.Sereis.__add__ のようなAPI(つまり df['a'] + df['b'] のような処理です)は処理が numpy に移譲されているためPythonのGILの影響を受けずに並列化されますが、 padas.DataFrame.apply などのメソッドはPythonのみで実装されているので並列化されません。 処理によってはそこがボトルネックになるケースもあります。今回は「ほぼimportするだけ」で pandas の並列化されていない処理を並列化し高速化できる2つのライブラリを紹介します。同時に2つのライブラリのベンチマークをしてみて性能を確かめました。 pandarallel pandaralell はPythonの m
ZOZOSUITのサーバーをPythonからScalaで実装し直してコストを下げた話 - Qiita
TL;DR ZOZOSUITで計測したデータを扱うサーバーは、元々Pythonで実装していた それをScalaで実装し直した 結果、レイテンシにおけるパフォーマンスが向上した さらに、リソース面におけるサーバーコストも削減できた 技術選定における背景 ここ数年、機械学習の文脈やサービスの立ち上げ期のプロトタイプ実装のため、Webアプリケーションの分野においてもPythonが選択されることは本当によく聞かれるようになりました。 事実、難しいビジネス要求や急な仕様変更への柔軟な対応においては、比較的実装コストの低い言語やフレームワークを選択するメリットはとても大きいと言えます。 利用できるすべての変数やメソッドの型をプログラムの実行中に決めなければならない場合、ランタイムのオーバーヘッドは甚大になります。静的型付け言語では、そのオーバーヘッドが不要になります。Python、Perl、Rubyと
うわっ…私のpandas、遅すぎ…?って時にやるべきこと（先人の知恵より） - Lean Baseball
※あくまでもイメージです（適当） 仕事じゃなくて、趣味の方の野球統計モデルで詰まった時にやったメモ的なやつです.*1 一言で言うと、 約19万レコード（110MBちょい）のCSVの統計処理を70秒から4秒に縮めました. # 最初のコード $ time python run_expectancy.py events-2018.csv RUNS_ROI outs 0 1 2 runner 0_000 0.49 0.26 0.10 1_001 1.43 1.00 0.35 2_010 1.13 0.68 0.32 3_011 1.94 1.36 0.57 4_100 0.87 0.53 0.22 5_101 1.79 1.21 0.50 6_110 1.42 0.93 0.44 7_111 2.35 1.47 0.77 python run_expectancy.py events-2018.c
pandasで1000万件のデータの前処理を高速にするTips集 - Qiita
はじめに 当社にアルバイトに来ていた人（来春に新卒入社の予定）に「pandasを高速化するための情報は無いですか？」と尋ねられました。 このパッケージの使い方は多数の書籍やWebで体系立った記事で書かれています。 しかし、高速化に関しては体系的な情報源が思いつかなかったので、「実際に書いてみて、1つ1つチューニングするしかないです」としか答えられませんでした。 そこで、この方を始め、来春（2019年4月）にデータアナリストまたはデータサイエンティストになる新卒へ向けて、pandasの高速化に関する私の経験をTips集にしてお伝えしたいと思います。 この記事は今後も内容を充実させるために、Tipsを追加していきます。 この記事を読んだ後にできるようになること pandasでレコード数1000万件のデータでも1分以内で完了する前処理が書けるようになります。 その結果、1日中実行し続けなければな
開発者がビッグデータ分析にPythonを使う時によくやる間違い | POSTD
システムの構築、新しい技術の習得、PythonやDevOpsなどに情熱を注ぐソフトウェア開発者です。現在はチューリッヒを拠点とするビッグデータのスタートアップで働いており、データ分析およびデータ管理ソリューションのためのPythonの技術を磨いています。 1 はじめに Python は開発時間を短縮できるという点で一般的に評価の高い言語です。しかし、Pythonを使って効率よくデータ分析をするには、思わぬ落とし穴があります。動的かつオープンソースのシステムであるという特徴は、初めは開発を容易にしてくれますが、大規模システムの破綻の原因になり得ます。ライブラリが複雑で実行時間が遅く、データの完全性を考慮した設計になっていないので、開発時間の短縮どころか、すぐに時間を使い果たしてしまう可能性があるのです。 この記事ではPythonやビッグデータで作業をする時に、最も時間を無駄にしがちな事柄につ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「aws lambdaでpythonを実行するときのチューニング案を試してみた！」というタイトルで登壇しました。 | DevelopersIO
Python scirpt for counting slow query log and sort it.