【勉強会メモ】【ヒカ☆ラボ】有名サービス開発エンジニア登壇のLT大会
- 日時：2018/10/27(土) 13:00 〜 17:00
- 場所：サイボウズ 大阪オフィス
サイボウズ、ロックオン、ウェブリオのエンジニアが登壇するヒカラボ主催のイベント。今回のテーマは「自動テスト」です。大阪では数少ない自社サービスを扱う会社の地道な取り組み事例を知ることができる貴重な機会でした。
kintoneのリリースを加速する！性能検証自動化
サイボウズ 鈴木 亜耶さん
kintoneのリリース
- 2015年：5回
- 2016年：8回
- 2017年：10回
- 2018年：12回＋α
- 基本1ヶ月に1回リリース
間隔が短くなった要因
- もっと早く出したいという思い
- やってみたら意外とできた
- UI変更が伴い・伴わないでリリース付きを分けていた
- いつの間にかどの月でもUI変更リリースをするように
- スクラム導入
- 職能横断でプロセス最適化
もっと早くリリースしたい
- 9月から週1リリースの試み
- プロセス改善である程度できた
- 週1リリースできる対応が限定されている
- UI変更：☓
- 性能に影響がありそうなもの：☓
UI変更
- いきなり使い勝手が変わると顧客が困る
- 顧客ごとのカスタマイズに影響がでる可能性がある
- 実装したものの品質が担保できないわけではない
実現するには社外との調整が必要
性能に影響がありそうなもの
- 性能検証が必要
- 現状のままだと週1実施はつらい
開発サイクル1ヶ月
- 特定の機能の検証はその都度検証
- 全体の検証は1ヶ月の開発期間の最後に検証⇒数日かかる
現状のままだと週1実施はつらい→やり方を変えよう
性能検証の自動化
ScaleBench
内製の負荷テストツール
VU（バーチャルユーザー）が高いほうが性能が良いという喧騒
- ある操作のシナリオを安定して操作できるユーザー数の最大
従来の性能検証
- 時間がかかる（特に準備）
- 指標の解釈が難しい
- 前月版は1200VUで今月版は1100VUなので9%劣化
- どの操作が遅くなったのかわかりづらい
- 様々なシナリオが混ざっている
単に自動化するだけなら満足できない
- APIごとに性能をみたい
- 性能劣化に繋がった改修を見つけるのが容易になる
性能のいろいろな観点
- 処理が早い→レスポンスタイム
- 同時にたくさん処理できる→スループット
- リソースを食わない→リソース使用量
⇒指標はレスポンスタイムにする
- これだけだと同時に処理したときの性能が担保できない
- 本番環境では同時に複数人が使う
- 本番の使われ方に近いリクエスト種・量で性能を見たい
⇒スループットも見る
２つの自動テスト
- パフォーマンステスト
- ロードテスト
パフォーマンステスト
- kibanaのダッシュボード
- どのビルドでどれくらいのレスポンスかがわかる
- 性能チェック&通知
- Jenkinsからチャットに投稿
- 計測：Junit
- ApachCommonsのStopWatch
- 計測結果：Elasticsearch
- 可視化：Kibana
- kintoneを使っていたがkibanaの可視化が強力だったので移行
- データ分析に特化しているので良いものは活用する
- チェック結果：kintone
ロードテスト
リソース使用量は別ダッシュボード
- Locust→Python製のシナリオテストツール
参考
- 計測：Locust
- リソースモニタ：Prometheus
- リソース使用量の可視化：Grafana
- リソース周りはもともと開発環境にあったものを転用
2つの性能検証のこれから
- まだ開発プロセスには組み込まれていない
- 1日4回実行
- パフォーマンステスト：4.5時間
- ロードテスト2時間
- 過去の性能劣化ケースを再現させて検知できるか検証中
- 一部ケースの安定化が課題
- APIによっては安定しない（悪化しているのかわからない）ものもある
安定化の課題
- パフォーマンステストの安定化の取り組みについて
以前の資料
www.slideshare.net
オープンソースEC-CUBEを支えるテストのしくみ
ロックオン 遠藤 良さん
EC-CUBEの開発スタイル
システム要件いろいろ
- PHPバージョン
- サポートDBいろいろ
EC-CUBEを支えるテストのしくみ
- TravisCIを利用
- ユニットテスト
- DBとPHPのバージョンを分けてテスト
- E2Eテスト
- MySQL,PostgreSQLわけてテスト
- AppVeyar
- 静的解析
※AppVeyar
自動テスト
- 複数環境でテストができる安心感
- 修正内容に問題がないか自動ですぐにフィードバックできる
- テストNGだった場合に取り込めない理由が明確にわかる
非機能要件の自動テスト
- より多くの環境でのテスト…Codeception
- パフォーマンス計測…ApacheBench
- セキュリティ解析…Vady
時間コスト高
- 毎日1回のみ実施
テストをより細かく
- PostgreSQL 9.2,9.6
- MySQL 5.5,5.6
- Chrome,firefox
- Root,Sub（インストールディレクトリ）
パフォーマンス計測（Apache Bench）
セキュリティ検査（Vaddy）
- E2Eテストを流用してクロール
- 毎日セキュリティ検査をしているという安心感
3年間の積み重ね
- 2015年
- ver.2
- 自動テストなし
- リリース前に長期テスト→1ヶ月ぐらい
- 2016年〜2017年
- ver.3
- Unitテストラインカバレッジ80%
- E2Eテスト
- 静的解析
- セキュリティて検査
- 2018年
- ver.4
- E2Eテスト
- パフォーマンス計測
いろいろなTRY
チームでふりかえり
- 自動テストも継続して改善
- よりスピード感を持って価値を生むことにフォーカスするために
DockerとJenkinsを使った開発速度と品質の向上
ウェブリオ平野 昌士 さん
DOckerを使った開発実践例
Dockerがなかったあの頃
- 環境構築で2日
- 手順書に書かれていない設定
- Windowsの手順しかない
- 手順書通りやっても動かない
Docker導入後
- Dockerコンテナを起動するだけ
- 開発者の環境が統一
- 環境構築の手順書作成の手間を省略
- イメージの再配布だけ
- 開発者がインフラの設定不要
Dockerの導入
- 開発環境、Jenkins,Redashなど
- docker-composeを使ってイメージのpullから起動まで
- Dockerイメージは社内のDockerレジストリ
Dockerfileの記述
- 構築手順が明確
- しかしビルドには時間がかかる
PrivateなDockerリポジトリ
- 社内におけるDockerレジストリ
- Docker HubのようにDockerイメージの配信
- Dockerfileからビルドしたイメージをpush
- イメージを作るDockerfileはGithubで管理
Docker辛かったところ
- Docker for Mac重い問題
- volumeでマウントしているホストファイルへのアクセスが原因
- DockerがosdxfsでFile Systemを監視しているのが原因
- ファイルの変更が多いとCPU負荷ががんが上がる
- 重くなったらDocker for Macを再起動
- Reset to factory defaultsを実行
- cachedオプションをつける
Dockerイメージ・コンテナが増えすぎる問題
- 全コンテナ停止、全コンテナ削除、イメージ削除コマンドを使う
ホストのマシン再起動後コンテナが起動されない
- 起動し忘れ
- 1つずつ主導でコンテナを起動するのが手間
- restart: "always" を設定
ここまでのまとめ
- 機械でできることは機械に任せる
- 手間を省いて開発速度を向上
- 手順見える化
Jenkinsを使った開発実践例
Jenkins
Jenkinsおじさんがいなかったあの頃
- テスト実行が手動
- 目視でレビュー
- デプロイも手動
CI導入後
- ビルド、テストデプロイが自動
- ユニットテストやE2E自動
- 静的解析も自動
- ヒューマンエラー減った
JenkinsはDocker上で動く
- アプリケーションごとに技術が違うためそれぞれのSlave用コンテナがある
Weblioの開発フロー
- developからブランチを切って開発しdevelopにマージ
- 開発完了→staging→QAやビジネスサイドのテスト→master
PR Builderを使った検証
- PRごとに不正なコードがメインブランチに入らないようにする
マージ後の検証
CIで工夫したこと
- 失敗したときのfallback
- 成功しないとマージされない
- Slackに通知してすぐきづけるように
- Dockerを起動するだけで元のJenkins環境再現
CIを楽しむ5過剰
- 自分が直接関わるところに力をいれる
- 自分が楽になることを考える
- 自分が使いたいものを導入する
- 自分がいなくても大丈夫な状態をつくる属人性を排除する
- 全部自動化しようと考えない
【勉強会メモ】Osaka Venture Today Meetup #4 - 開発生産性アップの秘訣
- 日時：2018/10/26(金) 18:30 〜 21:00
- 場所：サイボウズ大阪オフィス
MonotaROさん、サイボウズさん、freeeさんによる三社合同の勉強会。今回のテーマは「開発生産性アップの秘訣」でした。
遅刻してMonotaROさんの発表はまるごと聞き逃してしまいました。大変残念です。かわりに現地で頂いたMonotaROまんじゅうの画像をお楽しみください。。
さらに残念なことにPCを持っていくのを忘れてしまい、スマホで撮った写真とフリック入力で必死に追いかけたやや雑なメモになっておりますがご了承ください。
小さなサービスも契約する時代 〜マイクロサービスのテストをすばやく回しデプロイを安全にやるよい方法〜
小さなサービスも契約する時代 from RyoMitoma
www.slideshare.net
マイクロサービス
- 技術的異質性
- サービスごとに別の技術を使える
- 回復性
- スケーリング
- デプロイ容易性
- 組織面の一致
- チームとサービスを一致させる
- チーム間の折衝が減らせる
- 合成可能性
- 交換可能にするための最適化
テストにおける課題
- 全体を結合したテストが大変
- どのバージョンでテストするか判断ができない
- 誰がAPIを利用しているかわからない
どうすればいいのか？
- クライアントライブラリは自動生成
- 互換性の崩れた古いクライアントライブラリを意図せず使い続けられたら困る
- モノリポジトリの採用
- 全部のコードを1つのリポジトリに入れる
- モノリシックと変わらない
- 不充分なテストで本番に突っ込んで異常検知したら取り下げる
コンシューマ駆動契約
- 契約をもとに独立してテスト
- 提供側が守るべき契約をDBに問い合わせできる
- 利用側が起点となって提供側と契約するのがコンシューマ駆動契約
CDCは何を解決しないか
- 契約していないサービスの互換性保証
- 契約が壊れたときのチーム間のコミュニケーション
- APIの実際の動作保証
- サービス間の実際の疎通
サイボウズの事例
課題
※参考
Freee流DevOps Dailyリリースを支える技術と、データ可視化の先
増田茂樹さん@freee
- デプロイは毎日
- 年間135件の機能リリース
なぜ頻繁にデプロイできないのか？
- タスクの粒度が大きい
- デプロイまでのプロセスが多い
タスクの粒度
- 1スプリント2週間
- スプリント単位ではなくモノができたら毎日リリース
- 細かく分解
- 1機能で45タスクぐらい
- 数時間から1日で終わる範囲
- コード量は1タスク50行ほど
- 効果
- レビューしやすい
- 進捗管理しやすい
※50行を超えているとBotが「文化的ですか？」と聞いてくる
ブランチ戦略
- developに取り込まれると
staging→masterに自動で流れる
リリースフラグ
- システム全体、事業単位で設定できるフラグ
- 開発中
- ボタンや機能の制御
- 開発中継
- QAチームへの開放
- 運用
- ABテスト
- 障害の切り戻し
リリースフラグはフィーチャートグルとも言われる手法ですね https://t.co/lsOQ7YjGSW #ovento
— radiocat (@radiocatz) 2018年10月26日
デプロイプロセス
- ChatBotでデプロイ
- Chatで「デブデブしたい」と投稿すると自動でデプロイ
- おみくじでプルリクエスト
余談ですが、遅れて行ったら同じテーブルに元同僚が座っていました。その場ではあまり話が出来なかったので終わってから2人で飲みに行きました。一生のうち1回ぐらいは達成したい事リストのタスクを1つ消化した気分で帰宅しました。
勉強会に遅れて行ったら偶然にも同じテーブルに元同僚がいて終わってから2人で飲みに行くという一生のうちに1回達成したいタスクを1つ消化した。
— radiocat (@radiocatz) 2018年10月26日
【勉強会メモ】スクラム道関西 第112回オープン・ジャム
- 日時：2018/10/24(水) 19:00 〜 21:00
- 場所：株式会社リアズ
久しぶりにオープン・ジャムに参加してきました。いろんな人のスクラムの取り組みや抱えている課題が聞けて、議論に加わることで自分の理解度も改めて確認できるのでとても勉強になります。
オープン・ジャムではそれぞれが持ち寄ったテーマについて議論しますが、そのテーマや議論の内容はその場にいないと伝わらない部分が多いので、ここではあくまで私自身が得た気づきや特に気になった部分だけを切り取ってまとめています。
POの役割やチームでの動き方について
- POは半分は内向き（開発チーム）、半分は外向き（ステークホルダー）に行動する
- POがちゃんとできているか気になるなら開発チームに聞いてみる
- POが不安を抱えていて開発チームからフィードバックが得られないならスクラムマスターが何かしないといけない
バックログに”やらないこと”を定義することについて
- 開発チームがバックログに書いていない機能を作り込みすぎる場合にPOが"やらないこと”を定義することがある
- そもそもバックログに細かく定義しないといけない要因を考える必要はある
- チームの熟練度や認識の共有レベルにも依存
- バックログ個別ではなくチームの共通ルールとしてワーキングアグリーメントで定義する場合もある
スクラムマスターの育成
- やりたい人がいないかチームに聞いてみる
- スクラムに興味がある人がやるべき
- ファシリテートを当番制にする
- 外部のコーチを入れる
スクラムマスターの1日
- 明確な役割や決まった活動はない
- スクラムができているか気になるところを指摘する
- チームのひとり一人の発言や表情、行動など全てを観察する
- 兼任だとこれらを全て拾えない、見落としがち
スクラムマスターの成果アピール
- 周囲に成果を示そうとするとチームの成果になりがち
- 越境して他部門や経営陣に切り込む
運用系タスクのPBI
- 割り込み業務はスプリント計画時にあらかじめ見込んでおく
- 開発業務に比べて定型業務をスクラムでやることにモチベーションを保つのが難しい面がある
- 属人化している業務の改善、効率化、自動化などふりかえりでアクションを出せる要素は運用系タスクにもあるはず
ふりかえりのYWT
- 手法の1つなので使うかどうかはチームの状況による
- KPTと比較して仮説検証型のプロジェクトで効果が得られやすい
- 研究開発のプロジェクトなどで向いている？
- KPTはシングルループ学習、YWTはダブルループ学習
- やったことからわかったことを掘り起こして、わかったことから次にやることを掘り起こす
- 最初に出た意見からイメージが飛躍したアクションや全く違うアクションが出やすい
参考
【勉強会メモ】Payara&関ジャバイベント
- 日時：2018/10/16(火) 19:00 〜 21:00
- 場所：サイボウズ株式会社 大阪オフィス
今回の関ジャバはJakarta EEについてのおさらいと、Payara、Hazelcastの特集でした。 ParyaraとかHazelcastとか何？というのはこのあたりの情報を参照。
Payaraのほうは概ね理解できたのですが、Hazelcastのほうは個人的に馴染みの薄いプラットフォームなので理解度が低いです。拙いメモになっていますがご容赦ください。
Hazelcastについては解ったようで解ってない可能性を感じてる。
— radiocat (@radiocatz) October 16, 2018
なお、Hazelcastのほうのセッションを担当されていたかたが来られなくなったとのことで、すべてのセッションがPayaraの蓮沼賢志さんによる説明でした。
Session 1: To see the future - Jakarta EE, MicroProfile and Payara
Session 1-1: Jakarta EE Update - October 2018
JavaEE8
昨年秋に策定
↓移管
JakartaEE working Group
- Steering Committee
- Strategic Memberが中心に引っ張る
- Specification Committee
- JakartaEEの仕様に関する部分を扱う
- Marketing Committee
- どういう方向に持っていくかを考える
- Enterprise Requirement Committee
Jakarta EE Strategic Members
EE4J Project
- Project Management Committee
- Project Lead
- Committer
- Contributer
Migration Status
Roadmap
- Source Code Moves⇒2018年中
- EE4J側でGlassFishをビルドし直してJavaEE8の標準であることを証明
- Jakarta EEのマイナーチェンジ
- Jakarta EEでの新しいGlassFishを作る
- Jakarta EE9の開発
※参考
Session 1-2: Introduction to Payara Platform 5.183
What's Payara?
- Derived from GlassFish
- MicroProfile compatible
- 365日24時間サポートあり
- 4半期ごとにリリース
- 有償版は毎月バグフィクス提供
Payara Platform
- payara Server
- Payara Micro
- 軽量ランタイム
- マイクロサービス向け
- ラズパイ上で動かしたという情報もある
Payara's Version
- Payara 4.1.2.181
- 4.1.2⇒GlassFish 4.1.2互換
- 181⇒2018年Q1
Production Enhancements
- Hazelcast based clustering
- Domain Data Grid
- Deployment Groups
- Monitoring and Diagnostic
- HealthCheck,JMX Monitoring, Request Tracing
- Notificaiton Server
- 商用機能と謳っているがコミュニティ版にも入っている
New Features for 5.183
- MicroProfile 2.0サポート
Bash auto completion
- asadmin.autocompleteを読み込むとpathが通る
- 自動補完がきく
- Bash専用
Download
https://www.payara.fish/software/downloads/
Session 1-3: MicroProfile 2.0 Overview with Payara Platform
MicroProfile is
Implementations
- いろんなベンダーの実装を選べる
- Open Liberty/WebSphere Liberty（商用）
- Thorntail
- Payara Micro
Features Overview
MicroProfile 1.0
MicroProfile 1.1
- Config 1.1が追加
MicroProfile 1.2
- 2017年9月
- 以下が追加
- Metrics 1.0
- Fault Tolerance 1.0
- Health Check 1.0
- JWT 1.0
MicroProfile 1.3
- 追加
- OpenAPI OpenAPI v3、実態はSwagger
- Open Tracing
- Rest Client
- TypeセーフなRESTクライアント
MicroProfile 1.4
- APIは変化なし
- Java EE7/8両方動く
MicroProfile 2.0
- ベースとなるJavaEE共通部分がEE8対応
- Java EE8で動く
Session 2: Thinking Distributed: The Hazelcast Way
Hazelcast
- 分散コンピューティングを実現するプラットフォーム
- 2つの製品
- IMDG(in-memory Data Grid)
- JET
とにかく世の中にデータが多くなってきた
今後2040年までに年40%ペースで増える
4つのV
- Volume
- Velocity
- Variety
- Value
Hazelcastの特徴
In Memory Data Grid
3つの役割
- ストレージ
- In Memory Caching
- データストアシステムの間にHazelcastが入ってキャッシュする
- データ処理
- データ受け渡し
キャッシング
HD Memory
データ処理
- Executor Service APIを使う
- Lock API⇒悲観ロック、楽観ロックをサポート
- Messaging
- Queue
- Topic
- RingBuffer
- NodeごとにPrimaryとBackupを持つ
- Nodeの増減によってBackupがリバランスされる
- MicroServiceのスケーリング
- Java以外の言語も使える
※参考
Hazelcast Cloud
今年の8月に発表
Management Center
Webベースの管理コンソール
Jet
Edition
リリースサイクル
【勉強会メモ】第9回 関西DB勉強会
- 日時：2018/10/13(土) 13:00 〜 18:00
- 場所：Insight Technology 大阪支店
※途中から参加しました。
Amazon Aurora Deep Dive
AWSジャパン 藤原 吉規さん
リージョンとAZ（アベイラビリティゾーン）について
- 東京リージョンは4つのAZ（データセンターを4つの区域に分けて分散化）
特徴
- データベースをクラウドで利用
- ハイエンドデータベースのような性能と可用性
- OSSデータベースのようなシンプルとコスト効率
- MySQL 5.6,5.7／PostgreSQL 9.6,10
価格
- MIN：db.t2.small/$0.063
- MAX：db.r4.16xlarge/64cpu/488/$11.20
https://aws.amazon.com/jp/rds/aurora/pricing/
特徴
スケールアウト、分散、マルチテナントデザイン
ログストラクチャードストレージ
- もともとのMySQLやPGに変更を加えている
- マルチテナント
- 3つのAZに分散（データセンターまたがってデータ保持）
- AZに2つずつ計6つのデータをコピーを保持
マスターとレプリカが同じストレージを参照
Lambda
- S3
- IAM
CloudWatch
完全に管理されたサービス - 運用管理作業の自動化
AWS管理でアプリケーションの最適化に集中
- 自動化された管理タスク
なぜAuroraに移行？
- オープンソースエンジンを使っている
- より高いパフォーマンス
- 優れた可用性と耐久性
- コスト最大60%減
- 簡単な以降
- より高いパフォーマンス
- コマーシャルDBエンジンからの移行
- 1/10のコスト
Auroraのパフォーマンス
- MySQL
- スループット5倍
- PostgreSQL
- sysbenchで30GBの書き込み測定
- 2.x倍の処理速度
- 5倍のクライアント数
- 応答時間の削減⇒2倍超
書き込み中クラッシュからの復旧
- PostgreSQL⇒30BiB Redo/123秒
- Aurora⇒3秒で復旧
Real-life data
- リードレプリカレイテンシ
- 通常のMySQL遅延が12分
- Auroraのレプリカ遅延は20ミリ秒
Auroraの耐久性と可用性
- 3つのAZに計6つのコピー
- 最大15の読み取りレプリカが利用・昇格可能
Aurora Driver
最大64TBのストレージ
- 自動ストレージスケーリング
- 10GB単位で自動増分
高速なデータベースクローニング
- 重複したストレージのコストを伴わずにデータベースのコピーを作成
- 元のデータとクローン後のデータが異なる書き込みのみ作成する
バックトラック
- 時間を指定して特定の時点に戻る
- バックアップからの復元ではない
セキュリティとコンプライアンス
- 暗号化
- SSL接続
- 監査ログ
移行
マイグレーション：AWS Database Migration Service(DMS)
- 移行時にアプリケーションの動作を維持
- EC2またはRDSが複製先／元である必要がある（オンプレは不可）
- Schema Conversion Tool
- RDS DBインスタンスからAurora Read Replicaを作成
- MySQLナップショットバックアップから移行
- mysqldumpから移行の約20倍高速
Auroraの新機能
- Parallel Query
- 数千個のCPUを使用
- CPU課金されない
- Serverless
- 自動スケール
- Performance insights
- クエリレベルでパフォーマンスをモニタ
- Hour,day,week,month
- 35日前まで表示
今秋リリース予定のPostgreSQL 11を徹底解説
日本PostgreSQLユーザ会 澤田 雅彦さん
www.slideshare.net
PostgresSQL 11
- 150の新機能・改善
- 約300のコントリビューター
テーブル・パーティショニング
- 全150件中約1割がテーブル・パーティショニングの改善
- Partition Pruning高速化
- 小テーブルの刈り取り／絞り込み
- 大量の小テーブルがある場合に性能向上が期待できる
- 実行中のPartition pruning
- 実行計画作成時には小テーブルを絞り込めない場合に有用
- Prepared Statement
- 実行計画作成時には小テーブルを絞り込めない場合に有用
- Hash Partition
- キーのHash値に基づいてデータを配分
- データが均等になる
- Default Partition
- その他を入れる子テーブル
- Partition-wise Join,Aggregation
- 子テーブルごとに結合、集約を行う
- デフォルトではOFF
- パーティションが多いとプランニングに時間がかかる
できないこと
- パーティション・テーブルへの外部キー制約は未サポート
パラレルクエリ
- 1つのSQLを複数のCPUで実行
- ブロック単位でパラレル
- デフォルトON
- ブロック度が3倍になると処理並列が1つ増える
サポートされた機能
- SQL
- CREATE INDEX
- UNION
- CREATE TABLE AS, SELECT INTO, CREATE MATERIALIZED VIEW
- LIMIT
- ノード
- Hash Join
- Append
- 読み込みが並列化⇒書き込みはまだ
max_parallel_xxxパラメータ
- 上限値の設定
- workers
- workers_per_gather
- maintenance_worker
- 実際の並列数はデータ量等で自動的に使われる
- 個別の並列度の指定はテーブルごとに指定できる
Parallel Append
- UNIONやパーティションテーブルへのスキャンで使われる
- スキャン結果をあわせる処理
- それぞれのworkerが各プランを並列で実行する
パラレルできないこと
- CTE
- VACUUM
- Window関数
JITコンパイル
- CPUネックになるような処理で有効
- ExplainにJITの情報が出る
PROCEDURE
- 戻り値のない関数のようなもの
- ネストしたトランザクション制御
後半の発表に関連するMySQL8.0の新機能の話
Oracle 山﨑 由章( @yyamasaki1 ) さん
MySQL8.0を使ってブロックチェーンを実装する
森崎雅之( @masayuki14 ) さん
https://speakerdeck.com/masayuki14/mysql8-dot-0woshi-tuteburotukutienwoshi-zhuang-suru
使っているもの
- 分散型ネットワーク
- 合意形成
- スマートコントラクト
データ構造の部分だけにフォーカス
- ブロック⇒Record
- チェーン⇒Table
- ハッシュ⇒MD5
- ハッシュ制約⇒戦闘に0が4つ連続
CTE共通テーブル式
- 8.0でサポート
- 再帰的にJOINが実行できる
JSON_TABLE()
- 8.0で新規追加
- JSONを表に変換できる
- 他のテーブルとJHOINできる
まとめ
