履歴データテーブルとの向き合い方_PHPerKaigi2024PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222
You Don't Need AWS ~お前にAWSは必要ない~
はじめに タイトルはこちらから拝借しました。この記事は他のパブリッククラウド(Azure, GCP)を薦める記事でもなければ、プライベートクラウドを薦める記事でもありません。また私自身、エンジニアキャリアの中でAWSはたくさん使ってきましたし、今でもソフトウェア開発のわがままに答えてくれる素晴らしいサービスだと思っているので、AWSを貶めるような記事でもありません。むしろ以下に紹介するサービスはAWS上に構築されていることが多く、間接的にもますます世界中の基盤として発展していくはずです。 PaaSアーキテクチャ 前提条件 前提として、現在でも主流なSPAを中心としたフロントエンド、バックエンド、データベースサービスからなるアプリケーションを想定します。 この場合、 フロントエンド → CDN + Static Hosting バックエンド → Container Deploy(Auto S
オブジェクト指向は業務システムで本当に不要なのか？ - Qiita
主旨 以前はシステムの状態をオブジェクト指向でカプセル化し、オブジェクト同士の通信でシステムの制御をしようとしていた しかし、Webアプリケーションのように状態をメモリ上に保持し続けるのが難しい環境が増えると、上記のことがやりにくくなった（ORMのインピーダンスミスマッチの影響が大きくなった） 現在では、システム全体の状態を管理するためにオブジェクト指向を用いるシーンは減っているが、要所要所でシステムを抽象化する道具の一つとして用いるシーンはあり、適材適所で使い続ければ良い はじめに 一時期あれだけもてはやされた「オブジェクト指向」ですが、現在では「業務システム開発においてオブジェクト指向で作るとろくなことがない」、とか、いっそ「不要である」、という意見もよく見かけます。 オブジェクト指向、この記事では特に「オブジェクト指向プログラミング」を対象として話をしますが、その利点は以下の３点に集
Cloud Run + Litestream で RDB を使いつつ費用を格安に抑える
前から気になっていた Litestream を Cloud Run で使ってみたので、そのメモです。 Litestream とは？ サンプルコード 手順 動作確認してみる 制限事項 おまけ まとめ 参考 Litestream とは？ Litestream は、 SQLite のデータベースファイルを Amazon S3 や Google Cloud Storage などのオブジェクトストレージにリアルタイムでレプリケートすることができるオープンソースのツールです。 例えば通常 Cloud Run で DB エンジンとして SQLite を使用しようとしても、コンテナが破棄されると同時に毎回 SQLite のデータベースファイルも消えてしまうため、データを永続化することができません。 しかし Litestream を使用すれば、 SQLite のデータベースファイルをオブジェクトストレージに
Cloud FirestoreからPostgreSQLへ移行したお話 - ZOZO TECH BLOG
はじめに こんにちは。ブランドソリューション開発本部FAANSバックエンドブロックの田村です。普段はサーバサイドエンジニアとしてFAANSのバックエンドシステムの開発をしています。 FAANSとは、弊社が2022年8月に正式ローンチした、アパレル店舗のショップスタッフの販売サポートツールです。FAANSでは、データベースとしてGCPのサーバレスでドキュメント指向のNoSQLデータベースであるCloud Firestoreを当初採用していました。Cloud Firestoreはサーバレスなので運用負荷が掛からず、また安価でスケーラビリティにも優れたハイパフォーマンスなデータベースです。 しかし、Cloud Firestoreを使用して開発・運用していく中で直面した様々な課題からGCPのフルマネージドのリレーショナルデータベースであるCloud SQLのPostgreSQLにデータベースのリプ
主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ | コーソルDatabaseエンジニアのBlog
Microsoft SQL ServerMySQLOracle DatabasePostgreSQLSolarWinds DPAデータベース運用主要RDBMS製品の比較 2022.09.01 渡部 亮太 主要RDBMS製品の比較 – アーキテクチャ, スキーマ, データベース, メモリ Oracle ACE Proの渡部です。 主要なRDBMS製品についてアーキテクチャを比較します。 大枠を整理することが最大の目的です。細かい例外事項や拡張機能は適宜記載を割愛しています。 2022年9月時点の最新バージョンをベースに記載していますが、記載内容にバージョン依存は少ないはずです。 時間ができた時に随時追記予定です。 もし誤りを見つけた場合は、優しく教えていただけると嬉しいです。→ https://twitter.com/wrcsus4 or ryota.watabe at cosol dot
マイグレーションしないRDBMS
README.md マイグレーションしないRDBMSが欲しい! 課題 PostgreSQLなどの既存のRDBMSはスキーマを持つ。スキーマがあることは良いことだが、このスキーマのライフサイクルはアプリケーションコードのライフサイクルと乖離しがちで、結果として以下のような問題が発生する。 特に自動化をしない場合はマイグレーションをデプロイとは別に行う必要が発生する。これにより、 シンプルに作業が面倒。 承認フローが追加で必要になる。または、デプロイはレビューの管理下に置かれているのにマイグレーション側が適切に管理されないなどのミスマッチが起きる。 マイグレーション忘れ、マイグレーションのリバート忘れのリスクがある。 異なるバージョンのアプリケーションは同時に存在できるがスキーマは同時に存在できない。これにより、 ある種のスキーマ変更はローリングデプロイ環境下では実質的に実行できない。 (テー
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
How Litestream Eliminated My Database Server for $0.03/month
Here’s a riddle. My web app keeps all of its data in a SQL database. I can spontaneously tear it down, deploy the code to a different hosting platform, and the app will still serve all the same data. Running my app in production costs $0.03 per month. How is this possible? That’s easy. You have a separate database server running somewhere that stores all of your app’s state. No, my app never talks
RDBの限界とNoSQLの登場
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー
がんばらないDBaaSの作り方 - KADOKAWA Connected Engineering Blog
はじめに はじめまして、KCS部のmaruです。KCS部では、部長といくつかのサービスのオーナーをやっています。 KCS部は、KADOKAWAグループ向けプライベートクラウド(以下KCS)を提供しており、私がオーナーをしているサービスにはDataBase as a Service(以下DBaaS)があります。 主な利用者は株式会社ドワンゴがサービスを提供している『niconico』です。 今回はKCSが提供しているDBaaSについて、いかに頑張らないで運用できるようにしているかについて投稿します。 規模で見るKCS DBaaS KCSが現在提供しているDBaaSは下記の3つです。 KCS RDB基盤 for MySQL バージョン：MySQL 5.7系 MySQL数(概算)：450 masterの総データ量(概算)：3TB KCS Cache基盤 for Redis*1 バージョン：Red
最強データベース（RDB）設計とは？アンチパターンの見極め方法も - FLEXY（フレキシー）
※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大（@soudai1025）と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい
2020年現在のNewSQLについて - Qiita
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
Firebaseを採用する上で思っていることをちゃんと書く - Qiita
Help us understand the problem. What is going on with this article? これはなに？ 先日投稿した君はまだ平成のアーキテクチャを使ってるのか？僕はFirebaseと令和の時代に行くぞ。の続きです。 思っていたよりもたくさんのフィードバックを頂いて驚いています。ありがとうございます。 伝えたいことが伝わっていてよかったなと思う一方、記事の内容の設計が微妙だったなという感じのご指摘もいただきました。この記事では、前回の記事を読んでいただいたみなさんが抱いたであろう疑問・懸念にお答えすることができればと思っています。 この記事だけ読んでもおそらく何の話かわからんとおもうので、先に前回の記事を読んで頂くと良いと思います。 Firebaseって銀の弾丸なの？ 違います。 先の記事から引用しておきます。 大切なことは、解決したい問題を明ら
ダイソーが6年でIT内製化、マイクロサービス化、サーバレスに成功した理由
大創産業は1972年、家庭用品を販売する商店として創業された。今やよく知られた『100円SHOPダイソー』を運営する事業者である。ダイソーの展開に着手したのは1987年。2019年には国内3367店舗を数え、海外ではアジア、北米を中心に28の国、地域で2175店舗を構えるほどのグローバル展開を果たしている。 キッチン用品や文具、衣服やコスメ、食品やガーデン用品など、幅広い商品展開もダイソーの魅力の一つだ。商品数は7万点を超え、売れ筋の電池は1秒間に5本、ネクタイも15秒に1本、“つけまつげ”は1.3秒に1つ売れる勢いとのことだ。 取り扱う商品が多く、また尋常ではない速度で売れていくことは、それだけデータ管理の難しさが増すということでもある。アイティメディアが2019年9月17日に開催した「ITmedia DX Summit 2019年秋・ITインフラ編」に登壇した大創産業 情報システム部
RDBの限界とNoSQLの登場 - Qiita
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html NoSQLの登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャーディング
ダイソー快進撃を支える｢毎晩105億件データ処理｣する需要予測システムはどう生まれたか
小売業の特徴は、いわゆる｢ニッパチの法則｣（売り上げを支える売れ筋商品は全体の2割という法則）。いかにして売れ筋商品の在庫を把握し、将来の需要を予測して、欠品なく並べ続けるかは生命線だ。 一方、ダイソーの特徴は、取り扱う商品点数が非常に多いことだ。 大創産業情報システム部課長の丸本健二郎氏によると、ダイソーは全世界27カ国で5270店に展開し、新商品は毎月約800。｢均一価格｣は日本と同じだが、価格レンジは各国地域の物価に合わせている。 こういう状況では、｢人間の能力では在庫を把握するのは難しい｣という前提に立って、丸本氏が取り組んだのが、POSデータの統計的解析から個店ごとの需要予測をして欠品をなくす｢自動発注システム｣（2015年導入）だった。 着想後、いくつかの店舗で試験的に導入したところ、着実に欠品率が下がり、｢チャンスロス｣が解消された。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - superfly/litefs: FUSE-based file system for replicating SQLite databases across a cluster of machines
Google Cloud Spanner 沼への誘い Basic v20210730a
NoSQL は Poor SQL？ - Qiita