PostgreSQLのRow Level Securityを使ってマルチテナントデータを安全に扱う - HRBrain Blog
こんにちは、サーバーサイドエンジニアーのユキチです。 SaaSの開発を行う上では複数の企業様のデータを扱うことになります。 そういったマルチテナントのデータ設計を行う上で、弊社ではPostgreSQLのRow Level Securityという機能を使って実装しました。 今回はPostgreSQLのRow Level Security（以下RLS）という機能を使ってマルチテナントのデータ操作を安全に扱う方法を紹介していきたいと思います。 マルチテナントデータベース設計 主に3パターンの設計手法が考えられます。 Multi Tenants in 1 Database：複数企業のデータを一つのデータベースで管理 1 Tenant in 1 Database：テナントごとにデータベースを分けて管理。物理的なインスタンスは同じ。 1 Tenant in 1 Instance：テナントごとにデータベ
MySQL8.0のCHECK制約を試してみる
はじめに MySQL8.0.16（2019/04/25リリース）で、新機能としてCHECK制約が追加されました。 同機能は他のRDMSには既に実装されていることが多く、MySQLユーザにとっては待望の機能と言えます。 本記事では、この機能の概要について説明したいと思います。 CHECK制約とは CHECK制約は、その名の通りテーブルに挿入されるデータを精査して条件に見合ったものでない場合は弾いてくれる機能です。 MySQLでは、元々カラムごとに設定されたデータ型があり、その型に合わないデータは弾く仕様になっています（sql_modeの設定によってはエラーになりません）。 例： 数値型（int）の id カラムに対し、文字列（”aaa”）は入れることができない
並べ替えできるデータをデータベースに保存する方法
システム開発を行っているとよく、クライアントからデータを任意の順番に並び替えたいという要望があります。並び替えを実行するプログラムは、配列の順序を変えるだけなので簡単ですが、その順序をデータベースにどうやって保存するかという点についてはいつも迷ってしまいます。 これには色々なやり方がありますので、まとめてみました。 8つの方法 今回は8つの方法に分けてみましたが、いくつかの方法は組み合わせて使えると思いますし、さらに工夫した方法もあると思います。方法1～6は大きなくくりとしてよく見かけるものです。方法7方法8は私が考えたもので見たことがないし私自身も実装したことが無いのですが、飛躍したアイデアでもないので載せました。 対象のデータベースは主にRDBですが、KVSに向いているかどうかも（良い・普通・悪い）の3段階で書いています。 データ構造と使い方の説明は書いていますが、具体的な実装は書いて
分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO
基調講演「30分でわかるデータ指向アプリケーションデザイン」 ・ スピーカー 斉藤 太郎氏 Twitter：@taroleo / Github：@xerial Principal Software Engineer , Treasure Data 東京大学理学部情報科学科卒。情報理工学 Ph.D。データベース、大規模ゲノムデータ処理の研究に従事。その後、スタートアップであるTreasure Dataに加わり、アメリカ、シリコンバレーを拠点に活動中。日本データベース学会上林奨励賞受賞。OSSを中心にプログラミングやデータ処理を簡単にするためのプロダクトを作成している。 「30分でわかるデータ指向アプリケーションデザイン」最新の論文にも触れながら、分散データシステムの世界の魅力を伝えていきます。後半、@tagomoris https://t.co/TQ2TnsFIOT… — Taro L.
知られざる「マルチテナントアーキテクチャ」（3）～スキーマとメタデータの謎 － Publickey
セールスフォースが採用しているマルチテナントアーキテクチャでは、すべてのユーザーが同一データベース、同一スキーマを共有しています。 では、個別に入力項目を増やすようなスキーマの変更を伴うアプリケーションのカスタマイズや、新たなテーブルを作成してそこに独自データを保存するようなアプリケーションの新規作成はできないのか？ といえば、そんなことはなく、セールスフォースが提供するプラットフォームの上で、自由に項目の追加や新しいテーブルの作成が可能です。 全ユーザーでスキーマを共有しながら、しかし個別のカスタマイズを許容する。この一見矛盾する要件を、セールスフォースはどのように実現しているのでしょうか？ （本エントリは「知られざる『マルチテナントアーキテクチャ』（2）～スケーラビリティのカギは組織ID」からの続きです。） 公開されているスキーマを見てみる ユーザーがスキーマを変更したり、新規テーブル
MySQL 外部キー制約のデッドロック | 優技録
外部キー(FOREIGN KEY)制約を利用している場合、 子テーブルに追加、更新や削除を行う時は、必ず親テーブルの対象のidに対して排他ロックを行ってから、更新や削除、追加を行う。 親テーブルの該当idに対して排他ロックを取る 子テーブルの該当行に対して追加、更新、削除等を行う これならロックは起こらない。 外部キー制約を利用していると、 子テーブルにINSERT, UPDATE, DELETEを行うと親に共有ロックがかかる 外部キー制約を利用している子テーブルにINSERT, UPDATE, DELETEを行う場合は、 排他ロック「FOR UPDATE」をかけてからINSERT, UPDATE, DELETEを行う 共有ロック→排他ロックはデッドロックが起こる原因になる。外部キー制約を利用しているテーブルをSELECT以外で操作する場合は、必ず排他ロックを行ってから、更新や削除、追加を
MySQL | 占有ロック(FOR UPDATE)と共有ロック(LOCK IN SHARE MODE) - わくわくBank
トランザクション中で「UPDATE」や「DELETE」を行うとロックがかけられます。また、SELECTについても「占有ロック(FOR UPDATE)」と「共有ロック(LOCK IN SHARE MODE)」をかけることができます。ここでは、ロック周りの動作を確認します。 (動作確認は、MySQL5.7 InnoDBで行っています。) 占有(排他)ロックと共有ロック UPDATE トランザクション内で UPDATE を行った場合、占有(排他)ロック がかけられます。 SELECT トランザクション内で FOR UPDATE を利用した SELECT を行った場合、占有(排他)ロック がかけられます。 トランザクション内で LOCK IN SHARE MODE を利用した SELECT を行った場合、共有ロック がかけられます。 関係 (ロックの解放待ち) ロック種別共有ロック占有ロック
SQL ロックの種類(共有ロック/排他ロック) | ITSakura
ユーザ１が行001を書き込んでいる間は、ユーザ２は行001を読み込み、書き込みともにできません。 →排他ロックです。占有ロックとも言います。 ユーザ2は行001に対して共有ロックも排他ロックもかけることはできません。待ちの状態になります。 デッドロックとは ユーザ1が行001に対してを排他ロックをかけてupdate1を行いました。commitしていません。 ユーザ2が行002に対してを排他ロックをかけてupdate2を行いました。commitしていません。 ユーザ1が行002に対してをupdate3を行おうとしますが排他ロックがかかっていて待ちの状態になります。 ユーザ2が行001に対してをupdate4を行おうとしますが排他ロックがかかっていて待ちの状態になります。 この場合データベースの機能によってはデッドロックを検知して両者の更新を失敗させることができます。 楽観的ロック(アプリ側)
MySQL :: MySQL 8.0 リファレンスマニュアル :: 8.4.7 テーブルカラム数と行サイズの制限
MySQL にはテーブル当たり 4096 カラムの強い制限がありますが、特定のテーブルの有効な最大値が少なくなる可能性があります。 カラムの正確な制限は、いくつかの要因によって異なります: すべてのカラムの合計長がこのサイズを超えることはできないため、テーブルの最大行サイズによってカラムの数 (および場合によってはサイズ) が制限されます。 行サイズ制限を参照してください。 個々のカラムの記憶域要件によって、指定された最大行サイズ内に収まるカラム数が制限されます。 一部のデータ型の記憶域要件は、記憶域エンジン、記憶域形式、文字セットなどの要因によって異なります。 セクション11.7「データ型のストレージ要件」を参照してください。 ストレージエンジンは、テーブルカラム数を制限する追加の制限を課す場合があります。 たとえば、InnoDB には、テーブル当たり 1017 カラムの制限があります。
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.3.1 文字列データ型の構文
文字列データ型は、CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM および SET です。 MySQL は、文字列カラムを CREATE TABLE または ALTER TABLE ステートメントで与えられている型とは異なる型に変更することがあります。 セクション13.1.20.7「暗黙のカラム指定の変更」を参照してください。 文字列カラム (CHAR、VARCHAR および TEXT 型) の定義では、MySQL は長さの指定を文字単位で解釈します。 バイナリ文字列カラム (BINARY、VARBINARY および BLOB 型) の定義では、MySQL は長さの指定をバイト単位で解釈します。 文字列データ型 CHAR、VARCHAR、TEXT 型、ENUM、SET および任意のシノニムのカラム定義では、カラムの文字セットおよび照合順序
SQLを速くするぞ―お手軽パフォーマンス・チューニング
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
