This document summarizes a microservices meetup hosted by @mosa_siru. Key points include:
1. @mosa_siru is an engineer at DeNA and CTO of Gunosy.
2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway.
3. Challenges discussed were managing 30 microservices, ensuring API latency below 50ms across availability zones, and handling 10 requests per second with nginx load balancing across 20 servers.
ブログでもいろいろ解説しています。
http://little-hands.hatenablog.com/entry/top
ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。
---
公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています)
bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
境界付けられたコンテキスト
特定のモデルを定義・適用する境界を明示的に示したもの。
代表的な境界の例は、サブシステムやチームなど。
まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。
・概念としての境界付けられたコンテキスト
・境界付けられたコンテキストをどう実装に落としこむか
今回のスライドでは、概念の方の説明をしたいと思います。
This document summarizes a microservices meetup hosted by @mosa_siru. Key points include:
1. @mosa_siru is an engineer at DeNA and CTO of Gunosy.
2. The meetup covered Gunosy's architecture with over 45 GitHub repositories, 30 stacks, 10 Go APIs, and 10 Python batch processes using AWS services like Kinesis, Lambda, SQS and API Gateway.
3. Challenges discussed were managing 30 microservices, ensuring API latency below 50ms across availability zones, and handling 10 requests per second with nginx load balancing across 20 servers.
ブログでもいろいろ解説しています。
http://little-hands.hatenablog.com/entry/top
ドメイン駆動設計屈指の難解な概念「境界付けられたコンテキスト」について解説します。
---
公式DDD Referenceの定義は以下の通りです。(和訳はだいぶ意訳しています)
bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
境界付けられたコンテキスト
特定のモデルを定義・適用する境界を明示的に示したもの。
代表的な境界の例は、サブシステムやチームなど。
まぁなかなかよくわからないですよね。DDD用語の中でもかなり難解なワードです。 境界付けられたコンテキストは、2つの観点から解説が必要でしょう。
・概念としての境界付けられたコンテキスト
・境界付けられたコンテキストをどう実装に落としこむか
今回のスライドでは、概念の方の説明をしたいと思います。
Big Data Developerに贈る ~ Microsoft Azure による Big Data Architecture と、Elasticsearch、Databricks 解説 [セミナー] 東京開催
https://www.microsoftevents.com/profile/form/index.cfm?PKformID=0x8311627abcd
Meta/Facebook's database serving social workloads is running on top of MyRocks (MySQL on RocksDB). This means our performance and reliability depends a lot on RocksDB. Not just MyRocks, but also we have other important systems running on top of RocksDB. We have learned many lessons from operating and debugging RocksDB at scale.
In this session, we will offer an overview of RocksDB, key differences from InnoDB, and share a few interesting lessons learned from production.
Consistency between Engine and Binlog under Reduced DurabilityYoshinori Matsunobu
- When MySQL instances fail and recover, the binary logs and storage engines can become inconsistent due to different levels of durability settings. This can cause issues when trying to rejoin instances to replication.
- The document discusses challenges in ensuring consistency between binary logs and storage engines like InnoDB under reduced durability settings. It also addresses issues that can occur when restarting masters or replicas due to potential inconsistencies.
- Solutions discussed include using the max GTID from the storage engine to determine where to start replication, truncating binary logs on restart if they are ahead of the engines, and using idempotent recovery techniques to handle potential duplicate or missing rows. Ensuring consistency across multiple storage engines is also challenging.
MyRocks is an open source LSM based MySQL database, created by Facebook. This slides introduce MyRocks overview and how we deployed at Facebook, as of 2017.
The document discusses using MySQL for large scale social games. It describes DeNA's use of over 1000 MySQL servers and 150 master-slave pairs to support 25 million users and 2-3 billion page views per day for their social games. It outlines the challenges of dynamically scaling games that can unexpectedly increase or decrease in traffic. It proposes automating master migration and failover to reduce maintenance downtime. A new open source tool called MySQL MHA is introduced that allows switching a master in under 3 seconds by blocking writes, promoting a slave, and ensuring data consistency across slaves.
Automated, Non-Stop MySQL Operations and Failover discusses automating master failover in MySQL to minimize downtime. The goal is to have no single point of failure by automatically promoting a slave as the new master when the master goes down. This is challenging due to asynchronous replication and the possibility that not all slaves have received the same binary log events from the crashed master. Differential relay log events must be identified and applied to bring all slaves to an eventually consistent state.
This document summarizes optimizations for MySQL performance on Linux hardware. It covers SSD and memory performance impacts, file I/O, networking, and useful tools. The history of MySQL performance improvements is discussed from hardware upgrades like SSDs and more CPU cores to software optimizations like improved algorithms and concurrency. Optimizing per-server performance to reduce total servers needed is emphasized.
This document discusses indexing strategies in MySQL to improve performance and concurrency. It covers how indexes can help avoid lock contention on tables by enabling concurrent queries to access and modify different rows. However, indexes can also cause deadlocks in some situations. The document outlines several cases exploring how indexes impact locking, covering indexes, sorting and query plans.
Linux performance tuning & stabilization tips (mysqlconf2010)Yoshinori Matsunobu
This document provides tips for optimizing Linux performance and stability when running MySQL. It discusses managing memory and swap space, including keeping hot application data cached in RAM. Direct I/O is recommended over buffered I/O to fully utilize memory. The document warns against allocating too much memory or disabling swap completely, as this could trigger the out-of-memory killer to crash processes. Backup operations are noted as a potential cause of swapping, and adjusting swappiness is suggested.
15. NoSQL台頭の背景 – SQLの負荷軽減
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
user WHERE user_id= 10001234;
user WHERE user_id= 10002345;
user WHERE user_id= 10003456:
user WHERE user_id= 10004567;
user WHERE user_id= 10005678;
user WHERE user_id= 10006789;
主キーのWHERE条件が違うだけの同一のクエリが、全体の大部分を占めるケ
ースがある
Mobageのユーザ管理テーブルや、mixiのログイン時刻管理テーブルなど
いずれも主キーはユーザID
ユーザIDを主キーとするテーブルは、テーブルサイズはそこまで大きくならない
1レコード100バイトとして、3000万レコードで3GBにしかならない
全データがメモリに乗るのでCPUバウンドになる
SQLがボトルネックになる → API一発で取れるNoSQLの方が高速
実はMySQLはストレージエンジンをNoSQLとして切り離して使うことができる
InnoDB memcached plugin
RDBMSとNoSQLのハイブリッド構成