時系列データを分析する時、csv/tsvファイルからデータを読み込む処理をすることがよくありますよね。 数十MBに収まる容量のファイルならそこまで気にならないかもしれませんが、数百MB程度のファイルになると読み込むだけで数秒〜数十秒かかったりして、コードを実行する度に発生する待ち時間がストレスになってしまいます。 ここでは少しの工夫で読み込みの処理を爆速化出来る方法を紹介します。 実行環境 手元のMBPで実行時間の計測を行います。
時系列データを分析する時、csv/tsvファイルからデータを読み込む処理をすることがよくありますよね。 数十MBに収まる容量のファイルならそこまで気にならないかもしれませんが、数百MB程度のファイルになると読み込むだけで数秒〜数十秒かかったりして、コードを実行する度に発生する待ち時間がストレスになってしまいます。 ここでは少しの工夫で読み込みの処理を爆速化出来る方法を紹介します。 実行環境 手元のMBPで実行時間の計測を行います。
Redis のインストール パッケージから導入する方法と、ソースからインストールする2種類の方法があります 各自の環境制約を踏まえて導入手段を検討してください パッケージから導入する場合 Redis は標準パッケージに含まれていません(2015/11/15時点) サードパーティのリポジトリをインストールするので、標準リポジトリしか利用できない環境では後述の「ソースからインストール」にスキップしてください サードパーティのリポジトリをセットアップします remi と EPEL リポジトリが必要です導入手順はこちら メモリ管理に tcmalloc を利用しているため gperftools-libs もインストールします
俺です。 Redisバージョン: 3.0.5 Redis内のデータがnGB超えていたのでチューニングする。 repl-timeoutはRedisのデータサイズに応じて長めに設定したものの、 slave再接続時にmasterで実行されるdisk出力のbgsaveを抑える方法があったので検証した。 参考 m(__)m 検証結果 nGB超のデータを扱う際はディスクレスレプリケーションが有効です。 ディスクレスレプリケーションであればmasterで一時ダンプは出力されないのでcached memoryは消費しません デフォルトのレプリケーションに比べてFull syncの時間が1/2になりました。 本例(master/slave関係)ではmasterのノードにのみディスクレスレプリケーションのパラメータをセットしましたが、Sentinelを利用する場合は全Redisノードに対して設定しておくのが良
2018/05/24追記: AWS公式ドキュメントに Best Practices for DynamoDB が公開されているので、コチラをチェックしましょう。 0.前提 このドキュメントは、先に下記の参考資料を読み、後で振り返りやすいようポイントをまとめることを目的としています。そのため、用語などの解説は行いません。 参考資料 Must AWS Black Belt Techシリーズ Amazon DynamoDB - Slideshare Amazon DynamoDB(初心者向け 超速マスター編)JAWSUG大阪 - Slideshare DynamoDBによるソーシャルゲーム実装 How To - Slideshare Optional DynamoDB ベストプラクティス - Qiita AWS Summit 2014 Tokyo「Amazon DynamoDB テーブル設計と実
概要 RedisClusterのチュートリアルを読みつつ疑問を解消していく。 Redis自体がシンプルな仕組みなこともあり、ドキュメントを読むだけでおよそ理解できるものと思われるので、下手な追加説明はあまりしていません。 以下、引用の箇所は筆者が和訳したもの、それ以外が筆者のコメントになります。 Redis cluster tutorial このドキュメントはRedisClusterについて書かれています。 distributed systemのコンセプトを簡単にまとめたものになります。 どうやってクラスタを構成し、テストし、運用するかを要点を絞ってまとめたものです。詳細はspecの方をご確認ください。 しかし、可用性と一貫性についての説明も試みています。 プロダクションで使うにはspecificationも読むことをおすすめしますが、とりあえず試したい方はこちらをお読み下さい。 Redi
Memcached クラスのコンストラクタで指定 Memcached クラスのコンストラクタでは、パーシステントIDを引数を渡すことができます。 パーシステントIDを指定すると、memcached への接続が持続的なものになり、次回リクエストでは同じ接続が再利用されます。 http://jp2.php.net/manual/ja/memcached.construct.php Memcached セッションハンドラで指定 Memcached のセッションハンドラで、持続的接続を行うには、session.save_pathの先頭にPERSISTENT=%ID%を指定します。%ID%の部分がパーシステントIDとなります。 PERSISTEN=%ID%の後ろには、半角スペースが必要なので注意して下さい。 下記では、パーシステントID=1 で、持続的接続を行っています。
TL;DR FuelPHPでセッション情報をMemcacheやRDBMSなどを使って複数ノードで共有する場合には、 app/config/crypt.php を複数ノードで同じ値となるように設定する必要がある。 背景 Webアプリを複数ノードで構成して、ロードバランサでセッション維持をしない場合には、どのノードにユーザの再アクセスがあってもセッションを維持するために、セッションストアとしてMemcacheやRDBMSなどを使うと思います。 例えば、以下のような構成。 このような構成を FuelPHP で行う場合の注意点を書いておきます。 図と、以降の説明では ElastiCache(Redis)を使っていますが、注意点についてはRDBMSだろうが普通のMemcacheだろうが同じです。 セッションストアの指定 FuelPHP では、セッションストアの指定を app/config/sessi
$ brew install memcached ==> Installing memcached dependency: libevent ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/libevent-2.0.22.yosemite.bottle.tar.gz ######################################################################## 100.0% ==> Pouring libevent-2.0.22.yosemite.bottle.tar.gz ? /usr/local/Cellar/libevent/2.0.22: 48 files, 1.8M ==> Installing memcached ==> Downloadi
※このお話はたぶんフィクションです。実在の人物や団体とはあんまり関係ありません。 序 planetter.comをバージョンアップすることにした。数年前にリリースしてからずっと放置していたけど、そろそろ手を付けないとやばいと思った。 しかしウェブの世界はドッグイヤーだ。3年も経てば何もかもが変わっている。しばらく開発から遠ざかっていた僕には、最近の技術トレンドなんてさっぱりわからない。 まずは自分自身をアップデートするところから始めよう。 Atom 最初はIDEだ。以前はEclipseを使っていたけど、いまはもうウェブ系言語の進化速度に追いつけていないようだった。ウェブ開発用のIDEならいまはWebStormが人気のようだ。有料だけど、最新の技術に対応しているし、使い勝手もいい。 でも最終的にはAtomを選んだ。IDE(統合開発環境)ではなくエディタなので、これ自体は単機能だけど、不足分は
※実運用では、登録日などの項目も持たせて、セッションタイムアウト時間も設けたほうが良いです。 Lambdaファンクション ログイン処理 入力値として、emailとパスワードを受け取ります。 ログインに成功すればセッションIDを返します。webシステムで使う場合はこのセッションIDをcookieに保存して引き回してあげましょう var aws = require("aws-sdk"); var doc = require('dynamodb-doc'); var crypto = require('crypto'); var dynamo = new doc.DynamoDB(); exports.handler = function(event, context) { if ( typeof event.email === 'undefined' || typeof event.passw
<form method="post" action="API Gatewayエンドポイント"> <input type="text" name="email" value=""/> <input type="password" name="password" value=""/> <input type="submit" value="Send"> </form> フォームの送信先にAPI Gatewayをセットします。HTMLフォームからAPIGatewayを使ってAWS LambdaにPOSTするを参考にして、POSTのデータをLambda側でjsonで扱えるように設定します。 正常に処理が終了すればサンキューページにリダイレクト DynamoDBにデータが登録できれば、サンキューページにリダイレクトするようにAPI Gatewayを設定しましょう。 Method Responseを
やること Phoenixアプリにmemcachedにアクセスするプロセスを追加する Phoenixで子プロセスを立ち上げている部分を確認 Elixir(そしてErlang)は複数のプロセスが協働しながら一つのアプリケーションを実行するマルチプロセスモデルを採用しています. なので当然Elixirで作られているPhoenixFrameworkも同様にマルチプロセスモデルを元に作られています. 実際に, アプリケーション作成時に以下の様なコアモジュールが作成されます. defmodule PhoenixSample do use Application # See http://elixir-lang.org/docs/stable/elixir/Application.html # for more information on OTP Applications def start(_typ
インフラ構成はこんな感じ。アプリケーションサーバが集計を行います。 Phase 4: Hot hash問題 データが3,000万超えた辺りからアクセスが集中するとCloudWatchからアラートが飛ぶように。。 The level of configured provisioned throughput for one or more global secondary indexes of the table was exceeded. Consider increasing your provisioning level for the under-provisioned global secondary indexes with the UpdateTable API 気付いたらいつの間にかデータサイズが10GB超。プロビジョニングされたスループットを超えた書き込みが発生していました。
memcached-cli で Memcached の Slabs Reassign と LRU Crawler を試してみるPerlMemcachedmemcached-cli この記事では、Gotanda.pm #8 でデモをする予定だった内容の手順と結果を紹介します。 勉強会では、発表時間が足りずデモが実施できませんでした。 何かの参考になれば幸いです。 はじめに memcached-cli は筆者が開発した Perl 製の Memcached クライアントです。 テキストプロトコルでできる操作はすべて実行でき、TELNET よりもユーザーにやさしいインタフェースとなっております。 依存も少なく、Perl 5.8 以上であれば動作するように作ったつもりなので、Memcached をお使いの方はぜひ使ってみてください。 Memcached Slabs Reassign と LRU Cr
最近触り始めたので調べたことをまとめてみる・・・!(長くなった!) DynamoDBとは ・AWSの提供する完全マネージドNoSQL DBサービス →KVS的に使うもよし →インデックスを張って軽いクエリも可能 →最近ではJSONドキュメントもサポートされ、ドキュメントストアとしても使えるとのこと ※まだ自分で試してないのでなんともですが、JSONドキュメントの中を検索とかできるのかな… ・ストレージ無限 ・パフォーマンスも無限 →ただしある一定以上に設定する場合はAmazon側に上限緩和申請が必要 →とはいえ項目サイズを1KBとした場合、10000req/sec以上までは申請不要なので通常は十分 ・ユーザが気にするのはスループット値の設定のみ →ReadもWriteも設定値を増やすのは1日何回でも可能だが、減らすのは1日4回までなので注意 →ReadとWriteの設定値減を同時に1リクエ
まずは動かす 依存関係の追加 mavenの場合pomにspring-boot-starterとspring-boot-starter-redisを追加する。 Spring Data デフォルトではJedisを利用してRedisにアクセスする。 <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.3.0.M5</version> </parent> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dep
memcachedのインストール memcachedをインストールしていない場合はこちら libmemcachedのインストール brew install libmemcached 下記のような表示がされれば成功。 $ brew install libmemcached ==> Downloading https://downloads.sf.net/project/machomebrew/Bottles/libmemcached-1.0.18_1.yosemite.bottle.tar.gz ######################################################################## 100.0% ==> Pouring libmemcached-1.0.18_1.yosemite.bottle.tar.gz ? /usr/local/
はじめに Memcachedと、一般的なクライアントライブラリを用いた時の問題を 本当は怖いMemcached としてまとめました。 その時の結論としては「お手軽にMemachedを冗長化したいんだったらKyotoTycoonの相互レプリケーション機能を使うのがいいよ。」でしたが、多少のパフォーマンス劣化を許容できるのであれば、Memcachedでも信頼性を担保出来るやり方がありましたので、その記事になります。 この方式は過去に実際に利用したことのある方式に少し手を入れてデータ削除時の不整合発生を抑制する方式になります。 前回の記事の補足について ちなみに、前回の記事に関して、以下の様なコメントをいただいております。それぞれ大変有り難いご指摘ではあるのですが、ここではいちいち反論しておきます。 Q. そもそもキャッシュなんだから信用出来ないよね。 A. マスタデータ更新時に自分でキャッシュ
この記事はSansanアドベントカレンダー3日目です。 前提 個人でアプリを開発していても、やっぱりなんだかんだサーバーサイドが必要になる機会ってあると思います。ただ、注力したいのはやっぱりアプリ側の開発なのでできるだけサーバーサイドにはコストをかけたくない、そんなときどうすれば、、、みたいな話です。 基本的には、 金をかけたくない 時間をかけたくない でもサーバーサイド用意したい という前提で雑にサーバーサイド環境を用意する場合の話です。 作ったアプリなど 最近は放置気味になっていますが、下記のようなアプリをこれまでにリリースしました。いずれも2人で開発した個人アプリで、アプリに注力しながらもそれなりに頑張ってサーバーサイド側も用意しました。瞬間最大風速では、1000リクエスト/秒くらいのアクセスがあっても特に負荷などの問題も起きず、一応正常に動作してました。 ヒミツのアルバム(写真管理
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く