S3にあるALBログの調査はAthenaよりDuckDBのほうが簡単 - road288の日記
AWSのALB(Application Load Balancer)のログはS3に置かれるが、この中身をサクッと調べたいとき、Athenaを使う方法が標準的で、下記で案内されているようにパーティション射影(Partition Projection)でテーブルを作ってAthenaからクエリする。 パーティション射影を使用して Athena で ALB アクセスログ用テーブルを作成する - Amazon Athena 私も従来はその方法を使っていたが、Athenaはブラウザから使うと動作がもっさりしているし、決まったクエリを1回きり実行して結果を取得したいだけのときならまだしも、探索的にクエリを何発も実行したいときには使い勝手が悪い。 最近他のプロジェクトでDuckDBを使うようになって、使い勝手の良さに感動していたが、DuckDBはALBのログを探索的に調べたいときにもめっちゃ使えると思った
今年の汚れ、今年のうちに！MySQLで使っていないインデックスを削除しよう - クラウドワークス エンジニアブログ
この記事は クラウドワークス Advent Calendar 2023 シリーズ2 2日目の記事です。 こんにちは。crowdworks.jp SRE チーム 田中（@kangaechu）です。 年末といえば大掃除ですね。 皆さんのデータベースにも使っていないインデックスが溜まっていませんか？ お掃除してきれいな新年を迎えましょう。 手順 1. MySQLで使っていないインデックスの一覧を取得 未使用のインデックスは sys.unused_indexes ビューで確認できます。 dev.mysql.com しかし、このビューの元データである performance_schema テーブルは起動時から終了時までのデータしか保持していません。 Tables in the Performance Schema are in-memory tables that use no persistent
DB設計の共有で疲弊してない？dbdocsのすゝめ
DB設計の管理や作成に疲弊してません？こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは？ dbdocsは、コードベース（DBML）でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
モデリングはキラキラ技術より地味だが役に立つ / modeling-over-shiny-tech
# Event データモデリングとデータ基盤の構築・運用 （第14回ちゅらコラボ）CARTA HOLDINGS x ちゅらデータ 合同イベント https://churadata.connpass.com/event/254417/ ぼくのかんがえる最高のレポーティング基盤 https://speakerdeck.com/pei0804/hokufalsekankaeruzui-gao-falserehoteinkuji-pan-at-awsdeshi-jian-analytics-modernization ディメンションモデリングモデリング https://zenn.dev/pei0804/articles/dimensional-modeling スタースキーマ https://zenn.dev/pei0804/articles/star-schema-design コンフォ
1000万件オーバーのレコードのデータをカジュアルに扱うための心構え - joker1007’s diary
自分が所属している会社のメンバーの教育用資料として、それなりの規模のデータを扱う時に前提として意識しておかなければいけないことをざっくりまとめたので、弊社特有の話は除外して公開用に整理してみました。 大規模データ処理、分散処理に慣れている人にとっては今更改めて言うことじゃないだろ、みたいな話ばかりだと思いますが、急激にデータスケールが増大してしまったりすると環境に開発者の意識が追い付かないこともあるかと思います。 そういったケースで参考にできるかもしれません。 弊社は基本的にAWSによって運用されているので、AWSを前提にした様なキーワードやサービス名が出てきます。後、句読点があったり無かったりしますが、ご容赦ください。 追記: 社内用の資料の編集なのでかなりハイコンテキストな内容だから誤解するかもしれませんが、これらはそもそもRDBの話ではありません。(関係無くは無いけど) 1000万オ
【旧版・説明欄参照ください】 サーバーレスアプリケーション向きの 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
これだけ抑えればOK!権限管理のDB設計デザインパターン - blog.waterlow.work
目的 最近仕事で権限管理の設計をやっていたのだが、設計でかなりはまってしまった。 今後ははまらないように、DB設計や判断基準をまとめておく。 ベースとなるパターン ユーザとロールは多対１で、ロールとアビリティは多対多に関連している。 権限管理やりましょうという場合にはこれにしておけば大抵の複雑な要求には対応できる。 もしユーザが増えてロールとアビリティの管理が複雑になってきても、DB管理なのである程度自由にやりことができる。 ただし、ちとファーストステップとしてはやりすぎか。 ユーザ-ロールが多対多パターン 前の例に加え、ユーザもロールを多数持つパターン。各権限が互いに素に近い状態、例えばカスタマーサポートとマーケティング、そのどちらも担当する人みたいなケースが有る場合に使える。 アプリケーションが大きくなっていて、権限の数も数十くらいになってきた場合はこれか。 直接アビリティパターン ユ
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
DBの寿命はアプリより長い！ 長生きするDBに必要な設計とリファクタリングを実践から学ぶ アプリケーションの寿命よりも長く、データの追加やテーブルの変更で成長し続ける「データベース」と、どのように付き合っていけばよいのでしょうか？ 曽根壮大（soudai）さんによる寄稿です。 こんにちは。そーだい（@soudai1025）です。 新しいサービスを始めるとき、必ずと言っていいほどデータベースは利用されています。また今稼働しているサービスの多くでも、RDBMSをはじめ、いろいろなデータベースが利用されています。そんなに広く利用されているデータベースだからこそ、多くの問題の元になるのもまた事実です。 そこで今回は、Webサービスを中心にデータベースの選び方、設計についてお話していきたいと思います。そして私もまさに今、2011年から続くWebサービス「オミカレ」のRDBMSのリファクタリングに携わ
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴データテーブルとの向き合い方_PHPerKaigi2024
【イチから理解するサーバーレスアプリ開発】 サーバーレスアプリケーション向きの DB 設計ベストプラクティス 20190905版
履歴を持つデータの設計
想定外な規模へと成長し続けるサービスを 支えるサーバ開発・運用の軌跡 ~ DBの縦横分割スケーリング ~ / History of a large-scale Web API service development and operation with vertical and horizontal database partitioning.