並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 45件

新着順 人気順

datastoreの検索結果1 - 40 件 / 45件

datastoreに関するエントリは45件あります。 databaseデータベースDB などが関連タグです。 人気エントリには 『2020年現在のNewSQLについて - Qiita』などがあります。
  • 2020年現在のNewSQLについて - Qiita

    Disclaimer 当記事はNewSQL開発ベンダの技術ブログや各種論文、その他ニュースサイト等の内容を個人的にまとめたものです。 そのため、理解不足等に起因する誤解・誤認を含む可能性があります。更なる理解が必要な方はリファレンスに挙げた各種文献を直接参照下さい。技術的な指摘は可能であれば取り込み修正しますが、迅速な対応はお約束できません。 NewSQLの解説は二部構成 当記事は前編でNewSQLの概要編となる。 全体の目次は下記である。 NewSQLとは何か NewSQLのアーキテクチャ NewSQLとこれまでのデータベースの比較 NewSQLのコンポーネント詳解 1章から3章までの内容を当記事で解説する。 4章はさらに詳細な技術的解説となり、後編の「NewSQLのコンポーネント詳解」で記述している。 こちらも合わせて一読いただきたい。 1. NewSQLとは何か NewSQLとは、海

      2020年現在のNewSQLについて - Qiita
    • リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら

      リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得られるということなのだと思うので、可能であればMVCCを採用したいのですが、あまり初学者向けの実装例も見当たらず、どうしたものかと悩んでおります。 SS2PL/S2PLとMVCCの実装の難易度・工数はどの程度違うものなのでしょうか? また、初めてリレーショナルデータベースシステムを開発する者

        リレーショナルデータベースシステムを趣味で開発している者です。 現在、開発中のシステムを並行トランザクションへ対応させることを検討しており、どのような手法があるのか調べたところ、SS2PLもしくはS2PLという手法が私と同じように自作をされている方々の中では多く採用されているようだと分かりました。 一方で、PostgreSQLやMySQLなどのプロダクションレベルで利用されているシステムではMVCCと呼ばれる手法が採用されているということも分かりました。 きっと後者の方が多くの場合で高いスループットが得ら
      • 30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18

        600ページを超える書籍である「データ指向アプリケーションデザイン」の要点を最近の話題を交えながら解説します。 Data Engineering Study #18 の発表資料です プレゼンテーション https://www.youtube.com/watch?v=ZiKWXc0fSCw イベントURL https://forkwell.connpass.com/event/269125/ データ指向アプリケーションデザイン https://www.oreilly.co.jp/books/9784873118703/

          30分でわかるデータ指向アプリケーションデザイン - Data Engineering Study #18
        • NoSQLデータモデリング技法 · GitHub

          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データモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック

            NoSQLデータモデリング技法 · GitHub
          • MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? | mond

            MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ(InnoDBの場合16KB)の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ

              MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? | mond
            • 開発者が知るべきキャッシュ設計でよく遭遇する問題

              はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない

                開発者が知るべきキャッシュ設計でよく遭遇する問題
              • AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方

                リーガルテック領域のリーディングカンパニーである株式会社LegalForceが、「検索インフラTechTalk!」を開催しました。インフラ領域の中でも「検索インフラ」にフォーカスした今回は、検索インフラに関する具体的な事例や取り組みについて各スピーカーから発表がありました。野口真吾氏は、AWSを用いたデータレイクの基礎について紹介しました。 企業規模に関係なく起こるデータのサイロ化 野口真吾氏(以下、野口):みなさんこんばんは。本日は「検索インフラ Tech Talk!」ということで、検索インフラから少し広げた話題にはなるんですが、「AWSを用いたデータレイクの基礎」というお話をします。よろしくお願いします。 最初に簡単に自己紹介します。アマゾンウェブサービスジャパンでスタートアップ担当のソリューションアーキテクトをしている野口真吾と申します。Twitterでは@nogというIDを使って活

                  AWSで“データのサイロ化”を防げ すべてのデータを1ヶ所に集めるデータレイクの作り方
                • 日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud

                  日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud MySQL互換のオープンソースデータベース「TiDB」(タイデービー)を提供しているPingCAP社は、日本語を含む自然言語の問いをChatGPTを用いてSQL文に変換し、実行する「Chat2Query」機能を、クラウド上でTiDBのマネージドサービスを提供する「TiDB Cloud」にβ版として搭載したことを発表しました(日本語のプレスリリース) Introducing #Chat2Query, our AI-powered natural language querying tool that will release you from tedious manual SQL writing and change the way of #DataExploration

                    日本語の問いをChatGPTでSQLに変換、実行する「Chat2Query」を搭載。MySQL互換のTiDB Cloud
                  • ワークフローオーケストレーション入門

                    「Data Engineering Study #23 Data orchestration 特集」の発表資料です イベントページ: https://forkwell.connpass.com/event/310011/

                      ワークフローオーケストレーション入門
                    • Cloud Native時代のデータベース

                      2021/6/11 #InfraStudy 2nd Season

                        Cloud Native時代のデータベース
                      • App Engine VS Cloud Run

                        Cloud Run CPU 0.08 ~ 8 Core (2nd gen は最小 0.5~) Memory 128 MiB ~ 32 GiB (2nd gen は最小 512MiB~) Deploy App Engine は Deploy (gcloud app deploy) を実行すると Cloud Build が暗黙的に動いて Deploy が行われるが、これがなかなか時間がかかる。 開発環境だと CI でとりあえず main branch に merge されたら、Deploy したりするけど、Deploy を Skip してもよいような時でも CI 回してると Deploy を待つことになって、ちょっとめんどうに感じる。 更にこの仕組みは成果物は Deploy しないと生まれないので、CI と CDを分離しづらい。 Cloud Run は Container Registry a

                          App Engine VS Cloud Run
                        • マイクロサービス環境におけるDB戦略 in DMMプラットフォーム

                          Database Engineering Meetup #2 の登壇資料です。 https://scalar.connpass.com/event/310641/

                            マイクロサービス環境におけるDB戦略 in DMMプラットフォーム
                          • オープンソースによるFirebase代替を名乗るBaaS「Supabase」が正式サービスとして提供開始

                            オープンソースによるFirebase代替を名乗るBaaS(Backend as a Service)「Supabase」が正式サービス化を発表しました。 Supabaseはこれまで約4年間ベータ版としてサービスを提供してきました。現在は100万以上のデータベースをホストし、新規データベースも1日あたり2500以上増加しており、モバイルアプリケーションからエンタープライズ用途まで十分な機能と安定性、スケーラビリティが実証されたとしています。 Supabaseの主な機能はデータベースや認証、ファイルストレージなど SupabaseはBaaSとして主に以下のマネージドサービス群から構成されています。 PostgreSQLによるデータベースサービス 認証サービス ファイルストレージ エッジロケーションにおけるNode.jsDenoベースのサーバレス基盤 マルチプレイヤーゲームなどに対応するリアルタ

                              オープンソースによるFirebase代替を名乗るBaaS「Supabase」が正式サービスとして提供開始
                            • [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022

                              [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022 マイクロソフトは現在開催中のイベント「Microsoft Ignite 2022」で、グローバル規模の分散NoSQLデータベース「Azure Cosmos DB」でPostgreSQLをサポートする「Azure Cosmos DB for PostgreSQL」を発表しました。 Cosmos DBはデータを自動的にユーザーの近くのリージョンにレプリケーションすることで、どのユーザーに対しても高速なデータベースアクセスを実現し、かつグローバルな規模で稼働する大規模分散NoSQLデータベースです。 最大で数ペタバイトのデータ容量と秒間数百万トランザクションまでスケールする性能をカバーできる点を特徴としています。 Azure Cosmos DB

                                [速報]分散PostgreSQLをAzure Cosmos DBが提供開始、オープンソースの分散DBエンジン「Citus」を採用。Ignite 2022
                              • NewSQLのコンポーネント詳解 - Qiita

                                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つ目のアルゴリズム・シャー

                                  NewSQLのコンポーネント詳解 - Qiita
                                • バッチ処理のスケジューリングパターン

                                  この記事はこの記事は Google Cloud Japan Customer Engineer Advent Calendar 2019 の 12日目の記事です。 はじめにGoogle Cloud Platform (GCP) でバッチ処理を起動するための以下のパターンについてご紹介したいと思います。以下、8パターンあげてみました。とはいえ、最後の3つは GCP のバッチスケジューリングという観点からは少し外れますが、バッチの起動時に使われるということでご容赦を。 Cloud Scheduler : フルマネージドな cron ジョブスケジューラです。フルマネージドという点が非常に大きなメリットであり、多くの処理を自動化し実行することが可能です。Google App Engine cron サービス : HTTP GET を利用して、特定の URLを呼び出します。Google AppEng

                                    バッチ処理のスケジューリングパターン
                                  • 未来の自分に対し「こんなDB設計にして申し訳ない」とツイート→その通りになってしまった人の話

                                    補足説明: MySQLには、バージョン5.7から「JSONデータ型(JSON Data Type)」と呼ばれる概念が登場しています。これにより、JSON型を直接入れられるカラムを作成できます。 便利な一方、一般的なRDBの正規化を崩すことになりますので、仕様には注意が必要です。詳しくはこちらをご覧ください。 リンク WPJ もう知ってた? MySQL 5.7でNoSQLっぽくJSONデータを扱う方法 MySQL 5.7では、JSONデータを「JSON型」としてネイティブで扱えます。サンプルを見ながら、基本的な使い方を確認しましょう。 ※本記事は2016年5月31日に掲載した記事を一部再編集して更新したものです。執筆時点の技術情報をベースにしています。 「SQL vs NoSQL: The Differences」で紹介したように、SQLとNoSQLの境界線は、両言語が他方の特徴を取り入れる

                                      未来の自分に対し「こんなDB設計にして申し訳ない」とツイート→その通りになってしまった人の話
                                    • Google App Engineのスタンダード/フレキシブル環境を選ぶときのヒントと設定の注意点

                                      イメージとしては スタンダード環境の方が気楽にはじめられる フレキシブル環境の方がより細かな設定ができる という感じでしょうか。 「料金が安いのはスタンダード」とは限らない ググって見つかる情報を読むと、多くの人は「スタンダード環境の方が安く済みそうだ」という印象を持つと思います。僕もそのような考えから、当然のようにスタンダード環境を選んでいました。しかし、結果として、Zennの場合にはフレキシブル環境の方が料金は大幅に安く済むことが分かりました。 Zennの場合 具体例があった方が読んでいて楽しいと思うので、恥を捨てて実際にかかっていたGAEの料金を載せてしまいます。ほれっ。 ※ 料金の推移は、サービスへのアクセス数とはほぼ相関していない ピーク時には1万円/日近くいってしまっていますが、設定と環境を見直すと¥500/日くらいで済むようになりました。設定をミスらなければPS5を転売ヤーか

                                        Google App Engineのスタンダード/フレキシブル環境を選ぶときのヒントと設定の注意点
                                      • オープンソースのCockroachDBも大手クラウドに反発してライセンスを変更、商用サービスでの利用を制限。ただし3年後にオープンソースに戻る期限付き

                                        オープンソースのCockroachDBも大手クラウドに反発してライセンスを変更、商用サービスでの利用を制限。ただし3年後にオープンソースに戻る期限付き 大手クラウドベンダがオープンソースのソフトウェアを利用して自社のクラウドサービスを充実させていることにRedisやMongoDBなどいくつかのオープンソースベンダが反発し、ライセンスを変更してクラウドによる商用サービスを制限する方向へ向かっていることは、以前に紹介しました。 Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 そして、これに同調するオープンソースソフトウェアがまた1つ増えました。CockroachDBを開発しているCockroach Labsです。 同社が開発するCockroachDBは、GoogleのSpannerに触

                                          オープンソースのCockroachDBも大手クラウドに反発してライセンスを変更、商用サービスでの利用を制限。ただし3年後にオープンソースに戻る期限付き
                                        • Google App EngineでRubyのスタンダード環境でのサポート開始。負荷がないときはゼロインスタンスまで縮退可能

                                          Google App EngineでRubyのスタンダード環境でのサポート開始。負荷がないときはゼロインスタンスまで縮退可能 Google App Engineは、JavaやPython、PHP、Node.js、Goなどさまざまなプログラミング言語の実行環境を提供する、いわゆるPaaS型クラウドサービスです。 利用者はこれらのプログラミング言語で記述されたコードをデプロイするだけで実行可能。負荷に合わせたプロセスの増減などスケーラブルな処理や、万が一プロセスが異常終了したときのフェイルオーバーの処理などもクラウド側で行ってくれるため、運用の手間がかからないなどのメリットがあります。 Google App Engineは2016年から、ユーザーがGoogle App Engineにプログラミング言語の実行環境を持ち込んで実行できる「フレキシブル環境」においてRubyをサポートしていました。

                                            Google App EngineでRubyのスタンダード環境でのサポート開始。負荷がないときはゼロインスタンスまで縮退可能
                                          • ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開

                                            ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開 日本電気株式会社と株式会社ノーチラス・テクノロジーズは、NEDO(国立研究開発法人新エネルギー・産業技術総合開発機構)のプロジェクトとして開発をしてきた国産のリレーショナルデータベース管理システム「劔(Tsurugi)」のアーリーアクセス版の公開を発表しました(開発者の神林氏による解説「劔"Tsurugi"とは何か」)。 劔の最大の特徴は、メニーコア、大容量メモリといった最新のハードウェアに対して最適化されたインメモリデータベースとして最初から設計、開発されていることです。 これは、現在主流となっているリレーショナルデータベース製品の多くが10年以上前のコンピュータハードウェアの主流であったシングルコアやデュアルコアなど少数のプロセ

                                              ノーチラス・テクノロジーズとNEC、メニーコアと大容量メモリに最適化した国産の次世代インメモリデータベース「劔(Tsurugi)」発表。アーリーアクセス版公開
                                            • オープンソースのグラフデータベース「Neo4j 4.0」正式版リリース。リアクティブアーキテクチャを新採用

                                              オープンソースのグラフデータベース「Neo4j 4.0」正式版リリース。リアクティブアーキテクチャを新採用 オープンソースのグラフデータベースであるNeo4jの最新版「Neo4j Graph Database 4.0」正式版がリリースされました。 Introducing Neo4j Graph Database 4.0 [GA Release] – by @jimwebber, Chief Scientist @Neo4jhttps://t.co/X8csuFuEFC#GraphDatabase #Neo4j — Neo4j (@neo4j) February 4, 2020 一般に、リレーショナルデータベースではテーブルのあいだで関係が設定されますが、グラフデータベースではデータひとつひとつがほかのデータとの関係を持てます。 また、あるデータとデータとの関係において重要度や距離、評価、時

                                                オープンソースのグラフデータベース「Neo4j 4.0」正式版リリース。リアクティブアーキテクチャを新採用
                                              • GAE 2nd-gen でのサービス間認証

                                                TL;DRGAE 2nd-gen では X-Appengine-Inbound-Appid ヘッダの代わりに、ID Token + Identity-Aware Proxy を使った方式をサービス間認証に使えます。 はじめにGAE でマイクロサービスを構成する場合、各サービス同士を呼び合うときに同一 GAE アプリからのリクエストであるかを確認したい場面があります。シンプルな例だと、サービスがフロントエンドとバックエンドに別れていて、バックエンドはフロントエンドからしか呼び出せないようにしたい場合です。 GAE 1st-gen では X-Appengine-Inbound-Appid ヘッダという魔法のヘッダがありました。このヘッダは URLFetch を使用して別の GAE サービスにアクセスする時に、GCP が自動で呼び出し元の Project ID を入れてくれるヘッダです。そのため

                                                  GAE 2nd-gen でのサービス間認証
                                                • AppEngineの旧Log APIを脱却したい話 | メルカリエンジニアリング

                                                  この記事はMERPAY TECH OPENNESS MONTHの3日目の記事です。 メルペイ ソリューションチームで毎日コード書いたりして遊んでいるvvakameです。 TL;DR AppEngine 2nd genでロックインAPIから解放され大脱出できるようになった AppEngine Log APIはオーパーツ(完全には真似できない) プラットフォーム出力のrequest logを使う アプリではapplication logだけ出力する 高度なフィルターの使い方を覚える 05/23 もらった情報をもとに追記をしました。 AppEngineはいいものだよ & 2nd genの台頭 メルペイではプロダクト提供のためにAppEngineはほぼ使われていません。だいたいのものがGKE上で動いていて、だいたいのDBはSpannerです。しかし、お客様に提供するものではない、internalな

                                                    AppEngineの旧Log APIを脱却したい話 | メルカリエンジニアリング
                                                  • WEARにおけるGAE(Google App Engine)を用いた機械学習アプリケーションの運用について

                                                    When Systems Fail: Lessons learned from real life experience's as SRE's

                                                      WEARにおけるGAE(Google App Engine)を用いた機械学習アプリケーションの運用について
                                                    • Serverless NEG でシステム開発をより柔軟に

                                                      はじめに以前 Yuki Furuyama さんが「NEG とはなにか」という哲学的な(?)記事を書かれていましたが、このたび「Serverless NEG」(Serverless Network Endpoint Group)という新しいタイプの NEG が追加されました。(まずは Beta でのご提供です → EDIT(2020–10–14): 2020年10月14日に GA になりました。) これで NEG は Zonal NEG、Internet NEG、Serverless NEG の三種類になりました。 Furuyama さんの Zonal NEG に関する記事には「NEG は Kubernetes の Service に相当するもの、Network Endpoint は Pod に相当するものです」とありましたが、Serverless NEG では「Network Endpoi

                                                        Serverless NEG でシステム開発をより柔軟に
                                                      • Cloud Monitoring を支える 分散グローバルデータストア「Monarch」

                                                        「GCPUG Shonan vol.74」で使用予定のスライドです。 https://gcpug-shonan.connpass.com/event/243711/

                                                          Cloud Monitoring を支える 分散グローバルデータストア「Monarch」
                                                        • ホット タブレット  |  Bigtable のドキュメント  |  Google Cloud

                                                          フィードバックを送信 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 ホット タブレット Bigtable には、パフォーマンスの問題をトラブルシューティングするため、クラスタ内のホット タブレットを特定してモニタリングする機能があります。このページでは、ホット タブレットの概要、ホット タブレットのリストを取得する方法、ホット タブレットの識別が有益な状況について説明します。このページを読む前に、Bigtable の概要を理解しておく必要があります。 ホット タブレットのリストを取得するメソッドの名前は、使用する言語によって異なります。わかりやすくするため、このドキュメントでは RPC Cloud Bigtable Admin API 名(ListHotTablets)を使用します。ホット タブレットのリストは、以下のものを使用して取得できます。 Goo

                                                            ホット タブレット  |  Bigtable のドキュメント  |  Google Cloud
                                                          • Bigtable の新しい変更ストリームを使用して、データをリアルタイムで操作する | Google Cloud 公式ブログ

                                                            ※この投稿は米国時間 2023 年 9 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。 Cloud Bigtable は、スケーラビリティに優れたフルマネージド NoSQL データベース サービスで、ミリ秒単位のレイテンシと最高 99.999% の可用性 SLA を実現します。また、リアルタイム分析、ゲーム、通信など、高スループットと低レイテンシを必要とするアプリケーションに適しています。 Cloud Bigtable 変更ストリームは、Bigtable データの変更を追跡し、簡単にこのデータにアクセスして他のシステムと統合できる機能です。変更ストリームを使用すると、Bigtable での変更を BigQuery に複製してリアルタイム分析を行ったり、(イベントベースのデータ パイプライン用に)Pub/Sub を使用してダウンストリーム アプリケーションの動

                                                              Bigtable の新しい変更ストリームを使用して、データをリアルタイムで操作する | Google Cloud 公式ブログ
                                                            • Cloud Bigtable で位置情報を扱ってみる

                                                              はじめに最近 IoT の文脈であらゆるものがインターネットに接続され、位置情報 (緯度・経度からなる情報) が含まれたデータを扱う例も増えてきているように思います。また、位置情報を使ったゲームなんかも増えてきていますね。 本記事では以下のようなワークロードを仮定して、これを GCP で実現するにはどうしたら良いかを考えていきたいと思います。 複数種類の移動オブジェクト (車、トラック、バイク、歩行者、タクシー) から、毎秒数十万レコードに及ぶ位置情報を含むデータが生成される生成されるデータはそれぞれタイムスタンプを持っているこれらのデータをリアルタイムに永続化しつつ、可能な限り低いレイテンシ (~1sec) で時間と位置情報を条件にしたクエリに応答する必要がある今回は大量に発生したデータを高スループットで書き込みつつ、低レイテンシで読み出せる Cloud Bigtable を使って位置情報

                                                                Cloud Bigtable で位置情報を扱ってみる
                                                              • Cloud Firestore のベスト プラクティス  |  Firebase

                                                                フィードバックを送信 Cloud Firestore のベスト プラクティス コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。 ここで紹介するベスト プラクティスは、Cloud Firestore を使用するアプリケーションを構築する際のクイック リファレンスとしてご利用ください。 データベースのロケーション データベース インスタンスを作成するときは、ユーザーとコンピューティング リソースに最も近いデータベースのロケーションを選択してください。広範囲に及ぶネットワーク ホップはエラーが発生しやすく、クエリのレイテンシを増加させます。 アプリケーションの可用性と耐久性を最大化するには、マルチリージョン ロケーションを選択し、重要なコンピューティング リソースを少なくとも 2 つのリージョンに配置します。 アプリケーションでレイテンシが重要な場合や、他の GC

                                                                • わかる!Firestore

                                                                  tl;dr Firestore は NoSQL のサーバーレスデータベース。 新規開発ならネイティブモードを選択する。 ドキュメント指向のデータモデルを採用していて、コレクション、ドキュメントの階層構造で構成される。 サブコレクションを使うと効率よくクエリができる。 直近のアップデートで、より使いやすくなった。 はじめに みなさん、こんにちは。Google Cloud パートナーエンジニアの Sho です。 この記事は Google Cloud Japan Advent Calendar 2022(今から始める Google Cloud ) の 12/11 の記事です。本記事では、Firestore を取り上げてご紹介させていただきます。 Cloud Spanner や AlloyDB など特徴的なデータベースラインナップを持つ Google Cloud ですが、その中でも NoSQL デ

                                                                    わかる!Firestore
                                                                  • How Litestream Eliminated My Database Server for $0.03/month

                                                                    Here’s a riddle. My web app keeps all of its data in a SQL database. I can spontaneously tear it down, deploy the code to a different hosting platform, and the app will still serve all the same data. Running my app in production costs $0.03 per month. How is this possible? That’s easy. You have a separate database server running somewhere that stores all of your app’s state. No, my app never talks

                                                                      How Litestream Eliminated My Database Server for $0.03/month
                                                                    • Amazon Timestream であらゆる規模の時系列データを保存してアクセス – 一般提供が開始されました | Amazon Web Services

                                                                      Amazon Web Services ブログ Amazon Timestream であらゆる規模の時系列データを保存してアクセス – 一般提供が開始されました 時系列は、物事が時間の経過とともにどのように変化するかを説明する非常に一般的なデータ形式です。最も一般的なデータソースには、産業機器と IoT デバイス、IT インフラストラクチャスタック (ハードウェア、ソフトウェア、ネットワークコンポーネントなど)、およびそれらの結果を経時的に共有するアプリケーションがあります。時系列データの効率的な管理は、このデータモデルが汎用データベースに合わないことから容易ではありません。 本日からの Amazon Timestream の一般提供をお知らせできることが嬉しいのは、これが理由です。Timestream は、1 日に数兆件もの時系列イベントを収集、保存、および処理することを簡単にする高速で

                                                                        Amazon Timestream であらゆる規模の時系列データを保存してアクセス – 一般提供が開始されました | Amazon Web Services
                                                                      • GCPのCloud FirestoreのネイティブモードとDatastoreモードの違い - Qiita

                                                                        はじめに GCPのCloud Firestore Datastoreモードを使用してサーバレスのWebサービスPocを実現しました。 その際に、FirebaseのCloud FirestoreとGCPのCloud Firestoreがネットで情報が混在していた為、その部分についてまとめてみました。 何か間違っている場合、また意見があれば募集中です Cloud Firestoreの概要 GCPのCloud Firestoreは2019年2月1日に正式リリースされた、FirebaseとGCPからのモバイル、Web、サーバー開発に対応した柔軟でスケーラブルな NoSQL クラウド データベースです。 まとめると、Firebase の技術をベースにして、Google Cloud Platform に統合されたサービスです。 Cloud Firestoreには2種類のネイティブモードとDatasto

                                                                          GCPのCloud FirestoreのネイティブモードとDatastoreモードの違い - Qiita
                                                                        • TechCrunch | Startup and Technology News

                                                                          Apple’s Worldwide Developer Conference (WWDC) is now just less than a week away. Many developer communities are already organizing watch parties across the world. But if you are going to the eve

                                                                            TechCrunch | Startup and Technology News
                                                                          • Snap、Google Cloud 上で KeyDB データベースを使用してレイテンシを 96 パーセント短縮 | Google Cloud 公式ブログ

                                                                            Snap、Google Cloud 上で KeyDB データベースを使用してレイテンシを 96 パーセント短縮 ※この投稿は米国時間 2023 年 10 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。 モダンなアプリケーションは高度に分散化が進み、マイクロサービスや API がマルチクラウドのような多数の異なる環境で実行されるケースが多くなっています。このアプローチには、レジリエンスやスケーラビリティなどを向上させて、チームの共同作業を加速するメリットがある一方で、レイテンシの面では懸念があります。この投稿では、Google Cloud コンサルティング(GCC)と Snap が共同で Snap の「ユーザー サービス」マイクロサービスのレイテンシを 96% 短縮し、最終的には、パフォーマンスを許容範囲内に維持しながらマルチクラウド環境でデータ分析を行える

                                                                              Snap、Google Cloud 上で KeyDB データベースを使用してレイテンシを 96 パーセント短縮 | Google Cloud 公式ブログ
                                                                            • FireStoreのイベントをトリガーとして、Eventarc経由でCloudRunを呼び出す

                                                                              (これはこの記事からの転載です) FireStoreのイベントは、Eventarcを用いることで他のサービス、例えばCloud Runなどをトリガーできます。 今回、Eventarcを用いてFireStoreのイベントをトリガーとしてCloud Runを呼び出してみることにします。 EventarcはAuditとPub/Subの両方から流し込むことができます。PubSubはCloud PubSubとして他のいろいろなところから流し込むことができ、AuditはFireStoreのイベント以外にもGoogle Cloudで起きるほぼすべてのAPI呼び出しをイベントとして流し込めます。 1. 取得したいイベントの監査ログを有効化する 最初にEventarcを有効化する監査ログの種類を指定し、有効化します。 IAM権限管理 -> 監査ログ で、 "Firestore/Datastore API"

                                                                                FireStoreのイベントをトリガーとして、Eventarc経由でCloudRunを呼び出す
                                                                              • Cloud IAP で作る手軽でセキュアな社内サービス | フライウィール

                                                                                こんにちは、ソフトウェアエンジニアの yuku です。好きなおでんの種は大根です。 仕事をしていると社内向けに何かしらのサービスを作りたくなることがありますよね。この時面倒なのが認証と認可です。外部に公開されていない社内ネットワークにだけ公開すれば安全ではありますが、外からアクセスするためにいちいち VPN 接続せねばならず面倒です。インターネットからアクセス可能にする場合、画像などコンテンツもセキュアな場所に確実に配置する必要があります。 こんな時 G Suite を使っている会社であれば Cloud IAP を使ってどこからでもアクセス可能な社員向けサービスを簡単に作ることができます。今回の記事では Cloud IAP と、フライウィールで実際に Cloud IAP を使って実装されている社内向けドキュメント共有サービスを紹介します。 Cloud IAP とはCloud IAP (Id

                                                                                  Cloud IAP で作る手軽でセキュアな社内サービス | フライウィール
                                                                                • key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え

                                                                                  key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思えるのですが,この問題はうまく回避できるのでしょうか 前提として世の中にあるデータベースは基本的にログファイルが破損する事を想定していません。ログは信頼できるストレージに複製込で保存されており、化けたり消えたりする事はないという前提を置いています。想定する一番大きな障害でもMedia Fai

                                                                                    key-value storeを設計するにあたって,リカバリのためにwalを設計するとします。walを可変長にしたい場合,各wal recordにrecord長を表すheaderをつけるような実装が素直な実装の一つとしてあると思うのですが,wal recordを格納しているファイルが破損し,あるwal recordのheader部分が信頼できなくなった場合,各recordの長さがわからなくなってしまうため当該wal record以降のすべてのwal recordが信頼できなくなるような弱点があるように思え

                                                                                  新着記事