OSS（オープン・ソース・ソフトウェア）データベースの企業利用をお考えのお客様必見！ 代表的なOSSデータベースである「PostgreSQL（ポストグレスキューエル）」をビジネスで本格利用したいと考えるお客様が増えています。しかしOSSデータベースには「企業ユースに耐えうる信頼性・可用性の確保」「情報漏えいなどのセキュリティ対策」「トラブル時のサポート体制確保」など検討しなければならない課題があるのも事実です。そこで、富士通ではPostgreSQLを企業利用するために技術面、サポート面から全面的にバックアップ！PostgreSQLを安心して利用できる体制を整えています。 本ページではPostgreSQLの運用ノウハウや導入いただいたお客様の声（導入事例）やテクニカルキーパーソンへのインタビュー記事、対談、PostgreSQLコミュニティー活動への参加などをとおして当社のPostgreSQL
データベースのスキーマを変更するときは、スキーマの変更作業によってテーブルが長期間ロックされてしまわないように注意が必要です。 2019年にリリースされたPostgreSQL 12.0以降では、NOT NULLを安全に追加するためによりよいベストプラクティスができています。まだ知らない人もいるかもしれないので、ここで紹介します。 何が問題なのか?次のようなDDLコマンドを考えます。 -- posts.moderatedをNULL禁止にする ALTER TABLE posts ALTER COLUMN moderated SET NOT NULL;これはテーブルをACCESS EXCLUSIVEでロックしたままフルテーブルスキャンを行います。その間は他のトランザクションはこのテーブルに関する処理を進行できません。 テーブルが小さければこれで特に問題ありません。しかし、postsがそれなりに大
Serverless computing has a range of benefits. It means quick and simple deployments with no servers to manage or maintain. It means true scalability, serving a large demand without breaking a sweat if and when you get it. (On the other hand, it also means pay-per-use, so you don’t end up out of pocket on hosting costs if a very large demand never comes). Serverless typically also means low latency
We recently ripped out RabbitMQ from our system and replaced it with a queue built on top of our Postgres db and written in SQL. The change took half a day to implement + test, and had a net delta of -580 LOC. Much more importantly, it drastically improved the reliability and resiliency of our system. This is a writeup of that change, the rationale behind it, and how we did it. Note: this is not a
技術戦略部 SREグループの古越です。 前回の記事でパーティショニングを導入する段階で注意するポイントについて主に触れてきました。今回は導入するために具体的に行った事や追加で導入する拡張機能の解説などを踏まえて紹介していきます。 前提知識と導入するまでの背景については前回の検討編を見て頂ければと思います。 Aurora PostgreSQLでテーブルパーティショニングを導入した話 【検討編】 実践したこと 前回のブログでも軽く触れましたが、導入する前には以下を重点的に検証し、実践しました。 パーティション管理の自動化のため pg_partmanを導入する local開発環境でpg_partmanを利用可能にする Aurora PostgreSQLパラメーターのチューニング パーティションの一部をS3にエクスポートする このあたりを具体的に解説していければと思います。 1. pg_partm
技術戦略部 SREグループの古越です。 MoTで開発しているサービスの多くはAurora PostgreSQLを利用しています。一部サービスにはデータが蓄積し、肥大化していくテーブルの管理が課題になっています。今回は開発者からの要望で新規サービスの幾つかにパーティショニングを導入する事になりました。SREグループでパーティショニング導入までに検証したことを検討編と実践編という2つの記事で紹介できればと思います。 検討編では事前検証として行った事のまとめとして、導入検討の段階で注意するべきポイントを紹介いたします。実践編では導入するために行った具体的な施策について紹介してきます。 背景 肥大化するテーブル管理の課題 PostgreSQLに限らずDB一般に言えることですが、ログや履歴が含まれるテーブルはサービス成熟とともに徐々にデータが蓄積していきます。蓄積しすぎて肥大化すると簡単なクエリの応
今回の記事は、パフォーマンスチューニングの観点と仕組みを理解することに主眼を置いています。具体的な対処方法についてはシステムによって異なるため、マニュアルの確認や、各種チューニングサービスのご利用をご検討ください。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 本記事の構成 本記事「パフォーマンスチューニング9つの技」は以下4つの記事から構成されています。他の記事も併せてご覧ください。 パフォーマンスチューニング9つの技 ～はじめに～ パフォーマンスチューニング9つの技 ～「書き」について～ パフォーマンスチューニング9つの技 ～「探し」について～（本記事） パフォーマンスチューニング9つの技 ～「基盤」について～ 1. パフォーマンスチューニングの「探し」とは PostgreSQLは、SQLが発行されると、アクセス先のデータの特性を示す『統計情報』を参照
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Partition and conquer 原文公開日: 2017/11/07 著者: Sergey Dolganov、Denis Lifanov サイト: https://evilmartians.com/ 原文タイトルはおそらくCommand&Conquerのもじりと思われます。 前書き 本記事は実際の出来事をヒントにしたデータベースパーティショニングについて書いたものです。productionアプリ、すなわちRuby on RailsとPostgreSQLの速度を低下させる巨大なテーブルを分割する方法について手順を追って学びます。 これ以上大きくなっては困るとき データベースは肥大化する傾向があります。データベースのサイズはある時点から負債と化しますが、主キー数が上限に達するような極端な状況をなかなか想定できません（そしてこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
