Pinterest、6人で1100万人支えてた時代のDB設計がヤバい Pinterestが6人のエンジニアで1100万人のユーザーを支えてたって話、控えめに言ってバグってるんだけど… それ以上にすごかったのが、その急成長をMySQLベースのアーキテクチャで乗り越えた戦い方だった。 MongoやCassandraを試しては不安定さに泣かされ、クラスタリングはリバランスが地獄。 何度もデータ破損の危機を迎えた末に選んだのが、シャーディング × キャッシュ × シンプル設計。 ユーザーごとに全データをひとつのシャードに集めて、ID構造でどのシャードにあるか即判定できる仕組みを用意。 さらに結合や制約はアプリケーション層に逃がして、 「システムは壊れる前提」で動くように組んでたのが本当にかっこいい。 もちろん失ったものもある。トランザクションとか、JOINとか。 でもそれ以上に、「崩壊せずスケール
最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
【プロンプト付き】AIエージェントと社内DBをつなげて、SQL不要なデータ分析基盤を構築する - BigQuery編 本記事を読むとわかること 1. なぜ今「AIでのデータ分析」が注目されているか 2. SQL不要でデータ分析ができるAIを爆速構築する方法 3. 導入時に気をつけたい“誤回答対策”や“運用”のポイント はじめに「社内にある膨大なデータを活用したいけれど、SQLが書けない…」「エンジニアの協力を仰がないとデータ分析が進まない…」 そんな悩みを持つ方、多いのではないでしょうか。 ここ数年のAI技術の進歩はめざましく、いまやプログラミングスキルがなくてもAIを通して扱うハードルが下がっているツールが増えています。特に、自然言語で指示すると裏側でAIがSQLクエリを生成し、必要なデータをサッと引っ張ってきてくれる――そんな仕組みがいま大注目。いわゆる「Text-to-SQL」と呼ば
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 排他制御とは 共有資源（データやファイル）に対して複数のアクセスが見込まれる場合に、同時アクセスにより不整合が発生することを防ぐため、あるトランザクションが共有資源（データやファイル）にアクセスしている時は他トランザクションからはアクセスできないようにして直列に処理されるように制御すること。 ■同時アクセスによる不整合の例 ■排他制御をすることで整合性を保つ 排他制御の方式 排他制御の実現方式はいくつか存在するが、ここでは代表的な楽観ロック（楽観的排他制御）と悲観ロック（悲観的排他制御）を紹介する。 楽観ロック（楽観的排他制御） 楽観ロ
InfluxDB 3.1 Now Available: See what’s new in Core & Enterprise Time series starts with InfluxDB Join the millions of developers using InfluxDB to predict, respond, and adapt in real-time. InfluxDB 3 Core and Enterprise are now generally available, bringing the full power of InfluxDB 3 to production. Get started with InfluxDB
This textbook examines database systems from the viewpoint of a software developer. This perspective makes it possible to investigate why database systems are the way they are. It is of course important to be able to write queries, but it is equally important to know how they are processed. We e.g. don’t want to just use JDBC; we also want to know why the API contains the classes and methods that
はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 ZOZOTOWNリプレイスが順調に進む中始まった「カート決済機能」のリプレイス。第5回では、始動の経緯と、システムの安定稼働につながる大きな改善をもたらしたキューイングシステムの導入について解説します。 目次 はじめに 目次 ZOZOTOWNカート決済リプレイスの始動 体制変更 カート決済サービスの将来像 ジレンマと優先順位 スケールアップ戦略だけでは防ぎきれなくなった障害 キューイングシステムの導入 Kinesis Data Streamsの採用理由 First In First Outでのキャパシティ Kinesis Client Libraryを利用した開発工数の削減 本システムのポイント 過熱商品専用のKDSを作成 既存
Latest Versions Stable v0.11.5 Note that v0.11 is not fully compatible with v0.9. Several plugins for v0.9 would not work with v0.11. Take a look at this article for details. Past stable v0.9.25 Recent Articles Looking for long-term maintainers around the Embulk eco-system Shutting down dl.embulk.org Installing Maven-style Embulk plugins 'embulk gem install' may fail in Embulk v0.9: incompatibilit
はじめに Goで自作RDBMSに挑戦してみたログです。自作、といっても大部分は参考にした書籍の移植です。 ここ1年くらいRDBに向き合う機会が多く、その内部実装を手を動かしながら身を持って理解してみたいというモチベーションから始めてみました。ちょうど会社の『内部構造から学ぶPostgreSQL』読書会に参加したこともモチベーション上げるきっかけとなりました。 (他の方の記事ですが、読書会の記録はこちら↓) 『内部構造から学ぶPostgreSQL』読書会を完走した感想 ［改訂3版］内部構造から学ぶPostgreSQLの社内読書会振り返り データベースをデータの箱としか思っていなかった私の『内部構造から学ぶPostgreSQL』を読んだ感想 普段何気なく使ってるRDBMSですが、ACID特性を守るため・大量の読み書きを捌くため、非常に緻密に設計されております。 これを完全再現といかなくとも自分
エンジニアの佐野です。今日はカンムの決済システムでユーザの残高管理をどうやっているかについて書きます。 カンムの製品であるバンドルカードはプリペイド方式のカードです。ユーザによる入金、店舗での利用、運営事由の操作などによりユーザの残高が増減します。このような残高の管理について単純に考えると user_id と balance と updated_at あたりをもったテーブルを用意して balance と updated_at を更新していく方法があるかもしれません。しかしながらカンムでは残高を管理するテーブルを持たず、これらイベントの履歴のみで残高を管理しています。以下、本記事ではこれらユーザの残高が増減するイベントのことをトランザクションと呼びます。ここでは DB の Transaction Processing を意味しません。 本記事のポイントは 残高を管理をするテーブルは作らず、ト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
