エムスリーのデータ基盤を支える設計パターン - エムスリーテックブログ
こんにちは、エムスリー エンジニアリンググループ の鳥山 (@to_lz1)です。 ソフトウェアエンジニアとして 製薬企業向けプラットフォームチーム / 電子カルテチーム を兼任しています。 ソフトウェアエンジニアという肩書きではありますが、私は製薬企業向けプラットフォームチームで長らくデータ基盤の整備・改善といったいわゆる "データエンジニア" が行う業務にも取り組んできました。 本日はその設計時に考えていること / 考えてきたことをデータ基盤の設計パターンという形でご紹介しようかと思います。多くの企業で必要性が認識されるようになって久しい "データ基盤" ですが、まだまだ確立された知見の少ない領域かと思います。少しでもデータエンジニアリングを行う方の業務の参考になれば幸いです。 データ基盤の全体像 収集部分の構成 RDBデータ ログデータ 活用部分の構成 データマートの実例 「データ基
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
決済システムの残高管理周りの DB 設計と戦略 - カンムテックブログ
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
開発者が知っておきたいSQLの実行モデル～アプリからデータベースへのアクセスを高速化するには？
データベースのデータ・モデルは解決したい問題に合わせて使い分けることができ、昨今ではドキュメントやグラフなどのリレーショナル以外のモデルも注目されています。また、トランザクション系が生成した大量のデータをリアルタイムで分析するというような、性質の異なるワークロードを扱うことも求められています。これら性質の異なるデータ・モデルやワークロードを扱うにはどのような実装が必要でしょうか。この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム（DBMS）の基本を振り返り、実装に合った技術の組み合わせを解説します。 第1回はデータベースにアクセスするAPIで最も広く使われているSQLという言語の実行モデルを再確認します。なぜこの言語がリレーショナル・モデルのみならず他のデータ・モデルに対しての操作にも使われるようにな
Do You Really Need Redis? How to Get Away with Just PostgreSQL
Do You Really Need Redis? How to Get Away with Just PostgreSQL There’s a tried-and-true architecture that I’ve seen many times for supporting your web services and applications: PostgreSQL for data storage Redis for coordinating background job queues (and some limited atomic operations) Redis is fantastic, but what if I told you that its most common use cases for this stack could actually be achie
ARIES - Qiita
ARIESとは、WALでページ更新しつつNo-forceかつStealな特性を持ち、Fuzzyなチェックポイントを獲得するという、Disk-Orientedな伝統的データベースでのベストプラクティスを集めた技法である。IBMのFellowであるDr. C.Mohanらによる"ARIES: A Transaction Recovery Method Supporting Fine-Granularity Locking and Partial Rollbacks Using Write-Ahead Logging"という論文が原著のようだ。 IBMのDB2やMircosoftのSQL Serverにて採用されている、とWikipediaには書いてあるが現状の製品の中では様々な改造が加えられて原型を留めてないかも知れない。現にSQL Serverのアーキテクチャはhekatonなどのインメモリ
SQLが重いときに見るお気軽チューニング方法
SQLのチューニング方法 昔Qiitaで書いたものをzennにうつして、若干の修正、追加をしてみました。 ORACLEでの経験を元に書いていますがコストベースのリレーショナルデータべースなら大体共通の考え方だと思うので他にも使えると思います。 SQLのチューニングといえば比較的容易に済むインデックスをとりあえず作成する。といった対応を取られがちですが、数万レコード程度でのデータ量ではあまり効き目がなく（自分の経験則）、どちらかといえば、結合順が大幅に狂ってたりすることが原因のことが多かったりします。よって本当にインデックスがないことが原因なのか？を熟考する必要があります。（例えばID以外のフラグとかコードに単項目indexを貼ってるのもみたことがあります。怖いけど実話） また、インデックスを作りすぎるとオプティマイザが狂いやすくなって他のSQLにも悪影響を及ぼしたりするので結構熟慮して追加
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ - エンジニアHub｜Webエンジニアのキャリアを考える！
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
PlaySQLAlchemy: SQLAlchemy入門
PlaySQLAlchemy: SQLAlchemy入門1. SQLAlchemy 入門 for Kobe Python Meetup #13 2017/09/15 Kobe Japan 2. Yasushi Masuda PhD ( @whosaysni ) Tech team, Core IT grp. IT Dept. MonotaRO Co., LTD. Pythonista since 2001 (2.0～) • elaphe (barcode library) • oikami.py （老神.py） • PyCon JP founder 翻訳もろもろ 3. アジェンダ よくある誤解 SQLAlchemyを3行で エンジンの基礎 (+hands-on) SQL式を使う (+hands-on) ORMの基礎 (+hands-on) 4. 参考文献 オンラインドキュメント: http
NoSQLデータベースCassandraの紹介 〜 ヤフーのデータ基盤を支える技術
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは！ 山下郁矢です。2018年新卒で入社し、現在はNoSQLデータベースエンジニアとして働いています。 サービスを作るにあたってデータベースは必要不可欠ですよね。ヤフーでは100を超えるサービスで毎日生み出される膨大なデータを、データベースを用いてリアルタイムで蓄積し、運用管理しています。 今回は、その中でも利用規模の大きい、NoSQLデータベースの1つであるApache Cassandraを皆様に知ってもらうべく、ヤフーでどのようにして利用されているのかをお伝えしたいと思います。 NoSQLの立ち位置 Cassandraについてご紹介する前に、NoSQLについて軽く説明します。 NoSQLデータベースは一般的に非RDBM
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応
Google、ORMが生成するSQLが遅いときの調査を容易にする「sqlcommenter」をオープンソースで公開。Rails、Spring、Djangoなど主要なフレームワークに対応 SQL文を直接書かなくとも、自動的にSQL文を生成、実行してくれるORM（Object-Relational Mapper）は、プログラミングを容易にしてくれる技術としてRailsやHibernate、Springなどさまざまなフレームワークなどで活用されています。 一方で、ORMが生成するSQL文はときに複雑に、あるいは非効率なものとなり、データベース処理の遅さにつながることもあります。 このとき、SQL文の生成と実行を明示的にコードとして記述する必要がないというORMの特徴が、なぜデータベース処理が遅くなったのか、どのようなSQL文が生成され、そのどこに原因があるのか、といった調査を難しくている面があり
GitLab.comはどうやって6TBのPostgreSQLを9.6から11にたった2時間で移行したのか? | DevelopersIO
GitレポジトリのホスティングサービスGitLab.comは2020年の5月に 6TB あるPostgreSQL 9.6クラスターをたった2時間のメンテウィンドウ中に11.7へアップグレードしました。 GitLab.comのエンジニアブログに、このPostgreSQLのメジャーアップグレードプロジェクトが解説されていたので、かんたんにご紹介します。 How we upgraded PostgreSQL at GitLab.com | GitLab ポイント PostgreSQL 9.6から 11.7 へのメジャーアップグレード 2時間のメンテナンスウィンドウ内でアップグレード完了 データサイズは6TB DBクラスターは GCP 上の 12台の VM インスタンスで構成 クラスターはアップグレード用の8台とリカバリー用の4台に分割 pg_upgrade & ハードリンクでインプレースアップグ
ぐるぐるSQLは止めてくださいという話 - Qiita
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
あと2時間でElastiCacheのメモリが枯渇！そのときあなたは何をしますか？
突然ですが... あなたは、あるゲームプロジェクトの本番リリース2日前にサーバエンジニアとしてJOINしました。いざリリースを迎えたとき、ElastiCacheのメモリが突然危険域を超え、さらにあと2時間で枯渇しそうな状況になりました。 さて、この状況におかれたあなたは何をしますか？ はじめに モバイルゲームのシステムは新しいイベントをopenするとトラフィックが2倍、3倍、時には普段の10倍以上来ることがあり、トラフィックの変動が非常に大きい特性があります。 新しいゲームのリリース時はより顕著で、想定以上のトラフィックが来ることもしばしばあります。 この記事は、あるゲームプロジェクトの本番リリース時に大規模トラフィックが来た際のサーバトラブルを題材に、 どのような観点で問題を切り分けていったのか、トラブルシュートのプロセス どのような準備(負荷テスト)をしていれば防げるのか という話をし
PostgreSQLのメモリアーキテクチャを知る
こんにちは、GMOアドマーケティング インフラ開発部のhakumaiです。 前回の記事「AWSエンジニアがGCPメインの会社に転職してみた」を読んでいただいた方々、ありがとうございます。 初めまして、GMOアドマーケティング インフラ開発部のhakumaiです。今年1月にHRTech系企業からGMOアドマーケティングに転職してきました。現職では、女子向けメディア「めるも」のインフラ業務に携わり、日々業務に励んでおります。今回は、私が転職してみて感じたインフラ技術のギャップの一部についてお話しいたします。 前職でのインフラ環境・経験について前職のHRTech企業で触っていたインフラ環境は、ほぼAWSでした。インフラの保守運用業務に加え、新規プロダクトのインフラアーキテクチャ設計構築を経験したこともあり、V... 今回は2回目の投稿になります。 前回と同様に、「AWSエンジニアから見たGCP」
PostgreSQL Benchmarks: Apple ARM M1 MacBook Pro 2020 | Crunchy Data Blog
This graph is amazing to me: Of course Intel has Xeon processors that have pushed single core performance higher than these laptop-oriented Intel results. But look at that big cluster below 5 clients, showing how long they've been stuck in the same performance range when power and heat is limited. I mentioned last time Intel had only doubled performance in the 8 years of MacBook models I looked at
データベースを遅くするための８つの方法
はじめに Twitterのタイムラインを見ていたらバッチ系のプログラムで逐次コミットをやめて一括コミットにしたら爆速になったというのを見ました。当たり前でしょ、と思ったけど確かに知らなければ分からないよね、と思って主に初心者向けにRDBを扱うときの注意点をまとめてみました。 プログラミングテクニック的なところからテーブル設計くらいの範疇でDBチューニングとかは入ってないです。 自分の経験的にOracleをベースに書いていますが、他のRDBでも特に変わらないレベルの粒度だと思います。 大量の逐次コミットをする バッチアプリケーションでDBにデータをインサートすると言うのはかなり一般的な処理です。しかしデータ量が少ない時はともかく大量のインサートを逐次コミットで処理するとめちゃくちゃ遅くなります。数倍から十数倍遅くなることもあるので、10分程度のバッチが１時間越えに化けることもザラにあるので原
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Cloud Native時代のデータベース
FastAPIを使ってCRUD APIを作成する - Qiita
https://pgstats.dev/