Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
MySQLやPostgreSQLといったクライアント・サーバー型のデータベースで大量のクエリを発行すると、クライアントとサーバー間の通信が大きなボトルネックとなることがあります。一方、軽量データベースのSQLiteは、その設計上「大量の小さなクエリ」の処理が得意であるとのこと。なぜSQLiteが効率的に大量のクエリを処理できるのかについて、SQLiteが説明しています。 Many Small Queries Are Efficient In SQLite https://sqlite.org/np1queryprob.html SQLiteの利用方法を記したページによると、SQLiteでは1つのウェブページにつき200クエリが適切であるとのこと。この記述について、開発者からしばしば「1つのページにつき200クエリなんて、ばかげている」と指摘されることがあるそうです。 SQLiteは開発者か
概要 階層構造を持つDBで入れ子集合モデルについて調べた内容をメモする。 RDBの階層構造 いろいろなパターンが存在する。 隣接リスト SQLアンチパターン - ナイーブツリー 経路列挙型 階層構造をＳＱＬで簡単に操作する 入れ子区間モデル 入れ子区間モデルという幻想 入れ子集合モデル SQLで木と階層構造のデータを扱う（１）―― 入れ子集合モデル 第5回 SQLで木構造を扱う～入れ子集合モデル （1）入れ子集合モデルとは何か 入れ子集合モデルで子供データを取得する際のパフォーマンス などなど とりあえず、隣接と経路はなんとなくやったことがあるので入れ子集合についてさらに調べてみる。 とりあえずやってみる 下記サイトを参考に試してみる。 ※ 2章 Naive Trees(素朴な木) テーブルとデータ作成 CREATE TABLE staffs( id INTEGER NOT NULL AU
1．入れ子集合モデルとは 木構造のデータ・サンプルとして、次のような階層の深さが 4 の組織図を例に取りましょう。一つのノードは、複数の親を持つことはない（＝複数の上司を持たない）、かつ必ず一つの親を持つ（＝命令系統から外れる社員がいない）と仮定します。この条件を破ると、木構造ではなくなってしまいます。 一般的な隣接リストモデルでこのデータを表現すると、次のようなテーブルになります。 --隣接リストモデルによる階層データ表現 CREATE TABLE OrgChart (emp VARCHAR(32) PRIMARY KEY, boss VARCHAR(32), role VARCHAR(32) NOT NULL ); INSERT INTO OrgChart VALUES ('足立', NULL, '社長'); INSERT INTO OrgChart VALUES ('猪狩', '足立
サーバ監視サービスMackerelにおいて開発中の、高解像度・長期間のサーバメトリック収集を実現するための新しい時系列データベースDiamondを紹介します。具体的には、Amazon ElastiCache、Amazon DynamoDB、Amazon S3を組み合わせ、Amazon Kinesis StreamsとAWS Lambdaによりコンポーネント間を接続した、階層構造のデータストアアーキテクチャの設計と実装を解説します。 2018/06/05 追記: この記事の内容をWSA研#2でより一般的なアーキテクチャレベルでの貢献として書き直しました。 サーバレス時代におけるヘテロジニアス時系列データベースアーキテクチャ - ゆううきブログ はじめに 先日開催されたAWS Summit Tokyo 2017にて、「時系列データベースという概念をクラウドの技で再構築する」というタイトルで登壇
こんにちは。インフラストラクチャー部 SRE グループの吉川 ( @rrreeeyyy ) です。今期オススメのアニメはツインエンジェル BREAK です。 普段の業務並びに趣味の一環として、サーバのモニタリング環境の調査や改善に取り組んでいます。 そこで本稿では、モニタリングのコンポーネントの一つとして外すことが出来ない、時系列データベースの基礎知識に関して紹介します。 そもそも時系列データ・時系列データベースとは？ 時系列データというのは、特定の時間ごとに何らかの値を取得した際の、取得した一連の値を指します。 例えば、以下のようなフォーマットをしたデータなどは時系列データにあたるでしょう。 timestamp1,key,value1 timestamp2,key,value2 timestamp3,key,value3 : 時系列データベースとは、上記のような時系列データの保存・処理に
ブロックチェーン技術について説明する記事を書いていると、次のような意見を耳にすることがあります。「ブロックチェーン技術を使わずにデータベース管理システムを使えばいいのでは？」──主にITに詳しい人からこの意見が出る場合が多いようです。 筆者の個人的な意見としては、ブロックチェーン技術とデータベース管理システム（DBMS）やKVS（Key-Value Store）は目的も特性も異なる技術なので「別のもの」と考えた方が理解が早いと思います。それ以前に「そもそも、ブロックチェーンとデータベースを比べること自体が間違っている」とのご指摘もあろうかと思います。 現実に、ブロックチェーンの説明で「データベース」という用語を使う事例はいくつかあります。「ダボス会議」で知られている世界経済フォーラムによる解説動画では、パブリックブロックチェーンについて「オープンで脱・中央集権的なデータベース」と説明してい
書き込みと読み込みのどちらに力を入れているかは、ストレージエンジンによって異なります。たとえば昔ながらのリレーショナルデータベースは、外部キーなどの制約を使ってデータの整合性をうまく制御できるようになっています。一方でNoSQLデータベースは、スループットとスケーラビリティを確保するために、そういった組み込みのガードレールをはずしてしまいました。データ層においても、どちらか一方に特化した最適化をすることがあります。たとえば、あらかじめ計算済みの値を保持しておけば、「一日あたりのサイト訪問者数」などの読み込み操作を効率よく行えるでしょう。ストレージソリューションのメーカーはどこも、「うちのプロダクトならあらゆるニーズを満たせます」などと自社製品の機能を自慢します。しかし実は、昔ながらのCRUDモデルに沿ってストレージエンジンを選んでデータ層を設計した時点で、さまざまな関心事の間で何らかの妥協
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
データを扱うときに、きちんと定められたワークフローがあると助かります。具体的には、「ストーリーを伝える」（データの可視化／ジャーナリズム）ことだけを目的として分析を行いたいのか、それとも一定のタスク（データマイニング）をモデリングするためにデータに依存するシステムを構築することが目的なのか、プロセスが重要です。前もって方法論を定めておくことによって、チームの足並みが揃い、次に何をすべきか考え出そうとして無駄な時間を費やさなくて済みます。それによって早く結果が得られ、資料の公表も早くなります。 これを念頭に、Ashley Madisonの漏洩データ分析に関する 前回の記事 に続いて、私たちが現在使用しているワークフローをご紹介します。このワークフローは、データ漏洩（Ashleyのケースなど）を分析するためだけでなく、社内のデータの分析にも使用されます。ただし、重要な点として、このワークフロー
データマネージャ このステップで、クエリマネージャはクエリを実行するので、テーブルとインデックスからデータを取得する必要があります。そこでデータマネージャに対してデータを取得するよう要求するのですが、ここで次の2つの問題が発生します。 リレーショナルデータベースはトランザクションモデルを使用しています。この場合、「いつでも・どんなデータも取得できる」というふうにはいきません。どこか別の場所で、ここに格納されているデータを同時に使用したり更新したりしている可能性があるからです。 データの取得は、データベース内で実行する処理の中で最も時間のかかるもの です。従ってデータマネージャはそれを見越して、メモリバッファにデータを取得しておき、それを保持しなければなりません。 このセクションでは、リレーショナルデータベースがこの2つの問題にどう対処しているかを説明します。なお、データマネージャがデータを
クライアントマネージャ クライアントマネージャは、クライアントとの通信を扱います。クライアントとは、（Web）サーバであったり、もしくはエンドユーザ、またはエンドアプリケーションであったりします。ここではJDBC、ODBC、OLE-DBといった良く知られる一連のAPIを介してデータベースにアクセスできる様々な方法が提供されています。 また、データベースアクセスのための専用のAPIも提供されています。 データベースと接続する手順は以下の通りです。 マネージャは最初に 認証を行い （ログイン情報とパスワードの確認）、次にデータベースにアクセスできる 権限 を持ち合わせているかチェックする。これらのアクセス権はDBAによって規定されている。 その後、クエリを管理できるプロセス（もしくはスレッド）が利用可能かチェックする。 データベースに高負荷がかかっていないかどうかも確認する。 要求されているリ
リレーショナルデータベースが話題に挙がるとき、私は何かが足りないと思わずにはいられません。データベースはあらゆるところで使われており、その種類も、小規模で便利なSQLiteからパワフルなTeradataまで様々です。しかし、それがどういう仕組みで機能しているかを説明したものとなると、その数はごくわずかではないでしょうか。例えば「リレーショナルデータベース 仕組み」などで検索してみてください。ヒット数の少なさを実感できると思います。さらにそれらの記事は短いものがほとんどです。逆に、近年流行している技術（ビッグデータ、NoSQL、JavaScriptなど）を検索した場合、それらの機能を詳しく説明した記事はたくさん見つかると思います。 リレーショナルデータベースは、もはや大学の授業や研究論文、専門書などでしか扱われないような古くて退屈な技術なのでしょうか？ 私は開発者として、理解していないものを
この2つの技術は、グーグル独自の技術というわけではない。しかし、ハードウェアから構築している、既存のグーグルのクラウド技術を活用し、パブリックなクラウドサービスとして提供可能なレベルの実装になっている点がGoogle BigQueryの強みとなっている。 BigQueryの特徴 他の類似サービスとの比較 巨大データを処理する技術としては、同じグーグルが使ってきたMapReduceというものがある。MapReduceとBigQueryを比べると、MapReduceが巨大なデータを安定的に処理できるプログラミングモデルであることに対し、BigQueryはアドホックにトライ＆エラーしながらクエリを実行するサービスであることが異なっている。 MapReduceは、非構造化データを、プログラミングモデルを通して扱うことができ、巨大なテーブルの結合や巨大な出力結果のエクスポートも可能である半面、処理時
リレーショナル・データベースは実に素晴らしいものだ。しかしモノのインターネットでのプロジェクトにおいてこれは実に役立たずだ。 少なくとも、数十億のスマートデバイスで構成される次世代ネットワークの管理について調査を行ったマキナ・リサーチによればそう言える。これによれば、リレーショナル・データベースは「構造化・均一化なデータの処理を処理するためのもの」であり、NoSQLデータベースは数えきれないほどのセンサー、デバイス、ゲートウェイから生成される、はるかに規模が大きく、不均一なデータのマネジメントの為に不可欠なものだという。 言い換えれば、もしあなたが開発者なのであればNoSQLデータベースを自分の武器として持っておく必要がある。 NoSQLが必要な理由“NoSQL”というそのありがちな呼称とは裏腹に、これは他のデータベースとは異なるものだ。NoSQLデータベースでは厳格なスキーマを強制しない
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く