サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
GPT-4o
qiita.com/tzkoba
Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海
この記事は「RookだらけのAdvent Calender」10日目の記事です。 昨日、Japan Rook Meetupが行われましたが、そちらでも紹介したYugaByteDBについて、何回かに分けて解説をしていきます。 RookにおけるYugaByteDB対応とは アドベントカレンダー1日目の「Rookの概要とRook-Ceph」にもあったように、Rook自体はマルチなストレージプロバイダをオーケストレーションできるツールです。 その中でCephなどのSDSと異なり、データベースに近いプロバイダとして、以下3つがあります。 Cassandra (http://cassandra.apache.org/) CockroachDB (https://www.cockroachlabs.com/) YugaByteDB (https://www.yugabyte.com/) これらは分散KV
上表の「特徴的な追加/改善内容」の列を見てもらうと分かる通り、下記3つのポイントが機能改善の傾向として共通している(なお、YugabyteDBは2020年2月に2.1をリリース済で2.2の差分が小さい)。 OLAP向け機能の強化(カラムナストア、ベクター化実行) 悲観的ロックのサポート バックアップとリカバリの機能強化 それぞれがどんな意図を持って追加されたのか、次節以降で私なりに解説をしていく。 1. OLAP向け機能強化 このテーマについて議論する前に一つ触れるべきなのは、 「NewSQLは分析系クエリ、つまりOLAP処理に適しているのか?」 という疑問である。 個人的にこれに回答するならば、現時点では"No"となる。 シンプルな言い方をすればRedshiftやBigQuery、最近であればSnowflakeなど分析クエリを専門とするデータベースとは方向性が異なり、まともには競えない。
はじめに July Tech Festa 2020において、「マイクロサービスの今だからこそ!理解して拡げる 分散システムの基礎知識」のタイトルで登壇をしてきました。スライドはこちらにありますが、資料内や当日のトークで話せていない部分を含めて、こちらでblogとして解説をしておきたいと思います。 1. セッションの導入 - 新たなムチャブリ - 今回は昨年の#JTF2019で私が話した、「Cloud Native開発者のためのDatabase with Kubernetes」からの続編という形にしてみました。 昨年は、 「せっかくKubernetesを使うのにアプリケーションだけじゃもったいない。 DB、そしてステートフルなワークロードにも適用していきましょう」 という話をしましたが、Kubernetes-native Testbedなど、そうした取り組みが増えつつある傾向にはとても興味を
【#CNDT2019 登壇記録】Cloud Native Stoageが拓くDatabase on Kubernetesの未来PostgreSQLkubernetesRook 登壇資料 CloudNativeDays Tokyo 2019で私が発表した資料は、SpeackeDeckにあげています。 普段のLTより少し硬いイメージの発表資料に仕上げてみました(途中おふざけはありますが)。 本日の1B3、「Cloud Native Storageが開くDatabase on Kubernetesの未来」の登壇資料です。 #cndt2019 #RoomBhttps://t.co/ygm96pLK1j — こば(右) (@tzkb) July 22, 2019 当日の様子 7/22(月)の15時40分から40分間、RoomBで発表を行いました。 同じ時間帯にMySQL Operatorのセッション
CNDT2020のCFPを確認しよう 2020年9月8日-9日にオンラインで開催されるCloudNativeDays Tokyo 2020のCFPが出揃いました。 このカンファレンスでは全てのCFPをこちらから確認することが出来ます。今年も続く素晴らしいポリシーだと思います。そして、好きなCFPを「いいね」や「リツイート」で応援することが出来ます。 もちろん、応援したら結果も気になりますよね? それを確認するためにダッシュボード的にツイートを並べてみました。CFP応募数が 77 件だそうでまさか1ブログに納まりきらない!むりやり詰め込みますが。 実は昨年も同じことをやっています。比べてみたいという方はこちらも見てみて下さい。 CFP紹介ツイート(update 6/1 23:00) #CNDT2020@tjun による「メルペイにおけるマイクロサービス運用の苦労と改善」を受け付けました。この
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の20日目です。 25日間の完走めざして頑張っていますが、先日からの検証に詰まっており、19日目の投稿は後ほどとなります。今日はちょっと目先を変えて、Rancherを利用したKubernetes環境の構築について見ていきたいと思います。 TL;DR Rancherをつかえば複数のKubernetes環境の構築・管理も簡単。 Kubernetes Providerの選択には注意、CUSTOMではクラウド関連のAPIは叩けない模様。 ※12/20 さっそく追記 同日にこちらが公開されていました。CUSTOMでもEBSを使うことは出来るようです。良く読んで、後ほど当記事も修正します。 Rancherとは こちらの資料に詳しいですが、Kubernetesのクラスタを簡単に構築できるツールだと言って良い
TL;DR Top N取得SQLでは、ORDER BY句狙いのインデックスを使うと性能改善する場合が多い。 それでも無駄なレコード取得が行われるケースがあるので、実行計画を良く見よう。 #そーだい本 で楽しいSQLチューニングライフを! はじめに 今日は基本的な事象ながら意外と見落としがちな、 「先頭N件(Top N)の取得でORDER BYも使うケースのSQLチューニング」 について、解説をしてみたいと思います。 (2020/3/29 追記) 初稿は基本的にOracleを前提としていたため、PostgreSQLでの例を検証して追記しました。 テーブル・レイアウト まず、今回チューニングの対象となるデータモデルについてです。 対象はメッセージキューでDBにテーブルとして実装されており、以下のレイアウトとなっていました。 名前 型 説明 -------------------- ------
4.2.1 Shardingの手法 先ほどの表1を理解するにはSharding手法の列にあげられた各用語の理解が必要となる。 YugaByteDBのブログ「Four Data Sharding Strategies We Analyzed in Building a Distributed SQL Database」には、非常に詳しくShardingの手法が紹介されている。この記事では、大きく以下4つの分類があるという。 Algorithmic Sharding (例: Memcached/Redis) Linear Hash Sharding (例: 過去のCassandra) Consistent Hash Sharding (例: DynamoDB、Cassandra) Range Sharding (例: Spanner、HBase) 詳細は割愛するが、1つ目のアルゴリズム・シャー
当投稿はKubernetes Advent Calenderの18日目の記事となります。 17日目はnnao45さんの「【Kubernetes】KubernetesのCronJobのcronスケジュールはどう管理されているのか?」でした。 今日はKubernetesのDatabase Operatorということで、私が何度かカンファレンスで触れているKubeDBについて解説したいと思います。今回は主に耐障害性についての設計とその動作確認をしていきます。 TL:DR KubeDBはマルチデータストアなKubernetes Operator。 しかし、Kubernetes v1.16ではうまく動かない。 PostgreSQLのレプリケーションは簡単に構築可能、障害時のFOも問題なし (開発体制に不安はあるものの)今後のリリースに期待したい。 KubeDBとは AppsCodeという会社が提供し
Help us understand the problem. What are the problem?
メリークリスマス! この記事は「エンジニアの登壇を応援する会 Advent Calendar 2019」の24日目の記事です。 これまでもQiitaに登壇記録はいくつか投稿してきましたが、2019年も終わりということで今年一年を振り返ってのまとめをしたいと思います。 年頭に立てた目標的なもの 2018年末にPGConf.Asia 2018で登壇した後、2019年の目標として以下のようにカンファレンスで登壇を目指していくことを決めました。 KubeConでの登壇は叶わなかったものの、それ以外の3つと+αでCFPが通って登壇することが出来ました。目標達成率という意味では上々といえると思います。 カンファレンスでの登壇 先ほど伸べたように4つのカンファレンスで登壇しています。それぞれ登壇記録へのリンクと一言感想を書いておきます。 CloudNativeDays Tokyo 2019 登壇記録はこ
「RookだらけのAdvent Calendar 2019」の経緯 もう最終日なのですが、これまでこのAdvent Calendarの起こりみたいなものを書いていませんでしたので、それも残しておきます。 流れは以前書いたJapan Rook Meetupの発生経緯と同じで、私の思いつきに2名の方が乗って下さる形で立ち上がりました。 僕も同じくアドベントカレンダーを目標に設定してたんです!よろしければ一緒にどうですか?? — Japan Rook (@japan_rook) November 5, 2019 さらにDM等で内容を詰めて、私とうつぼさん、makotowさんで緩やかに投稿スケジュールと分野が決まりました。 (当初の予定) 12/1-12/8 :うつぼさん、Rookの概要とCeph関連 12/9-12/10 :tzkoba、Japan Rook meetup振り返り 12/11-1
この記事は「RookだらけのAdvent Calender」20日目の記事です。 昨日までの4日間、makotowさんによるEdgeFSの解説をお楽しみ頂きました。Cephと並んでRook内でStableであるEdgeFSは国内での情報が非常に少なく、概要レベルの解説や「試してみた」という記事も殆ど見た覚えがありません。 Cephとは異なるCloud NativeなSDSとして期待している人も多いと思いますので、ぜひこうした情報が拡がっていくことを期待しています。 さて、今日からはRookからNFSを利用する手順を解説していきたいと思います。 が、その前に! Rook v1.2がリリースされました Rook 1.2 is now available! Thank you to everyone in the @rook_io community for getting another gr
この記事は「RookだらけのAdvent Calender」15日目の記事です。 昨日は、オブジェクトストレージの概要とRookからMinIOを構成する方法について解説しました。 本日は実際にMinIOを利用し、ファイルのアップロードと確認をKubernetesから行ってみます。 MinIO with Rookの最大の問題 昨日の投稿で書いても良かったのですが、当ブログの企画後に以下の知らせが入ってきました。 RookはCeph,EdgeFS,NFSなどをサポートしていますが、ろくにメンテされていないものも多々あります。それに対して最近、機能マージ後一切更新されていなかったMinioサポートを切るPRが出ました。今後もこういうことが増えるのではと推測していますhttps://t.co/oAdc1S9ACz — sat (@satoru_takeuchi) December 12, 2019
TL;DR パーティションをノード間でレプリケーションするDRBD9をKubernetesから試す。 DRBD9の管理ツールであるLINSTOR経由で、PVのプロビジョニング・アタッチ等が可能。 CSIにも対応しており、今回はlinstor-csiを試してみる。 概要 以下の構成図のように、LINSTORのCONTROLLERを1台(実際はSATELLITEとのCOMBINED)とSATELLITEを2台(兼DBデプロイノード)、計3台からなるKubernetesクラスタを構築します。 [linstor-csi+DRBD9でPostgreSQL on k8s の構成図(完成図)] SATELLITEのディスク1本をレプリケーション対象とし、そこにLVMのPV・VGを構築していきます。 PostgreSQLはCSI経由でDRBDのボリュームをマウントします。このボリュームは常に1ノードからの
登壇編って? 先日、PGConf.Asiaの参加記録 -エンジニア邂逅編- を書きました。そちらでは日本のエンジニアや海外勢との会話で記憶に残したいものをまとめています。 PGConf.Asia 2019自体についても邂逅編をご覧下さい。 今回は自身の登壇について、準備や発表当日の様子、QAの内容などをまとめていきます。 準備 今回登壇は初の海外・英語での登壇ということもあり、自分なりに入念に準備を重ねました。 発表準備にあたり、さくらインターネット研究所のmatsumotoryさん、yuukiさんのブログは非常に参考になりました。具体的には下記2つの投稿で、スライドやスクリプトの準備、そして質疑にもきちんと備えることなどを読み、自分の準備にも活かしていきました。 はじめて国際会議で論文発表して考えたこと ラストオーサーとしての国際会議投稿やジャーナル執筆のサポートについて 私の発表はアカ
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の25日目です。 25日間のアドベントカレンダーもいよいよ最終日です。ここ一週間はギリギリアウト気味の投稿状況でしたが、何とか完走といって良いのではないでしょうか。 PostgreSQL on Kubernetesで目指してきたところ #2で説明したように、当アドベントカレンダーでは、レプリケーションをk8s上に展開したマルチインスタンスDBではなく、ストレージ・レイヤで冗長化を担保するActive-StandbyのDBクラスタを構築することを目的としてきました。 この構成で解決したかった最大の課題は「複雑性の排除」でしたが、検証結果が示したのは引き換えにサービスレベル低下を招いてしまうという、残念な内容でした。 データベースをk8sで動かす事にこだわる訳 では、現時点でデータベースをKube
CNDTの次はCNDKだ! 2019年11月27日-28日に開催されるCloudNative Days Kansai 2019のCFPが出揃いました。 CNDTの際と同様に、CFPをまとめて見れるように並べてみました。 今回は28本のCFP(※1)が提出されています。 さあ、気になるCFPをいいね/リツイートで応援しましょう。 ※1 公式のCFP一覧には29本のCFPがあるのですが、「Kubernetes運用を支えるGitOps」についてはTweetが見つかりませんでした。勘違いの可能性もあるので、必要に応じて訂正します。 CFP紹介ツイート #CNDK2019 @capsmalt による「流行りのOperatorで逆に大変やない!?何とかせねば!」を受け付けました。このプロポーザルを聞いてみたい人はいいねやリツイートでぜひ応援してください! 公募セッション一覧はこちら https://t
本記事はKubernetes Advent Calendar 2018の6日目です。 昨日は@nnao45さんの「kubectl-completion-zshを車輪の再発明した」でした。 コマンド補完、いいですよね。あれやこれや一々打つの面倒くさいし! さて私は「PostgreSQL on Kubernetes 2018(全部俺)」のAdvent Calenderを執筆中ですが、そこでデータベースをStatefulSetで動かしています。 その際に起きた問題や調べたことを書いていきたいと思います。 TL;DR PostgreSQLをStatefulSetで動かしたら、Failoverしなかったよ。 良く調べたらそれが仕様。 operatorを使えるようになるとつよい。 PostgreSQL on Kubernetes こちらで述べたように、PostgreSQLをContainer-Nati
TL;DR StolonはKubernetes上にレプリケーション設定されたPostgreSQLクラスタを構築してくれる。 障害時にはネットワーク分断を考慮したMaster選出が行われ、可用性を高めている。 StolonではStandbyノードへの参照クエリ振分けは行われない。 シェアードナッシングで構築は容易だが、運用にはPostgreSQLの知識を要する。 Stolonとは StolonはKubernetes上にPostgreSQLのStreaming Replicationを構成してくれるOSSです。 CNCF LandscapeでもDatabaseとして登録され、PostgreSQL on Kubernetesという観点では古参のプロジェクトになっています。 <図1 CNCF LandscapeにおけるStolonの位置付け> Stolon開発の動機はこちらのブログに書かれています
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の3日目です。 昨日は「PostgreSQL on Kubernetesの目指すところ」ということで、分散ストレージRookの上にPostgreSQLを稼動させ、冗長化レイヤを下げる構成を紹介しました。 本日はこのPostgreSQL on Rookの基礎部分となるRookの導入方法をガイドしていきます。 TL;DR RookはKubernetes上に分散ストレージ:Cephを構築して管理するオペレータ。 ストレージサーバとしてノードを3台準備して、Rookの構築をやってみよう。 Rookの紹介 昨日書いたように、RookはKubernetes上に分散ストレージを構築するOSSです。 更に具体的にいえば、OpenStackなどでも利用される分散ストレージであるCephをKubernetes上に
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の1日目です。 正確にいうと PostgreSQL on Kubernetes 2018(全部俺) の第一回です。 今日は初日になりますので、「どんな話なの?」「なんでデータベースをk8sにのせるの?」といった辺りの概要をお話したいと思います。 TL;DR Kubernetesは既に標準プラットフォーム データベースもこれをフォローしておかないと、デバイス対応で困ったりすると思うよ。 すでにPostgreSQL on k8sとかMySQL on k8sの事例もあるよ。 Kubernetesを取り巻く状況 昨今はねこも杓子もコンテナの時代になりつつありますが、その界隈の覇権がDockerからKubernetesに完全に移ったように見えます。 これはただ単に抽象化レイヤの中で上位に移行したというよ
k8sにおけるポッド障害って何? 今回テストにするにあたり、そもそもk8sにおけるポッド障害とは何を指すのかを確認しておきます。 ポッドの障害ケースを試す際に良く見られるのが、kubectl delete pod コマンドです。 しかし、使ってみると分かりますが、kubectl deleteでは即時に別のポッドが起動されます。 これはおそらく、KubernetesのAPIサーバにコマンドを投げた際、ポッド削除とメタデータ更新がされているため、すぐにリカバリが走る状態になっていると考えられます。 そのため、本来のポッド障害を想定した場合にはkubectl deleteではない方法で擬似障害を起こさなくてはならないのではないでしょうか。 その方法として、以下の3つを考えてみました。 kubectl execでポッドに接続し、PID:1のプロセスをkill ポッドが稼動するノードに接続し、psコ
TL;DR CSIはKubernetesなどからストレージを扱うインターフェースのこと。 Kubernetes CSI Developer Documentationに実装すべき事項、サンプルが整理されている。 Rook v1.0+Ceph CSIも上記に準拠して実装されていることを確認する。 そもそもCSIとは CSIはContainer Storage Interfaceの略で、ここからも分かるとおり、Kubernetesだけを対象としたものではなく、コンテナオーケストレーションツールからストレージを扱うインターフェースを定めた規格です。 Kubernetesでは1.13からGAとなっているため、先日書いたこの投稿やこちらでも1.13.4を使って検証を行っています。 CSIがそれ以前のストレージ関連機能と何が違うのか?という観点では、in-treeかout-of-treeかということが
TL;DR 5月頭にリリースされたRook v1.0を試してみた。 7月に発表予定のDB on Kubernetesの検証なのでCeph RBDで使ってみる。 RookではBeta版のCSIでやってみる。 手順が煩雑でドキュメントに分かりづらい部分もあるけど動いたよ。 Rook v1.0、リリース Rookはv0.8の頃から試しており、過去にPostgreSQL on Rookということで試してきました。 ※過去の投稿はこの辺にあります。 今回、5/3に公式ブログでRook v1.0のリリースが発表されました。 このタイミングでブランディングも更新されたようで、これまでの城砦ロゴだけではなくSirSir(ドルアーガの塔っぽい??)というマスコットが登場しました。 Hey everyone I'm proud to introduce the updated @rook_io design
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の24日目です。 25日間のアドベントカレンダーも残り2日となりました。ここからはPostgreSQL on Kubernetesの今後の進め方で必要となる要素を検討していきたいと思います。 TL;DR Kubernetesで検証をすすめると、大量のYAMLが出来上がる。 Helmでテンプレート化しておくと後で役に立ちそう。 もっと進めてOperator化も検討しよう。 PostgreSQL on Kubernetesの検証で積み上がったもの これまでPostgreSQLインスタンスを分散ストレージであるRookやAmazon EBS上で動かす検証を続けてきました。KubernetesのワークロードとしてもStatefulSetを中心にDeploymentなども差異を検証しています。 さらにモ
本記事はPostgreSQL on Kubernetes Advent Calendar 2018の12日目です。 昨日は「関連コミュニティの紹介」ということで、Kubernetes・PostgreSQLのコミュニティをいくつか紹介しました。 今日はPostgreSQL on Kubernetesの環境を構築する際に検討したストレージを紹介していきたいと思います。 TL;DR "Container storage for Dummies"は無償版と思えないクオリティ、是非読もう。 Kubernetesにストレージの全てを突っ込む、コンテナ・ネイティブストレージがこれからのおすすめ。 NetAppやEMCなどのベンダもKubernetes対応をすすめてるよ。 Container storage for Dummies まず、こちらのEBookを紹介したいと思います。 このEBookにはRed
次のページ
このページを最初にブックマークしてみませんか?
『@tzkobaのマイページ - Qiita』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く