Hatena::ブログ(Diary)

wmo6hash::blog このページをアンテナに追加 RSSフィード Twitter

2018/09/22(Sat)

[][][]Oracle Databaseバージョン選択における考察'18 Oracle Databaseバージョン選択における考察'18を含むブックマーク Oracle Databaseバージョン選択における考察'18のブックマークコメント

2018年9月21日(金) 17:30 – 18:15 db tech showcase Tokyo 2018 A38:Oracle セッション内で「Oracle Databaseバージョン選択における考察'18」をお話しました。


当日用いたスライドから、内容に関わらないもの数枚を省き、内容に関わる1枚も省いたものを公開しました。



ポイント
  • 2018年に入って新たに得られた最新情報を振り返って
    Oracle Databaseに関連する現況をどのように捉えるか
  • 日々お会いしたり見聞きする様々な方々の戸惑いに寄り添って
    新旧リリースモデルをどのように捉えると誰かの理解が進むと考えているか
  • 囚われてはいけない過去の知識に決別して
    これからバージョンを選択するなら いつどんな基準を起点とするのが現実的か

*1


どなたかの yak shaving timeの削減や、わずかばかりでも なにかの応用元や吟味する材料となれば幸いです。


謝辞

会場に足を運んでいただいた みなさま、機会をくださった主催者のインサイトテクノロジーのみなさま、JPOUGのメンバー、そして同僚に感謝しています。*2

どうもありがとうございました。

*1:口上は、スライドに書かれた文字を読み上げたのではありません。むしろ口で話したのは「このスライドを表示しながらそんな話か!」が多かったかもしれません。

*2db tech showcase 2012でお話したときの様子をスクリーンに映したのですが、その際にお話を聴いてくださっていた方がいらっしゃったり、db tech showcase 2017で少し触れた PostgreSQL Foreign Data Wrapper for Oracle の開発者の方とお話できたり、とてもうれしかったです。

2018/04/13(Fri)

[]4月20日(金)の“エキスパートはどう考えるか?体感!パフォーマンスチューニング II” - Oracle Database Connect 2018 4月20日(金)の“エキスパートはどう考えるか?体感!パフォーマンスチューニング II” - Oracle Database Connect 2018を含むブックマーク 4月20日(金)の“エキスパートはどう考えるか?体感!パフォーマンスチューニング II” - Oracle Database Connect 2018のブックマークコメント

エキスパートはどう考えるか?体感!パフォーマンスチューニング II
〜Autonomous Databaseの到来において必要となるチューニングとは〜

パフォーマンス・チューニングはデータベース・エンジニアの腕の見せ所です。現場で発生したパフォーマンス問題に対して、データベース・エキスパートがどのように分析し、どのような対処策を適応するのか? ―― 会場の皆さんもご一緒に考えながら、エキスパートの思考プロセスを体感ください。


Japan Oracle User Group(JPOUG)

関口 裕士 氏

諸橋 渉 氏

渡部 亮太 氏

日本オラクル株式会社

Oracle Database Connect 2018 〜Autonomous Database がデータの価値を変える〜

Mac De Oracleの関口さん、わたし、コーソル DatabaseエンジニアのBlogの渡部さん、津島博士のパフォーマンス講座の津島博士、しばちょう先生の試して納得!DBAへの道の しばちょう先生の5人*1が、みなさんに私たちの“思考プロセス”を体感していただく試み II です。

2018/03/31(Sat)

[]MANABIYAで学んだことのよな落書き帳 MANABIYAで学んだことのよな落書き帳を含むブックマーク MANABIYAで学んだことのよな落書き帳のブックマークコメント

3月23日に 【国内最大級のエンジニア向け技術祭典】MANABIYA -teratail Developer Days-で聴講しました。

いずれも良いお話が聞けたと感謝しております。確かに学び舎でした。

「MANABIYAで学んだこと」を書きたくも、ほぼメモったことの書き起こしです。


f:id:wmo6hash:20180323200005j:image:w640


2時間目 インフラ
分散処理とコンテナ化インフラの面白い関係

用いられたスライド:MANABIYA.tech にいってきた&しゃべってきた - たごもりすメモ

このスライドが公開されることを事前にお聴きしており、それを見ただけでわかるようなことはメモしていません。発言を正確に反映したものではありませんし、ほんの一部です。

  • 本題の前の話
    • YAMLで書いたファイルはそのままでjarファイルのパス切り替えのデプロイだと、設定のみの変更がしにくい。それを再起動時に反映したいもののみDockerイメージにして、再起動で変更の反映ができる。
  • 本題
    • 今日の話は方向性や目指すべき点の話
  • モダンなシステムの共通点
    1. どのサーバーか意識せずにデプロイの頻度を高める
    2. プロセスを止めて変えて起動
    3. たとえば1プロセス30秒かかったら他で起動するとか特にクラウド事業者にとって都合の良い話
    4. ローカルファイルシステムを前提にせずネットワーク上の他のDBとかRESTで保存先を指定するのみとか
  • 分散処理の物語
    • ごく最近、OSSCassandraとかHDFS、YARN,Mesos,k8sとか出てきた。
    • 分散技術は昔からあるが、広く使われていなかった。
    • 最初はストレージ -> 処理 -> リソースの順で実装され、どんどんコンテナ化され使われるようになった。
    • どこで何をするかを考えないといけなくなる。
    • できるソフトウエアは使われる。
  • モダンなシステムでのデータの配置
    • Dockerでできるのはプロセスの分離
    • k8sはデータは含まれず、ストレージの課題は解決していない。
    • クラウドならRDSとかS3とか使っているはず。
    • Logging は fluentdとかを想定
    • ストレージのライフタイムは数年、SLAも高くないと。
    • じゃぁ何かは、答えがない。わからないから、工夫のしがいがある。
    • コミュニティに体験をシェアしましょう !

3時間目 DB
AI系技術の一般化でデータベースに求められること

用いられたスライド:DB改造屋雑記: MANABIYA でお話する資料

スライドを読むのみで理解できるように作られています。私が印象に残った言葉のみ。

  • 説明としてAIとは違う言葉があるはず。AIは未来にしかないのだから。
  • 研究者とモデルとリソースはあるが、精度の高いデータが必要なのが今。データのあてがないと、収集コストでお金が尽きる。
  • 「ないことをする」に意味がある。

4時間目 DB
CrossSession

ステージ上の4名のみでなく、会場内でお話された内容を聞き取りながら、雑にメモした内容です。発言を正確に反映したものではありませんし、ほんの一部です。

  • 30年後のDB
    • ハードウエアの進化に追随するものが出てくるだろう。NVMや1000 Core対応、PG-Stromとか。
    • MySQLないですよね。Oracle Databaseがあれば良いんじゃないですか。
    • MongoDBとかRedisとかはスーパーグローバル変数があれば良かったのかなと。
    • RDBMSではないデータストアとか。
    • 30年前を想像すると、今あるのは、これからもあるんじゃないの。
    • データの型が違う ? DBがなくなる ?
    • RDBMSが残るのかというと、集合が主ではなくなるかも。
    • トランザクションを人間が書くのは難しいよね。
    • 住み分けはどうなっていくか。
    • 複数からの更新が入らないならスケールするようになっている。
    • KVSは得意な領域が限られる。
    • お金がどこに流れるかによって変わるのかも。
    • 細分化されるだろう。
    • 間のインターフェースSQLなのが変わるかも ? SQLの次がないと変わらないんじゃ ? トランザクションのないデータストアにSQLかぶせるとか。
    • FDW ? PostgreSQLHUBとして NoSQLと連携。トランザクションは、受け取ったところで管理するが FDWでは難しい。
    • NoSQLトランザクション ? トランザクションがないから良いのに。
  • リファクタリング
    • DBは触りたくない。塩漬け。技術的負債になっているが。
    • バージョンアップ時のデータは、PostgreSQLは論理ダンプ取って入れ替えていく。
    • MySQL再帰テストありき。
    • 10年ぐらい使おうと思ったらコード読んだ方が速いよ。
    • DBは政治が大事。現状に不満が無ければバージョン上げなくて良いんでは。
    • MySQL 5.5より前はサポートしたくない。塩漬けにも限度がある。
    • OSのバージョンをあげるのと同じタイミングとかで良いのでは ?
    • 一番寿命が短いのがハードウエア
    • クラウドは事業者がソフトウエアのバージョンを上げる。
  • DBの選び方
    • この機能ないからダメ以外は、なんでもよいのでは ?
    • PostgreSQLだとParallel Queryとか FDWとか実装されてきているし。
    • MySQLの中で一番良さそうなのを選ぶ。InfiniDBとか。
    • 身近に助けてくれる人が多いものを選ぶのが良いかも。困った時に相談相手がいると、大怪我しにくい。
    • 良い点ばっかりだとアレなんで悪い話もちょっと。
      • MariaDB ColumnStore、InfiniDBだと、エラーメッセージの対応がキツイ。調べるとGitHubか自分のブログとか。
      • pgupgradeは良い評価を聴かない。PostgreSQLはバージョン違いのレプリケーションができない。PostgreSQLの拡張はメンテされなくなるときがあり、コミュニティがメンテしているものが良い。