まだプログラマーですが何か?

プログラマーネタ中心。たまに作成したウェブサービス関連の話も https://twitter.com/dotnsf

タグ:redis

備忘録的なブログエントリです。

高速なメモリストアである RedisNode.js から使う場合に多く利用されるライブラリの代表が node-redis です:
2022013000


自分もこれまでに開発した多くのアプリの中で Redis を利用し、Node.js で実装していた場合はほぼ全てで node-redis を使っていました。いわゆる Key-Value 型のデータベースで、高速なデータストア用途だけでなく、ログインセッションの共有保管場所としても使っていました。

これまで使ってきた中でこのような用途がなかったからではあるのですが、今回「登録されている全てのデータのキー」を取得したい、ということがあり、すぐにわからなかったので調べてみました。要は全データを取り出したいのですが、そのためには全キーが必要で、その取得方法を知りたかったのでした。本ブログエントリはその調査結果でもあります。

結論としては RedisClient の keys() というメソッドを使うことで全キーを取得できます。以下サンプルです:
var redis = require( 'redis' );
var redisClient = redis.createClient( "redis://localhost:6379", {} );
redisClient.keys( '*', function( err, results ){
  if( err ){
  }else{
    :
  (results に全キーが配列で格納されている)
    :
  }
});


keys() メソッドを '*'(全て)というパラメータを付けて実行することで全てのキーを取得することができます。

redis CLI でも、
> keys *

のように実行してキー一覧を取得できることは知っていたのですが、node-redis ライブラリで取得する場合の方法を調べるのに手間取ったこともあって、自分でまとめておきました。

IBM Cloud から提供されている 30 日間無料 Kubernetes サービスIBM Kubernetes Service 、以下 "IKS")環境を使って利用することのできるコンテナイメージを1日に1個ずつ 30 日間連続で紹介していきます。

環境のセットアップや制約事項については Day0 のこちらの記事を参照してください。

Day 6 からはデータベース系コンテナとその GUI ツールを中心に紹介してます。Day 12 ではメモリキャッシュとしても利用されている Redis イメージをデプロイする例を紹介します。
redis



【イメージの概要】
キー・バリュー型のメモリデータベースです。I/O にディスクアクセスを伴わないため、高速なトランザクション処理が可能です。また最近のコンテナ化の中でこの高速性を共有セッションの管理などの用途に使われることも多くなっています。



【イメージのデプロイ】
まずはこちらのファイルを自分の PC にダウンロードしてください:
https://raw.githubusercontent.com/dotnsf/yamls_for_iks/main/redis.yaml


今回の Redis は特にパラメータ指定不要で、そのままデプロイすることができます。以下のコマンドを実行する前に Day 0 の内容を参照して ibmcloud CLI ツールで IBM Cloud にログインし、クラスタに接続するまでを済ませておいてください。

そして以下のコマンドを実行します:
$ kubectl apply -f redis.yaml

以下のコマンドで Redis 関連の Deployment, Service, Pod, Replicaset が1つずつ生成されたことと、サービスが 30379 番ポートで公開されていることを確認します:
$ kubectl get all

NAME                        READY   STATUS    RESTARTS   AGE
pod/redis-fd794cd65-8phh2   1/1     Running   0          58s

NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/kubernetes    ClusterIP   172.21.0.1      <none>        443/TCP          27d
service/redisserver   NodePort    172.21.187.90   <none>        6379:30379/TCP   60s

NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/redis   1/1     1            1           59s

NAME                              DESIRED   CURRENT   READY   AGE
replicaset.apps/redis-fd794cd65   1         1         1       59s

この後に実際にサービスを利用するため、以下のコマンドでワーカーノードのパブリック IP アドレスを確認します(以下の例であれば 161.51.204.190):
$ ibmcloud ks worker ls --cluster=mycluster-free
OK
ID                                                       パブリック IP    プライベート IP   フレーバー   状態     状況    ゾーン   バージョン
kube-c3biujbf074rs3rl76t0-myclusterfr-default-000000df   169.51.204.190   10.144.185.144    free         normal   Ready   mil01    1.20.7_1543*

つまりこの時点で(上述の結果であれば)アプリケーションは 169.51.204.190:30379 で稼働している、ということになります。これまでの例と同様、動作確認は次回の GUI ツールのインストール後に行うことにするので、今回はこのデプロイ作業までとします。



【YAML ファイルの解説】
YAML ファイルはこちらを使っています(編集する前の状態です):
apiVersion: v1
kind: Service
metadata:
  name: redisserver
spec:
  selector:
    app: redis
  ports:
  - port: 6379
    protocol: TCP
    targetPort: 6379
    nodePort: 30379
  type: NodePort
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis
spec:
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis
        ports:
        - containerPort: 6379

Deployment 1つと、Service 1つのごくごくシンプルな YAML ファイルですが、一応解説を加えておきます。アプリケーションそのものは 6379 番ポートで動作するように作られているため、NodePort 30080 番を指定して、外部からは 30080 番ポートでアクセスできるようにしています(NodePort として指定可能な番号の範囲は 30000 ~ 32767 です、指定しない場合は空いている番号がランダムに割り振られます)。また ReplicaSet は1つだけで作りました(データベースなので、別途クラスタ構成の準備をしない限りはこの数値だけを増やしてもあまり意味ないと思います)。


デプロイしたコンテナイメージを削除する場合はデプロイ時に使った YAML ファイルを再度使って、以下のコマンドを実行します。不要であれば削除しておきましょう(ちなみにこの Redis コンテナは明日の Day 13 でも使う予定なので、削除するのはそのあとの方がいいかもしれません):
$ kubectl delete -f redis.yaml


【紹介したイメージ】
https://hub.docker.com/_/redis


【紹介記録】
Dayカテゴリーデプロイ内容
0準備準備作業
1ウェブサーバーhostname
2Apache HTTP
3Nginx
4Tomcat
5Websphere Liberty
6データベースMySQL
7phpMyAdmin
8PostgreSQL
9pgAdmin4
10MongoDB
11Mongo-Express
12Redis
13RedisCommander
14ElasticSearch
15Kibana
16CouchDB
17CouchBase
18HATOYA
19プログラミングNode-RED
20Scratch
21Eclipse Orion
22Swagger Editor
23R Studio
24Jenkins
25アプリケーションFX
262048
27DOS Box
28VNC Server(Lubuntu)
29Drupal
30WordPress

(↓2015/Jan/26追記)
このブログエントリに書かれている内容は最新のものではありません。ご注意ください。
また、こちらの記事も参照ください:
Bluemix 内の MySQL データベースでサイズが選択可能になった
(↑2015/Jan/26追記)


IBM BlueMix からは数多くのデータストアサービスが提供されています。RDB(リレーショナルデータベース)だけでも4つあります(青っぽい背景のが IBM 提供サービス、白背景のがオープンソースベースのコミュニティ提供サービスです):

※2014年4月23日時点の情報を元に記述しています。詳しくは各リンク先を参照ください。
サービス価格最大サイズ説明
BLUEAccelerationベータ期間は無料標準で圧縮後1GB(最大10GBまで拡張可能)サイズは圧縮後のサイズなので、実際にはこれら以上のデータを格納可能
SQLDBベータ期間は無料1GB最大接続数は2(BlueMix環境からのみ)
MySQL無料10MB最大接続数は1000
PostgreSQL無料30MB最大接続数は1000

容量10MB のデータベースって・・・ (^^;

ちなみに RDB 以外のデータストアサービスについてはこんな感じです:

サービス価格最大サイズ説明
JSON DBベータ期間は無料1GBJSON ストア型
MongoDB無料250 MBJSON ストア型
Redis無料N/A (?)KEY-VALUE ストア型
Mobile Dataベータ期間は無料(?)ローカルネイティブのように使えるモバイル向けデータストア


それなりに実用的な量のデータを格納しようとすると、IBM 提供のデータストアサービスを選ぶことになるんでしょうかね。リレーションなしと割りきって JSON 型の MongoDB を選ぶという選択もあるけど。

この表だとわかりにくい差もあると思っています。例えば MySQL や MongoDB などは管理コンソールを別途 phpMyAdmin や phpMoAdmin などで用意する必要があります(参照)。一方、BLUAcceleration や SQLDB には標準で管理コンソール機能が付属していたりします。
2014042201


ちなみに BlueMix のサービスで MySQL を立ちあげた場合、BlueMix 内のアプリケーションサーバーからしか接続できません。ただし BlueMix の外で稼働している MySQL に BlueMix のアプリケーションサーバーから接続することは(パフォーマンスに目をつぶれば)可能でした。なので意地悪く特定のポートが閉じられている、とかいうことはなさそうです。どうしても MySQL で10MB以上のデータを使いたい、ということであればデータベースだけは外部接続にする、という選択肢もありますね(遅いし、PaaS のメリットも薄くなるのでオススメしませんけど)。



このページのトップヘ