これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気!! 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍(とか)を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
At Buildkite, we've historically stored our data with two keys. We use sequential primary keys for efficient indexing, and UUID secondary keys for external use. The upcoming UUIDv7 standard offers the best of both worlds; its time-ordered UUID primary keys can be utilized for indexing and external use. This blog post will take you on the journey Buildkite took that led to our eventual adoption of
※この投稿は米国時間 2023 年 8 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。 はじめにデータベースのパフォーマンスは、日常業務の効率と効果に影響を及ぼすため、どのようなビジネスにおいても重要です。低速なデータベースはトランザクションの処理を遅延させ、顧客満足度や収益性に悪影響をもたらす可能性があります。 Cloud SQL for PostgreSQL は、Cloud SQL Insights と SQLcommenter によるデータベース オブザーバビリティを備えており、デベロッパー ファーストのアプローチを使用してデータベースのパフォーマンスの問題を診断、検出、予防できます。 Cloud SQL for PostgreSQL は、データベースの接続と接続解除およびクエリ実行に関するメタデータを記録できる追加のデータベース ログをサポートしてい
【Unit4 ブログリレー3日目】 こんにちは,エムスリーエンジニアリンググループの榎田です.数学とテレビゲームが好きです. 今回は,Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します.普段の私が意識していなかった, RDBMS の内部機構に関する話が登場して面白かったので,今回の記事を書きました. なお,本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており,特にその他の RDBMS で同様の動作をするかは確認していません.定性的な挙動に共通するものはあるかもしれませんが,ここで述べた話はそのままは通らないであろうことをお断りさせてください*1. プロダクトについて index なしで意外と耐えたが,耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
PostgreSQLには、用途や環境に応じて様々な構成を組み、最適なパフォーマンスで動作させられるよう、設定ファイルpostgresql.confに多くのパラメーターが存在します。そのパラメーターを正しく設定し調整を行うためには、PostgreSQLのアーキテクチャーを理解する必要があります。ここでは、押さえておきたい、PostgreSQLの基本的なアーキテクチャーについて説明します。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 1. PostgreSQLの基本構成 PostgreSQLの基本的な構成について説明します。はじめに、主なプロセス、メモリー、および、ファイルについての構成図を示します。 図1 PostgreSQLの基本構成 PostgreSQLを構成する主なプロセス、メモリー、ファイルについて、その用語と概要を説明します。 リスナープロセス
弊社では、RDBMSにPostgreSQLを利用して数年間サービスを運営しています。 PostgreSQLはMySQLと違って、Webサービスでの運用事例をあまり見かけないので、今回は弊社サービスの「夜行バス比較なび 」でどのように運用しているかを紹介いたします。 システムの特徴 ユーザからのアクセスは、9割が参照処理。 データはバッチ処理で、随時 ( 毎分 ) 更新されている。 参照SQLの結果はmemcachedを利用してキャッシュをしているが、データの更新頻度が高いため長時間のキャッシュはしていない。 参照SQLは、集計処理が多いため比較的重いSQL。 参照対象となるテーブルのデータ量は、最大で数100万レコードと比較的少ない。 24/7で稼働。 構成 AWSのEC2上に、PostgreSQL 9.3を導入しています。c4系のインスタンスを使いたいので、RDSは使っていません。インス
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」(~約2万件) プランの情報「朝食付き・ロングステイ△△プラン」(0~1500件/施設) 客室の情報(~100件/
はじめにTechnogoly Innovation Group 辻です。 PostgreSQL を使用する際、最適な実行計画が選択されず、クエリの速度が遅くなることがあります。オプティマイザが最適な実行計画を選択できない理由はいくつかありますが、たとえばバッチ処理で大量のデータを投入した直後、統計情報と実データの乖離により、少ないデータに適した計画が大量のデータでは不適切になることがあります。このような場合、PostgreSQL の拡張モジュールである pg_hint_plan を用いた SQL ヒントや pg_dbms_stats により実行計画を固定することで、チューニングが可能です。 私たちのユースケースでは pg_hint_plan を使った SQL ヒントによりクエリをチューニングしましたが、 Aurora PostgreSQL と RDS Proxy を使っている環境下で pg
エンタープライズで利用するデータベースシステムは、障害に強く、安定稼動ができるよう、高可用な構成にすることが要求されます。また、将来的にデータ量やアクセス量が増加しても、サーバー増設等による性能向上により、システムの応答速度や処理キャパシティを維持できるよう、スケーラビリティーの高いシステムが要求されることもあります。 これらの要求に対応するために、PostgreSQLの周辺ツールの1つである、Pgpool-IIを利用した、高可用なシステム構成について解説します。 1. Pgpool-IIとは Pgpool-IIは、アプリケーションとデータベースの間で稼動するミドルウェアであり、LinuxやSolaris上で動作します。Pgpool-IIは、主に以下の機能を提供しています。今回は、Pgpool-II 4.0.2をベースに説明します。 表1 Pgpool-IIの主な機能
uiu です。ハローでは普段バックエンド開発をメインに担当していますが、創業以来片手間でインフラも担当しています。 ハローでは、少数精鋭のメンバーの意識をプロダクト開発に集中するため、インフラ面では Cloud Run などマネージドなサービスを最大限に活用しています。 今回は、久しぶりにインフラに意識の一部を捧げ、いくつかの眠れない夜を過ごす機会があったので、インフラ面の話について紹介しようと思います。 スタートアップと PostgreSQL AutoReserve はサービス立ち上げ以来、DB は PostgreSQL、APPサーバーは Ruby on Rails のバックエンド構成で運用してきています。 特に PostgreSQL は立ち上げ以来安心して使い続けられている技術要素です。サービス運用から(ある規模までの)分析まで PostgreSQL だけで回せる点は、少人数でプロダク
概要 クラウドサービスから新たなストレージエンジンのサービスが出た時に実際の性能評価やちょっとした検証をある程度作り込まれたデータベースでやりたくなる人も多いのではないでしょうか。 今回そんな時に使えるサンプルのデータがあったのでちょっと紹介します。 PostgreSQL Tutorial PostgreSQL Tutorial にサンプルのデータを用意してくれているので、そちらを利用します。 例えばローカル環境上に構築するとして、一旦コンテナで検証してみます。 > docker run -d --name=postgres -p 5432:5432 -e POSTGRES_PASSWORD=postgres postgres
::: message info これは[フィヨルドブートキャンプ Advent Calendar 2022 Part.1](https://adventar.org/calendars/7760)の25日目の記事です。 昨日の記事は:@shujiwatanabe:shujiwatanabeさんの[質問しながら出来るようにしていく](https://shu91327.hatenablog.com/entry/2022/12/24/091025)と:@saeyama:saeyamaさんの[Rails/Vue 編集時に画像をD&Dで入れ替えした時のActive Storageの保存方法](https://saeyama.hatenablog.com/entry/2022/12/24/000123)でした。 ::: ↓こういうのを職人が丹精込めて一つ一つ手作りする時代は終わりました。 ```sh
AWS事業本部コンサルティング部のじゅんやです。 ふとRDSのサポートしているPostgreSQLの拡張機能を眺めていたところ aws_s3という名称が見えなんとなく面白そうだったので触ってみることにしました。 今回作成するもの pg_cron + aws_s3を使ってDB内のテーブル上の古いデータを定期的にS3に退避する処理を作成します。 今回は確認すぐに確認したいということもあるので5分毎に5分以上前のデータを対象に退避するような処理としています。 導入手順が違う部分はありますがRDS専用の機能ではなくPostgreSQLの拡張機能のためオンプレミス等の他の環境でも導入可能です。 pg_cron aws_s3 調査用に保持しているが古くなってくるにつれ使くなるような変更履歴テーブルなど、 持つ必要はあるが滅多に使わないデータをS3のライフサイクの延長として退避することで、 費用の削減を
Kubernetesでもデータベースを本格運用――「PostgreSQL Operator PGO」を使い倒す:Cloud Nativeチートシート(19) Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Operatorを利用して、Kubernetes上でデータベースを動作させる方法とその利点を紹介します。
{ "plpgsqlLanguageServer.database": "データベース名", "plpgsqlLanguageServer.user": "ユーザ名", "plpgsqlLanguageServer.password": "パスワード", "plpgsqlLanguageServer.definitionFiles": [ // glob をサポート。 "**/*.sql", "**/*.psql", "**/*.pgsql" ], // Language Server が対応するファイルの拡張子はデフォルトで ['*.pgsql', '*.psql'] です。 // ( SQLite など他の RDS と競合させないためです。) // '*.sql' のファイルも対応させたい場合は、下記の設定を追加してください。 "files.associations": { "*.sq
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く