【旧版・説明欄参照ください】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス
【2019/09/12 追記】 この資料は旧版であり、最新版が存在します。 2019/09/12 にアップロードしたものをご参照ください 最新版 → https://www.slideshare.net/AmazonWebServicesJapan/db-20190905 --------（元の文）------------------- 2019/05/09 に #AWSLoft Tokyo で開催されたイベント、「イチから理解するサーバーレスアプリ開発」における講演資料の一つです。 ・サーバーレスアプリケーションにおいて Amazon DynamoDB が利用しやすい理由 ・RDB と DynamoDB の設計プロセス・考え方の対比・明文化 ・実例に沿った DynamoDB の設計プロセス解説とサンプル例題 などを含みます。 イベント: https://understandingbasi
DB スキーマ設計のガイドライン - Qiita
この記事は、2011年頃に書かれた Yii framework サイトの wiki 記事 Guidelines for good schema design の翻訳です。 もともとは Yii 1.1 のために書かれたものですが、Yii 2, Yii 3 にもそのまま適用可能ですし、もっと広く、アクティブ・レコードのような ORM 一般に通用する内容であろうと思われます。つまり、以下の文章中の "Yii" という名前は、あなたが使っている任意のフレームワークの名前に置き換えてもよい筈です。 はじめに 事実上すべての Yii アプリケーションはデータベースの上に構築されます。Yii はデータベースの取り扱いにおいて非常に柔軟ではありますが、以下に述べる設計上の選択をすれば、そうでない場合に比べて、ものごとがより一層都合良く進みます。 最初に、ごく大まかに言うと、Yii アプリケーションではアク
アルゴリズムとデータ構造から理解するRedis / Learn Redis from Internal Algorithms and Data Structures
2019年新卒研修で使った資料です。 内部実装の雰囲気を感じとりながら、Redisについて理解を深める研修を行いました。 以下の内容について学びました。 1. Redisの概要 2. 社内での利用方法 3. 正しい用法用量 Redis についての前提知識は必要としていません。C言語の基礎的な知識は前提とします。
DBアクセスで遅くなったテストの実行時間を Docker で 40% 削減した方法 - Qiita
DBのレイヤーを含むエンドツーエンドテストやDBに依存したコンポーネントの自動テストがたくさんあると、全てのテストが終わるまでに長い時間がかかるようになってしまうことがあります。DBのクエリ実行はネットワークIOやディスクIOなどを含んだ高コストな処理だからです。 Docker を少し工夫して使うと、お手軽にテスト中のDBのクエリ実行にかかる時間を削減できます。自動テストが完了するまでの待ち時間を短縮し、開発のフィードバックサイクルをより早く回せるようになります！ MariaDB を用いたプロジェクトの実績では、DBアクセスを伴うテストケースが 153件 ありましたが、この方法によりそのテストスイートのローカル環境での実行時間を約 43% 削減できました（約 145.7s → 約 83.3s）。 どうやって？ Docker で tmpfs を使います。 tmpfs tmpfs とは、ディス
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
私の考えた最強のログ＆モニタリング設計 - 下町柚子黄昏記 by @yuzutas0
この記事はRecruit Engineers Advent Calendar 2018 - 8日目の記事です。 注意点 タイトルは煽りです。「新規事業におけるデータエンジニアリングの勘所」の方が正しいかもです。 クオリティというか記事の信頼度は、投稿時間がギリギリになってしまったことから察してもらえるとありがたいです。 本エントリーの内容は個人的な見解であり、所属する組織を代表するものではありません。データの取り扱いは非常にセンシティブなトピックでもあるため気軽に発信すべきではないということは重々承知しております。もし誤りや考慮不足だと感じる点があれば、それは全て私個人の力不足によるものですので、どうぞ私個人当てにご指摘のコメントをいただけると幸いです。 もくじ 注意点 もくじ 背景 前提 体制 システム 開発スコープ 機械学習WebAPIは分離 データ基盤設計 全体の設計ポリシー データ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLにWEBアプリのログを保存しているケースの8割くらいが幸せになる方法
アンチパターンから学ぶ RDBの正しい設計 / learn-from-failure-2
RDB THE Right Way - builderscon 2018/ RDB_THE_Right_Way