Locondo 20190215@ec tech_group

「靴業界全体の収益性・効率性の構造改革」
に取り組むLOCONDO.jpの可用性への取り組み
Copyrights LOCONDO,Inc. All Rights Reserved.
株式会社ロコンド - Design & Tech本部 IT部門/シニア・ディレクター
杉山真也 Twitter: @RDBMS
●●
2019/02/15@EC Tech Group #1
HashTag #ectg #locondo

https://www.youtube.com/watch?v=ZU8uE80OPR4Copyrights LOCONDO,Inc. All Rights Reserved.
●●
「業界に革新を､お客さまに自由を」

●●

ロコンド倉庫
（LOCOPORT）
3Q出荷個数: 605,517個
店舗倉庫
在庫在庫
LOCONDO.jp LOCOMALL
（楽天、Yahoo!)
BOEM
(自社EC支援)
リアル店舗同盟サイト
(magaseek, d fashion)
同盟サイト倉庫
（magaseek）
在庫
●●
WMS: B2B
EC: B2C
在庫の最適化をサポート
https://www.locondo.co.jp/#our_business

●●
詳細: https://www.locondo.co.jp/partner/

物流受託
e3PL (E 3rd Party Logistics)
●●
WMS:在庫管理システム(Warehouse Management System)
自社EC運営
BOEM 2.0
Brand’s Official EC Management

タブレットPOS & QR決済機能付き
モバイル会員カード
LOCOPOS & LOCOPAY
●●
店舗スタッフ用在庫販売システム
LOCOCHOC

卸販売システム
LOCONDO Wholesale
(2019年4月ローンチ予定)
●●クラウド基幹システム
LoCore
(2019年4月ローンチ予定)

取扱高推移(単体)
●●
目標: 2020年300 億

システム対応
更に顧客満足度の高いサービスを継続的に提供し、
サプライヤー様の売り上げ利益をサポート
●●

目的: MySQL高可用性構成
1: サイトの高可用性構成（マスター障害からの自動復旧）
2: 参照用スレーブ障害発生時の自動復旧
3: 障害発生時にアプリケーション側で設定変更不要
4: オンラインでスレーブ追加(プロビジョニング半自動化は次のフェーズ)
●●
ビジネス成長と共に、システム障害発生によるビジネスインパクトが年々増加。
システムの増加を抑えつつ、インフラ全体を更に冗長化する事でサービスの
安定化と機会損失を削減!! お客様のデータを保護し安定したサービスを提供。
＋障害発生時もエンジニアが落ち着いて対応出来る環境を構築。
KPI: 99.999% (5分15秒)
※ 計画メンテナンスを除く
2020年: 60,000円弱/分

システム要件
1: 今後の成長、2020年（x2.5倍の処理を行う事が出来るか?)
2: バッチ処理適用遅延についての仕様が許容出来るか?
3: 参照処理のスケールアウトが可能か?
4: バックアップ＆リカバリーの確実性
5: データーベース移行時の切り替えダウンタイム最小化
6: コスト的な妥当性の確認
7: その他
●●
2020年以降は
マイクロサービス化?

●●
●●
●●
InnoDB Cluster導入
～MySQLに組み込まれたコストパフォーマンスの良い高可用性ソリューション～

参照: https://www.s-style.co.jp/jirei/case049.html
詳細: 16.1.5.2 Enabling GTID Transactions Online
●●
※ APサーバー側のConnector/Jは事前にアップグレード
MySQL Connector/J 5.1.30 (2014-03-31)→Connector/J 5.1.47 (2018-08-17)

スペックと用途に合ったパラメータを選択
Multi-Thread-slaveは、GTIDに移行後で無いとメリットは無い事も
グループレプリケーションでは勿論、 Multi-Thread-slaveを設定。
log_slave_updatesは、マスターにならないスレーブでは忘れずにOFF
binlog_formatは、ディスクI/Oやネットワーク負荷が増えるので要確認。
グループレプリケーションでは、ROWフォーマットが必須。
パラメータ比較含む参考資料はこちらからもダウンロード可能
※ MySQL5.6, MySQL5.7, MySQL8.0等のパラメータを理解する事が重要
https://www.mysql.com/jp/news-and-events/seminar/downloads.html
●●

基本的にMySQLのオプティマイザーはバージョンアップと共に改良されていますが、
汎用的なパラメータの為に全ての条件に最適化されている訳ではありません。
移行後に一部処理が遅くなっていた為、パラメータや処理内容を見直しました。
例) 通常30分で終わるバッチ処理が、20時間かかってしまった。
アップグレードしたタイミングで実行プランが変わりVIEW経由のアクセスが遅くなった
【対応】実行プランを確認し、VIEWでは無くBASE TABLEを直接参照する事で対応し解消
※ ビジネスの成長過程で、工数をかけるべきポイントの優先順位は都度変わっていくものです。
常に全ての処理がベストな状況では無いかと思いますので臨機応変に適切に対応していく事が重要です。
20h:37m:53s ⇒ 36m 26s
※内部的に重い処理を複数回実行する処理(1 min 4.92 sec → 0.03 sec)
●●
要確認：5.7アップグレードに伴う追加対応
重要な処理は、Query Playback等で予め確認しておくことをお勧めします。

オプティマイザー(条件フィルタリング)の調整
set global optimizer_switch='condition_fanout_filter=off';
9.01 sec ⇒ 0.94 sec
5 min 48.71 sec ⇒ 3 min 13.31 sec
その他、考慮事項： WHERE句で絞り込めるデータを､データ参照時に適切に絞りこめているかも適宜確認。
●●
要確認：5.7アップグレードに伴う追加対応
動的設定変数なので
オンラインで設定変更可能

必要に応じて追加対応
[sys]> select * from schema_redundant_indexes limit 10,1¥G
*************************** 1. row ***************************
table_schema: demo
table_name: shopping_order
redundant_index_name: shopping_id_idx
redundant_index_columns: shopping_id
redundant_index_non_unique: 1
dominant_index_name: shopping_detail_uq_idx
dominant_index_columns: shopping_id, shopping_detail_id
dominant_index_non_unique: 0
subpart_exists: 0
sql_drop_index: ALTER TABLE `demo`.`shopping_order` DROP INDEX ` shopping_id_idx `
1 row in set (0.22 sec)
1:不要なインデックスの削除
2:必要に応じ文字コード変換
3:PKが無い場合はPKを付与
[sys]> explain select * from demo.shopping_order where shopping_id = 1;
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+
| 1 | SIMPLE | shopping_order | NULL | ref | shopping_detail_uq_idx,shopping_id_idx | shopping_detail_uq_idx | 4 | const | 1 | 100.00 | NULL |
+----+-------------+----------------+------------+------+----------------------------------------+------------------------+---------+-------+------+----------+-------+

参照: https://www.s-style.co.jp/jirei/case049.html
●●
Search: ElasticSearch
Cache: Redis
マルチマスター構成・シングルマスター構成を選択可能
今回はアプリケーション側の処理を考えシングルマスター構成を選択

●●障害発生時も自動的に切り替え、
Tomcat等の再起動は不要で対応工数 “0”
url="jdbc:mysql://127.0.0.1:3306,127.0.0.1:3307
conn.setReadOnly(false)= Master
conn.setReadOnly(true) = Slave
データベースはグループ内で自動的にフェールオーバー
メンバーは自動的にPRIMARYを切り替え。対応工数 “0”
機会損失を最小限に抑える事が可能

障害試験の実施
常に安定したサービスを提供出来るか? 障害発生してもサービスを継続出来るか?
●●

+---------------------------+--------------------------------------+-------------+-------------+----------------+
+---------------------------+--------------------------------------+-------------+-------------+----------------+
| group_replication_applier | e1731e29-f269-33j4-8646-020114770060 | TST-db-14 | 3306 | RECOVERING |
+---------------------------+--------------------------------------+-------------+-------------+----------------+
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
Slave
障害復旧
スレーブ障害
スレーブが復旧するとリカバリーモードに
なる。MySQL Routerがオンラインになっ
たのを判断して再接続を開始する。

+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
[root@TST-db-12 benchmark]# kill 37299
[root@TST-db-12 benchmark]# ps -ef | grep mysql
root 21661 33444 0 15:53 pts/0 00:00:00 grep --color=auto mysql
[root@TST-db-12 benchmark]#
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+----------------+
| primary master |
+----------------+
| TST-db-14 |
+----------------+
MASTER
障害発生
マスター障害
✓マスター障害が発生すると同時に自動的にグループ内のメンバーが
PRIMARYに昇格して更新処理を行う。(group_replication_member_weight)
✓スレーブは自動的に新しいマスターを参照しデータを受け取る。
✓ MySQL Routerはメタデータで新しいマスターを判断する。
Pri SecPri

localhost [BENCHMARK]> delete from t_slap01 where ID = 10;
Query OK, 1 row affected (0.00 sec)
localhost [BENCHMARK]> select @@hostname;
+------------+
| @@hostname |
+------------+
| TST-db-14 |
+------------+
localhost [BENCHMARK]> delete from t_slap01 where ID = 10;
ERROR 1290 (HY000): The MySQL server is running with the --super-read-only option so it cannot execute this statement
itlocondo12@localhost [BENCHMARK]> select @@hostname;
+------------+
| @@hostname |
+------------+
| TST-db-13 |
+------------+
マスター障害
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
+---------------------------+--------------------------------------+-------------+-------------+---------------+
MASTER
復旧
新しいマスターでは更新処理が出来るが、
セカンダリーメンバーではrootでも更新処理
は出来ないので安全。
旧マスターが復旧しても、マスターは障害発
生時に選択されたメンバーが引き続き処理

[mysql_innodb_cluster_metadata]> show tables;
+-----------------------------------------+
| Tables_in_mysql_innodb_cluster_metadata |
+-----------------------------------------+
| clusters |
| hosts |
| instances |
| replicasets |
| routers |
| schema_version |
+-----------------------------------------+
[mysql]> SELECT member_host as "primary master" FROM performance_schema.global_status
JOIN performance_schema.replication_group_members WHERE variable_name = 'group_replication_primary_member' AND member_id=variable_value;
+----------------+
| primary master |
+----------------+
| TST-db-12 |
+----------------+
[mysql_innodb_cluster_metadata]> SELECT member_id, member_host, member_port, member_state, @@group_replication_single_primary_mode FROM
performance_schema.replication_group_members WHERE channel_name = 'group_replication_applier';
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
| member_id | member_host | member_port | member_state | @@group_replication_single_primary_mode |
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
| e1731e29-f269-33j4-8646-020114770060 | TST-db-14 | 3306 | ONLINE | 1 |
| 42c3cbdc-f269-33j4-b56c-02011477005e | TST-db-12 | 3306 | ONLINE | 1 |
| e53e17a3-f269-33j4-98c5-02011477005f | TST-db-13 | 3306 | ONLINE | 1 |
+--------------------------------------+-------------+-------------+--------------+-----------------------------------------+
アプリケーション
MySQL Router
アプリケーションはMySQL Routerに接続
MySQL Routerはデータベース内のメタデータを
参照し障害を検知して自動的に振り分ける!!
アプリケーション側での対応は不要。
メモ：“max_connections = 2048“ 等,パラメータ設定は調整
bootstrap_server_addresses=
mysql://TST-db-12:3306,
mysql://TST-db-13:3306,
mysql://TST-db-14:3306
localhost:6446
localhost:6447
Application

負荷試験
中期的に、ユーザーに安定したサービスを提供する事が出来るか?
●●

OLTP更新とバッチ処理の負荷シュミレーション
SYSBENCH用: 初期データ(4テーブル)
+----------+---------+------------+
| Database | Table | Size in MB |
+----------+---------+------------+
| sysbench | sbtest3 | 22426.69 |
+----------+---------+------------+
Pri Sec Sec
Tool: mysqlslap (バッチ系の処理を確認)
大量にまとめてデータをINSERTして削除する等、一つのトランザクションで大量にデータを処理する試験に使用。
Tool: sysbench(更新処理内容：計測の為に各ベンチマークを10分間実行)
INSERT INTO sbtest1 (id, k, c, pad) VALUES (75087935, 12463253, '13889104256-30791869017-66538184821-5…….
DELETE FROM sbtest1 WHERE id=75087935
UPDATE sbtest1 SET k=k+1 WHERE id=63874937
UPDATE sbtest4 SET c='51744764069-67682943268-15332003429-10934680309-42746352369-…………….' WHERE id=12627688
アーキテクチャ: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 40
Model name: Intel(R) Xeon(R) CPU E5-2670 v2 @ 2.50GHz
Memory : 128GB
Disk : SanDisk ioMemory PX Series

OLTP:複数接続＋細かいデータ更新処理
[benchmark]# ./mysqlslap_check_group_member_lag.sh
BENCHMARKデータベースに対して、100クライアント x 1000件実行します
Enter password:
Benchmark
Average number of seconds to run all queries: 0.012 seconds
Minimum number of seconds to run all queries: 0.010 seconds
Maximum number of seconds to run all queries: 0.213 seconds
Number of clients running queries: 100
Average number of queries per client: 1
SQL> SELECT * FROM performance_schema.replication_group_members;SELECT count_transactions_in_queue FROM
performance_schema.replication_group_member_stats;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
+---------------------------+--------------------------------------+-------------+-------------+--------------+
細かくトランザクションが分かれているので、
トランザクションがQueueに溜まる事はあるが、
グループメンバー間に差は発生していない。
“insert”毎のコミット処理

select CHANNEL_NAME,RECEIVED_TRANSACTION_SET from replication_connection_status where CHANNEL_NAME = "group_replication_applier"¥G
select TRANSACTIONS_COMMITTED_ALL_MEMBERS from performance_schema.replication_group_member_stats¥G
select CHANNEL_NAME,WORKER_ID,LAST_SEEN_TRANSACTION from replication_applier_status_by_worker where CHANNEL_NAME = "group_replication_applier";
select @last_exec:=SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX( @@global.GTID_EXECUTED,':',-1),':',1),'-',-1) last_executed;
select @last_rec:=SUBSTRING_INDEX(SUBSTRING_INDEX(SUBSTRING_INDEX( Received_transaction_set,':',-1),':',1),'-',-1) last_received FROM
performance_schema.replication_connection_status WHERE Channel_name = 'group_replication_applier';
select (@last_rec - @last_exec) as real_lag;SELECT count_transactions_in_queue FROM performance_schema.replication_group_member_stats;
*************************** 1. row ***************************
CHANNEL_NAME: group_replication_applier
RECEIVED_TRANSACTION_SET: cb904887-a1fc-11e8-ae58-02011477005e:1-14035941
*************************** 1. row ***************************
TRANSACTIONS_COMMITTED_ALL_MEMBERS: cb904887-a1fc-11e8-ae58-02011477005e:1-13896262
<SNIP>
| group_replication_applier | 5 | cb904887-a1fc-11e8-ae58-02011477005e:14035940 |
+---------------------------+-----------+-----------------------------------------------+
+----------+
| real_lag |
+----------+
| 0 |
+----------+
+-----------------------------+
| count_transactions_in_queue |
+-----------------------------+
| 0 |
+-----------------------------+
この値は、Certificationモジュールによってグループ
メンバー全体の状況を確認する為に、一定の間隔で
更新される為、リアルタイムモニタリングには使えない。
受け取ったトランザクションはApplierスレッドが処理完了、
若しくは処理中。以下のクエリーの値が”0”を返す場合
は、まだコミットしていないトランザクションが残っている。
SELECT GTID_SUBSET(LAST_SEEN_TRANSACTION,
@@GLOBAL.GTID_EXECUTED) FROM
performance_schema.replication_applier_status_by_worker;
Queuingしているトランザクション数
大量に処理を流すと、Queueに溜まるが, 検証中は
問題になる程Queueは滞留する事はなかった。
受け取ったトランザクションセットの内容が
適用済みかどうか? 適用が完了していない、
トランザクションがあるかどうかの確認。

[root@TST-db-12 oltp16th80G]# ../oltp_test_read_only
sysbench 0.5: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 16
Initializing random number generator from timer.
Random number generator seed is 0 and will be ignored Threads started!
OLTP test statistics:
queries performed:
read: 32271554
write: 0
other: 4610222
total: 36881776
transactions: 2305111 (3841.82 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 32271554 (53785.48 per sec.)
other operations: 4610222 (7683.64 per sec.)
General statistics:
total time: 600.0049s
total number of events: 2305111
total time taken by event execution: 9595.8084s
response time:
min: 2.97ms
avg: 4.16ms
max: 66.61ms
approx. 95 percentile: 4.67ms
Threads fairness:
events (avg/stddev): 144069.4375/3076.16
execution time (avg/stddev): 599.7380/0.01
※ MySQL Router経由での処理は別途確認だがスレーブは分散されるのでスケール可
SELECT
TPS:3841.82
[root@TST-db-12 oltp64th80G]# ../oltp_test_read_only
queries performed:
read: 47745418
write: 0
other: 6820774
total: 54566192
General statistics:
response time:
min: 3.41ms
avg: 11.26ms
max: 227.48ms
Threads fairness:
※ MySQL Router経由での処理は別途確認だがスレーブは分散されるのでスケール可
TPS:5683.85

[root@TST-db-12 write16th80G]# ../oltp_test_write
queries performed:
read: 12396902
write: 3541972
other: 1770986
total: 17709860
General statistics:
response time:
min: 5.93ms
avg: 10.84ms
max: 1178.88ms
Threads fairness:
※ count_transactions_in_queueは0～5の間で推移し遅延無し
DML
TPS:1475.79
[root@TST-db-12 write128th80G]# ../oltp_test_write
queries performed:
read: 21410284
write: 6117224
other: 3058612
total: 30586120
General statistics:
response time:
min: 10.29ms
avg: 50.21ms
max: 2539.81ms
Threads fairness:
※ count_transactions_in_queueは0～400の間で推移するが遅延無し
※ こちらのワークロードでは、512 Threadsまではトランザクションがスケールする事を確認。
※ 1G程度の小さいテーブルであれば、512 ThreadsでTPS: 3500/sec以上可能
TPS:2548.67

queries performed:
read: 23119866
write: 6605676
other: 3302838
total: 33028380
General statistics:
response time:
min: 31.27ms
avg: 186.02ms
max: 3222.41ms
Threads fairness:
6,605,676書き込み/600秒
= 約11,000/秒
合計: 2746.82トランザクション/秒
細かいトランザクションであれば、
マスターとスレーブ間は同期状態
処理数を増やしていっても
ギャップが発生しない事を確認 ◎
更新処理も通常のOLTP処理であれば、
3倍以上は捌けると判断。

バッチ：長時間を要するシングルトランザクション
[BENCHMARK]> select now(),@@hostname;delete from t_slap01;select now(),@@hostname;
+---------------------+------------+
| now() | @@hostname |
+---------------------+------------+
| 2018-08-28 19:41:00 | TST-db-12 |
+---------------------+------------+
Query OK, 5000000 rows affected (1 min 53.19 sec)
+---------------------+------------+
| now() | @@hostname |
+---------------------+------------+
| 2018-08-28 19:42:53 | TST-db-12 |
+---------------------+------------+
[BENCHMARK]> select now(),@@hostname,count(*) from BENCHMARK.t_slap01;
+---------------------+------------+----------+
| now() | @@hostname | count(*) |
+---------------------+------------+----------+
| 2018-08-28 19:44:28 | TST-db-13 | 5000000 |
+---------------------+------------+----------+
[BENCHMARK]> select now(),@@hostname,count(*) from BENCHMARK.t_slap01;
+---------------------+------------+----------+
| now() | @@hostname | count(*) |
+---------------------+------------+----------+
| 2018-08-28 19:44:37 | TST-db-13 | 0 |
+---------------------+------------+----------+
注意： Primaryノードで長時間かかるトランザクションは、
コミットするまでバイナリーログが作成されない為、
スレーブへの反映が同様に遅れてしまう。
2分弱のギャップが発生!!
サービス的に許容出来る?

[performance_schema]> show variables like 'group_replication_flow_control_certifier_threshold';
+----------------------------------------------------+-------+
| Variable_name | Value |
+----------------------------------------------------+-------+
| group_replication_flow_control_certifier_threshold | 25000 |
+----------------------------------------------------+-------+
[performance_schema]> show variables like 'group_replication_flow_control_applier_threshold';
+--------------------------------------------------+-------+
| Variable_name | Value |
+--------------------------------------------------+-------+
| group_replication_flow_control_applier_threshold | 25000 |
+--------------------------------------------------+-------+
メモ：フローコントロールを設定するとグループメンバーの同期状態をコントロールする事が可能。
検証ではこちらの既定値で問題は無かったので、将来的にバッチ処理の内容等によって必要に応じて調整する。
要確認：フローコントロール設定(Default) ●●

slave_pending_jobs_size_max=134217728 (128M)
参照： MTS（マルチスレッドスレーブ）を使う場合の注意点
https://www.s-style.co.jp/blog/2018/08/2168/
マルチスレッドスレーブの場合、この変数は、まだ適用されていないイベントを保持するスレーブワーカー
キューに使用可能な最大メモリー量 (バイト単位) を設定します。この変数を設定しても、マルチスレッドが
有効ではないスレーブには影響しません。
この変数の値はマスターの max_allowed_packet の値以上である必要があります。そうでない場合は、マスターから到着する処理すべき
イベントが残っているときにスレーブワーカーキューがいっぱいになる場合があります。
Coordinator has waited ～ times hitting slave_pending_jobs_size_max
参考：スレーブワーカーキューの調整 ●●

参考： Additional Feature in MySQL8.0
WL#10379: Group Replication: consistent reads
https://dev.mysql.com/worklog/task/?id=10379
WL#11123: Group Replication: hold reads and writes when the new primary
has replication backlog to apply
WL#10378: Group Replication: group single/multi primary mode change and
primary election
●●

バージョンアップに伴う追加メリット
MySQLのレプリケーションは1メジャーバージョンの違いはサポート対象
“MySQL supports replication from one release series to the next higher release series. ”
●●

MySQL8.0：集計関数が利用可能(Windows関数・CTE)
Pri
5.7
Sec
5.7
Sec
5.7
Slave
MySQL8.0
mysql> select
-> rank() over w as 'rank',
-> Continent,Name,GNP,
-> row_number() over w as 'row_number',
-> dense_rank() over w as 'dense_rank'
-> from country
-> window w as (order by GNP desc) limit 10;
+------+---------------+----------------+------------+------------+------------+
| rank | Continent | Name | GNP | row_number | dense_rank |
+------+---------------+----------------+------------+------------+------------+
| 1 | North America | United States | 8510700.00 | 1 | 1 |
| 2 | Asia | Japan | 3787042.00 | 2 | 2 |
| 3 | Europe | Germany | 2133367.00 | 3 | 3 |
| 4 | Europe | France | 1424285.00 | 4 | 4 |
| 5 | Europe | United Kingdom | 1378330.00 | 5 | 5 |
| 6 | Europe | Italy | 1161755.00 | 6 | 6 |
| 7 | Asia | China | 982268.00 | 7 | 7 |
| 8 | South America | Brazil | 776739.00 | 8 | 8 |
| 9 | North America | Canada | 598862.00 | 9 | 9 |
| 9 | Europe | Spain | 598862.00 | 10 | 9 |
+------+---------------+----------------+------------+------------+------------+
mysql> with t1 as (select * from city where CountryCode = 'JPN')
-> select * from t1 limit 5;
+------+---------------------+-------------+----------+------------+
| ID | Name | CountryCode | District | Population |
+------+---------------------+-------------+----------+------------+
| 1532 | Tokyo | JPN | Tokyo-to | 7980230 |
| 1533 | Jokohama [Yokohama] | JPN | Kanagawa | 3339594 |
| 1534 | Osaka | JPN | Osaka | 2595674 |
| 1535 | Nagoya | JPN | Aichi | 2154376 |
| 1536 | Sapporo | JPN | Hokkaido | 1790886 |
+------+---------------------+-------------+----------+------------+
Windows関数による、容易なランキング集計
CTEによる、Viewや一時テーブル処理と比較したパフォーマンス改善
http://mysqlserverteam.com/mysql-8-0-improved-performance-with-cte/

サマリー
■ 移行完了後には、データベースの可用性は99.999%まで向上
■ データベース障害発生時の緊急対応は不要
■ 自動リカバリーによるシステム障害発生時の機会損失を削減
■ ECサイトからの処理は現状の3倍以上になっても処理可能
■ バッチ処理に関しては、細かくトランザクションを分割し対応
■ バックアップはそれぞれの環境にあった方法を選択
■ レポート関連処理に関しては、グループ外スレーブとして
Windows関数、CTEが利用出来るMySQL8.0を活用し生産性を向上
●●

https://www.locondo.co.jp/recruit#recruitment
エンジニア募集中!!
●●

有難うございました
●●

Locondo 20190215@ec tech_group

More Related Content

Similar to Locondo 20190215@ec tech_group

More from Shinya Sugiyama

Locondo 20190215@ec tech_group