GORM で出力されるログの SQL と実行される SQL が違った話 - カミナシ エンジニアブログ
7月に株式会社カミナシに入社したくらさわです！ カミナシでは、現場DXプラットフォーム「カミナシ」の開発をしています！ よろしくお願いします！！！ きっかけ 検証バージョン 結論 コード書いて確認してみた ドキュメント読んでみた コード読んでみた go-sql-driver/mysql のコード GORM のコード まとめ きっかけ 現在、カミナシの開発では、サーバサイドの言語は Go 、ORマッパーとして 「GORM」 を使い、DB には Amazon Aurora MySQL を使っています。 ある日、開発中に GORM が吐いてくれるログで query を調べていると、アプリケーションの実行中は結果が取れていないのに、その query をコピーして、手動で MySQL に投げると結果が取得できるということがありました。 パッとわからなかったので、それについて調べたことを記事にしてみま
MySQL互換のスケーラブルな分散DB「TiDB」、スマレジや＠cosmeによる評価は本番環境のDBから移行可能、性能も十分高いと［PR］
MySQL互換のスケーラブルな分散DB「TiDB」、スマレジや＠cosmeによる評価は本番環境のDBから移行可能、性能も十分高いと［PR］ いわゆる「NewSQL」と呼ばれる、トランザクション処理を実現しつつも非常に高度なスケーラビリティを備えた新しい種類のリレーショナルデータベースが登場し、注目されています。その代表的な製品の1つが、オープンソースで開発されている「TiDB」（タイデービー）です。 TiDBはアプリケーションからはMySQLと同様にアクセスできるMySQL互換のプロトコルを備えつつ、TiDBを構成する主要な2つのレイヤである、SQL文を処理する「TiDB」とデータを処理する「TiKV」がそれぞれオンラインでのスケールアウトに対応することで、リニアに性能を拡張することが可能です。 1つのTiDBクラスタで400TB以上のデータ容量、1つの分散テーブル内で数兆行のデータを扱え
Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
読者対象 ある程度データベースに関する知識を持っている，経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため，すべての SQL 使用者を対象とする また，ゼロからの丁寧な説明というよりは，リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id （データ型と INSERT 時のデフォルト埋め） 導入 一般的に採用されやすいプライマリキー用の値として，以下を考える。 連番整数 MySQL では AUTO_INCREMENT， Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7（ドラフト）: 単調増加であるタイムスタンプとラ
次世代SQLクライアントArctypeを触ってみる
どうも、株式会社プラハCEOの松原です 先日社内のエンジニアに「このSQLクライアントがイケてそう！」と教わったので早速Arctypeを触ってみました TL;DR クエリの補完が最高 チャートやダッシュボードを通して簡単に可視化できる 操作性に優れていて、見た目が綺麗 クエリやダッシュボードごとに権限管理できる プレースホルダーを使えば非開発者ともクエリを共有しやすい 説明しよう、Arctypeとは なんかイケてるSQLクライアントです セットアップ それぐらいしか分からないので、ひとまずDBを立ち上げて実際に使ってみようと思います。こちらのmysql-employeesを使わせていただきましょう docker run -d \ --name mysql-employees \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=college \ -v $PWD/
「スケールアウトできる『PostgreSQL』」――Yugabyte Japanに聞く「分散SQLDB」のメリット
「スケールアウトできる『PostgreSQL』」――Yugabyte Japanに聞く「分散SQLDB」のメリット：「Distributed SQL Summit Asia」の模様をレポート なぜ「分散SQLDB」が注目を集めているのか。日本国内における分散SQLDBの普及に注力しているYugabyte Japanに「分散SQLDB」とその利点を伺いました。記事後半では2022年3月に開催されたアジア圏向けイベント「Distributed SQL Summit Asia」の内容を紹介します。 本連載第4回では、DBエンジニアの祭典「db tech showcase」のイベントレポートをお届けしました。同イベントで多くのデータベース（DB）が紹介された中でも、分散DBのトピックが注目を集めている印象を受けました。 そこで今回は、日本国内における分散SQLDBの普及に注力しているYugabyt
PostgreSQL Isolation について
トランザクションのACID特性のうち、Isolation(隔離性)について整理する。 検証環境検証には、PostgreSQL 10.5を独自ビルドしたものを利用する。 (gdbでデバッグできるように最適化オプションを無効にした) 参考 PostgreSQL 9.4.4をソースコードからインストールする # select version(); version --------------------------------------------------------------------------------------------------------- PostgreSQL 10.5 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28), 64-bit (1 row) #
pixivのブックマークに関する負荷対策をしました - pixiv inside
10/22(金) 追記 この記事で解説している内容について解説する勉強会を開催することとなりました。以下のconnpassよりお申し込みください。 pixiv.connpass.com 10/22(金) 追記 pixivのブックマークについて ブックマークDBの問題について 具体的な対策内容 論理削除廃止・index追加・ブックマークタグのテーブル分割 適応ハッシュインデックスの無効化 アプリケーションコードのリファクタリング・全発行クエリの列挙と見直し 大きな更新処理の非同期化 結果 あわせてよみたい pixivではサービスの成長に伴い、気に入った作品に対して付けることができるブックマークの総数が急速に増加しており、ユーザーの皆様に滞りなくサービスを提供し続けるためブックマークに関するデータベース(以後DB)の負荷対策が必要になりました。 2021年2月より対策を行うプロジェクトを発足し
Google、大規模分散DB「Spanner」にPostgreSQL互換インターフェイスを実装。強い一貫性で秒間10億以上のリクエストを処理可能。Google Cloud Next '21
GoogleはGoogle Cloudで提供している大規模分散データベース「Cloud Spanner」に、PostgreSQL互換のインターフェイスを実装したと発表しました。 At #GoogleCloudNext, we've announced the preview of Cloud Spanner’s PostgreSQL interface—combining the scalability & reliability of Spanner that enterprises trust with the familiarity & portability of PostgreSQL that dev teams . Take a deeper dive ↓ https://t.co/Y3xD1lDPLg — Google Cloud Tech (@GoogleCloudTech
プライマリーキー(primary key)はシーケンシャルな値で良いと思うよ - 角待ちは対空
zenn.dev を読んでの感想です。「シーケンスナンバーをPKにする」以外の項目については言及しませんが、言及しないことは正当性や妥当性を保証していることにはならないです。 InnoDB(MySQL)を想定してます。が、原理は割と一般的なので他のDBでも適用できることが多いと思います。 追記:一般的とは分散でないような"普通の"RDBMSを想定してましたが、分散システム(distributed systemないしreplicated system)のような場合では話が違います。 なぜシーケンシャルな値がよいか 端的にいうと書き込み操作時にバッファープール(baffuer pool)に読み混む必要のあるページが少なくて済むからです。その結果書き込み操作時にバッファープールにページが存在する可能性が高くレイテンシー的に有利になる可能性が高いです。 バッファープール、ページ、btreeなど具体
MySQL で使用するメモリサイズの見積もり - 元RX-7乗りの適当な日々
最近、MySQLのパラメータの調整をする機会があったのですが、特定のパラメータを変更した際に、メモリの消費量にどう影響するのか、というのを調査する際に、インターネッツを彷徨ったところ、サイトによって書いてあることにバラつきがあったので、自分でもまとめてみることにした。 結論から書くと、参考にしたのは以下のオライリーの書籍「MySQLトラブルシューティング」で、記述が一番わかりやすく書かれていた。 このエントリは、この書籍の 「3.9.3 オプションの安全値を計算する」 にて記載がある内容をまとめたものになる。 MySQLトラブルシューティング 作者:Sveta SmirnovaオライリージャパンAmazon 著者について Sveta Smirnova(スヴェータ・スミルノヴァ): Oracle社MySQLサポートグループ・バグ検証グループの主席テクニカルサポートエンジニアとして毎日MySQ
Intro, Data Modeling, Databases | Prisma's Data Guide
Learn how databases work, how to choose the right one, and how to use databases with your applications to their full potential. Introduction to databasesLearn the basics of what databases are, why they are so important for most software, and which types of databases are best for different use cases. Start from the fundamentals to give yourself a solid foundation. What are databases?Comparing datab
MVCCとInnoDBでの実装について - shallowな暮らし
こんにちは。id:shallow1729です。先日はredo logを中心にストレージエンジンについて解説を行いましたが、今回は同時実行制御、特にMySQLなど多くのデータベースで採用されているMultiversion Concurrency Control(MVCC)という技術にフォーカスしようと思います。 今回の記事ではまず前半でMVCCというものがどういうものかについて解説をして、次にMVCCの実装方法についてInnoDBの実装を参考にしながら見ていこうと思います。前提知識はあまりいらないと思いますが、リレーショナルデータベースの操作経験はあったほうがいいかなと思います。また、前回のストレージエンジンの解説で述べた内容はあまり説明しないので、軽く目を通してもらえると頭に入りやすいかなと思います。 shallow1729.hatenablog.com トランザクションの原子性 まずトラ
「トランザクション張っておけば大丈夫」と思ってませんか？ バグの温床になる、よくある実装パターン
この記事は DeNA 20 新卒 Advent Calendar 2020 19日目の記事です。 はじめに MySQLやPostgreSQLに代表されるRDBMSではトランザクションと呼ばれる仕組みが提供されています。多くのWebアプリケーションエンジニアはこのトランザクションを駆使してDBとやりとりをするロジックを組み立てることになります。 しかし不整合を起こしたくない処理があるからといって闇雲にトランザクションを張ったり、トランザクションが張られているからと安心してアプリケーション側で闇雲にロジックを組み立ててしまうと思わぬバグを生むことになってしまいます。 このエントリでは、「トランザクションを張っておけば大丈夫」という考え方は危険な場合もあるということを、ありがちな実装例を交えて紹介していきます。 並列に処理されるトランザクション そもそも、トランザクションは全て直列に処理されるわ
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
PostgreSQLには「中途半端なサイズ」のデータを格納しないほうがいい
ウェブサイトやアプリケーションには、ユーザー名やメールアドレスといった小さなサイズのものからブログ本文といった大きなサイズのものまで多種多様なサイズのテキストが使われています。一般的にはテキストサイズによってデータベースを使い分けることはありませんが、データベースのPostgreSQLでは「中途半端なサイズ」のテキストデータを格納するとパフォーマンスの低下につながるという調査結果とその仕組みを、ソフトウェアエンジニアのHaki Benita氏が説明しています。 The Surprising Impact of Medium-Size Texts on PostgreSQL Performance | Haki Benita https://hakibenita.com/sql-medium-text-performance PostgreSQLの場合、データベースのインデックスとテーブルは
MySQL :: Employees Sample Database :: 3 Installation
The Employees database is available from Employees DB on GitHub. You can download a prepackaged archive of the data, or access the information through Git. To use the Zip archive package, download the archive and unpack it using WinZip or another tool that can read .zip files, then change location into the unpacked package directory. For example, using unzip, execute these commands: $> unzip test_
トランザクション中の文の失敗の扱いの違い - Write and Run
(読みづらいタイトルだな) ことの発端はこのツイート。 MySQLは、以下を満たさないという理解でいいのか？ エラーが出た時にPostgreSQLのようにロールバックを行わないので Atomicity（原子性）・・・トランザクションの実行結果は「全て成功」か「全て失敗」のいずれかでなければならない#mysql— imaharu (@imaharuTech) July 2, 2020 さすがの MySQL でもそこを破ってくることはないだろうと思いつつ、トランザクション野郎としてはちゃんと確かめねばならないと思い、早朝にも関わらず布団から出てラップトップを開いた(午前10時)。 実験1 以下のような docker-compose.yml と sql/script.sql を用意し、実験をする。 version: '3.3' services: db: image: mysql:8 envir
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TiDB on AWS EKS 〜DMM動画のPoCレポート〜 - DMM inside
PostgreSQLのtext型に対するINDEX
VercelからMySQL/PostgreSQLに接続したい場合にどういうアーキテクチャにするのが最適か
