連番IDを使うと会社が潰れる。(訳: 連番とUUIDのベンチマークを取ってみた❤️）
大いなる流れには逆らえない あるAI研究者が言っていた、私の仕事もいつか AI に奪われるという言葉が非常に印象的だった。 私は一時期自分のキャリアに危機感を覚えAIに関する情報を集めていた。そのとき見つけたYoutube動画でこのようなことが語られていたのである。 ではなぜ彼らは研究を続けるのかと思うかもしれないが、個人や一団体がそれを放棄したところで世の中のイノベーションの流れを止めることは不可能だろう。 平和を望む国々も兵器開発をやめられないのと似たようなものだ。 私がこの記事のタイトルを思いついたとき、つい溜息が出た。あまり楽しくない思い出があるからだ。 ただ、思いついてしまった以上これを世に出さないわけにもいかず、血の涙を流しながらこの記事を書いている。 私というちっぽけな存在では、この大宇宙の大いなる流れには逆らえないのだ。 申し遅れました。私、YadaYadaKonnanYa
目的別データベースの実践: PostgreSQL 行レベルセキュリティと DynamoDB Outboxパターン - KAKEHASHI Tech Blog
カケハシのプラットフォームチームのテックリードとして組織管理サービスと認証基盤を開発している kosui (id:kosui_me) です。今回は、目的別データベースをプラットフォームチームではどのように実践しているかご紹介します。 この記事は秋の技術特集 2024の 13 記事目です。 背景 目的 事例1: PostgreSQL の行レベルセキュリティを活用する組織管理サービス 組織管理サービスとは PostgreSQL の行レベルセキュリティ 行レベルセキュリティを用いたトランザクションマネージャー 行レベルセキュリティの運用上の注意点 事例2: DynamoDB を活用する認証基盤と Outbox パターンの活用 カケハシの認証基盤刷新 DynamoDB で実現する高稼働率の認証基盤 DynamoDB の特性を考慮する CDC と Outbox パターン まとめ 背景 医療の分野で様
PHPでデータベースを作ってみた/create-data-with-php
PHPカンファレンス福岡2024の登壇資料です。
MySQL/Aurora/TiDBロック入門 – 第５回 WHERE 条件と違うロック読取り【解説動画付】｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
MySQL/Aurora/TiDBロック入門 – 第５回 WHERE 条件と違うロック読取り【解説動画付】 第５回は REPEATABLE READ と READ COMMITTED の分離レベルの違いによって変わったり、WHERE 条件で感じる直感的な範囲とは一致しない範囲でかかるなど、MySQL のロック読取りの挙動について解説します。 ロック読取りは実戦でよく使われている重要な手法で、細かい挙動も重要なポイントになります。動画と合わせて是非ご覧ください！ ★ 第１回 トランザクション分離レベル ★ 第２回 ロックモニターの読み方 ★ 第３回 ロック読取りも SELECT は止められない ★ 第４回 INSERT を止めるインテンションロック ★ 第５回 WHERE 条件と違うロック読取り ★ 第６回 performance_schema ★ 第７回ギャップロックと消えるロック ★ 第
UUIDとULIDを理解していない方は見た方がいい記事
Auto increment（自動採番）型を採用したくない場合 Auto Incrementは、データベースにおいて自動的に一意の識別子を生成するメカニズムです。通常、数値型の列が対象となり、新しいレコードが挿入されるたびにその列の値が自動的にインクリメントされます。典型的なIDですかね。 ここでは一意性の確保の話や、データ移行やバックアップのデメリットには言及せず、セキュリティとプライバシーの懸念にフォーカスして考えます。 予測可能性 Auto Increment型のIDは連番であるため、次に生成されるIDが容易に予測可能です。これにより、攻撃者がシステムの内部構造を推測し、不正アクセスを試みるリスクが高まります。 情報漏洩のリスク 連番のIDはデータベースの挿入順序を反映しているため、公開されることで企業の活動パターンやデータ生成の頻度が漏洩する可能性があります。 例） 競合他社は、公
Raftとは？ 仕組みから考える得意なこと苦手なこと/What is Raft? Strengths and Weaknesses Based on Its Mechanism
-- 追記-- > termの説明で「今のリーダーが何代目のリーダーかを表す」と書かれていますが、あるterm内でリーダーが1人も選出されないことがあるので、termで何代目のリーダーかは表せなくないですか？ https://x.com/11Takanori/status/1801212885…
存在するはなぜ二階の述語なのか｜ミック
拙著『達人に学ぶ SQL徹底指南書』の中で、EXISTS述語の使い方を解説している章があるのだが、そこでEXISTS述語だけが唯一SQLの中で二階の述語である、ということを説明している。これはEXISTS述語だけが行の集合を引数にとる述語だからである。それは分かるのだが、なぜ述語論理を考えた人（具体的にはゴットロープ・フレーゲ。タイトル画像のおじさんである）はこんな着想を得たのか、そこが分かりにくいという質問をしばしば受けることがある。確かに、数ある述語の中でなぜ「存在する」だけが二階の述語であるのか、というは直観的にすこし分かりにくい。なぜフレーゲはこんなことを考えたのだろう？ この点について、述語論理の創始者でもあるフレーゲの議論を参照しながらかみ砕いて見ていきたいと思う。かなり理論的かつ哲学的な話になるので、興味ない方は読み飛ばしてもらってかまわない。とくにSQLの理解に支障のある話
今更聞けないDBMSのメモリ管理について
DBMSのメモリ管理について データベース管理システム（DBMS）の設計では、大量のデータと複雑なクエリを処理するために、ハードウェアの特性を最大限引き出すことが求められます。 この記事では、DBMSがどのようにメモリを使ってデータアクセスの速度を向上させ、同時にデータの安全性を確保しているのかを解説します。 DBMSと記憶装置の関係について DBMSが使う記憶装置は次の2つです。 HDD HDDは磁気ディスクを使用してデータを記録・読み取りする記憶装置です。その主な特徴は大容量であり、コスト効率が良いことです。DBMSでは、データの永続的な保存にHDDが用いられます。これにより、システムがシャットダウンされた後もデータが保持され、必要に応じて再びアクセス可能となります。 しかし、HDDのデータアクセス速度はメモリに比べて遅いため、リアルタイム処理や高速なトランザクションが求められるアプリ
データベース指向の新OS「DBOS」--クラウド時代に対応する新たなアプローチ
Jack Wallen （Special to ZDNET.com） 翻訳校正： 編集部 2024-04-10 07:30 「Linux」は長年にわたりクラウド上のサーバーに搭載されてきたが、クラウドが急激に拡大したこと、そしてLinuxがクラウド専用に設計されたものではないことを考慮すると、何かを変える必要があることは明らかだった。 その変化をもたらすのは、「Ingres」「PostgreSQL」「VoltDB」の開発に携わったMichael Stonebraker氏と、「Apache Spark」の生みの親でDatabriskの共同創設者／最高技術責任者（CTO）であるMatei Zaharia氏かもしれない。両氏はマサチューセッツ工科大学（MIT）のチームと協力して、「DBOS」（別名「DataBase OS」）という革新的なOSを開発した。 DBOSの開発は2022年に始まった。D
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
Cloudflare、世界中からのデータベースアクセスを高速化する「Hyperdrive」正式サービスに。CDNを用いてDBのコネクションプーリングやキャッシュを提供
Cloudflare、世界中からのデータベースアクセスを高速化する「Hyperdrive」正式サービスに。CDNを用いてDBのコネクションプーリングやキャッシュを提供 Cloudflareは、グローバルなCDNレイヤでデータベースのコネクションプーリングとクエリのキャッシュを提供することによりデータベースへのアクセスを高速化する新サービス「Hyperdrive」の正式サービス化を発表しました。 We kick off the week with announcements that help developers build stateful applications on top of Cloudflare, including making D1, our SQL database and Hyperdrive, our database accelerating service, g
データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
大量のSeedデータの管理基盤としてAirtableを活用したら開発体験が素晴らしかった話 - CADDi Tech Blog
はじめに こんにちは。CADDiでバックエンドエンジニアとして働いている中山です。 今日は、プロダクト開発において大量Seedデータの管理基盤としてAirtableを使ったら開発体験が素晴らしかったのでご紹介しようと思います。 ※ 以下の内容はAirtableの契約プランによって機能が異なること、執筆時にはできないが今後機能が追加されてできるようになっている可能性があることはご了承ください。 はじめに 背景 Airtableとは Airtableでできること UI上で操作が完結し、データの追加/編集がサクサクできる 表計算ソフトでおなじみの便利機能がたくさんある Web APIでCRUD操作ができる IDの生成をAirtableにお任せできる RDBのようにテーブル間にリレーションを作成できる Airtable Automation & Airtable Scripting 細かく権限管理
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - better_hacking_life
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
sq
ChartDB - Database schema diagrams visualizer
発表資料: Golangを使ったDB用負荷テストツールの開発 - so what
データベースでユニークキーにUUIDを使うメリットは何ですか？連番やタイムスタンプまたは複合などではいけないのでしょうか？どうも視認性が悪く使いにくく感じますし連番でも衝突しない気もします。
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
