2019年10月に社内LTにて発表したものです。 MyTwitter→ https://twitter.com/inukujira

1. RDBMSより高速なNoSQLを
実際に使ってみた話
ビッグデータとうまく付き合うために
Written by 犬クジラ at Oct 31 2019

2. NoSQLってなに？

3. 一般的なRDBMS(PostgreSQLとかOracleとか色々)は、
行と列を持つ表形式のデータ（テーブル構造）によって管
理されていますが、NoSQLはこの表形式のテーブル構造の
枠に収まらない（収めない）データを扱うデータベース、
またはデータ処理エンジンの事を言います。
NoSQLはざっくりRDBMS以外の事

4. NoSQLの種類

5. 広く認知されているタイプは３種類ほんとはもっと色々あるよ

6. キーバリュー型
キーバリュー(Key-Value)型は、「キー（Key）」に対して「値（Value）」が決まるタイプ
広く認知されているタイプは３種類ほんとはもっと色々あるよ

7. キーバリュー型
キーバリュー(Key-Value)型は、「キー（Key）」に対して「値（Value）」が決まるタイプ
ドキュメント型
JSON形式やXML形式のような階層型で使うタイプ
広く認知されているタイプは３種類ほんとはもっと色々あるよ

8. キーバリュー型
キーバリュー(Key-Value)型は、「キー（Key）」に対して「値（Value）」が決まるタイプ
ドキュメント型
JSON形式やXML形式のような階層型で使うタイプ
グラフ型
ノード間の「関係性」を構成して利用するタイプ（マインドマップの相関図みたいなやつかなたぶん）
広く認知されているタイプは３種類ほんとはもっと色々あるよ

9. キーバリュー型のNoSQLで有名な
Redisを使って速度検証してみました

10. キーバリュー型のNoSQLで有名な
Redisを使って速度検証してみました
インメモリ上で動いてくれるNoSQL
実際にRDBMSみたいにディスク上に書き出したり
レプリケーション機能ももってるスグレモノ
連想配列、リスト、セットとか色々なデータ構造を扱える

11. Compute Engine：f1-micro（vCPU x 1、メモリ 0.6 GB）
OS：CentOS7
Redis：5.0.6
PostgreSQL：11.0
検証環境
無料のGCPインスタンスにRedisとPostgreSQLを入れただけ

12. 検証方法
GraphQLを利用して530000レコー
ドをPostgreSQLとRedis上で
INSERT、SELECT処理を行い、それ
ぞれの応答時間を計測・比較します。

13. INSERTの応答時間

14. INSERT内容

15. INSERT結果
45秒前後くらい。
無料枠GCP上のRDBMSにして
は想像以上に速かった。
53万レコードの挿入

16. INSERT結果
45秒前後くらい。
無料枠GCP上のRDBMSにして
は想像以上に速かった。
さすがインメモリDB。ディス
クIOも走らないので別次元の
結果でした。
53万レコードの挿入 0.2秒の爆速！！
ニュートリノですか？

17. SELECTの応答時間

18. SELECT内容

19. SELECT結果
INSERTよりもおよそ半分の時
間で取得。直でSQL文叩くより
も若干早い気がした。
このあたりはTypeORMの恩恵か？
53万レコードの取得

20. SELECT結果
INSERTよりもおよそ半分の時
間で取得。直でSQL文叩くより
も若干早い気がした。
このあたりはTypeORMの恩恵か？
53万レコードの取得
GraphQL用への再編成処理を除
いても時間は変わらず。メモ
リ動作周波数の性能かも？
RDBMSの約半
分
でも0.2秒のINSERTと比べて遅いなー

21. 検証結果の感想

22. そこそこ大きなテーブル操作
でもやり方次第では高速に処
理が可能。RDBMSの性質上デ
ィスク性能によって大きくパ
フォーマンス変動するのでSSD
ならもう少し早いかも？

23. そこそこ大きなテーブル操作
でもやり方次第では高速に処
理が可能。RDBMSの性質上デ
ィスク性能によって大きくパ
フォーマンス変動するのでSSD
ならもう少し早いかも？
インメモリDBだけあって
INSERTはRDBMSと比較になら
ないほど高速だった反面、
SELECTに関してはPostgreSQLと
比較して思ったほど差は開か
ず。それでも２倍近く早いけど。

24. 試しにSSD上でも比較

25. 自宅ノーパソ：CPU:Core i7-3520M 2.90GHz メモリ:DDR3 1600 PC3-12800 8GB、SSD:128GB
OS：RedHat Linux 7.4
Redis：5.0.6
PostgreSQL：11.0
検証環境
眠ってたSSD入りノーパソ(Dell latitude e6230)でやる
よ

26. 実行結果
GCPに比べて飛躍的に早くな
ったけどおそらくSSDの恩恵以
外にネットワークの問題も大
きいかも？でも早い！
INSERT
SELECT
GCP：45秒 → PC：9秒
GCP：21秒 → PC：1.5秒

27. 実行結果
GCPに比べて飛躍的に早くな
ったけどおそらくSSDの恩恵以
外にネットワークの問題も大
きいかも？でも早い！
INSERTと同じく爆速！！GCP上
では時間かかってたけどなぜ
ここまで早くなったのか不明…
ネットワーク以外による何かの理由があるはず。ECCの有り無し？
INSERT
SELECT
INSERT
SELECT
GCP：45秒 → PC：9秒
GCP：21秒 → PC：1.5秒
GCP：0.2秒 → PC：0.18秒
GCP：12秒 → PC：0.18秒 (同じジャン…)
SELECTはやっ！！！

28. 利用方法

29. ぼくのかんがえたさいきょうのこーせー
Redis
キャッシュDBとして、いつ消えてもいいデータ
PostgreSQL
いつものRDBMSとして
GraphQL
EntryPointならなんでもOK
知らない人はスルーで！

30. ぼくのかんがえたさいきょうのこーせー
Redis
キャッシュDBとして、いつ消えてもいいデータ
PostgreSQL
いつものRDBMSとして
GraphQL
EntryPointならなんでもOK
知らない人はスルーで！
１．更新系の処理 ２．更新された値をキャッシュ
DBへ挿入する
３．RDBMSよりPUSHされ参照さ
れてもいい状態になる

31. ぼくのかんがえたさいきょうのこーせー
Redis
キャッシュDBとして、いつ消えてもいいデータ
PostgreSQL
いつものRDBMSとして
GraphQL
EntryPointならなんでもOK
知らない人はスルーで！
１．更新系の処理 ２．更新された値をキャッシュ
DBへ挿入する
３．RDBMSよりPUSHされ参照さ
れてもいい状態になる
１．参照系の処理 ２．RDBMSよりPUSHされ参照さ
れてもいい状態になる
使わない
mutation
query

32. まとめ
・NoSQLはRDBMSの代わりにはならない
基本的にトランザクションの概念がないのでデータの整合性に一貫性がなく更新や削除などの処理には向いてない
参照したり追加したりする事に特化しているので一時的なキャッシュや一部参照用DBとしての利用にとどめておく

33. まとめ
・NoSQLはRDBMSの代わりにはならない
基本的にトランザクションの概念がないのでデータの整合性に一貫性がなく更新や削除などの処理には向いてない
参照したり追加したりする事に特化しているので一時的なキャッシュや一部参照用DBとしての利用にとどめておく
・それぞれの特性を適材適所うまく使う事でいい感じになる
極論ですが大量のデータでもサクッと瞬時に処理してくれるアプリは”いい作り”である
逆に少量のデータでもっさり激重アプリは…まぁ…うん…。なのでこういう技術と向き合う事って大事だなと思った

34. ありがとうございました！
Written by 犬クジラ at Oct 31 2019