読書会(データ指向アプリケーションデザイン)第2回議事録

=================================================================
Java読書会BOF「データ指向アプリケーションデザイン」を読む会第2回
=================================================================

.. csv-table:: 開催概要

  "日時", "2020年11月28日 10:00 - 17:00"
  "場所", "川崎市教育文化会館第3会議室"
  "出席者(敬称略)","高橋(徹)、高橋(智)、松永、岩室、遠藤、吉本、平山、加藤"

第2章データモデルとクエリ言語
==============================

2.3 グラフ型のデータモデル
------------------------------

2.3.4 トリプルストアと SPARQL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

本日は、p.59 の 2.3.4.1 セマンティック Web から

* p.60 2行目、「実現するする兆し」となっており、誤植と思われる

2.3.5 礎となったもの: Datalog
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* p.64 図2-6 はルール2が2回適用されているということか？

  * 本文の 1,2,3 を見てもルール2が 2,3 で適用されているので、合っている

まとめ
~~~~~~

* きわめて長い文字列とあるが、ゲノムデータは結構大きい？

  * 本データまで管理するなら数百 GB、調査用の延期配列データは少なくとも 1GB 近く
  * 実際には数百人とか数千人とかのデータを扱うので、もっと大きな容量になる
  * 個人情報なので取り扱いにも注意しないといけない

地図
~~~~

* 大きく左側がトランザクション系、右側が分析系に別れているようだ

  * ETL: Extract Transform Load, トランザクション系からデータを抽出し、加工し、分析系に取り込む処理

第3章ストレージと抽出
======================

3.1 データベースを駆動するデータ構造
------------------------------------

* p.74 エスケープ処理していないので実際に使うには注意しないといけない

  * /bin/bash というのも気になる

3.1.1 ハッシュインデックス
~~~~~~~~~~~~~~~~~~~~~~~~~~

3.1.2 SSTable と LSM ツリー
~~~~~~~~~~~~~~~~~~~~~~~~~~~

* p.82 圧縮は、zip とかそういう圧縮アルゴリズムをかけるということか？

  * ディスクに書き込むときブロック単位で圧縮するだけ、インデックスのバイトオフセットは変わらない
  * そもそもソート済みセグメントはどう作るのか？
    * もう少しあとに記述がありそう

* p.83 LSM ツリー、構造がシンプルでわかりやすい割には割と新しい概念？

  * 文献には 1992 年発表とある
  * 1992 年っていうとパソコン通信の時代か・・・
  * SSTable から memtable は Google の 2006 年の論文から

3.1.3 B ツリー
~~~~~~~~~~~~~~

* そもそも B ツリーはなんの略だっけ？

  * Balanced Tree? Binary Tree?
  * Balanced Tree のようだ

3.1.4 B ツリーと LSM ツリーの比較
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* どの製品がどのアルゴリズムを採用しているのだろう？

  * 冒頭の地図がそれを説明している
  * MongoDB は NoSQL だが、 RDB で主流である B ツリーを利用しているのが特徴的だ
  * LSM のほうが分散システムと相性が良さそうな想像はできる

* B ツリーで削除をたくさんするとリバランスが不可欠になるよね

  * LSM もコンパクションがあるし、どっちみちインデックスはお手入れが不可欠

3.1.5 その他のインデックス構造
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* p.94 編集距離のアルゴリズムにレーベンシュタイン距離というのがあるので、レーベンシュタインオートマトンはそこから来ているのだろう

  * Java とか Ruby に計算ライブラリがあるね

* p.95 インメモリ DB、メモリは安くなっているけれどそれ以上に扱うデータ量が増え、結局使い所が限られる感じがある

  * インメモリ DB でもディスクも使うと思うが、どっからがインメモリ DB か

    * この本の定義では、読み込みが全てメモリから行われれば、インメモリ DB みたいだ

  * クラッシュしたらどうなるのか

    * 読み込めなくなるが、ディスクに書き込みログ等があれば元に戻せる

* 弱い耐久性といえば、非同期ログ書き込みとかもクラッシュ直前のログが消えちゃうとかあるな

  * 速度と耐久性のバランスがいいのは共有メモリへの書きこみだろうか
  * クラウドアプリケーションだとメッセージキューに書き込むとかがある

* NVM (不揮発性メモリ) はどんなものか？

  * Intel の Optane という DRAM の I/F にさせる不揮発メモリがある

3.2 トランザクション処理か、分析処理か？
----------------------------------------

3.2.1 データウェアハウス
~~~~~~~~~~~~~~~~~~~~~~~~

* データウェアハウスに直接突っ込むことはないのだろうか？

  * センサーデータ等は DB にあるとは限らない (オブジェクトストレージにおいたりする) が、 ETL でサマってデータウェアハウスに格納して分析対象にすることはある
  * ユースケース次第では OLAP だけで問題を解決したりもするだろう
  * Twitter も RDB から NoSQL に移行したりしている

3.2.2 スターとスノーフレーク: 分析のためのスキーマ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* 図3-9 sk はなんの略だろう？

  * ソートキー？サロゲートキー？シーケンスキー？

    * サロゲートキーっぽいが、p.106 にはソートキーという記述もある

  * dim はディメンション

3.3 列志向ストレージ
--------------------

* p.102 「この様子は図 3-10 の CSV の例を見れば分かるでしょう」とあるが、図 3-10 は列志向の話では・・・

* 列志向にするとアプリケーションからはどう変わる？

  * 内部構造が変わるだけで、SQL が変わるわけではない、 SELECT * ならどっちでも大差ない
  * 列志向では書き込みが大変になるので、トランザクション処理では使われない

* テーブルによって列思考と行志向を選べる？

  * 普通はデータベースシステムによって固定されるが、テーブル単位で選べる DBMS もある

3.3.1 列の圧縮
~~~~~~~~~~~~~~

* p.104 ランレングス圧縮はとても基本的なアルゴリズムだが、こんなに有用なユースケースは初めて見たかもしれない

  * 圧縮されたビットの配列だけを拾ってビット演算だけで (いわゆる解凍処理をせずに) 絞り込める利点は大きい

* p.105 BI ツールではベクトル化処理をよく使うため CPU 最適化するために C++ などを使うことが多い

  * GPU が得意な処理でもあるが、コードを書き換えるコストが高い・・・
  * Intel なら AVX-512 とか使えると速い

3.3.2 列ストレージにおけるソート順序
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.3.3 列志向ストレージへの書き込み
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.3.4 集計: データキューブとマテリアライズドビュー
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* p.107 BigQuery で SELECT COUNT(*) はコストかからないが、列を指定するとコストがかかってしまうので、 COUNT(*) がマテリアライズドビューやメタデータ的なものでキャッシュされているのかも

* データキューブは作っておけば透過的に利用される？

  * クエリするときに指定したり、ライブラリやツールを介して明示的に利用することになる
  * あくまで分析処理のパフォーマンス向上策の一つであり、時間がかかってもいいなら使わなくてもいい

まとめ
~~~~~~

* 広くて深い話なのに簡潔にまとまっていてすごい章だ
* 参考文献も充実している

第4章エンコーディングと進化
============================

4.1 データエンコードのフォーマット
----------------------------------

4.1.1 言語固有のフォーマット
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* p.121 Java の Kryo は初耳だ

  * これは試してみたい

4.1.2 JSON、XML、様々なバイナリフォーマット
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

* JSON や XML は広く嫌われてもいる・・・

  * XML は冗長、JSON はスキーマが・・・コメントが・・・、etc.

* p.123 "それが何であれ" が太字になっているが、それは何を指している？

  * 合意するということだろうか

----

本日は、 p.123 の 4.1.2.1 バイナリエンコーディングの前まで

----

[ 戻る ]