2021/7/16にCloud Native Database Meetup#1の発表資料です。
2021/7/16にCloud Native Database Meetup#1の発表資料です。
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html NoSQLの登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャーディング
回答 (3件中の1件目) ハイプサイクルという概念をGartnerグループが提唱してまして、様々な流行りスタリのサイクルを分析する標準的な方法となっています。 ハイプとは過度な期待や熱狂を意味する言葉です。一発屋芸人の人気のカーブみたいなもので、テツandトモみたいに安定する場合と、消えていくものがあります。芸人ではありませんがDA PUMPは一茶の人間性もありまして、次は厳しいけど定着すると思っています。 なんだかのトリガーで評価が上がり始め、ピークを迎える。その後評価が下がっていき、底を打つと少し上がって定着するという経過をたどるとしています。これと同じモデルで、流行りのハイテク...
はじめに Firebase Realtime DBを実践投入するにあたって考えたことを読んで頂いてありがとうございます。 多くの方から「いいね」を頂いて、今回のこの記事を書くモチベーションになりました 本当にありがとうございました！ さて、CloudFirestoreは、Firebase Realtime Databaseとは全く違うデータベースです。特にSubCollectionやQueryが導入されたことにより、リレーションシップの設計に関して大きく異なります。 この記事では、主にCloudFirestoreにおけるリレーションシップの設計方法から、アプリ・CloudFunctionsに至るまでを幅広く解説して行こうと思います。 次の記事ではデータベースの歴史を解説しています。 RDBの限界とNoSQLの登場 Cloud Firestoreでの開発について 私の経験上確実に断言できるこ
Hosting, Functions, Firestoreをつかったサーバレスっぽいアプリケーションをつくっていたら「Firestoreのデータ構造考えるの難しすぎるよ」とつぶやくだけのbotになるくらいむずかしすぎたので。 はじめに 概念をざっと理解しましょう ドキュメントとは：１件のデータに相当します。RDB時代の１レコードのようなものです。 コレクションとは：ドキュメントをまとめておいておくものです。RDB時代のテーブルのような概念ですが、スキーマが全く異なるドキュメントを持つことが可能です 一般的にそうすべきでないのは言うまでもないですが サブコレクションとは：コレクションの中に（見た目としてはドキュメントの１フィールドとして）さらにコレクションを持つことができます 使いどころがよくわからなかったのですが、セキュリティルールと併用したアクセスコントロールを行うにあたって重要な気がし
SubCollectionいつ使うの問題 Cloud Firestoreがリリースされて数日経ちました。SaladaをFirestoreに対応させるため、仕様の深いところまで検証しているところです。そんな中でぶち当たった問題について記載します。 TL;DR Queryに依存するアプリを作ると拡張性を失う。 QueryはElasticSearchに任せる。 SubCollectionの使い所は限定的。 SubCollectionとは FirestoreはCollectionとDocumentとDataで構成されます。 Collectionは複数のDocumentを持つことができ、 DocumentはDataとCollectionを持つことができます。Documentが持つCollectionのことをSubCollectionと言います。 なぜSubCollectionが必要だったのか Fir
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? TL;DR; Eventual Consistencyとか言いながらどうせもっとまともな一貫性実装してることはよくあるんだからみんな適切な名前を使おうぜ。 なぜこの記事を書くのか NoSQLの文脈においてスケーラビリティとのトレードオフでEventual Consistencyという用語は結構な頻度で出てくる。 ACIDに対抗してBASE(Basicaly Avalilable, Soft state, Eventual consistency)なんて言葉が出てきたり、CAP定理の中のAとPだと言ってみたり、分散システムのスケーラビリテ
Please stop calling databases CP or AP (2015-4-11) by Martin Kleppmann 元の記事は上のリンクよりご覧になれます。こちらの記事は 本人の許可を得て、翻訳・掲載したものです。翻訳へのフィードバックはコメントよりお願いいたします。 Jeff HodgesのNotes on Distributed Systems for Young Bloodsという優れたブログで、CAP定理を使ってシステムを評価することが推奨されています。多くの人はこのアドバイスを真摯に聞き、自分たちのシステムをCP（ネットワークの分割のもとでは一貫性はあるが可用性がない）、AP（ネットワーク分割のもとでは可用性があるが一貫性がない）、あるいはまれにCA（これの意味するところは「自分はまだ５年前のCodaの投稿を読んでいません」です）と表現するようになりまし
本連載では、「NoSQLデータベースの今」を正しく理解し、ビジネス躍進の実現に向けて対策していくための「ベストプラクティス」を掲示していきます。今回は「RDBではうまくいかなくなってきた理由」の基礎と背景を解説します。 前回は、「リレーショナルデータベース（以下、RDB）ではうまくいかなくなってきている背景と、その1つ目の理由」を解説しました。今回は、それ以外の「RDBではうまくいかなくなってきた理由」を解説します。 RDBは多種多様なデータに対応するように設計されていない 近年、構造化データと非構造化データを混ぜて扱えずに困る状況がますます増えています。以前ならば、重要なトランザクショナルデータや2、3の顧客基本情報だけを格納するだけで済みました。しかし2017年現在では一部の重要データを扱うだけでは許されず、基本的に全てのデータを格納する必要が出てきています。 RDBにとって、構造化デ
こんにちは。苦労で禿げそうです。 どうも、Jildinのハゲタカです。 先日Cassandraについて記事を書きました。 jildin.hatenablog.com 今日はその先のお話。実際にCassandraを使ってサービスを運用していく中で困ったことや苦労していることについて書きたいと思います。 Transactionという概念 CassandraにはOracleのようにtransactionという概念がありません。 なのでここからここまでの処理が全部終わったらデータベースに処理を反映してね、っていうことができないのです。いままでOracleがよろしくやってくれていたことができなくなってしまいます。 それでですね。なんでこのtransaction管理がないのが致命的にまずいのかちょっと事例を紹介したいと思います。 Transactionで困った話 Jildinは主にSFAの機能を備えた
こんにちは。Jildinのハゲタカです。 ハゲタカといいつつ髪の毛はもさもさです。 皆さんはCassandraはご存知ですか？ 今流行りのNoSQLの一種です。慣れてしまうと使い勝手もよく、割とイケている子なのですがいかんせんロゴがキモいのが玉に瑕(たまにきず)です。 今日はそんなCassandraについて記事を書きたいと思います。 CassandraはReadかWriteしかない RDBに慣れ親しんだ開発者の多くがこの仕様に殺されるところを見て来ました。それはそれは酷い死に方でした…。 そうなんです。CassandraにはReadとWriteの概念しかないのです。つまりどういうことかというと「INSERT」「UPDATE」「DELETE」がぜ〜んぶ同じなんです。 すでに存在しているキーに対してUPDATEをかけるだけでなく、存在しないキーにUPDATEをかけることだってできちゃうんです。
「Google Cloud Spanner」発表。地球規模の大規模分散環境で稼働するミッションクリティカルなリレーショナルDB。NoSQL並のスケーラビリティでSQL対応、トランザクション処理を実現 Googleは、クラウド上で高度なスケーラビリティを実現する、ミッションクリティカルな業務に対応したリレーショナルデータベースサービス「Google Cloud Spanner」を発表しました。 Google Cloud Spannerは、地球規模の大規模分散処理データベースとして、NoSQL並の非常に高いスケーラビリティと高い可用性、そして高速な処理を実現しつつ、SQLに対応。強い一貫性を持つトランザクション処理も実現。企業のミッションクリティカルな業務にも使えると説明されています。 地球規模に分散したリレーショナルデータベース 一般に、ミッションクリティカルな業務に対応したリレーショナルデ
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 最近，時代遅れのDB論理設計の流れが取りざたされている．そのため，私にDBの知識は無いが，DB利用反対を表明しようと思い，今回投稿する． 4ステップで作成する、DB論理設計の手順とチェックポイントまとめ - Qiita まず，いかにDBの知識が無いかをさらそうと思う． 以下の4ステップとして無知であることを説明する． ステップ1：エンティティとは ステップ2：エンティティの何を定義するのか ステップ3：正規化とはうまいのか ステップ4：ER図とは新たなビデオゲームか 無知をさらすためだけの投稿により，まとめは当然無い．ポイントをまとめる
6. 予備知識 ISAM (1) Indexed Sequential Access 6 ISAM: Indexed Sequential Access Method インデックス順にアクセスする方式 MySQLの内部はISAMで処理している → MySQLを使う上でも大切な基礎 でも案外知らない人も多い 昔はみんな使っていたけど、今はSQLで隠蔽されている 7. 予備知識 ISAM (2) インデックスとアクセス 7 id name group 1 akio 3 2 yoko 1 3 naoko 2 4 takeshi 1 先頭 seekFirst 最後 seekLast 前後 seekNext (++) seekPrev (--) キー値 seekEqual (=) キー値の前後 seekLessThan (<=) seekGreater (>=) アクセスメソッド （カーソルの移動と
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
