# DBリファクタリングの勘所と所感 - https://soudai.hatenablog.com/entry/2017/12/27/080000 # アジャイル開発とデータベース設計 - 変化に対応するシンプルな実装のために必要なこと - https://agilejourney.uzab…
例えば次のようなテーブルがあったとする。 -- PostgreSQL CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); -- MySQL CREATE TABLE history ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, data TEXT, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First
STEP2. アウトプットを実現するために必要なデータソースを書き出す アウトプットの整理ができたら、今度はインプットとなるデータソースの整理を行いましょう。 必要なデータソースは要件から読み解くことができます。 今回は「10代のユーザーの月間視聴数(性別 / 動画カテゴリごと)の推移をグラフで見たい」という要件です。 ここから、この分析に必要なエンティティ(実体)とその属性、集計値を抽出しましょう。 エンティティと属性 ユーザー 性別 年代 動画 カテゴリ 集計値 視聴数 これらのデータを管理するテーブルを、調査やヒアリングを実施して探します。 今回は以下のテーブルを使用することとします。 user:ユーザー登録に必須な入力項目を管理するテーブル user_profile:ユーザーが登録後に設定できる任意の入力項目を管理するテーブル video:ユーザーが投稿した動画を管理するテーブル
そーだいさんが執筆された記事で、履歴テーブルから最新の1件を取ってくる方法について解説している。PostgreSQLの例だと以下のようなユーザーの履歴データに対し: CREATE TABLE history ( id SERIAL PRIMARY KEY, user_id INTEGER NOT NULL, data TEXT, created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ); INSERT INTO history (user_id, data, created_at) VALUES (1, 'First entry of user1', '2024-01-01 10:00:00'), (1, 'Second entry of user1', '2024-01-02 09:30:00'), (2, 'First entr
突然ですが皆様は、稼働済みサービスのDBからテーブルカラムを削除されたりすること、ありますでしょうか? 基本的に削除はまずやらないのではと思います。えっやらないの? と思われた方もいらっしゃるかもしれませんが、きっとこの記事を読めばなぜ多くの方がカラム削除を避けるのかわかることでしょう。 とはいえ、そうして使わないカラムがテーブルに溜まっていくとやがて新規加入メンバーがコードにキャッチアップする妨げとなるレベルにまで溜まってきたりします。いつかは大掃除のときがくるわけです。DBは寿命長いですからね。そうしたときに実際どのような手順でカラムを削除するのか見ていきましょう。エムスリーエンジニアリンググループUnit1(製薬プロモーション)・Unit9(治験臨床研究支援)チームエンジニアの三浦 [記事一覧 ]が、最近実際にやった作業から知見をお届けします。 長いので3行で 考え方 1. そのカ
はじめに こんにちは。calloc134 です。 前のハッカソンイベントで、UUID をプライマリキーに利用するかどうかの議論がありました。 結果的にはあまりパフォーマンス要件の高くないアプリケーションであったため、プライマリキーとして UUID を採用することにしたのですが、イベント終了後に気になったため、調査を行いました。 今回は、この調査の結果を元に、MySQL と PostgreSQL におけるインデックスの内部構造の違いと、UUID をプライマリキーにする際の問題についてまとめてみたいと思います。 インデックスの概要 インデックスとは インデックスとは、データベースのテーブルに対して、アクセスを高速に行うための指標となる構造のことです。 インデックスとは日本語で索引ですが、まさに辞書の索引のように、アクセスにおいての手助けをしてくれます。 より具体的に解説すると、データベースにお
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
こんにちは、データベース愛好家のみなさん!今日は、データベース設計で永遠の議論となっている「テーブル名、単数形 vs 複数形問題」について、徹底的に掘り下げていきます。私は単数形派です!でも、なぜそうなのか、一緒に深掘りしていきましょう。 イントロダクション:我らが主人公、単数形くん みなさん、こんな経験ありませんか? You: テーブル名って、users? user? どっちがいいんだろう... 先輩: いや、絶対usersだよ!Rails使ってるし。 You: でも、user_idって書くときは単数形だよね? 先輩: あ、そうだね...でもやっぱりテーブルは複数形! You: (心の中で)なんかモヤモヤする... 実は、この「モヤモヤ」には理由があるんです。今日はその理由を解き明かし、単数形テーブル名の魅力をお伝えします。準備はいいですか?Let's dive in! 言語の壁を突破せ
DynamoDBも当初はマネージドとしてシンプルでしたが要求が増えるにつえ複雑になってきました。 *ソフトウェアでは良くあることで、そして新しくシンプルなものが生まれ新しいサイクルが始まる モデリングなどはドキュメントを見ていただきつつ、この記事では間違えやすい抑えていただきたいポイントを解説します on-demandモードを使う 初期設定はprovisionedモードになりがちですが固定料金を取られます。また、トラフィックが読めないとき、増減激しいときもあるでしょう on-demandモードが無難です(2024/11/1から半額になりなおさら) CDKの場合、dynamodb tableV2を使うと初期設定でon-demandです provisionedになっているテーブルを探すならAWS Configを使えばアカウント横断で検索できます provisionedは上級者向け。地味に難しい
はじめに 私ごとではありますが、現場でdynamodbをメインのデータベースとして採用してから約2ヶ月が経ちました。 たった2ヶ月いう期間で、何度も心身ともに崩壊し、そして粘り強く復活を遂げ、かろうじて奇跡的にレベルアップをしてきました。 今回の記事では、これからdynamodbの導入を検討しているエンジニアの皆様に向けて、わずかながら現場で(汗と血を流しながら)得た知見を共有したいと思います。 主にdynamodbを導入するときに楽できる部分、楽できない、苦労する部分がどんな感じか、この記事でなんとなく伝えられたら嬉しいです。 以下では、4つの項目(採用基準、設計、開発、運用)に分けて、知見を羅列していきますが、私もまだ駆け出しdynamodberの域を出ないので、誤りやアドバイス等ございましたら、是非コメントいただきたいです! なお、ここで紹介する内容は基本的にはAWSの公式ドキュメン
はじめに Goで自作RDBMSに挑戦してみたログです。自作、といっても大部分は参考にした書籍の移植です。 ここ1年くらいRDBに向き合う機会が多く、その内部実装を手を動かしながら身を持って理解してみたいというモチベーションから始めてみました。ちょうど会社の『内部構造から学ぶPostgreSQL』読書会に参加したこともモチベーション上げるきっかけとなりました。 (他の方の記事ですが、読書会の記録はこちら↓) 『内部構造から学ぶPostgreSQL』読書会を完走した感想 [改訂3版]内部構造から学ぶPostgreSQLの社内読書会振り返り データベースをデータの箱としか思っていなかった私の『内部構造から学ぶPostgreSQL』を読んだ感想 普段何気なく使ってるRDBMSですが、ACID特性を守るため・大量の読み書きを捌くため、非常に緻密に設計されております。 これを完全再現といかなくとも自分
はじめに リレーショナルデータベース設計の世界へようこそ!このガイドでは、データベース設計の基本から応用まで、幅広くカバーしていきます。一緒に学び、理解を深めていきましょう。 リレーショナルデータベースとは リレーショナルデータベースとは、データを表(テーブル)形式で整理・管理するシステムのことです。各テーブルは行(レコード)と列(フィールド)で構成され、情報を効率的に保存・検索できます。 例えば、顧客情報や注文履歴を別々のテーブルで管理し、共通のキー(例えば顧客ID)で関連付けることで、必要な情報を簡単に取得できます。このような構造により、データの一貫性や整合性を保ちながら、複雑なデータ操作や分析が可能になります。 本ガイドの目的と構成 このガイドの目的は、リレーショナルデータベース設計の基本概念から高度なトピックまでを体系的に学び、実践的なスキルを身につけることです。各章では、理論的な
カーネルにDBMSを載せた分散OS「DBOS」の特徴と利点は? サーバレスでTypeScriptとPythonの実行に対応 マサチューセッツ工科大学(MIT)とスタンフォード大学の研究者によって考案された分散OS「DBOS」が、TypeScriptに加えてPythonの実行に対応したことが発表されました。 DBOSはOS内部にデータベースが組み込まれており、OSやアプリケーションのすべての処理や状態をデータベースが記録します。そのため、アプリケーションやOSが何らかの原因で終了したとしても、処理や状態を失うことなく終了したところから再開できるなどの利点を備えています。 これによりTypeScriptやPythonで耐久性の高いアプリケーションの構築を容易にしています。 DBOS is coming to #Python! Development of the DBOS Transact f
マイクロソフト、NoSQL標準の策定を目指し、Cosmos DBで使われている「DocumentDB」をオープンソースで公開。PostgreSQLをベースに マイクロソフトはNoSQLデータベースの実装として「DocumentDB」をオープンソースで公開したことを発表しました。 DocumentDBは、Microsoft Azure上のvCore-based Azure Cosmos DB for MongoDBとして提供されているNoSQLデータベースのオープンソース実装です(AWSもMongoDB互換の「Amazon DocumentDB」と呼ばれるサービスを提供していますが、別の実装です)(追記:当初、「Azure DocumentDB」のオープンソース実装と記述していましたが、間違いでしたので記述を改めました。お詫びして訂正します)。 Announcing DocumentDB,
Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation. For the best experience please use the latest Chrome or Safari browser. Firefox 10 (to be released soon) will also handle it.
国産のインメモリDB「劔(Tsurugi)」、さくらの高火力上で一貫性を保ちつつ永続化の書き込み処理を5ミリ秒で実証。超低遅延AIシステムの実証実験 ノーチラス・テクノロジーズ、さくらインターネット、そしてスーパーフォーミュラなどカーレースの運営や宣伝などを行う日本レースプロモーション(以下、JRP)の3社は、鈴鹿サーキットで超低遅延AIシステムの実証実験を行い、その結果を発表しました。 実証実験では、鈴鹿サーキットで実施されたスーパーフォーミュラのレースにおいて走行中の21台のフォーミュラカーからテレメトリデータを取得。さくらの高火力コンピューティング上で稼働する国産インメモリデータベースである「劔(Tsurugi)」で機械学習によるラップタイム予測と順位予測などの推論とデータベースへの登録などの処理が行われました。 この実証実験におけるシステム上のパフォーマンスは、テレメトリデータに適
「これを見たらトランザクション周りがざっくり分かる」を目指します。 MySQLを前提に解説しますが、他のDBMSでもベースとなる部分は同じだと思います。 トランザクションとは? ざっくり言うと「ここからここまでワンセットです」な処理のことです。 たとえば、以下のようなSQLが2つあったとします。 この2つは絶対にセットで実行したいとします。 ですが、この2つを実行した結果「1つ目は成功したけど2つ目は失敗した」となった場合、「在庫だけ減ってしまった!」になってしまいます。 こういうときにトランザクションが使えます。 この2つをトランザクションとして実行すると、以下のどちらかに強制できます。 すべて実行する すべて実行しない つまり、中途半端に実行されるのを防げます。 トランザクションの書き方 トランザクションとして実行するには、BEGINとCOMMITで囲います。
今回発表されたDocumentDBとは DocumentDBは2025年1月にMicrosoftからオープンソースとして発表されたデータベースで、いわゆるNoSQLのワークロードを対象としながらも、以下のような興味深い特徴を持っています。 PostgreSQL上に構築されたドキュメント型のデータベース Azure Cosmos DB for MongoDBのエンジンとして使われている 今回の発表ではpg_documentdb_coreとpg_documentdbという2つのモジュールが公開された リレーショナルデータベースと異なり、NoSQL(ここではドキュメント型)では事実上の標準としてMongoDBがありますが、彼らは2018年にSSPLという新たなライセンスを発表し、オープンソース界隈で大きな議論を巻き起こしました。 そうした動きに対して、今回のDocumentDBではNoSQLの標
Techouseの「エンジニア基礎勉強会」とは Techouse では「基礎勉強会」と称して2週間に1回、わたしが OS・ネットワーク・データベース・ハードウェア・セキュリティ・システムアーキテクチャなどをお話する勉強会を開催しています。 講師は私ひとり、資料を準備するのも私ひとり、動画を収録して YouTube Live で社内向けに配信する作業も私ひとりでやってます。 参加は任意ですが、社内のメンバー (社員・インターン生・業務委託でご参画いただいている方) の多くの方が参加してくれています。先日の RubyKaigi 2024 に参加してくれたメンバーもほとんどがこの勉強会に参加し、基礎的な知識をもった上でセッションへ臨んでくれました。 開催履歴 これまでの開催履歴はこんな具合です。 見ていただくとわかる通り、ほんとうに基礎的な内容を1個ずつやっているということがわかるかと思います。
この記事は以下の2つのアドベントカレンダーの5日目のポストです。クロスコミュニティ! Snowflake Advent Calendar 2024 HTAPデータベース Advent Calendar 2024 Snowflake Hybrid Tables 2024年10月についにGAされたSnowflake Hybrid Tablesは、主キーや行ロック、インデックス等を具備した行指向の実装によるOLTP(Online Transaction Processing)的なワークロードと従来のOLAP(Online Analytical Processing)ワークロード双方に同時に対応できるその名の通りハイブリッドなアーキテクチャとなっています。こうしたOLTPとOLAPのハイブリッドアーキテクチャやハイブリッドワークロードはHTAP(Hybrid Transactional/Analy
Techouseの「エンジニア基礎勉強会」とは Techouse では「基礎勉強会」と称して2週間に1回、わたしが OS・ネットワーク・データベース・ハードウェア・セキュリティ・システムアーキテクチャなどをお話する勉強会を開催しています。 今回お試し的に、勉強会の内容を公開してみます。 データベース(1) ACID データベース(2) 分離性 今回は前回「データベース<ACID編>」の続きです。 ご笑覧くださいますと幸いです。 データベース(2) トランザクション <中編: 分離性> 前回で扱った「銀行口座」の例をそのまま使っていきます。 BEGIN; DROP TABLE IF EXISTS accounts; CREATE TABLE accounts ( id serial PRIMARY KEY, name varchar NOT NULL, balance decimal NOT
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く