速習!論理レプリケーション ~基礎から最新動向まで~ (PostgreSQL Conference Japan 2022 発表資料) 2022年11月11日(金) NTTデータ 技術開発本部 先進コンピューティング技術センタ 鳥越 淳
![EC2でkeepalived+LVS(DSR)](https://cdn-ak-scissors.b.st-hatena.com/image/square/ddc663979ce0f9136059a95ed69aa79bd01f3d40/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fec2keepalivedlvsdsr-130517102641-phpapp01-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
RSpecの標準マッチャー(matcher)の一覧を作ってみました。できるだけ一覧を見やすくして、開発の手助けになることを目指しています。 🚜 RSpecって何?RSpecのベーシックな情報は以下がお勧めです。 「RSpec をもっと理解したかったので、まとめを作りました」に感動してRuby 1.9.3でやってみた! : 以前作ったものです。RSpecの導入の手助けになると思います。 改めて学ぶ RSpec : RSpec初歩からしっかり理解できるすばらしい記事です。 RSpec 簡潔に記述する(1) it ブロックを短く書く! : 説明がすごくわかりやすくて勉強になります。 🐡 マッチャー一覧 マッチャー not 意味・機能
> 原文(Why MongoDB is a bad choice for storing our scraped data) 私自身はMongoDBを推進する立場なのだが、確かにMongoDBに適さないケースはある。 闇雲に推進しても結局は全員がアンハッピーになるので、この様なネタもどんどん紹介していこうと思う。 この記事はMongoDBを徹底的に使い尽くしたエンジニアが書いている様で状況が良く解った。 ちょっと難しい所もあるので要点を意訳して、軽く解説を書いてみる。 (もちろん是非原文で読むのをお勧めする) 状況 最初はMongoDBでうまく動いていたが、だんだん苦労が増えてきて 元々のアーキテクチャを刷新するタイミングでMongoDBから別のプロダクトに乗り換える事にした。 システムの規模 詳しく書かれていないが、1ノード辺り数TBとあるのでSharding環境ではないかと思われる。
ゴミがゴミ箱に命中しなくて、かなしい思いをすることがなくなりますよ! ポーンと投げたゴミを、ササッと自ら取りに行ってくれるゴミ箱。これは便利...! ハードウェアからソフトウェアまで、作者さんがイチから自作したこのゴミ箱、最高です。ゴミ箱をラジコンのように可動式にし、Kinect(のようなもの)画像認識し、ゴミ箱がその落下地点に取りに行くしくみになっているようです。機敏な動きで働き者です。欲しい...! 投稿直後からどんどん閲覧数が増えているこの動画、閲覧者の方々から、下記のような感動のコメントが大量に寄せられていました。 うん、これなら俺でも10年くらいでできるわw暇を持て余した神俺は投げる練習することにするよ...これ商品化してくれええええええええニコニコ技術部の本気を見たwww野球の守備はこの子に頼もう で、これ、いくら出せば買えるんです? 勝手に入るゴミ箱作った [ニコニコ動画]
MySQL-5.5よりRESET SLAVE;の挙動が変わり、直後にCHANGE MASTER構文を 発行しないと場合によっては問題が発生するとMySQLのドキュメントに記載されていました。 さらに、RESET SLAVE ALL;というクエリもサポートされたようです。 どういう事なのでしょう? 調べてみました。 ドキュメントにさらっと何か書いてある In MySQL 5.6 (unlike the case in MySQL 5.1 and earlier), RESET SLAVE does not change any replication connection parameters such as master host, master port, master user, or master password, which are retained in memory. Thi
最近@namikawaさんと@con_mameさんがEBSの性能測定をされていて、少し気になったので追試をしました。 Amazon EBS の性能ベンチマーク その1 (Standard編) - 元RX-7乗りの適当な日々 Amazon EBS の性能ベンチマーク その2 (Standard-Vol増量編) - 元RX-7乗りの適当な日々 Amazon EBS の性能ベンチマーク その3 (Provisioned IOPS編) - 元RX-7乗りの適当な日々 4,000IOPS EBSのベンチをとってみた - まめ畑 今一度Provisoed IOPS EBSのベンチをとってみた - まめ畑 測定環境です。 ap-northeast-1c m1.small (Spot Instance) Amazon Linux AMI 2013.03.1 EBS Standard Volume 16GB
Amazon EC2 M7g インスタンスは、Arm ベースの AWS Graviton3 プロセッサを使用します。汎用アプリケーションに対して、Amazon EC2 の中で最高の料金パフォーマンスを実現します。 特徴: カスタムビルドの AWS Graviton3 プロセッサを搭載 DDR4 比で帯域幅が 50% 多い最新の DDR5 メモリを搭載 M6g インスタンスと比較して、ネットワーク帯域幅が 20% 強化 デフォルトで EBS 最適化済み ホストサーバーに物理的に接続された EBS または NVMe SSD を通じて提供されるインスタンスストレージ M7gd インスタンスでは、NVMe ベースのローカル SSD がホストサーバーに物理的に接続されており、インスタンスの寿命に連係するブロックレベルストレージを提供します m7g.16xlarge、m7g.metal、m7gd.16
Announcing Amazon Managed Service for Apache Flink Renamed from Amazon Kinesis Data Analytics Today we are announcing the rename of Amazon Kinesis Data Analytics to Amazon Managed Service for Apache Flink, a fully managed and serverless service for you to build and run real-time streaming applications using Apache Flink. We continue to deliver the same experience in your Flink applications without
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く