2024年6月22日に開催された「第14回 関西DB勉強会 」での、 『こんなに違うよ MySQLとPostgreSQL ~MySQLとPostgreSQLのニッチな違いを語る~』 の発表資料です。 https://kansaidbstudy.connpass.com/event/316348/
この記事は? 著者は、現在こそToCの開発に携わっているものの、SaaS開発に関しては3年以上の設計と実装の経験があります。SaaS開発を行う上で必須となるテナントの分離を行う理由は、他企業へのデータアクセスによるセキュリティインシデントを防ぐためです。この記事では、一般のSaaS開発においてマルチテナント×RLSが有力なアーキテクチャとなり得る理由を説明します。 シングルテナントvsマルチテナント 注) テナントの概念に入門する人のためのパート。適宜読み飛ばしてください。 そもそもテナント(tenant)とは、店舗や事務所などを借りて住んでいる人のことを指します。では、SaaSでテナントとは通常誰のことを指すのでしょうか?テナントとはSaaSが展開するサブスクリプションの契約主で、法人と契約しているSaaSであれば企業=テナントになり、個人と契約しているSaaSであれば個人=テナントにな
mysqlの可変長文字列を扱う、varchar型とtext型の違いの話。 古い情報が混在していたので、ちょっと整理してメモ。 myisamの頃の話 sizeが違う 行の中身がdataか(varchar)、dataへのポインタか(text) 参照挟むので、performanceの違いがあった(varcharが早い) 今 net でぐぐって、ひっかかる情報の大半がこの話。 最近のinnodbの話 最大sizeは一緒。64kb(但し、TINYTEXT型、MEDIUMTEXT型、LONGTEXT型は名前の通り違う) varcharもtextも、中身は同じ仕組み(BLOB field / off page column) 行にdata入れるのも、外部(overflow page)への参照にするのも、行フォーマット次第(row format) 5.6で行formatのdefault は COMPACT
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
はじめに 対象となる読者 ツリー構造のデータを RDB で扱うために閉包テーブル (Closure Table) を検討している人 閉包テーブルで順序を保持する方法を探している人 この記事を読んだ後できるようになること 閉包テーブルで順序を保持する方法がわかります 閉包テーブルから深さ優先探索 (前順・先行順・前置順・行きがけ順) でソートした結果を取得できます この方法を採用する場合に注意すべき点がわかります この記事を書いたときの環境 DB: PostgreSQL 9.6.1 なぜ閉包テーブル (Closure Table) を採用しようと思ったか 今まではツリー構造のデータを扱うときに入れ子集合 (Nested Set) を採用することが多かったのですが、このモデルの問題はノードを挿入するために隙間を開ける必要があり、挿入するノードの right より大きい left or/and
はじめに みなさんこんにちは、プロダクト開発本部の亀梨です。 普段はXmediaOneというメディアプランニング・広告運用管理・トラッキング・マーケティング分析を行う 統合プラットフォームの開発を担当しています。 エンジニアの皆さん、SQLクライアント(GUIツール)って何使ってます? わたくしはこれまでデータベースの種類に応じて様々なSQLクライアント(全て無料)を使ってきました。 PostgreSql -> pgAdmin・Postico・PG Commander MySQL -> Sequel Pro Redis -> Medis といった感じです。PostgreSQLはPosticeをメインに使用しているのですが、無料版は接続先が9つと限られているので他のも併用しています。というわけで常時4つ程度のクライアントを使い分けているわけです。手間だし、面倒だし、PCにも優しくない。。。な
「サーバーで付近の情報を通知するサービスのつくり方」 という、Geohashを使って近傍検索を実現する記事をみつけました。 最近Redisに関する記事を書いた関係で、 この記事をみて「GeohashはRedisと一緒に使うともっと便利だよ!」と思わず宣伝したくなったのですが、 MySQL5.7でInnoDBに空間インデックス(Spatial Index)のサポートが入ったので 「MySQLでももっと簡単にできるのでは?」と思い、 RedisやMySQLを含めたいろんなDBで近傍検索を実現する方法を調べてみました。 以前、スマートフォンのセンサを活用して花火の打ち上げ場所を推定するアプリを作った関係で、 地球上での距離計算の実装も気になったので、それについても調査してみました。 関連知識 GeoHash Geohash(ジオハッシュ) は緯度・経度を短い文字列に変換する方法です。 距離が近い
こんにちは、三苫です。 この記事はTECHSCORE Advent Calendar 2014、5日目の記事です。 近年、Rails複数DB Casual Talksが開催されるなど、Railsでも複数・異種データベース混在したシステム構成は何ら特別でなものではなく通常の開発でカジュアルに選択される構成だぞという機運が高まっています。 togetterで参加者の反応を見ても、「establish_connectionは基本」「前にも見たぞこのスライド」など、おおむね知見が業界全体に広まりつつある事がわかります。 本記事はRails複数DBがまだカジュアルではない時代、マルチテナントシステムのデータベースをMySQLからPostgreSQLに、各サブシステムは縮退しつつも、システム全体としては無停止で移行を行った記録を共有するためのものです。 移行したシステムの前提 マルチテナントシステム
■■序論 徳丸さんのスライド「いまさら聞けないパスワードの取り扱い方」に見られるように、昨今、ウェブアプリケーションの設計要件として、サーバ内に侵入された場合でもユーザーのパスワードをできるだけ保護すべきという論調が見受けられるようになってきました。 上掲のスライドでは、その手法としてソルトつきハッシュ化を勧めています。しかしながらスライドに書かれているとおり、ソルトつきハッシュには、複雑なパスワードの解読は困難になるものの、単純なパスワードを設定してしまっているユーザーのパスワードについては十分な保護を提供できないという問題があります。そして、多くのユーザーは適切なパスワード運用ができない、というのが悲しい現実です。 ソルトつきハッシュを使った手法でこのような問題が残るのは、ウェブアプリケーションサーバに侵入した攻撃者がユーザーの認証情報をダウンロードして、認証情報をオフライン攻撃するこ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く