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)
Amazon RDS のベストプラクティス - Amazon Relational Database Service
Amazon RDS の基本的な操作のガイドライン 以下に示しているのは、基本的な運用についてのガイドラインであり、Amazon RDS の使用時にすべてのユーザーが従う必要があります。Amazon RDS のサービスレベルアグリーメントでは、次のガイドラインに従う必要があります。 メトリクスを使用して、メモリ、CPU、レプリカの遅延、およびストレージの使用状況をモニタリングします。Amazon CloudWatch は、使用パターンが変更されたり、デプロイメントの最大容量に近づいたりすると、通知するように設定できます。このようにして、システムのパフォーマンスと可用性を維持できます。 最大ストレージ容量に近づいたら、DB インスタンスをスケールアップする。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。 自動バッ
Amazon Auroraの先進性を誰も解説してくれないから解説する - Qiita
TL;DR; Amazon AuroraはIn-Memory DBでもなくDisk-Oriented DBでもなく、In-KVS DBとでも呼ぶべき新地平に立っている。 その斬新さたるやマスターのメインメモリはキャッシュでありながらWrite-BackでもなくWrite-Throughでもないという驚天動地。 ついでに従来のチェックポイント処理も不要になったのでスループットも向上した。 詳細が気になる人はこの記事をチェキ！ Amazon Aurora Amazon AuroraはAWSの中で利用可能なマネージド(＝運用をAWSが面倒見てくれる)なデータベースサービス。 ユーザーからはただのMySQL、もしくはPostgreSQLとして扱う事ができるのでそれらに依存する既存のアプリケーション資産をそのまま利用する事ができて、落ちたら再起動したりセキュリティパッチをダウンタイムなしで(!?)適
SQLトランザクション分離 実践ガイド | POSTD
(注：2017/10/16、いただいたフィードバックを元に翻訳を修正いたしました。) (注：2017/10/11、いただいたフィードバックを元に翻訳を修正いたしました。) データベースのドキュメントで分離レベルを目にして、軽く不安を感じつつ、あまり考えないようにしたことはないでしょうか。トランザクションの日常の使用例できちんと分離について言及しているものはほとんどありません。多くはデータベースの初期設定の分離レベルを利用しており、後は運頼みです。しかし、本来、理解しておくべき基本的なトピックであり、いくらか時間を投入してこのガイドの内容を学習すれば、もっと快適に作業できるようになるでしょう。 私はこの記事の情報を学術論文、PostgreSQLドキュメンテーションから集めました。分離レベルの 何たる かだけでなく、適用の正確さを保持しつつ最大速度で使うにはいつ使うべきか、という疑問に答えるべ
Best Practices | Cloud Datastore Documentation | Google Cloud
Stay organized with collections Save and categorize content based on your preferences. You can use the best practices listed here as a quick reference of what to keep in mind when building an application that uses Firestore in Datastore mode. If you are just starting out with Datastore mode, this page might not be the best place to start, because it does not teach you the basics of how to use Data
Amazon DynamoDBの応答時間をミリ秒からマイクロ秒へ、インメモリキャッシュのDynamoDB Accelerator（DAX）が正式版としてリリース
AWS上でNoSQLデータベースとして提供されているDynamoDBを高速化する「DynamoDB Accelerator」（以下DAX）が、正式サービスとなったことが、AWSブログの記事「DynamoDB Accelerator (DAX) Now Generally Available」で発表されました。 Amazon DynamoDBはマネージドサービスで提供されているNoSQLデータベースす。非常に高いスケーラビリティと安定した高性能が特徴です。高速なレスポンスやスケーラビリティを重視するようなゲームや広告配信、コンテンツ配信サービス、モバイルアプリケーションなどのバックエンドなどによく使われています。 このDynamoDBにインメモリキャッシュを追加することで高速化するのが、今回正式サービスとなったDAXです。Webサイトからの説明を引用します。 Amazon DynamoDB
MongoDB - Wikipedia
MongoDBはRDBMSではなく、いわゆるNoSQLと呼ばれるデータベースに分類されるものである。RDBMSのようにレコードをテーブルに格納するのではなく、「ドキュメント」と呼ばれる構造的データをJSONライクな形式で表現し、そのドキュメントの集合を「コレクション」として管理する（このデータの物理的な格納はBSONと呼ばれるJSONのバイナリ版といえる形式で行われる）。コレクションはRDBMSのような固定的なスキーマを持たない。ドキュメントには複雑な階層構造を持たせることもでき、それらの構造に含まれるフィールドを指定したクエリやインデクス生成も簡単な指定によって行える。RDBMSのように高度な結合操作を効率的に行うことはできないが、データの追加・更新・削除・クエリは高速に行うことができる。また、アプリケーションは自身の構造やデータ型に合った自然な形でデータを格納することができるため、扱う
PostgreSQLのJSONデータ型っていうのをためしてみる - DRYな備忘録
JOSNデータ型とは 8.14. JSONデータ型 "このようなデータは、text型として格納することもできますが、" "各種JSON固有の関数と演算子もあります" "JSONデータ型にはjson型とjsonb型という2種類" " jsonb型の重要な利点はインデックスをサポートしていることです。" ぱないの スキーマレスな何かを入れるときに重宝しそう。基本的にはjsonbが良いっぽい。 やってみる % psql --version psql (PostgreSQL) 9.5.0 % createdb hoge createdb: could not connect to database template1: could not connect to server: No such file or directory Is the server running locally and a
BigQueryで150万円溶かした人の顔 - Qiita
※ かなり前の記事ですが、未だに引用されるので一応追記しておきます。タイトルと画像がキャッチーなのはちょっと反省していますが、これを見てBigQuery使うのを躊躇している人は多分あまり内容を読んでいないので気にする必要はないです。自分は当時の会社でも今の会社でも個人でも普通にBigQuery使っていて解析用データなどはBigQueryに入れる設計をよくしています。また、アドベントカレンダーだったのでネタっぽく書きましたが事前に想定できる金額です。 ※ 代役：プロ生ちゃん（暮井 慧） 巷のBigQueryの噂と言えば「とにかく安い」「数億行フルスキャンしても早い」などなど。とりわけ料金に関しては保存しておくだけであれば無視できるほど安く、SQLに不慣れなプロデューサーがクエリを実行しても月数ドルで済むなど、賞賛すべき事例は枚挙に暇がありません。 しかし、使い方によってはかなり大きな金額を使
DELETE_FLAG を付ける前に確認したいこと。 - Qiita
DELETE_FLAG という思考停止フラグ DELETE_FLAG という boolean の列が DB 設計でよく話題になります。 論理削除という言葉で上手に論理武装し、スキを見せるとすぐに入れたがる人がおり、 一方でそれにつよく反対する人もいます。 自分の経験としては、広義の論理削除はありえると思いますが、実現方法が DELETE_FLAG だとなった時、それはあまり考えてないでなんとなくパターンとして盛り込んでる場合が多いと感じます。 ただし、設計に唯一の答えは無いので、もしかしたらそれが妥当な設計である場合があるかもしれません。 今回は「DELETE フラグがなぜダメなのか？」などという話をするつもりも、アンチパターンだと断言するつもりもありません。 問題は、仕様をきちんと把握すると、「最適な設計は DELETE_FLAG ではない」という場合が有って、その場合は、その最適な設計
ソーシャルゲームのためのMySQL入門 | BLOG - DeNA Engineering
こんにちはこんにちは。最近お腹痛いばっかり言ってることで有名なiwanagaです。 DeNAは外部的にはプラットフォーム的な部分の方がフィーチャーされることが多いですが、実はソーシャルゲームの提供も行っています。怪盗ロワイヤルとか、どこかで聞いたことがあるのではないでしょうか。 僕はDeNAでソーシャルゲームが誕生した辺りからずっとサーバサイドを見てきましたが、そんな運用の中で自分が貯めてきた知見とかTIPSをご紹介したいと思います。 かれこれ10タイトル近くはレビューしたり運用したりしてるため結構言いたいことはいっぱいあるので、小出しにしつつ評判よければ次も書きます。 ソーシャルゲームのためのMySQL入門一覧 ソーシャルゲームのためのMySQL入門 - Technology of DeNA ソーシャルゲームのためのMySQL入門2 - Technology of DeNA 「MySQL
MySQLのEXPLAINを徹底解説!!
以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約？を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか？そのためにはまず現在どのようにクエリが実行さ
なぜMySQLのサブクエリは遅いのか。
よくMySQLはサブクエリが弱いと言われるが、これは本当だろうか？半分は本当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし
IDの設計についてのさらに突っ込んだ議論
今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり（ブログ書いてないで原稿書けよ＞俺）であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で
MySQL AB :: MySQL 4.1 リファレンスマニュアル
概要 これは MySQL リファレンスマニュアルです。 MySQL 8.0 から 8.0.25、および NDB のバージョン 8.0 から 8.0.25-ndb-8.0.25 に基づく NDB Cluster リリースについてそれぞれ説明します。 まだリリースされていない MySQL バージョンの機能のドキュメントが含まれている場合があります。 リリースされたバージョンの詳細は、「MySQL 8.0 リリースノート」を参照してください。 MySQL 8.0 の機能. このマニュアルでは、MySQL 8.0 のエディションによっては含まれていない機能について説明します。このような機能は、ご自身にライセンス付与されている MySQL 8.0 のエディションに含まれていない場合があります。 MySQL 8.0 の使用しているエディションに含まれる機能に関する質問がある場合は、MySQL 8.0
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
