UUIDとULIDを理解していない方は見た方がいい記事
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
MySQL8.0でSELECT COUNT(*)が低速になる動作は8.0.37で解消されていた！ - CyberAgent SRG #ca_srg
メディア統括本部 サービスリライアビリティグループ（SRG）の鬼海雄太（@fat47）です。 #SRG（Service Reliability Group）は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 本記事は、MySQ
こんにちは。LINEヤフー株式会社で、出前館というプロダクトのサーバーサイドエンジニアをしている古田大志です。 株式会社出前館はLINEヤフーのグループ会社です。資本業務提携を結んでいて、LINEヤフーが開発などをサポートしています。 詳しくはこちらをご参照ください。（https://corporate.demae-can.co.jp/pr/news/demaecan/line.html）（外部サイト） 今回の記事では、その出前館における開発の内容を紹介させていただきます。 出前館はデリバリーサービス事業のプロダクトで、開発においてはマイクロサービスアーキテクチャを採用しています。出前館のマイクロサービスの1つに、クーポンに関するドメインの責務を持ったコンポーネントであるクーポンサービスがあります。 クーポンサービスでは、ビジネスエンハンスに伴う「非機能要件の増大」や「仕様の複雑さの肥大化
Raftとは？ 仕組みから考える得意なこと苦手なこと/What is Raft? Strengths and Weaknesses Based on Its Mechanism
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885873602681 termは必ずしもリーダーを示すものではなく、また票割れや投票前の段階ではリーダーを指すとは限りません。 Raftの論文では > Terms are numbered with consecutive integers. といっており、リーダーかどうかは問いません > log indexは単にlog entriesの中の当該logの位置を示すものなので、「今のリーダー」に言及しないほうが良さそう https://x.com/komamitsu_tw/status/180125035
変化と挑戦：NoSQLとNewSQL Serverless Databaseの技術革新とマルチテナンシーの秘密
リンクアンドモチベーション ソフトウェアエンジニア向け紹介資料 / Introduction to Link and Motivation for Software Engineers
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第３回ロック読取りも SELECT は止められない【解説動画付】 MySQL とその互換 DB のロックの挙動を紹介する入門シリーズ、第３回は第２回で紹介したロックモニターを使って、業務ではよく使われているロック読取りについて解説します。 ロック読取りは、ゲームのバックエンドサーバーなど「同時に多数の処理をこなすけど、データとしての一貫性も重要」な場合に必須となるテクニックです。既に使っているという方も復習を兼ねてぜひご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うレコードロック ★ 第６回 ギャップロックがあっても更新される ★ 第７回 ネクストキー
TimeTree の SRE が海外展開においてやったこと＆やってないこと by【TimeTree × みてね勉強会】 グローバル対応への挑戦 〜SRE/インフラ編〜
![[TimeTree] Aurora から Spanner への 移行の決断と背景](https://cdn-ak-scissors.b.st-hatena.com/image/square/b2996b601519e42f0b70cc7e630a29ea83be92bf/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F545a6393167a49a2ab387ecc0a0ca90c%2Fslide_0.jpg%3F30594713)
DatadogでAPI毎のSQL発行数を可視化してN+1を改善！ - Nealle Developer's Blog
こんにちはSREチームの宮後(@miya10kei)です。最近、スマートホーム化にハマっていていろいろと買い漁っています🛒 N+1問題を検知するのって結構大変ですよね？ 今回はDatadogを使ってN+1問題を可視化し、パフォーマンス改善につなげた話を紹介したいと思います。 ※ 2024/05/29に開催されたJapan Datadog User Group Meetup#4 でもLTしてきました🎤 speakerdeck.com N+1問題とは？ N+1問題は主にデータベースへのクエリーを扱う際に出くわすパフォーマンス上の問題です。1つのクエリーでN件のデータを取得した後にそれぞれのデータに対して追加でクエリーが発行されることでパフォーマンスを大幅に低下させます。（1 + N問題と呼んだ方がしっくりくる気がしますが...🤫） 背景 この取り組みを始めた経緯は、システムへのリクエスト
【JJUG CCC 2024 Spring】物理削除/論理削除 #jjug_ccc_c #jjug_ccc | ドクセル
TORANOANA Lab 物理削除 vs 論理削除 レコード消滅作戦 虎の穴ラボ 河野 裕隆 JJUG CCC 2024 Spring Copyright (C) 2024 Toranoana Lab Inc. All Rights Reserved. #jjug_ccc_c 自己紹介 河野 裕隆（こうの ひろたか） 好きなもの ● 2019/08 虎の穴ラボ入社 ● VOCALOID（初音ミク） ● 新規開発チーム ● 謎解き、クイズ ○ ● クリエイティア他 X: @hk_it7 虎の穴ラボへの入社理由 ● スキルを高めあえる仲間がほしい ● ユーザーに近い仕事がしたい JJUG CCC登壇は半年ぶり3回目 初めてスタッフ参加🎉 2 Copyright (C) 2024 Toranoana Lab Inc. All Rights Reserved. #jjug_ccc_c
Oracle Database 23aiの新機能「AI Vector Search」で、テキストをベクトルデータに変換して検索してみた / 開発者向けブログ・イベント | GMO Developers
Oracle Database 23aiの新機能「AI Vector Search」で、テキストをベクトルデータに変換して検索してみた 5/2に発表およびリリースされた、Oracle Databaseの最新バージョン「23c」改め「23ai」 自らaiと呼称する通り、AIにフォーカスを当てた新機能であるベクトル検索機能「AI Vector Search」が導入されています その新機能である「AI Vector Search」を実際に導入し、ベクトル変換およびベクトル検索を試してみましたのでご紹介します
SQLポケットガイド 第4版
現場で重宝するSQLリファレンス。ソフトウェア開発の現場では、「SQLの構文をすぐに確認したい」「データベースによって異なるSQLの書き方を知りたい」「久しぶりにSQLを使うので簡単に復習したい」といったことがよくあります。本書では、仕事でSQLを利用しているプロの開発者を対象に、主要な5つのデータベース――MySQL、SQL Server、Oracle、PostgreSQL、SQLite――で使われるSQLの構文およびデータベースの基本を簡潔に解説します。PythonやRからSQLを利用する方法も解説しているので、データアナリストやデータサイエンティストなど、開発者以外のSQLユーザーにも有用でしょう。 まえがき 1章 SQL速修講座 1.1 データベースとは何か？ 1.1.1 SQL 1.1.2 NoSQL 1.1.3 データベース管理システム（DBMS） 1.2 SQLクエリーとは何
Amazon AthenaからRDS for PostgreSQLとAmazon S3に対する横串クエリ(Federated Query)を実行してみた | DevelopersIO
接続文字列は以下のような形となります。 一般的なJDBC接続文字列ですが最近だとライブラリ等にラップされているせいで見ることも少ないので意外と忘れがちな部分ではあります。 postgres://jdbc:postgresql://{{RDSのエンドポイント}}:5432/{{接続先DB名}}?secret=${Secretsの名前} 認証情報はSecrets Manager側に以下の形式で保存されていれば利用する際に良い感じに展開してくれます。 { "username": "{{接続ユーザ名}}", "password": "{{接続ユーザーパスワード}}"} パラメータの情報に関する情報は作成上の説明文の記載に加え情報は以下にも記載がありますのでこちらをご参照ください。 ここまでで正常に設定できていればデータコネクタの部分で以下ように接続先のスキーマ情報が確認できます。 ここまでで各種設
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
イベント駆動とドメインモデルの完全性を意識したアーキテクチャ設計
[TimeTree] Aurora から Spanner への 移行の決断と背景