オフラインWebアプリを実現するDropboxの新API「Datastore API」。Dropboxは実質的にBaaS市場へ参入した
オフラインWebアプリを実現するDropboxの新API「Datastore API」。Dropboxは実質的にBaaS市場へ参入した Webアプリケーションをオフラインの状態でも利用できるようにするには、オフラインのときに保存したデータを、ネットワークと接続したときにサーバと同期してくれるAPIが必要です。 しかし、データ同期のプログラムを作るのは非常に面倒です。データの差分だけを取り出して同期するアルゴリズムをどうするか、同期の途中でネットワークが切れたらどうするのか、同期待ちのデータが複数のデバイスに分散されていたら、どれを同期後に上書きするのか、などを解決しなければなりません。 Dropboxが発表した新API「Datastore API」は、オフラインに対応し、データを自動的に同期してくれる機能を備えています。オフラインWebアプリケーション普及のための道具が揃いつつあるのです。
［Google App Engine編］大量データの処理はかかる時間に注意
Google App Engineで大量データを処理する場合、特別な配慮が必要になります。処理時間の制限など、独特の制約に引っ掛かる恐れがあるからです。 大量データを扱うケースとして、テーブルのスキーマ変更、検索結果のダウンロードなど、データの一括処理という三つについて、それぞれの設計ノウハウを解説します。 スキーマのバージョンをフィールドに持つ 一つ目の設計ノウハウは、テーブルのスキーマを変更する際に効果があるものです。 稼働中のシステムにおいて、機能を追加・変更する際、テーブルのスキーマ変更が必要になる場合があります。スキーマの変更に備えて、Google App Engineでは、RDBベースの場合とは違った設計が必要になります。「スキーマのバージョンをフィールドに持つ」というものです。 Datastoreはそもそも、同じテーブル内で、異なるスキーマのレコードが混在していてもかまわない
Google App Engine上のベスト・プラクティス、その１: Datastore
Google App Engine上でアプリを作りはじめて約二ヶ月。いろいろと分かって来たこともあるので、自分へのメモも含めてまとめてみる。まずは、Datastoreの話から。 なによりも大切なのはデータベースの設計 あたりまえと言えばあたりまえの話だが、App Engine上でアプリを作る上でもっとも大切なこと（＝頭を使うべきところ）は、データベースの設計である。特にリレーショナル・データベース（RDB）上でのアプリ作りに慣れた人には、大きな「発想の転換」が必要なので、ここは注意が必要。 特に絶対にやっては行けないのは、 将来RDB上へ移行できるようにレイヤーを作って、その上にアプリを作る RDB上に作ったアプリをデータモデルを大幅に変更せずにApp Engine上に移植する RDBを前提に設計されたフレームワークをApp Engine上に載せて、その上にアプリを作る など。App En
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
