いまさら Redash の マルチバイト検索対応について調べてみた

f:id:ariarijp:20200831234000p:plain

設定画面にある Feature Flags > Enable multi-byte。

日本のユーザーならオンにしていることが多いと思いますが、この設定をオンにすると内部的には何が起きるのか。

v9.0.0-beta ブランチで確認した結果、答えは「PostgreSQL全文検索の仕組みを使わず、キーワードがクエリ名または説明文に含まれるかを ILIKE で部分一致検索する」でした。

github.com

日本語で全文検索と言えば PGroonga が思いついたのでドキュメントを眺めてみると、PostgreSQL全文検索は英数字のみサポートしていると書いてありました。

Redash が内部的に利用している SQLAlchemy-Searchable が CJK をサポートしていないのかと思っていたのですが、どうやら PostgreSQL全文検索の制約のようです。

PGroonga は Docker イメージも公開されているので、Redash に組み込めるか検証したくなってきました。

メッシュ WiFi の導入後 Nature Remo の WiFi 再設定がうまくいかなかったときにやったこと

COVID-19 の影響でリモートワーク生活が続いていますが、居室と仕事部屋が対角線上の位置にあり、ときおり ZOOM などが不安定になってしまうので、以前から気になっていたメッシュ WiFi を導入しました。

期待する結果(少なくとも電波強度は明らかに改善しました)がでるかは明日以降の仕事でわかるのですが、そのまえに自宅のネットワーク環境をすべて切り替えるのにひと苦労あったという話です。

ちなみに、これまでは TP-Link の C3150 を使っていたので、メッシュ WiFi の構築に使った機器は TP-Link の deco シリーズ(m9 plus + m5)にしました。

自宅の回線が NURO なので、二重ルーターを避けるためブリッジモードで使っているのがやや残念です。

Nature Remo の WiFi 再接続がうまくいかない問題

難なく m9 plus と m5 でメッシュ WiFi を構成し、既存の C3150 を撤去した後に、いくつかの機器の設定を切り替え忘れていることに気づきました。

そのなかのひとつが、我が家ではテレビの電源操作などで重宝している Nature Remo でした。

設定し忘れたことに気づき、Nature Remo の Android アプリを開いてみたところ、以下のような再設定手順があったので、それに従って設定を進めました。

Q6-3. Nature RemoのWi-Fi情報を変更したい — Nature

しかし、接続先のアクセスポイントを指定しても、設定に失敗したとエラーがでてしまい、何度リセットボタンを教えても変わらず、先に進めない状態になりました。

念のため、アプリ上から既存のデバイス設定を削除し、新規デバイスとして再設定してみようとするも、結果は同じく失敗が続きます。

設置場所の電波環境も問題なく、ただ接続は失敗するという状況で気持ちが折れかけ、当面は Remo を諦めるかとも思ったのですが、ふと思い立った以下の対応でつながるようになりました。

  • メッシュ WiFi の中継側機器の電源を切る(WAN側の機器のみにする)
  • メッシュ WiFi の帯域を 2.4MHz のみ に設定する
  • メッシュ WiFi の WAN 側機器を再起動する

切り分けをしたわけではなく適当にやったので、実際どれかひとつの手順でよかったのか、あるいは全く他の問題が偶然おきていて、それによって設定ができなかったのかはわかりませんが、なんにしても私の場合はこの対応で解決できました。

再設定完了後は、中継機側を追加しても、5GHz を有効にしても、今のところ特に困らず利用できています。

既存の設定を削除してしまったことで、エアコンの設定などもすべて消えてしまったのですが、それによって導入以来 IFTTT 連携で使っていた設定をすべて削除し、Google アシスタントのみで動かせるように移行ができたのでよしとします。体感で2秒ぐらい、赤外線が飛ぶまでのラグが減った気がします。

珍しく Redash が一切でてこない記事になりました。

Redash が活きると思うところ、活かせないかもしれないところ

近々 Redash について話す機会があるのだけど、これから Redash を使ってみようと思う方に「どういう課題があったら試してみてほしいか」あるいは「こういうところでは Redash の良さが活きないかも」というのを考えているので、メモついでに公開。

念のため書いておきますが、これらはひとりの Redash ユーザー個人としての意見であり、また、Redash が公式に発表していることではありません。

Redash が活きると思うところ

  • データをチーム、組織、会社全体で共有したいが、コストは最小化したい
    • Redash は Self-hosted でも SaaS 版でもユーザー数無制限です
  • 扱いたいデータソースの種類が多い
  • データ抽出を毎回エンジニアへ依頼している
    • Redash によって解決された問題として一番わかりやすい例です
  • 社内にエンジニア組織があり、OSS プロダクトへの理解がある
    • とりあえず試してみる、わからなかったら調べる、どうしても変えたいところは自分で直すという気持ちがあると良いと思います
  • データ活用の文化を浸透させたい
    • Redash 利用をきっかけに社内で SQL やデータベースについての理解を深めるような取り組みをされているような企業も多いようです

Redash が活かせないかもしれないところ

  • 分析可能な形で蓄積されたデータがない
    • データ基盤がないと Redash は活躍しにくいかもしれません
    • 個人の印象ですが、BigQuery や Athena にデータを蓄積し、Redash からクエリーを実行するという事例が多いような気がします
  • 特に共有などは不要で、ひとりでデータを見られれば良い
    • デスクトップでサクサク動くTableau Desktop や Power BI などのツールから始めるのがよいかもしれません
      • これらのツールが「共有」をおろそかにしているという意味ではないです
  • コストを全くかけずに利用したい
    • Self-hosted でもインフラのコストは必要なので、必要なものにはコストをかけるということに理解が必要かもしれません
  • クエリーを絶対に書きたくない
    • 書かなくていいツールを探してみましょう。OSS では Metabase なども最近利用されている印象です
  • ダッシュボードやグラフに高い表現力を求めている
    • Redash のダッシュボードやグラフは必要十分なものではあると思いますが、言い方を変えると「素朴」なものでもあります
  • 日本語で手厚いサポートがほしい
    • 私の知る限りでは Redash の日本法人や代理店は無いので、やりとりは基本的に英語になります
    • 何か知りたいことがあれば、ドキュメントやソースコードを読むか、フォーラムで質問することになりますが、フォーラムで質問したら必ず回答が得られるわけでもないのでご注意ください

動画ファイルのコンタクトシートを vcsi を使ってコマンド一発で出力する

GitHub で Star/Fork したリポジトリを見直してて、便利だった記憶があるので個人的なメモ書き。

github.com

仕事柄動画ファイルに触れることが多いので、その時に調べたような気がする。

ちゃんと中身見てないけど、Pythonffmpeg をラップした感じのものだと思う。

使い方は以下。ffmpeg が必要なので vsci の README とかを参考によきように。パッケージマネージャは最近 Poetry 使うようにしている。

$ poetry init -n
$ poetry add vcsi
$ poetry run vcsi vsci.mov -t -w 850 -g 10x10
Processing vcsi.mov...
Sampling... 100/100
Composing contact sheet...
Cleaning up temporary files...

すると、10x10 のコンタクトシートを作ってくれる。

f:id:ariarijp:20200109140717j:plain

また何かの機会に使うことがあるかもしれない。

(余談として、サンプルが小さくてわかりにくいけど、手頃な動画がなかったので手元のターミナルで懐かしの sl コマンドを実行したものを動画キャプチャした)

2019年末版: Redash のメモリ使用量を節約する

まえがき

約2年前にこんな記事を書きました。

ariarijp.hatenablog.com

最近、Twitter で趣味の Redash エゴサをしていると、メモリ使用量でお悩みの方がいるようだったので、2019/12/20 現在で Redash のメモリ節約にチャレンジしてみます。

サクッといきます。

環境

先日公開した以下の記事の手順に沿って Vagrant 上で環境構築しました。

ariarijp.hatenablog.com

コンテナのリソース確認のため、 ctop も使います。

github.com

節約前

ctop コマンドで見るとこんな感じ。

f:id:ariarijp:20191220232537p:plain

ざっくり Redash のコンテナ群だけで1.2 GB 前後といったところでしょうか。

(注)PostgreSQL のメモリ使用量については、この記事ではいっさい触れません。

節約後

f:id:ariarijp:20191220232728p:plain

起動しているコンテナ自体が減っていることもありますが、全体で300MBほど。メモリ使用量だけでいえば 1/4 程度に収まりました。

何をやったか

サービス、プロセスを減らす

docker-compose.yml をいろいろ書き換えました。詳しくは diff を見てみましょう。

@@ -13,25 +13,13 @@
     ports:
       - "5000:5000"
     environment:
-      REDASH_WEB_WORKERS: 4
-  scheduler:
+      REDASH_WEB_WORKERS: 1
+  worker:
     <<: *redash-service
     command: scheduler
     environment:
-      QUEUES: "celery"
+      QUEUES: "celery,scheduled_queries,schemas,queries"
       WORKERS_COUNT: 1
-  scheduled_worker:
-    <<: *redash-service
-    command: worker
-    environment:
-      QUEUES: "scheduled_queries,schemas"
-      WORKERS_COUNT: 1
-  adhoc_worker:
-    <<: *redash-service
-    command: worker
-    environment:
-      QUEUES: "queries"
-      WORKERS_COUNT: 2
   redis:
     image: redis:5.0-alpine
     restart: always

Web のワーカーを減らす

性能度外視で節約を目的にするので、プロセス数を1にします

Celery のワーカーをまとめて減らす

デフォルトでは Celery の管理、スケジュール実行、アドホック実行と、3つのサービスにわかれていますが、それをひとつのサービスにまとめます。

ひとつのサービスに詰め込むことになるので、サービス名を worker としています。さらにワーカーのプロセス数も減らして 1 にします。

もちろん、キューが処理されるのは遅くなりますが、これも節約のためです。

使用しないクエリランナーを無効にする

Redash は多くのデータソースに対応している反面、依存パッケージも多く、それらの読み込みによってメモリが多く消費されるようです。

今回の検証では、PostgreSQLMySQLSQLite、BigQuery 以外は無効にするため、以下の設定を /opt/redash/env に追加しました。

REDASH_DISABLED_QUERY_RUNNERS=redash.query_runner.athena,redash.query_runner.google_spreadsheets,redash.query_runner.graphite,redash.query_runner.mongodb,redash.query_runner.couchbase,redash.query_runner.url,redash.query_runner.influx_db,redash.query_runner.elasticsearch,redash.query_runner.amazon_elasticsearch,redash.query_runner.presto,redash.query_runner.databricks,redash.query_runner.hive_ds,redash.query_runner.impala_ds,redash.query_runner.vertica,redash.query_runner.clickhouse,redash.query_runner.yandex_metrica,redash.query_runner.rockset,redash.query_runner.treasuredata,redash.query_runner.dynamodb_sql,redash.query_runner.mssql,redash.query_runner.memsql_ds,redash.query_runner.mapd,redash.query_runner.jql,redash.query_runner.google_analytics,redash.query_runner.axibase_tsd,redash.query_runner.salesforce,redash.query_runner.prometheus,redash.query_runner.qubole,redash.query_runner.db2,redash.query_runner.druid,redash.query_runner.kylin,redash.query_runner.drill,redash.query_runner.uptycs,redash.query_runner.snowflake,redash.query_runner.phoenix,redash.query_runner.json_ds,redash.query_runner.cass,redash.query_runner.dgraph,redash.query_runner.azure_kusto

まとめ

とにかくメモリ使用量を減らすことに集中すると、設定を変えるだけでかなり多くのメモリを節約できます。実用性はともかく、ここまでやれば AWS EC2 の t3.micro 相当でもなんとか動かせるのではないかなと思います。

この記事で紹介した設定はあくまでメモリ使用量節約のデモであり、そのまま使うことはおすすめできませんが、使っていないデータソースの精査だけでも効果が大きいというのを以前の記事でもご紹介していますので、まずはそこから手を付けてみるのが良いと思います。

この記事が Redash の運用でお困りのかたの役に立つとうれしいです。