ドキュメントDBかリレーショナルDBどっち使う？ - Qiita
はじめに ドキュメントデータベースかリレーショナルデータベース、どちらを選ぶか。 この選択で、アプリケーションのパフォーマンス、コスト、コードの可読性など幅広い影響が出るため、慎重な判断が必要です。この記事では、自分が思う「考慮すべきポイント」を解説したいと思います。 考慮すべきポイント 1. どのデータモデルがアプリケーションコードに最適か スキーマ制約を課さずに、データレコードをドキュメント（つまりJSONオブジェクト）として保存すべきか？それともスキーマを正規化してデータをいくつかのテーブルに分けるべきか？ このような判断をするために、開発しているアプリケーションのモデルの関係性（例: UserとTaskの関係が1:N）と、一度に読み込むデータの種類を見た方がいいです。 ドキュメントDBがおすすめの時 アプリケーションのデータは、以下のような木構造で表現できますか？普段そのデータを一
KVSと二年間向き合って得たナレッジを還元する時がきた | フューチャー技術ブログ
はじめにこんにちは、Technology Innovation Group所属 DBチームの岩崎です。 テックブログにて記事を書くのは1年半ぶりです。(反省)あれからずっと設計～開発まで推進し、無事アプリリリースが完了しました。 — 脱RDB脳 — Cassandraのデータモデルについて考えてみる このタイミングで改めてKVS関連のナレッジを還元できたらと思い筆を執りました。 1. データモデル設計の勘所前回の記事でも書かせていただきましたが、KVSを採用するにあたって一番ポイントになるのがデータモデル設計です。 ここを外すと、開発で大いに苦しみます。場合によっては要件を満たせず再設計ORノックアウトなんてことにも繋がりかねません。 1-1. 更新要件を中心に設計するのがベターKVSはキーアクセスしかできないのでデータ参照にフォーカスしたモデルを設計しがちです。 もちろんこのアプローチは
ここが大変だよBigtableとGoogle App Engine
ここが大変だよBigtableとGoogle App Engine：分散Key-Valueストアの本命「Bigtable」（3）（1/2 ページ） RDBとは別の、クラウド時代のデータベースとして注目を浴びている「分散Key-Valueストア」。その本命ともいえる、Googleの数々のサービスの基盤技術「Bigtable」について徹底解説 月間3000万PVの大規模サイトの運用費が月額4万円!? 月間3000万PV相当の膨大なトラフィックを楽々とさばく大規模サイトが、月額4万円弱で運用されている。 Google App Engine（以下、App Engine）が普及するにつれて、そんな驚愕の国内事例も登場しつつあります。GClueがApp Engine上で実装したmixiアプリモバイルモバイルには、1日100万PV以上のアクセスが集中している状態でもサービスのレスポンス低下やダウンは皆無
Datastoreで検索エンジンを作る
Datastoreで検索エンジンを作る 29 Oct 2016 Daigo Ikeda Knightso, LLC Profile Daigo Ikeda @hogedigo Knightso, LLC http://www.knightso.co.jp/ Shizuoka, JAPAN 2 Datastore Indexおさらい 3 Sample: Book Store Model: type Book struct { ID string Title string Category string Price int PublishDate string } 4 Sample: Book Store Run Query: q := datastore.NewQuery("Book").Limit(20) // apply filters here var books []*Book _,
Cloud FirestoreのSubCollectionとQueryっていつ使うの問題 - Qiita
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データモデリング技法
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データモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
ミリシタを支えるGAE/GoをミリシタP向けに翻訳してみた - うしろのこの本ください
良いスライドなのに肝心のミリオンPからしたらちんぷんかんぷんな内容だったので未来ちゃに説明するつもりで噛み砕いていこうと思います。そこそこ長くなってしまった。 件のスライド ミリシタを支える GAE/Go from Google Cloud Platform - Japan www.slideshare.net 既に目を通したPも多いかと思いますが、４ページ目で一般人バイバイです。テクニカルタームの嵐です。 ミリシタの話をするのならせめてフリガナを振ってくれよな！カタカナにも！ GAEってなんだろ〜(●・▽・●) Googleとあるように、天下のGoogle様が提供する「アプリケーションを運営するためのプラットフォーム」です。 本来何らかのサービスを運営するためには、アプリ本体を置くサーバーやそれを配信するためのインフラ環境、大量アクセスへの対応、セキュリティ対策、データ解析、そしてアプリ
Spanner - Qiita
これまで多くのトランザクションの要素技術を説明してきた。 Googleの公開している論文Spanner: Google's Globally-Distributed Database は公開当初、要求される専門技術の多さからよくわからないと言っている人が多かったが、これまでに説明した要素技術をベースにすると理解しやすい。 Spannerとは 複数のデータセンターに跨ってデータベースの内容を複製し続ける事で高い可用性を実現するという構想は数多くあった。 しかしそれらの分散データベースは実用的な速度を実現しようとすると、データモデルがただのRDBより単純化して使いにくかったりトランザクションをサポートしなかったりと、アプリケーションの一貫性を実現するのが難しい。 現にGoogleの社内でもBigtableなどを用いたアプリケーションは複数あるものの、それぞれでそのデータモデルの上で無理やりトラ
これで怖くない Datastore のトランザクション
Lv：20 Exp：76341 メカです。 Cloud Computer と Neural Network に興味があります。 ”トランザクション” 聞いただけで嫌厭する方も少なくないのでは？ Datastore のトランザクションに関して、 そもそも RDB のときからトランザクションってよく分からなかったってのにDatastoreになってますます混乱しそう いきなり Datastore から始てみたけど、トランザクションがよく分からない といったように”トランザクションうわぁ”と思ってしまってませんか？ そんなあなたの垣根を少しでも取っ払い、 Datastore を触ってもらえたらなぁという期待を胸に執筆しました。 Datastoreのコードと一緒にMySQLのクエリを並べ、さらに、開発でよく見かける６つのパターンに分けて、実装例と共に説明していきます。各パターンについて具体的な要件の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
『Cassandraのデータ設計で注意していること』