スキップしてメイン コンテンツに移動

db tech showcase 2018 メモ

db tech showcase (株式会社インサイトテクノロジー主催)に1日だけ参加してきたよという話。
https://www.db-tech-showcase.com/dbts/tokyo

数年前から毎年開催されているデータベース技術に特化した，カンファレンス型イベント。インサイトテクノロジーの事業との関連性だろうと勝手に想像しているが，かつてはOracleデータベースが中心だった様な印象を持っていた(あくまで印象だけ)。けれど，徐々に「OSSのDBMSの枠が増えてきたみたい」とは感じていた。今年は驚くことにOSS系の比率がものすごく多くなった様に感じる。ざくっと「半分くらいOSSじゃないか？」(←かなり乱暴な感想)と思うほど。しかも，NoSQLなどRDBMS系以外の比率も高い。

PGECons[ https://www.pgecons.org/ ]の参加も，いまや定番枠と言っていいかもしれない。今年はWG3:課題検討WGから「PostgreSQLのレプリケーション」が発表されていた。

━━━ 個別セッション ━━━

■D33: Apache Ignite: インメモリーデータグリッドからメモリー中心分散データベースへ

Roman Shtykh (シュティフ ロマン), ヤフー株式会社 - データ＆サイエンスソリューション統括本部
[資料配付=有　…と記されているが，まだ出てこない]
本セッションでは，Apache Igniteを紹介し，インメモリーデターグリッドからメモリー中心データベースへの発展について説明します。このセッションによって，Apache Igniteのメモリーを中心としたアーキテクチャの特徴や，高速なデータ保管・処理の強みについて知る事ができます。
【コメント】
Microsoftのイベントではない。
インメモリDBは昔から存在はしていたが，結構キワモノっぽかったり，そうでなければ他のDBMSのフロントに置いてキャッシュとしての使い方が一般的だった(←合ってるかな？)。IgniteはインメモリDBながら“プライマリの”DBとして使うことを目指したもので，かつ，分散化もできる。これを指して「In Memory DataGrid (IMDG)」と呼ぶそうな。また，SQLの表現力も欲しい，とか，分散コンピューティングにも対応(←詳しくは不明)など，かなり欲張ったツールになってる印象。

━━━

■E34: 地方の飲食/小売業をテクノロジーでデザインする。 ～老舗ベンチャーが考えたBIツール機械学習と画像解析，IOTの使い方〜

小田島 春樹 (おだじま はるき), 株式会社EBILAB / 有限会社ゑびや - 代表取締役社長
常盤木 龍治 (ときわぎ りゅうじ), 株式会社EBILAB / 有限会社ゑびや - 最高戦略担当
[資料配付=無]
エンドユーザー発，現場が本当に必要としてた課題解決を様々なテクノロジーの力で用いて，売上＆利益を大幅に向上させ，ヒット商品開発にも活用する明治創業１００年以上続く伊勢の老舗食堂のおはなし。
【コメント】
DBの話でも，技術の話でもない，今回のdb tech showcase最大の変わり種。ゑびや(えびや)は伊勢神宮近くの食堂＆お土産屋，EBILABはゑびやのIT担当会社(子会社かどうか不明)。「地方の1食堂だってITを使って経営を劇的に改善することが可能だぞ」というのがメッセージだろう。

━━━

■C35: もうSQLとNoSQLを選ぶ必要はない！?　～ 両者を備えたスケールアウトデータベース　GridDB ～

服部 雅一, 東芝デジタルソリューションズ株式会社 - ソフトウェア＆AIテクノロジーセンター　技監
[資料配付=有]
GridDB は高いスケーラビリティ，高い信頼性，データ一貫性を兼ね備えたNoSQLデータベースですが，NoSQLのデータモデルをテーブルにマッピングすることで，NoSQLの高速性とSQLの利便性をシームレスに利用することができます。単なるSQL機能を実現しただけではありません。分散並列処理技術を駆使したことで，従来のRDBでは扱えなかった巨大データを短時間で処理することができます。本講演ではアーキテクチャも含めて，その内容をご紹介したいと思います。
【コメント】
GridDBはNoSQLなので，高いスケーラビリティは当然として，普通はNoSQLがニガテなデータ一貫性を保てる(要はトランザクション処理ができる)。疑うわけではないが，それが額面どおりなら，もっと注目されてもいいはずなのに。

━━━

■C36: ビッグデータ処理データベースの全体像と使い分け 2018年Version

渡部 徹太郎, 株式会社リクルートテクノロジーズ - データテクノロジーラボ部
[資料配付=有]
ユーザ企業のアーキテクトが中立な立場でビッグデータ処理技術を評価する。商用製品，OSS，クラウドにわたり様々な技術を整理すると共に使い分けを説明する。主なトピック：Google BigQuery, Spanner, AWS Redshift, Athena, EMR, Hadoop, Snowflake, TresureData, Oralce Exadata, Cassandra, MongoDB
【コメント】
OSSコンソーシアムのデータベース部会主催セミナーでも登壇してもらった渡部徹太郎さんの定番ネタ。ホンマによく調べてる。ところで，上の講演概要の中のOracleのスペル間違いはわざとかな。

━━━

■A37: 明日から使えるPostgreSQLレプリケーション

家島 拓也, PostgreSQLエンタープライズ・コンソーシアム（株式会社アシスト所属） - 技術部会 WG3 代表
[資料配付=無]…なんで？
PostgreSQL標準の高可用性機能である「ストリーミングレプリケーション」の紹介です。仕組み，構築手順，運用と監視など，未経験者でも理解できる内容となっています。
【コメント】
TISメンバも参画しているPGECons/WG3の成果発表。(諸事情あって内職してたので，話をあまり聞いてなかった)。ところで，コンソーシアム活動成果の発表なのに資料公開無しになっているのは，コンソーシアム(PGECons)での成果物公開ぺージにアクセスしてもらいたいと考えたからかな？
( https://pgecons-sec-tech.github.io/tech-report/ → 2017年度WG3活動報告書 レプリケーション調査編 )

--

コメント

コメントを投稿

このブログの人気の投稿

5600ページのIEEE 802.3-2018が入手可能になった

IEEE 802.3の名称は今では「IEEE Standard for Ethernet」になっている。 「イーサネットとIEEE 802.3は別物なんだよ」という話は，今では昔話でしかない。もうひとつ“いまはむかし”な話をすると，「イーサネットはCSMA/CDだよ」なんて言うと恥をかくのでやめた方がいい。こちらは名称の問題では無く中身の話だが，ここでは詳しい説明は割愛する。 この「イーサネット標準」の2015年以来の改訂版が，2018年8月に発行。6ヶ月のIEEE会員限定期間が過ぎたので，一般にも入手可能になった。ただし個人アカウントは取得する必要がある。この話は以前に書いた ( https://nmizos.blogspot.com/2017/12/ieee802.html 参照)。 https://ieeexplore.ieee.org/document/8457469 このネタをブログにしようと思った動機はタイトルに記してしまった。この規格は改定されるたびにドンドン太って巨大になってきている。本編改訂の間に発行されたamendment (補遺と訳すのがいいのかな)が取り込まれるので，太るのはしょうがない面もある。でもねぇ，ついに5600ページ。もちろん通し読みするようなものじゃない。PDFファイルなので「厚さ」は無いが，印刷したらどれくらいになるんだろう。 参考までに，過去10年の本編のボリュームを比較してみた。 　2008 = 5分割，2977ページ 　2012 = 6分割，3748ページ 　2015 = 4017ページ，56Mバイト 　2018 = 5600ページ，98Mバイト 以前は数セクションにファイルを分割して公開されていた。ファイルが大きすぎるのを気にしてたんだろう。2018版も中身は8セクションに分かれている(ページ番号も別に付いている)のを，PDFファイルとしては合体してある。100Mバイト程度のPDFが「デカ過ぎて開けない」ってことも無いだろうから，1本になっていた方が全文検索ができて都合がいい。ちなみにiPadで開いて全文検索しても，今の98Mバイトなら困らない。 参考までに，無線LANのIEEE 802.11の方は，802.11-2016が3534ページ。こちらも結構なもんだ。 --
コメントを投稿
続きを読む

IEEE802標準文書の入手

■概要 入手方法が変わった。たぶん2017年のどこかから。 ダウンロードの都度メルアド等を入力するのではなくて，メンバ登録＆ログイン形式に。 個別の参照(入手)時点の操作も変わった。 概要の表示ページから“Download PDF”を選ぶとPDFファイルが呼び出されるが… 即ダウンロードでは無くて，(ブラウザ依存だと思うがFirefoxの場合は)インラインでPDF表示になるので，その後に表示しているPDFをダウンロードさせることになる。 802.3の場合は困ったことに文書がデカ過ぎる。従来は複数パート(セクション)にPDFが分割されていたが，参照方法が上記の様に変わったのに合わせて，802.3全体が1本のPDFに。なんと4000ページ超，50MB超の1本のPDFになり，それをまとめてインライン表示しようとするので，待ち時間がとても長い。メモリの少ないPCだと途中でアカンことになりそう。   ---- ■操作 入口=  http://ieeexplore.ieee.org/browse/standards/get-program/page/series?id=68 (  http://ieeexplore.ieee.org/  からでもたどれるだろう )。 メニューをたどって，例えばIEEE 802.11(無線LAN)の標準文書を参照しようとすると… “Download PDF”は選択できなくなっている。 画面最上部の“Personal Sign In”からログインすると… “Donwload PDF”が有効になる。 概要でも記したように標準文書フルテキストPDFのダウンロードは，Firefoxの場合にブラウザのインラインでの表示になるので，保存する場合にはブラウザの操作でファイル保存する。 ユーザ登録は“Create Account”から。 入力方法などは自助努力で。(画面のガイダンスや注意事項を読みましょう)。 --
コメントを投稿
続きを読む

RFCは番号を無駄遣いしていないか？

新規に発行されるRFCの番号が8000番台になっていて，その8000番台も1年くらいで食い潰しそうな勢いだ。実は8年ほど前にも同じ様に「なんと6000番台後半だよ」と思ったのだった。 ところで，RFCの番号って，几帳面にきっちりと順番に使っているわけでは無い。大物RFCにはキリ番を使うことがある様だし（RFC 8200とか），規格のバージョンアップの際には旧番号から覚えやすいものにすることがある（RFC 822 → RFC 2822など）。 …ということは，ところどころ虫食い状態で空き番号がたくさんあるんじゃないかな？と，ふと思った。 RFCの一覧ページはこれ: 　 https://tools.ietf.org/rfc/ これを眺めると，ところどころに「Not Issued」となっている番号があるので，虫食いになっているのはたしかなようだ。無効化（Obsoletes）されたRFCもたくさんあるけれど，一度は使われた番号だから，これについては「使った」ということでいいだろう。 もう1つの一覧形式で，Mini-Indexページなるものがあった: 　 https://tools.ietf.org/rfc/mini-index ぱっと見で，虫食い状態がわかる。言い換えるとそれしかわからない。 上記のMini-IndexのHTMLを解析して，具体的にどれくらい虫食いなのかを調べて見た。単なる酔狂でしかないけれど。 結果（RFC 8754まで） 個数 RFC番号  735 8000番台  996 7000番台  973 6000番台  971 5000番台  973 4000番台  982 3000番台 1000 2000番台  995 1000番台  933 999番以下 こうしてみると，最初の999番までが一番大雑把だ。 RFC化の検討に入ったけど最終的に発行されないものもあるから，2000番台の様に完全に埋まることは珍しいと思う。そういう意味では，まぁまぁ，几帳面に番号割当てをしていると思っていいのだろう。 さて，RFC 10000に到達するまで残り約1250。そこに達するのは，だいたい4年ちょっと後の2024年頃だろうか。 【参考: カウントスクリプト】 : count.sh #...
コメントを投稿
続きを読む