データベースの在庫の持ち方をビットで管理してる話 - 一休.com Developers Blog
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください！ https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
実践Immutable Data Model - 紙箱
ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か？」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま
Raftをつかった分散データベースを作る際に、WALをステートマシンのログであるRaft Logで代用できますか？ （つまり、Raft Logを永続化することでリカバリに利用できますか？） 直感的にはステートマシンが正しく実装されていれば、WALの代用になり得る気がしまがプロの目からみてなにか問題があるのであれば教えていただきたいです。 | mond
できます。 むしろ「データ指向アプリケーションデザイン」ではそういった方向性を推奨しています。Redoログだけ何らかの手段で強固に永続化されていれば、そのログの永続完了を分水嶺にして個別のトランザクションのロールバック・ロールフォワードを決定できるようになり、分散DB全体の原子性を実現する事ができます。 MicrosoftのSocratesはこの方向で詳しく書いているので参考になると思います。 https://www.microsoft.com/en-us/research/uploads/prod/2019/05/socrates.pdf システム図を引用すると以下です。 このXLOG SERVICEと書いてあるブロックの部分でログを永続化し、ページサーバーで必要なログを分配してページ情報をXStoreに置いています。このXLOG ServiceのLanding Zoneは3多重で複製を
DB に JSON を保存したいときに Protobuf を使うと便利 #LayerXテックアドカレ - LayerX エンジニアブログ
こんにちは。バクラク事業部 Enabling チームの @izumin5210 です。最近「HUNTER×HUNTER」の既刊を全部読みました。 この記事はLayerXテックアドカレ2023の9日目の記事です。 前回「1人目データアナリストとしてデータチームに異動しました 」 次回「Slack × Zapier × MiroでKPTでの振り返りをラクにする」 RDB や KVS などのデータ保存先において、データを正規化せずにそのまま保存したいと思うことはありませんか？ 8月にリリースされた「バクラク請求書発行」というプロダクトには「柔軟なレイアウトカスタマイズ」機能が搭載されています。リンク先の画面操作イメージを見ていただくと、この機能の雰囲気を理解していただけると思います。この機能が扱うレイアウトデータはまさに「関係の正規化をせずに保存したいデータ」でした。 bakuraku.jp こ
[Yahoo!広告] Spring Boot+Neo4jを 使⽤した広告アカウント管理での 階層構造化の実現
Yahoo!広告では、広告運用を効率的に行うために、複数の広告アカウントを階層構造で管理できる機能を提供しています。 広告アカウントのデータストアにはRDBを使用していましたが、機能拡張で階層数を増やそうとしたところ、要求された性能を満たすことができませんでした。 解決手段として、階層構造を表現するのにより適したGraphDBのNeo4jを導入しました。 本セッションでは、Spring BootアプリケーションでRDBを利用しながら、Neo4jを導入した事例を発生した課題と対策を含めて紹介します。 発表者 武知 茉美 / LINEヤフー株式会社, エンジニア 2019年度にヤフー株式会社（現: LINEヤフー株式会社）に新卒入社。広告のアカウントシステムの開発。 ※この資料は以下イベントで発表した内容です https://jjug.doorkeeper.jp/events/164154
![[Yahoo!広告] Spring Boot+Neo4jを 使⽤した広告アカウント管理での 階層構造化の実現](https://cdn-ak-scissors.b.st-hatena.com/image/square/3af15eef1c9f86bfef162ba3343c9b671a1c46e5/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F95ab69f47bb9444dbb9c06804f93fb0f%2Fslide_0.jpg%3F27793081)
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ | mond
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか？ 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ（InnoDBの場合16KB）の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
Webアプリケーションのパフォーマンス・チューニングの勘所 / web tuningperformance
# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-application-tuning-guildline - https://speakerdeck.com/soudai/basic-of-rdb - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726 - https://fortee.jp/phperkaigi-2021/proposal/1d
Amazon MSKを用いてMySQLに対してChange Data Captureを実現する - ZOZO TECH BLOG
はじめに こんにちは。基幹システム本部・物流開発部の作田です。現在、ZOZO社内で使用している基幹システムのリプレイスを担当しています。 現在行っているリプレイスでは、既存の基幹システムから発送機能を切り出し、マイクロサービスに移行しています。リプレイスの詳細については、ZOZOBASEを支える発送システムリプレイスの取り組みをご覧ください。 techblog.zozo.com マイクロサービスは発送業務の各作業が完了したことを基幹システムに連携しており、この連携を実現するためにAmazon Managed Streaming for Apache Kafka（以降、Amazon MSK）を採用しました。今回は、サービス間のデータ連携にAmazon MSKを採用した理由やAmazon MSKでの実装例と考慮点について紹介します。MySQLなどのリレーショナルデータベースに対してAmazon
Why we migrated from PlanetScale to Turso.
What are we building ? 🏗️ We are building an open source status uptime monitoring with a beautiful status page. Our goal is to provide a fast service to our users. To achieve this, we are hosting it on the Vercel Edge Runtime, which requires an Edge Database to fully benefit from it. We also aim to simplify contributions to our project by eliminating the requirement for an account on an external
PostgreSQLのアーキテクチャー概要｜PostgreSQLインサイド
PostgreSQLには、用途や環境に応じて様々な構成を組み、最適なパフォーマンスで動作させられるよう、設定ファイルpostgresql.confに多くのパラメーターが存在します。そのパラメーターを正しく設定し調整を行うためには、PostgreSQLのアーキテクチャーを理解する必要があります。ここでは、押さえておきたい、PostgreSQLの基本的なアーキテクチャーについて説明します。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 1. PostgreSQLの基本構成 PostgreSQLの基本的な構成について説明します。はじめに、主なプロセス、メモリー、および、ファイルについての構成図を示します。 図1 PostgreSQLの基本構成 PostgreSQLを構成する主なプロセス、メモリー、ファイルについて、その用語と概要を説明します。 リスナープロセス
DBマイグレーションツールのロールバック機能は使うな - モヒカンメモ
データベースマイグレーションツールのロールバック機能は安全に使えないので使うべきではないと思う。 ロールバック機能 RDBMSのデータベーススキーマを管理するためのツールとして flyway や、ウェブアプリケーションフレームワーク組み込みのマイグレーションツール (例: Laravel Migration ) がある。 DBマイグレーションツールにはマイグレーションを進める (up) 機能のほかに、進めた変更をロールバックする (down) 機能がついている。 マイグレーションを進める例: CREATE TABLE customers ( id INT PRIMARY KEY, name VARCHAR(50), email VARCHAR(100) ); マイグレーションをロールバックする例: DROP TABLE customers; この記事では、ロールバックする (down) 機
MySQLでNested Loopなクエリはインデックスをどう辿っているか - $shibayu36->blog;
タイムライン的なものをSELECTだけで実装しようと思った時に、Nested LoopなクエリでUsing temporary; Using filesortが出るようなそこそこ遅いクエリになる。その時にMySQLがインデックスをどう辿っているかを知りたかったので調べてみた。MySQLバージョンは8.0.33。 あまり自信はないので、もし間違った話をしていたら教えて欲しい。 どのようなクエリを検証するか タイムラインの取得ができるような、ユーザー・フォロー関係・投稿の3つのテーブルを作る。スキーマは次の通り。 CREATE TABLE users ( id INTEGER PRIMARY KEY AUTO_INCREMENT, name VARCHAR(100) NOT NULL ); CREATE TABLE follows ( id INTEGER PRIMARY KEY AUTO_I
MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ
こんにちは、サービス開発部の荒引 (@a_bicky) です。 突然ですが、RDBMS の既存のテーブルを見てみたら「何でこんなにインデックスだらけなの？」みたいな経験はありませんか？不要なインデックスは容量を圧迫したり、挿入が遅くなったりと良いことがありません。 そんなわけで、今回はレコードを検索するために必要なインデックスの基礎知識と、よく見かける不適切なインデックスについて解説します。クックパッドでは Rails のデータベースとして主に MySQL 5.6、MySQL のストレージエンジンとして主に InnoDB を使っているので、MySQL 5.6 の InnoDB について解説します。 InnoDB のインデックスに関する基礎知識 インデックスの構造 (B+ 木) InnoDB では B+ 木が使われています。B+ 木は次のような特徴を持った木構造です。 次数を b とすると、
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
マルチテナントの実現におけるDB設計とRLS / Utilizing RSL in multi-tenancy
B+木入門：PHPで理解する データベースインデックスの仕組み/b-plus-tree-101
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
DBアーキテクチャの比較と選択
実践イミュータブルデータモデル — NEWTポイント機能の設計
Announcing TiDB Cloud, Managed as a Service and in the Marketplace | PingCAP
図解 DB インデックス
