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

公開日: 

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

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

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

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

sponcer link

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

  • 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とのこと。いずれにせよ古いw
  • メンテナンスされてないのはつらいです

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のゆりあho
  • MyNAたんとMariaNaはぎじんかされない
  • 5.7になってもrollbackセグメントのクリアが面倒

HDFSのイケてない所

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

    • 突き合わせする前にロックかける
  • イケてないセーフモード

Google Cloud Datastore

  • 発表者:@najeira
  • CloudDatastore
    • googleのビッグテーブルをお客様に公開しました
  • スケーラビリティの高いのでハマるポイントが多い
  • ここからtweet 禁止のため詳細は載せられませんが、実に興味深いデータを色々見せてくれました。
  • 一番のハマリポイント

 

個人的まとめ

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

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

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

  • このエントリーをはてなブックマークに追加
  • Pocket
PAGE TOP ↑