EC2上のAerospikeでycsbを実行(4) 1台で複数SSDを使ったら速くなる?
単純に考えると、RAIDと同じような構成になりそうなので、速くなりそうな気はします。
が、実際にはそれほどでもありませんでした。
可能性としては、
などが考えられます。(t2.microは1コアしかありません)
一応、状態を確認してみるとい、両方のディスクkは使われているようです。
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util xvda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 xvdg 0.00 0.00 0.00 49.23 0.00 12603.08 256.00 0.36 7.38 7.29 35.90 xvdf 0.00 0.00 0.00 48.72 0.00 12471.79 256.00 0.08 1.56 1.56 7.59
スループットはloadは低下、runは変わらずといったところでしょうか。1回しか計測していないので、たまたまなのか、必然なのかは不明です。
SSD 1台
SSD 2台
そして、t2.microでも、ストレージをいろいろ追加して実施して、誤って課金されてもいけないので、
計測が終わったら容赦なくインスタンスを削除しまーす。
これで一通りのAerospikeシリーズは終了です!
EC2上のAerospikeでycsbを実行(3) クラスタ構成にチャレンジ
さて、前回の実行で、EC2でAerospikeを簡単に構成できることがわかったので、クラスタ構成にもチャレンジしてみます。
無料範囲でやりたいので手早く!
takumats.hatenablog.com
ちなみに、データを削除するときは、以下のコマンド。データが多い場合はすべて削除されるのに時間がかかるようです。
全て削除される前に、ycsbのloadを実行すると、キーがすでに存在しているとかのエラーになるので要注意です。
asinfo -v "set-config:context=namespace;id=ycsb;set=usertable;set-delete=true;"
データが削除されたかを確認するには、データベースノードで「aql」で入った後に「show sets」で確認します。すると以下の感じで表示されます。
+-----------+------------------+----------------+-------------------+----------------+---------+-------------+------------+ | n_objects | disable-eviction | set-enable-xdr | stop-writes-count | n-bytes-memory | ns_name | set_name | set-delete | +-----------+------------------+----------------+-------------------+----------------+---------+-------------+------------+ | 345063 | "false" | "use-default" | 0 | 0 | "ycsb" | "usertable" | "false" | +-----------+------------------+----------------+-------------------+----------------+---------+-------------+------------+ 1 row in set (0.000 secs)
今回はクラスタ構成にチャレンジしました。設定は簡単。
設定ファイルに「mesh-seed-address-port」のところで自分以外のサーバーのIPアドレスを追加するだけみたい。
それで複数のサーバーでサービスを起動させると、もともとデータが入っていると、勝手に同期が始まるようです。
クラスタ構成は、asadmコマンドで確認できます。本コマンドでは、ノードごとのマスター件数などもわかります。
Documentation | Aerospike
[ec2-user@ip-xx-xx-xx-xx YCSB]$ asadm -e info -h xx.xx.xx.aa ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Network Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Node Node Ip Build Cluster Cluster Cluster Principal Client Uptime . Id . . Size Key Integrity . Conns . ip-xx-xx-xx-aa.us-west-1.compute.internal:3000 *BB9AC4AD410DF06 xx.xx.xx.aa:3000 C-3.8.2.3 3 8FDC01A429213D62 True BB9AC4AD410DF06 5 00:22:13 ip-xx-xx-xx-bb.us-west-1.compute.internal:3000 BB98CE423192806 xx.xx.xx.bb:3000 C-3.8.2.3 3 8FDC01A429213D62 True BB9AC4AD410DF06 5 00:16:49 ip-xx-xx-xx-cc.us-west-1.compute.internal:3000 BB980F34E0EDF06 xx.xx.xx.cc:3000 C-3.8.2.3 3 8FDC01A429213D62 True BB9AC4AD410DF06 5 00:16:38 Number of rows: 3 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Namespace Information~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Namespace Node Avail% Evictions Master Replica Repl Stop Pending Disk Disk HWM Mem Mem HWM Stop . . . . Objects Objects Factor Writes Migrates Used Used% Disk% Used Used% Mem% Writes% . . . . . . . . (tx%,rx%) . . . . . . . ycsb ip-xx-xx-xx-aa.us-west-1.compute.internal:3000 90 0 322.056 K 341.691 K 2 false (0,0) 972.286 MB 10 50 40.512 MB 4 60 90 ycsb ip-xx-xx-xx-bb.us-west-1.compute.internal:3000 90 0 337.478 K 336.959 K 2 false (0,0) 987.945 MB 10 50 41.164 MB 5 60 90 ycsb ip-xx-xx-xx-cc.us-west-1.compute.internal:3000 90 0 340.466 K 321.350 K 2 false (0,0) 969.457 MB 10 50 40.394 MB 1 60 90 ycsb 0 1.000 M 1.000 M (0,0) 2.861 GB 122.070 MB Number of rows: 4
したがって、前述のasinfoでデータを消すオペレーションを実行すると、ここに表示されるオブジェクト数が0になります。
で、ちなみにパフォーマンスはどうなったかというと、さっくり、以下のようなかんじでした。
ノード数 | スループット(load) | スループット(run) |
1 | Throughput(ops/sec), 8781.173164734808 | Throughput(ops/sec), 3114.096754847738 |
2 | Throughput(ops/sec), 5840.405090497077 | Throughput(ops/sec), 5956.125094127134 |
3 | Throughput(ops/sec), 5683.335890834484 | Throughput(ops/sec), 5758.298796657827 |
EC2上のAerospikeでycsbを実行(2)
先日以下のトライアルをやりました。
takumats.hatenablog.com
で、元の記事をよく見ると、N.CaliforniaにあるaerobenchなるAMIを使うように書いてあることに今更ながらきづきました。
ということで、試してみました。
http://www.aerospike.com/docs/benchmarks/cassandra/simple_ycsb/index.html
ただし、インスタンスタイプは引き続きt2.microを使っています。
すると、ほとんどのセットアップがすでに済んでいたので、難なく実行可能でした。
ただ、Cassandraがうまく起動できませんでした。t2.microを使っているせいだと思いますが、いまいち原因特定できていません・・・。
札幌UIターンナイト2017新年会、に急遽参加(2017年1月6日@札幌)
当日に急遽ご案内をいただいたので、以下の「札幌UIターンナイト2017新年会」に参加してきました。
sapporo-iju.jp
sapporo-iju.jp
私も移住者なので意外と興味のあるイベントでした。
札幌への(札幌に限らずでしょうが)移住にあたっては「仕事」(=収入)が非常に重要だというお話は、非常に納得するところ。
ビッグの方のお話し、とても面白かったです。
ちなみに、1月末に移住促進?のイベントがあるようです。
sapporo-iju.jp
25社の出展枠に倍程度の応募があったとか。札幌の会社の採用意欲は高いことは高いです。どこで話を聞いても人がなかなか採用できないと聞きますしね。。
EC2上のAerospikeでycsbを実行
先日AerospikeをEC2(もちろん無料Tierのt2.micro)で試してみました。
takumats.hatenablog.com
今回は、そこにycsbを入れてみますが、手順は先日Windows上のVirtualboxでやったのと同じなので割愛。ちなみにAerospikeのページをよく読むと、ycsbをインストール済みのaerobenchというAMIが公開されているとのことだが、見当たらなかった。(と思ったら、N. Californiaにありました。後から気づきました。)
takumats.hatenablog.com
基本的にはAerospikeのサイトにある以下の手順に従えば実行できます。
Documentation | Aerospike
が、ここで問題。マシンのサイズが小さすぎるので、デフォルトのworkload-shortloadが動きません。なので、workload-shortloadをコピーしてworkload-shortload2を作成し、最初のrecordcountと、operationcountを適当に10分の1(=100000)にしました。
これで見事実行できます。ちなみにloadは2回やろうとすると、キー重複のエラーになるので、今はメモリのみモード(永続化なしモード)なのでサービスを都度再起動すると楽勝です。runは何回でも実行可能です(でした)。
[ec2-user@ip-xxx-xx-xx-xx YCSB]$ bin/ycsb load aerospike -s -threads 100 -P workloads/workload-shortload2 -p as.host=127.0.0.1 [WARN] Running against a source checkout. In order to get our runtime dependencies we'll have to invoke Maven. Depending on the state of your system, this may take ~30-45 seconds (中略) [OVERALL], RunTime(ms), 6793.0 [OVERALL], Throughput(ops/sec), 14721.036360959812 [CLEANUP], Operations, 100 [CLEANUP], AverageLatency(us), 43.14 [CLEANUP], LatencyVariance(us), 629.1203999999998 [CLEANUP], MinLatency(us), 27 [CLEANUP], MaxLatency(us), 238 [CLEANUP], 95thPercentileLatency(us), 0 [CLEANUP], 99thPercentileLatency(us), 0 [CLEANUP], 0, 100 [CLEANUP], 1, 0 [CLEANUP], 2, 0 (中略) [INSERT], Operations, 100000 [INSERT], AverageLatency(us), 6032.59377 [INSERT], LatencyVariance(us), 3.942717181160718E7 [INSERT], MinLatency(us), 27 [INSERT], MaxLatency(us), 197585 [INSERT], 95thPercentileLatency(us), 16000 [INSERT], 99thPercentileLatency(us), 24000 [INSERT], Return=OK, 100000 [INSERT], 0, 3173 [INSERT], 1, 807 [INSERT], 2, 995 [INSERT], 3, 8158 (後略)
ちなみに、たくさん出てくる以下の列はヒストグラム情報。
[INSERT], 0, 3173 [INSERT], 1, 807 [INSERT], 2, 995 [INSERT], 3, 8158
以下のようなグラフを描けます(実際には1000分割してるけど、グラフが見づらいので上位100のみで描画)
なお、このヒストグラム出力の細かい設定は、ycsbのworkload設定ファイルで可能な模様です。
runの場合も、workload-shortrunが大きすぎるので、workload-shortrun2を作って、10分の1サイズにします。
ちなみに、このaerospikeのworkload-shortrunの中身で、operationcountが0になっています。ただ、ここが0でも実際にはオペレーションが全くないということではなさそうなので、よくわかりません。
Aerospike Webinar "2017 DB Trends for Powering Real-Time Systems of Engagement" 聴講 (2016/12/15)
Aerospike Webinarを日本時間2016/12/15 4amから見ていました。
Aerospikeは高速性を売りにしたNoSQLデータベース。
特徴は、
- SSDをネイティブサポートすることによる高速性
- 応答速度の安定性
- スケールアウトが用意
CassandraやRedisの置き換えを想定しています。
であることがあげられます。
Adtechなどでの採用が日本でも進んでいます。
Sapporo Tech Bar #5開催 (2016/12/19@札幌)
おなじみのSapporo Tech Bar #5を開催しました。
www.db-tech-showcase.com
今回はMariaDB/MySQLスペシャルということで、PerconaからColinさんと、ストレージエンジンSpiderの開発者であるスパイラルアーム社の斯波さんに講演いただくことができました。お二方とも、なかなか札幌でお目にかかるのは難しい方々です。
www.percona.com
www.spiderformysql.com
ColinさんはMariaDBで働かれていて、つい最近Percona社に移られた方で、MySQL、MariaDB、Perconaに対してのバックグラウンドが豊富です。講演ではMySQL(とその仲間たち)の歴史から将来まで俯瞰いただくことができました。
www.percona.com
www.percona.com
www.publickey1.jp
www.percona.com
斯波さんはストレージエンジンSpiderの開発者です。
MySQLはストレージエンジンを選択できるのが特徴の一つです。
thinkit.co.jp
Spiderはフェデレーション、シャーディングをMySQLで実現するエンジンでMariaDBには現在バンドルされています。
d.hatena.ne.jp
Spiderは海外でいうと、中国テンセント社での利用が有名です。
日本だとSansan社が使っていたようです。
今回忘年会スペシャルということで、初めて、Sapporo Tech Bar終了後に懇親会を催しました。
予想以上の方々に来ていただいて、非常に感謝しております。
来年もどうぞSapporo Tech Barをよろしくお願いいたします。