Learn Postgres at the Playground | Crunchy Data Blog
Today I'm excited to introduce a new place for devs to polish their Postgres skills, a Postgres Playground and Tutorials from Crunchy Data. What is the playground? Put simply it is: Postgres running in your local web browser With canned datasets you can load Guided tutorials to follow along to learn about the power of Postgres Postgres in a browser?!? Wait?!?!? Postgres in the browser? Yep. You ca
Google、MySQL/PostgreSQLでクロスリージョンのレプリカを実現する「cross-region replica for Cloud SQL」発表
Google、MySQL/PostgreSQLでクロスリージョンのレプリカを実現する「cross-region replica for Cloud SQL」発表 Googleは、MySQLとPostgreSQLなどのマネージドデータベースサービスを提供する「Google Cloud SQL」で、リージョンをまたいだレプリケーションを実現する新機能「cross-region replica for Cloud SQL」を発表しました。 cross-region replica for Cloud SQLは、マスターデータベースの内容を自動的に別のリージョンのデータベースに継続的に読み取り専用で複製する機能。Cloud SQLのMySQLとPostgreSQLで利用可能です。 これにより、万が一マスターデータベースのリージョンが丸ごと失われたとしても、別のリージョンに複製したデータは失われず、
ユーザ情報を保存する時のテーブル設計 - そーだいなるらくがき帳
はじめに ※この発言は個人の見解であり、所属する組織の公式見解ではありません 用法用量を守り、個人の責任で業務に投入してください 参考資料 2024/02/14追記 実際のテーブル設計の詳細はこちらを参考にどうぞ。 agilejourney.uzabase.com 要件 User情報を保存するときにどのようなテーブル設計を行うか 今北産業で頼む テーブルに状態を持たせず状態毎のテーブルを作る 状態が変わればレコードを消して別のtableに作る tableの普遍的な情報は別に持たせる 僕の考えた最強のDB設計 PostgreSQLをベースの雑なER図を作った。 これを元に話を進める。 table構成 users 親tableであり、すべてのユーザはここに属する。 基本はINSERTのみでUPDATE、DELETEを考慮しない。 user_detail userに付随する詳細の情報がここに登録
PostgreSQLは20年間どのようにfsyncを間違って使っていたか - 聴講メモ -
TL;DR 聴講メモ Intro into durability PostgreSQLのCHECKPIONT CHECKPOINT中にエラーが発生したら？ fsyncへの2つの間違った期待 なぜ今になって問題が明らかになってきた？ そもそもなぜBufferd I/Oなのか？ どうやって直すかか 参考リンク 質疑 最後に 先日PostgreSQLの新しいマイナーバージョンがリリースされました。このマイナーリリースでメインとなる修正は「fsync周りのバグ修正」で、このバグは間違ったfsyncに対する間違った認識から約20年間存在してたバグということで注目されていました。 このバグについてPostgreSQLのコミッタ(Tomas Vondra氏)が解説しているセッションが、先々週開催されたFOSDEM 2019でありました。私もFOSDEM 2019に参加していたのですがその際は裏セッション
DBリファクタリングをやっているって話 - そーだいなるらくがき帳
言語の勉強会でその言語の話をしない人ランキング堂々の第一位、そーだいです（当社比 控えめに言っても最高な毎度おなじみ #kichijojipm で今日LTする話の補足です。 kichijojipm.connpass.com speakerdeck.com タイトルは出落ちです。 全然最強じゃなくて頑張ってやってるよって話です。 資料がかなり薄いので補足します。 DBリファクタリングについて 26Pは現状です。 MySQLって書いてますが本番はAurora1を使っています。 以降、このDBを 現行DB と呼びます。 ここではオミカレとみんなの婚活はWebサービス名です。 つまり2つのサービスから現行DBを見ていますし、機能によっては現行DBの同じテーブルを参照・更新・削除などを行います。 この2つ以外にも社内システムなどでこの現行DBは利用されており、メインのテーブルを変更すると影響範囲が広
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！｜ハイクラス転職・求人情報サイト AMBI（アンビ）
PostgreSQLとMySQL、使うならどっち？ データベース専門家が8つの視点で徹底比較！ オープンソースのデータベースとしてよく比較されるPostgreSQLとMySQL。どんな長所・短所があるのでしょう？ それぞれの専門家による対談で明らかにします。 エンジニアとして働いていると必ず直面する悩み。それは、「どのリレーショナル・データベース（以下、RDB）を選ぶのが最善なのか？」です。 RDBごとに長所と短所は異なっています。そのため自社サービスにマッチしないRDBを選んでしまうと、それがボトルネックとなり開発・運用にトラブルが生じるケースは少なくありません。 なかでもよく比較検討されるのが、PostgreSQLとMySQL。ともにオープンソースRDBのデファクトスタンダードであり、高い性能と数多くの機能を持っています。 では、両者は具体的にどのような長所・短所があるのでしょうか。そ
BdashというBIツールをリリースしました - hokaccha memo
BdashというアプリケーションをElectronで作りました。 bdash-app/bdash: A simple business intelligence application. 以下からダウンロードしてインストールできます（現状まだMac版だけ）。 https://github.com/bdash-app/bdash/releases ざっくりとこんな感じのことができる。 SQLを書いて保存＆実行できる 結果を元にグラフを書ける gistで共有できる 現状で対応しているデータソースはMySQL、PostgreSQL（Redshift含む）、BigQuery 仕事でRedshiftを使って分析SQLを書くことが増えて、手元ではJupyter Notebookを使ってたんだけど、SQL書いてグラフを書くだけの用途には若干オーバースペックでもうちょっと簡単にできるといいなと思ったのがき
GitLab.comが操作ミスで本番データベース喪失。5つあったはずのバックアップ手段は役立たず、頼みの綱は6時間前に偶然取ったスナップショット － Publickey
果たしてGitLab.comで何が起きたのでしょうか？ これまでの経緯をまとめました。 スパムによるトラフィックのスパイクからレプリケーションの不調へ GitLab.comは今回のインシデントについての詳細な経過を「GitLab.com Database Incident - 2017/01/31」で公開しています。また、もう少し整理された情報がブログ「GitLab.com Database Incident | GitLab」にも掲載されています。 これらのドキュメントを軸に、主なできごとを時系列に見ていきましょう。 1月31日16時（世界協定時。日本時間2月1日午前8時）、YP氏（Yorick Peterse氏と思われる）はPostgreSQLのレプリケーションを設定するためにストレージの論理スナップショットを作成。これがあとで失われたデータを救う幸運につながります。 1月31日21時
第7回 UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く | gihyo.jp
IT Cutting Edge ─世界を変えるテクノロジの最前線 第7回UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く デジタルディスラプションを象徴する企業として、いまこの瞬間も破竹の勢いで成長を続け、交通サービスの世界を大胆に塗り替えているUber。未上場ながらすでに企業価値は6兆円を超えているとも言われており、世界最大のユニコーン企業として、その動向はつねに注目されつづけています。 クラウドやビッグデータ分析、オープンソースなど、最先端のITをフル活用し、ごく短期間で劇的にビジネスを拡大させたUberに対しては、やはり技術者からの強い関心があつまります。現在、1200名を超えると言われるUberのエンジニアたちは何をどんな環境で使い、どう動かしているのか ―Uberのエンジニアリングチームが公開している技術ブログ「Ub
このRDBについて私は驚くべき闇を見つけたがそこを発表するにはネットは怖すぎる
YAP(achimon)C::Asia Hachioji 2016midの資料です。
国土交通省のデータを使って、緯度経度から市区町村までを取り出す - Qiita
FrogApps 技術ブログ始めました！ RailsやiOS、HTML5の情報を発信中!! → http://qiita.com/teams/frogapps ここ数年、位置情報を使ったアプリ・サービスが増えましたが、GPSから取得出来る緯度経度だけではデータとして使いにくい事があります。 GoogleのGeocodingサービスなどで、緯度経度から住所への変換ができますが、件数や速度の問題があります。 そこで、国土交通省のデータを元に、緯度経度から住所への変換を行ってみましょう。 国土数値情報ダウンロードサービス http://nlftp.mlit.go.jp/ksj/gml/datalist/KsjTmplt-N03.html から全都道府県を選択。最新の情報を全都道府県分選択します。 PostGISのセットアップ http://trac.osgeo.org/postgis/wiki/
もう二度と、絶対にMongoDBを使うべきじゃない理由
MongoDBは悪だ。なぜならそれは… …データを無くす（ソース：1、2）。 …実際、長期間、デフォルトでエラーを無視し続け、何があってもすべての単一書き込みが成功したとみなした（ 32ビットのシステムで3GBかそこらを使用したら、MongoDBの制限によって何の警告もなしに全データを失うことになった）。 …宣伝していたユースケースでですら遅く、これが早いと主張するには完全に証拠に欠けている（ソース：3、4）。 …ほぼ全てのユースケースで、暗黙のスキーマという悪しき習慣を強要してくる（ソース：4）。 …ロッキングに問題がある（ソース：4）。 …セキュリティの問題になるくらい、応答時間が酷く遅い。求めてきた人全員に認証なしで全データをさらしてしまうという危険なデフォルト設定をパッチするのに2年かかった（ソース：5）。 …ACID特性に準拠していない（ソース：6）。 …拡張やメンテナンスをする
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いまふたたびのJDBC - Qiita
つらくないマルチテナンシーを求めて: 全て見せます！ SmartHR データベース移行プロジェクトの裏側 / builderscon 2018
Postgres 10の開発者向け機能
GitHub - MasahikoSawada/pg_simula: A database system failure simulation tool for PostgreSQL
RDBアンチパターン // Speaker Deck
バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い
PostgreSQL 9.5 新機能紹介
