2016/08/26 CEDEC 2016
3. Copyright©2016 NTT corp. All Rights Reserved. トランザクションの基本 トランザクションとは: データに対する一連の操作を一つにまとめた単位の事 トランザクションマネージャとは: 複数のトランザクションがACIDを守って走るよ うに管理する機構 A: Atomicity 結果がAll-or-Nothingとなる事 C: Consistency 一貫性を守る事 I: Isolation 過程が他の処理から見えない事 D: Durability 結果が永続化される事 Consistentな状態空間 Inconsistentな状態空間 Diskが取りうる全ての状態の空間 Atomicな遷移 4. Copyright©2016 NTT corp. All Rights Reserved. 何らかの実行順(スケジュール空間) 直列に実行した場合の結果
7. ストレージエンジンによる テーブルスキャンの例 ha_tina::store_lock ha_tina::external_lock ha_tina::info ha_tina::rnd_init ha_tina::extra - ENUM HA_EXTRA_CACHE Cache record in HA_rrnd() ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::rnd_next ha_tina::extra - ENUM HA_EXTRA_NO_CACHE End caching of records (def) ha_t
DevLOVE X Day1 C-5のセッションです。 ITの活用範囲の広がりとともに、費用・品質よりもデリバリを優先するプロジェクトも増えてきました。しかし「しっかり考えるよりも、作ってリリースしちゃおうぜ、正解なんて誰にも分からないんだから」というマントラを唱えながら、返済見込みの立たない大量の技術的負債を抱える。それが最善の選択なのか、もう少しだけ立ち止まって考えてみませんか? YAGNIという言葉を便利に使いすぎてはいませんか? コードを書きなぐるのと、ちょっと考えて設計して作るのとで、そんなに開発スピードに違いがありますか? 考えてみたいと思います。 This document discusses messaging queues and platforms. It begins with an introduction to messaging queues and their
情報に取り囲まれた現代社会において、内部の不正アクセス事件が途絶えることはなく、価値ある情報が格納されているDBおよび関連する内部リソースに対して管理者の意思ひとつで容易にデータが持ち出せることは昨今の事件などから明白である。 マイナンバー法の施行や個人情報保護法改定を控え、企業における情報管理のあり方は、漏えい事件に法的な罰則が見えていることからも、今まさに見直しを迫られている。 DBSCではこれまでDB管理手法のガイドラインや、ログ管理・暗号化といった手法について提示してきたが、直近のDBAへのリサーチ結果から浮き彫りとなったのは、セキュアなDB管理が行き届いておらず、また管理者に対する管理が行き届いていないため、漏えいの事実を第三者(外部)から知らされるという現状とリンクしている。 上記法改正によりDB上の個人情報の取り扱いおよび漏えい時の対応は企業側に重い責任を要する。当WGでは管
オープンセミナー2015@香川の登壇資料です。 http://connpass.com/event/15646/
Googleドライブ上でFusion Tablesというデータベースが使えます。Google Apps Script(GAS)で制御できるのと、それを介してスプレッドシートと連携できるのでとても便利です。今回はFusion Tablesの導入から認証方法、GASからの制御方法(今回は簡単にSELECT文からの読み込みのみ)について書き留めておきます。Fusion Tablesの導入Google Drive上の「アプリの追加」からFusion Tablesを探して有効化します。登場してから数年経ちますがまだ(試験運用)のままですね。 有効化すると新規メニューに現れるのでクリックして起動し... いろいろアプリを導入できるらしいのですが、その中から、「Fusion Tables(試験運用)」を選びます。まだ試験運用みたいですね。 導入するとメニューに現れます。それをクリック。 以下の画面が現れ
MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。 PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。
2015/08/22 YAPC::Asia Tokyo 2015 Lightning Talk 2016/01/13 update about default_password_lifetime will be 0Read less
一応、立場的には第三者に戻った(MySQL/InnoDBの性能追求が仕事ではない)ので、忘れられない暗い過去にも触れてみようと思います。 未だに騙されている人が多いみたいなので、MySQL/InnoDBの名誉のために書き残さなければなりません。何度でも言いますが、性能比較は自分の目的とする処理をちゃんと比較しないとだめです。そうでなくては、騙されて本当は悪い性能のものを掴まされることになります。 DBT-2と言う(TPC-Cをベースにした)ベンチマークがありますが、数多のRDBMS(商用/OSS双方)に対して独自にTPC-Cベンチマークを実装・チューニングして比較した経験のある私から見て、怪しい結果しか出ないので、長年、基本無視のスタンスを取っています。 が、3年前にあろうことかMySQLの性能QAがDBT-2(nonsp:mysql)を利用していて、とある性能FIXに対して問題を指摘して
表題の通り、MyNAとJPUGの合同DB勉強会で発表をしたので資料を公開した。 内容の詳細はスライドそのものを見ていただくとして、言いたいことの主旨はこうである。世の中に完璧なデータモデルはないので、NoSQLは当然の如く必要になる。だが、何でもかんでもNoSQLを使えば良いというものではない。むしろアプリケーションが必要としているデータモデルが何かということをよく理解し、本当に必要な場合にこそ、NoSQLを使うべきなのである。つまり「ご利用は計画的に!」ということだ。 大切なのは、様々なデータモデルを理解し、アプリケーションにとってベストな製品を選択するということだ。ベストなのがRDBかも知れないし、そうでないかも知れない。最適なデータモデルを選択した場合に、出来上がったものの性能も最高になるし、開発効率も最も良くなる。データベースの主流はRDBだが、それはリレーショナルモデルがカバーで
「PostgreSQL」はエンタープライズでどこまで使える? ”SIエンジニア連合”が技術検証:Database Watch(2015年6月版)(1/2 ページ) 商用DBからPostgreSQLへの移行ノウハウを「普段は競合」に所属するITエンジニアらが合同で検証した成果は? 9.4での性能評価資料の他、移行プロセス検証なども。 2015年5月14日、PostgreSQLエンタープライズコンソーシアム(以下、PGEC)は毎年恒例となる活動成果発表会を行いました。今年で3回目の開催となり、活動成果としてまとめたノウハウも充実してきました。過去の活動成果報告は「PostgreSQLは80コアまでリニアに性能アップする」などで紹介した通りです。 もともとPGECには業務で商用RDBMSを使っていた企業が多く参加しています。商用RDBMSの機能や性能には満足していても、ライセンス費用の高さやベン
超おはようございます。最近めっきり暑くなってきましたね。城内です。 今回は、db tech showcase Tokyo 2015に参加してきましたので、セッションレポートを書きたいと思います。 セッション情報 セッション名:NoSQLの必要性と主要プロダクト比較 スピーカー:株式会社野村総合研究所 OpenStandiaチーム 渡部 徹太郎氏 スライド オープンソース サポート 保守 サービス(OSS サポート 保守 サービス)| OpenStandia™(オープンスタンディア) セッション内容 データを取り巻く環境の変化 データのボリュームが肥大化 →GoogleやFacebookの保持データがペタバイト級に データ処理の応答スピードが重要に →Webサイトのアクセス数が秒間10万アクセス データの多様性 →非構造データが増えてきているため、RDBMSでは格納が困難 RDBMSの現状
3/31付けで4月から国立研究開発法人になった産業技術総合研究所を退職致しまして、4/1からTreasure Dataに入社しました。第一号のResearch Engineerとして東京オフィスで働きます。 CTOの太田さんから2013年頃に一度お誘いを受けておりましたが、2014年になってまた声を掛けて頂き、2年越しでの入社となりました。 なんでTreasure Data? 現在のTreasure Dataでは、毎秒45万レコード、4,000億レコード/日ものデータが投入されていて、Hiveで処理されるデータ量も3+ペタバイト/日と急速な発展をとげております。研究でもこの規模のデータ量を扱うことはGoogleやFacebook等の一部の研究者を除いてはありませんから、非常に挑戦的な課題に取り組める環境であることにDB研究者として第一に魅力を感じました。優秀なエンジニアが集まっていて刺激的
今日朝イチで見たエントリーがこれでした。 qiita.com 論理削除の弊害は色々なところで言われているけど、僕の足りない頭で理解している所によると、二つの値しか持たない削除フラグ的なものはカーディナリティが云々で検索条件につけても性能上的にもよくないし、意味がないということです。 論理削除を完全に悪だとは言いませんが、論理削除を極力排したい人たちは、基本的にデータそのものを削除する、もしくは論理削除というのはまだ要件的に未確定な要素が隠されていることを示すフラグであると考えているようです。 僕がITの業界でキャリアをスタートしてから2年目くらいに配置されたプロジェクトではT字型ER手法というのをベースにしたテーブル設計をしていて、そこでかなり鍛えられたわけですが、その時にはだいたいこのような原則を叩きこまれました。 テーブルに状態を持たせない 究極には機械が認識するキーと、人間にとって意
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く