Datastore Masakari Talksに参加してきた発表メモ #dsmasakari

公開日：2015/02/27

Datastore Masakari Talksにいってきたのでその時のメモ。

資料などは追加され次第に随時追加していこうかと思います。

とにかく5分しかない発表時間というなか、皆様全力の勢いで話すのでやたらにメモが走り書きで何書いてるかよくわからない部分等もあるかと存じますが、キーワードをみて、なんとなく「あ…察し…」てきな感じになってもらえると幸いです。

※一応Tweet禁止な部分は伏せていますがだめっぽいとこあったらご連絡下さい。

Datastore/Megastoreはクソ遅いし結果整合性すぎる話

発表者：@kazunori_279様

SQLっぽいけどSQLではない
- JOIN, GROUP BY, OR, 集計関数(MAX, MIN)などはない
クエリにはインデックス必須で、インデックスがないと実行できない
- インデックス数の上限もある
エンティティ1MB制限
- 無限のスケーラビリティと思いきや、1つのエンティティは1MB以下
結果整合性
- 強い整合性のクエリが使える状況には制限があり、結果整合性のクエリを使うことになる
- データを書き込んで、即座にSELECTのクエリをして、書き込んだ結果が出るかというとそうではない
- AppEngineのゲストブックに書き込んでリロードするというチュートリアルがあるが結果整合性のせいで表示されないことがある
トランザクションに制限がある
- ACIDに対応しているが、最大で25EntityGroupまでしかトランザクションに参加できない
- EntityGroup : レコードをグループ分け出来る
- 最初から意識しないと後ほど動かないということに
マイグレーションが面倒
- 新しいプロパティを追加しても、既存のエンティティは自動では更新されない
- 過去のエンティティに増やしたい場合は古いレコードを引っ張っていれなおさないといけない
スナップショットが難しい
- 書き込みを停止してバックアップしないと、ちゃんとスナップショットにはならない
- 整合性を保ったままバックアップをとるには書き込みを停止させないといけない
まとめ
- SQL風のクエリがあるからといってRDBのように使えると勘違いして設計すると死ぬ

Treasure Dataのイケてない所

発表者：@shibacow様
TreasureDataとは
- 位取型ビックデータ集計、保存、集計、分析サービスを提供する
利用感想
- メンテナンスフリー
- 障害はほぼ起きない
  - 時々バッチがつまることはあった
- ログがなくなる・欠落することはない
集計レスポンスが遅すぎる
- 簡単な食えるで2~3分
- 複雑だと10分〜
- TreasureData query acceratorは高い
S3にダンプできるが、Table:Export機能が弱い
- Export先がus-east固定
- フォルダーが/database/table名固定
- Booleanがtable schemeではStringだが、jsonではboolean型で出力されるので、うまくロード出来ないことがあった
スキーマレスだからといってネストしすぎたjsonを勝手に入れてしまう
- 何故か中途半端に途中で文字列にされていたりする
fluentedでログを入れるれるので、タグで手軽にテーブル作れるからといってテーブル数がどんどん増えていく
- イベント事にテーブル作成はやり過ぎでは
- 似たようなテーブルが大量に作られる

Oracle Database

発表者：@wmo6hash様 (唯一のスーツ！)
- JPOUGの設立及びボードメンバーの一人です
Oracle ACE = Oracle’s Bitch?
- 釣りタイトルでTimが書いていた見解には同意
  - オラクルは高い、診断とチューニングパックはタダにしろなどなど
OracleはInfinity Dressみたいないもの
- ひとつのドレスで無限大の着方ができる
RDBMSとはよべない機能が多く形容しがたい
- PL/SQLはDB界のCOBOL
- 適しているかどうかはともかく、何でも使えてくれないと困る
20年も使っていると、なくなった機能が復活したり、自らが重宝している機能がなくなったりする
- 昔になくなった機能やフィックスしたはずの不具合への恒久的でない対応を元にして利用者が設計して延々と残ったり・・・
MOSの記事はOracleが著作権を有しています
※残念ながら時間切れで全部は聞けませんでした… 時間があれば後でお話お伺いしたかった…

BarkelyDB

発表者：@taroleo様
BarkelyDBはKVSがある前から存在している
- 埋込み型KVS
- トランザクション処理のコンポーネントが大杉
- フラグの組み合わせを間違えると動かない
- envを閉じ忘れるとDB壊れる
- BerkeleyDBのマニュアルはマニアックで、読むと専門家レベルになれる
2つのDBつかうとデッドロックの嵐
- DBへのアクセス順は合わせる！
- Layered 2PL Schedule = 自分で作れ
多次元インデックス？
- 複合キーの検索、UB-Tree？
- B+-tree上に構築
- しかしこれも自分で作る
最近のおはなし
- sqlite3のインターフェイス+BerkeleyDBのストレージ
- 使ったらソースコードは公開しろ
- 開発スタイルがかかん
- 充実したUpgradeガイド => 多すぎて追えない
- PostgreSQLに先を越された
研究
- XML DBを作ってみた
- 多次元インデックスで高速化
- 数万行近くコード書かされた

PostgreSQLについて若干

発表者：@hide_kaw様
文句1：近傍検索が遅い
cyclo-joinというアルゴリズムをやってみた
- Single vs, Cyclo-joinしたら3時間位みじかくなった
- postgresql終わらない・・・
R-treeはもっと遅い
文句2：選択下降がない
- 村田 postgresqlでぐぐって
Esper
- Norikaに採用されたストリーム処理システム
- Line, CAで使われているらしい
- しかし、遅い & 非並列化
まとめ
- PostgreSQL : 遅い
- Esper : 遅い
FPGAは超早い

GlusterFS masakari

GlusterFS Masakari Talks from Keisuke Takahashi

発表者：@keithseahus様
Recap: GlusterFSについて
- 分散ファイルシステムです
昔こんなバグが！
- self-healでtruncateわすれ　ファイル容量を減らす処理したのにファイルが減ってない
- symlink先が変わらない
- write-behindで無駄にパフォーマンス低下
- readdir中にF/Oするとクライアント側のプロセスがダウン
- windowsからNFSマウントした場合、ファイルを削除してもファイルが消えない
- fgidの衝突
- メモリリークいろいろ
技術関係者の証言
- NFSをCTDBでフェイルオーバーさせている時に書き込み中だと固まる
- レプリカ構成のボリュームにて片方brickサーバダウンさせると書き込みが30秒程度とまる
- シーケンシャルreadのスループット値はいい
- SSDの仲で高速な製品を選定する意味が無い
  - IOPSおよびスループット頭打ちになるため意味ない
- CentOS 7でのKVM統合には工夫が必要
  - OpenStackCinderとして導入する場合には注意
- マルチテナントは難しい
- リバランスが終わらない
個人的に思うこと
- self-healとリバランス頑張れ
まとめ
- 簡単に動くけど、考えることはいっぱいある

Database Masakari Talks Amazon S3

発表者：@shot6様
ツイート禁止なため詳細は載せられませんでしたが、S3への愛を感じる発表でした

the real world of kyoto tycoon

The real world of Kyoto Tycoon from SATOSHI TAGOMORI

発表者：@tagomoris様
Kyoto Tycoonとは
- kyoto cabinet + network rpc
  - Tokyo Tyrantの作り直しです
- KVS
- protocolがいろいろある
  - rpc, restful
  - 一部だけbinary protocol!
- Replicationサポート
  - master-slave
  - dual-master
Client Library
- swdyh/node-kyoto-tycoonはこわれていた
- wezm/kyoto-clientはコーヒースクリプトでかかれていて、自分でパッチ当ててアップロードしてつかわないといけない
- node.jsのバージョン上がって動かない
Database typeがありすぎ
- ForestDB使っていたが、ネットワークでバリュー突っ込むときにシリアライズしないといけないが、ネットワーク送るときにシリアライズ化でつまっていて、いくらDBが早くても意味なかった。protocolに問題あった
2年前にKyotoTycoon使うのやめたが最近やてみたら。。。
- 最後のコミットは2011-01-18 Release: 0.9.25 -> 修正記事によると 2012-05-01 Release : 0.9.56とのこと。いずれにせよ古いｗ
メンテナンスされてないのはつらいです

MongoDB

発表者：@repeatedly様
スライドなし！
メモリをどんどん食ってswap食って遅くなります
3.0からStorage Engineをふやす -> WiredTiger!!
- 7倍以上早くなっている
- でもストレージエンジンがよくデットロックするらしい
- JOIN対応！どこへいく・・・
mongoのbsonについて
- 昔はbsonobjbuilder.hというのが勝手にincludeするが、using namespace std;と書かれていて、c++の標準ライブラリがシンボルが全てincludeされるというクソ実装だった
fluentedはチャンクを送るが、mongoにはBson Documentには16megabyte制限がある
- 16Mbyteこえると勝手にきっておくってくれるというのがあったが、途中でエラーおこすと、半分だけインサートされたものが帰ってきたりすることがあった

AWS Storage Gateway よいとこつらいとこ (cached volumeについて)

発表者：@lamanotrama様
概要
- 特殊なAMIからS3のデータをiscsiのターゲットとして提供してくれる
- ここがいい
  - 最大32TBのブロックデバイス
  - S3とほぼ同じGB単価
  - 使った分だけ課金
    - キャパシティプランニングが楽
  - S3値と比べるとだいぶ早い
  - スナップショットが取れる
  - お手軽にDR
ここがつらい
- iscsiのターゲットがたまに見えなくなってきたりしてたまに落ちる
  - 年に数回落ちる
  - 原因がわからない。
  - 自動で復旧はしてくれない
  - ＼サポートもわからない！！！／
- 落ちるとファイルシステムがよく壊れる
- 落ちるとリードキャッシュが飛ぶ
  - 中のデータが使い物にならなくなったりする
  - キャッシュが消えるとrandom readが死ぬほど遅い
  - rsyncでの差分バックアップとかだと致命的
- キャッシュのあたたまる速度にムラがある
  - あるときは半日〜数日かかったりする
- 落ちた時のことを考えると32TB使いきるのは怖い
- オンラインでのローカルディスクのつけかえができない
- コストパフォーマンスの良いタイプのEBSにカジュアルなリプレイスが出来ない
- オフラインでも微妙だしキャッシュリセットされる
- 増設は可能
- スナップショット込みだと実は結構高くなる
まとめ
- データ量が多い
- 将来的な増加ベースが見積もりしにくい

夢のRDBMS Auroraさいこー！

発表者：@maroon1st様
aurora
- MySQL互換
- MySQLはNestedLoopJoindでJOINが可能
- 高速なフェイルオーバー
  - 既存RDSと同じフェイルオーバー方式
- ストレージの自動拡張
  - EBSはThinProvisioningのはず
- 既存のDBに比べて5倍高速
  - SysBenchの計測結果を公開している -> でもモデルは1テーブル。RDBの比較ではない
    - Transaction Processing Performance Councilつかうんじゃないのか・・・？
ここからTweet禁止のため詳細は載せられませんが実際に使ってみた感想などを述べられてました。
まとめ：さいこー！ -> さいこー？

AWS ElastiCache (Redis)

発表者：@suzryo様
概要
- aws提供のマネージドサービス
  - バックアップ
  - クラスタ管理
- データ永続性
  - スナップショットはS3を使用したバックアップ
スナップショット
- リソース消費
  - BGSave中、ノードメモリ圧迫する
  - リードレプリカからの取得推奨
- ファイル直アクセスはできない
AOFはデフォルトでは無効
- リブートするとデータロス
- ノード障害には無力
  - 出力先は多分エフェメラレウディスク
- リソース消費がほぼ2倍くらいつかう
クラスタ
- 去年の10月から児童フェイルオーバできるようになった
- 3〜5分で切り替え
- AOF設定は必須
- グラスタグループはGUIからやると全て削除される
インスタンス誓約
- cache.t2系インスタンスは制限刈り
セキュリティ
- パスワード認証なし
- セキュリティグループなし
CloudFormationは未対応項目多い
まとめ
- AOFは有効に
- redislabsを合わせて使いましょう

マイエス★キューエル

ほとんど資料内容の走り書きなので資料をご参照下さい。

DS masakari talks from yoku0825

発表者：@yoku0825様
1テーブル当たり1インデックス
基本NestedLoopJoin
クイックソートつかってます
BtachedKeyAccessは5.7でもデフォOFF
サンプリング8ページ
クエリーキャッシュ
ジャイアントロック
不正な文字列はとりあえずまとめる
utf8_unicode_ci を使うと、はは=ばば=ぱぱ同じ問題
暗黙の型変換を無効にできない
localhostと127.0.0.1がべつ
datetime_formatがいあつまでも飾り
- 5.7でdepricated
キモいINSERT構文が使える
perfomance schmemaメモリ食い過ぎ
innodb_read_onlyはcdromにあってもきどうできるらしいが誰得
xa recover出来ません
デフォルトautocommit on
ビュー、プロシージャのSQL
トリガーもDEFINER権限で動く
Inndb はRead-Unncommited
MyISAM++はmariaDBになりました
MySQL++
Oracle嫌われすぎ
MariaDBとディスり愛
Mysqlのゆりあｈo
MyNAたんとMariaNaはぎじんかされない
5.7になってもrollbackセグメントのクリアが面倒

HDFSのイケてない所

発表者：@uprush様
大規模になるとストレージコストお高い
- なんでも3レプリケーション保持する
イケてないロッキングの仕組み
- 全てのロックがGlobal RW Lockk
- Read Lock
  - 同時に複数の読み込み可能
  - ただし書き込みはブロックされる
  - write lock
- reducemapとかやるとすごい大変
  - 解決法はjobをころすしかない
namenode再起動に時間が掛かる
- 解決法は再起動しない
最もイケてないコード

    writeLock() {
        reportDiff()
        allTheHeavyProcess()
    }

writeLock() {

reportDiff()

allTheHeavyProcess()

}

突き合わせする前にロックかける

イケてないセーフモード

Google Cloud Datastore

発表者：@najeira様
CloudDatastore
- googleのビッグテーブルをお客様に公開しました
スケーラビリティの高いのでハマるポイントが多い
ここからtweet 禁止のため詳細は載せられませんが、実に興味深いデータを色々見せてくれました。
一番のハマリポイント
- Balancing Strong and Eventual Consistency with Google Cloud Datastore 参照
- indexが古くなるのはよく知られている
- 謎のグループ化をしないとstrong consistencyにならない

個人的まとめ

実に幅広いDatastoreの駄目なお話を聞けて楽しい日でした。

扱ってないところらへんはついてくのが必死だったところもあるので、（発表早いのでメモ必死というのもありますが）まだまだ勉強不足を感じるところでした。

最近Databaseまわりいじってないからたまにはいじって思い出さないとなぁ

もぐめぽろぐ

日々暮らしていく中での備忘録をつづっていく場所です