タグ

DBに関するYaSuYuKiのブックマーク (86)

  • 削除フラグのはなし

    Query Optimization with MySQL 5.7 and MariaDB 10: Even newer tricksJaime Crespo

    削除フラグのはなし
    YaSuYuKi
    YaSuYuKi 2014/09/10
  • 分割と整合性と戦う

    え、まって。その並列分散処理、Kafkaのしくみでもできるの? Apache Kafkaの機能を利用した大規模ストリームデータの並列分散処理NTT DATA Technology & Innovation

    分割と整合性と戦う
    YaSuYuKi
    YaSuYuKi 2014/09/03
    XAトランザクション十分使えるのか
  • クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ

    インフラストラクチャー部の成田(@mirakui)です。 Rails の OR マッパーである ActiveRecord ですが、みなさんどのように運用していますか? ActiveRecord を使うと、 SQL を直接扱うことなく、抽象化された表現で RDB にアクセスできるので、アプリケーションの開発効率という観点ではメリットが大きいです。 一方で、 ActiveRecord が駆使されているアプリケーションをサーバに配置してプロダクションとして運用する立場からすると、いくつかの問題に突き当たります。 まずはクックパッド体アプリケーションにおける、最新の rake stats をご覧ください。 +----------------------+-------+-------+---------+---------+-----+-------+ | Name | Lines | LOC

    クックパッドにおける最近のActiveRecord運用事情 - クックパッド開発者ブログ
    YaSuYuKi
    YaSuYuKi 2014/08/29
    コネクションをプールしたくないということは、プールすることによるコスト削減よりプールのために失われる柔軟性の方が重いということか(実際そう書いてあるし)
  • フルパワーで加速するGPUの咆哮を聞け!最先端GPUでPostgreSQLを20倍高速化!?:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活

    GPUってあるだろ? グラフィックス・プロセッシング・ユニット。 コンピュータの中で最も高速な部品はなんといってもGPUだ。 たとえばnViditaの最新SoCであるTegra K1。 CPU部は単精度で73.6ギガFLOPS(フロップス)、だがGPU部は364.8ギガFLOPSだ。 これが30万円する最新のGPUボード、GeForce GTX TITAN Zになると、なんとびっくり、8テラFLOPSだ。 これはIntelの最高級IA-64チップ、Xeon ES-2687Wの198.4ギガFLOPSを大きく上回る。 Core i7は92ギガFLOPSに過ぎない。 ちなみにかつて数億円したスーパーコンピュータ、Cray-2はわずか1.9ギガFLOPSに過ぎず、今のコンピュータがどれだけ速いか窺い知れる。JAMSTECの地球シミュレータは131テラFLOPSだが、追いつかれるのは時間の問題だろ

    フルパワーで加速するGPUの咆哮を聞け!最先端GPUでPostgreSQLを20倍高速化!?:電脳ヒッチハイクガイド:電脳空間カウボーイズZZ(電脳空間カウボーイズ) - ニコニコチャンネル:生活
  • 続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi

    三度の飯よりエラー処理。古橋です。 大変好評をいただいた序章リトライと冪等性のデザインパターンの続編です。 前回はほぼ前置きでしたが、今回は冪等でない操作を冪等にする具体的なテクニックもまとめていきます。 パターン2:エラーを区別してDELETEを冪等にする リソースに常に一意なIDが振られていれば、Deleteを冪等にするのは難しくない。そもそも同じリソースを2度削除することはできない。 一つ注意するべきなのは、削除されたリソースのIDが再利用されるケースでは、Deleteの冪等性は保証されない。例えば、kill -KILL <pid> コマンドはDelete系のAPIと考えられるが、pidは再利用されるので、何度も繰り返すと意図しないプロセスを殺してしまう可能性がある。 一般にIDの生成は非常に難しい問題だが、Deleteに関してのみ言えば再利用されなければいいので、単調増加する整数(

    続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
    YaSuYuKi
    YaSuYuKi 2014/06/12
  • jOOQ: The easiest way to write SQL in Java

    jOOQ generates Java code from your database and lets you build type safe SQL queries through its fluent API. Start your free jOOQ trial now! Great Reasons for Using jOOQ Our customers spend most time on their business-logic. Because jOOQ takes care of all their Java/SQL infrastructure problems. Database First Tired of ORMs driving your database model? Whether you design a new application or integr

    jOOQ: The easiest way to write SQL in Java
  • LevelDB入門 (基本編) - from scratch

    さて、今回は比較的新しいデータストアであるLevelDBについてまとめてみました。 LevelDBは1年ほど前からNode.js界隈ではブームが来ていて、理由がよくわかっていなかったんですが、まとめている内に分かるかなと思ってまとめました。今回はNode.js無関係でLevelDBの基礎的なことだけ調査した結果をまとめてみました。 Node.jsで使ってみる話は後に回します。 LevelDBとは? key-value型のデータストアの一つです。 Googleの研究者である、Jeff DeanとSanjey Ghemawatが開発し、2011年に公表されました。C++で書かれており、多くのプログラミング言語でbindingsが書かれています。もちろん、JavaScript/Node.jsでも書かれています。 LevelDBGoogle のBigTableをベースにしたアーキテクチャを持

    LevelDB入門 (基本編) - from scratch
    YaSuYuKi
    YaSuYuKi 2014/05/05
  • YappoLogs: なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか

    なぜ SQL_CALC_FOUND_ROWS や LIMIT OFFSET のページングが良く無いのか ここ最近の大規模サービス関連したデータページング考です。 mysql 5.5.34 で試して記事書いてます。 bigdata テーブルは id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (id) なカラムがある前提です。もちろん InnoDB です。 2014年なんだからCOUNT(*)とかSQL_CALC_FOUND_ROWSとかLIMIT OFFSETのページングはやめようぜ - Togetterまとめが発端にみえるけど、わりと昔から話されてる事なんだけど、「nippondanji SQL_CALC_FOUND_ROWS」でググっても有用な情報ないし文書化されてないからしとく。 ページング処理で使われがちな機能です。 S

    YaSuYuKi
    YaSuYuKi 2014/03/12
  • TechCrunch | Startup and Technology News

    Services like Midjourney and ChatGPT have pushed the boundaries of how AI can create images and text out of basic text prompts. Now, audio appears to be the inevitable next frontier. Music generation

    TechCrunch | Startup and Technology News
  • SQLでエスケープなんてしたら負けかなと思ってる。 - めもおきば

    オレオレSQLセキュリティ教育は論理的に破綻している | yohgaki's blog 「プリペアードクエリが基だけど、動的に SQL を組み立てる場合もあるから、そういう場合に備えてエスケープも知っておいたほうがいいかも」 - Togetterまとめ SQLインジェクション対策で大垣靖男氏は何を勘違いしていたか | [ bROOM.LOG ! ] エスケープとプレースホルダをめぐる議論 - Togetterまとめ SQLインジェクション対策としてのプリペアドステートメントとエスケープについての議論 - Togetterまとめ IPAの「安全なSQLの呼び出し方」が安全になっていた | yohgaki's blog SQLへの安全な値の埋め込み方について、ここ数日で色々議論というか意見の投げ合いがありましたが、自分としての考えをまとめておきます。 1. SQLに値を埋め込む場合は、プリペ

    SQLでエスケープなんてしたら負けかなと思ってる。 - めもおきば
    YaSuYuKi
    YaSuYuKi 2013/12/12
    SQL Server2000にJDBC経由でクエリを発行しようとした時、「select top 1 * from a」の「1」をプレースホルダにしたらクエリがこけた
  • IDの設計についてのさらに突っ込んだ議論

    今日も前回に引き続きデータベース設計の話をする。今回の話で一旦データベース設計については筆を置くつもり(ブログ書いてないで原稿書けよ>俺)であるが、その前に話をすっきりさせて置きたいと思う。最後を飾るテーマはIDの設計である。 数字しかないのに意味を含んだID前回のエントリを見ていただいた方から、次のような構造を持った学籍番号があるというフィードバックを頂いた。 全部数値で"入学年度下2桁"+"学科コード"+"学科内のあいうえお順の順位" このようなルールで割り当てた学籍番号を、単なる数値として扱うのであれば大きな問題はない。これは数値しか含まれていないので、SQLのデータ型としては単に数値型を使えば良いだろう。だが、学籍番号から入学年度を判断する、あるいは学科を判断するといった用途で使われるのであればやはり適切ではないといえる。リレーショナルモデルの観点だけからではなく、IDとして適切で

    IDの設計についてのさらに突っ込んだ議論
    YaSuYuKi
    YaSuYuKi 2013/12/10
    一つ前のエントリで☆がたくさんついていたコメントは、この議論を先取りしたようなものが多かったな。/サロゲートキーが悪いのではなく、「代理」でない真のキーになるまで突き詰めないのが悪い
  • リレーショナルモデルのドメイン設計についての議論

    リレーショナルモデルを実践するには、ドメイン(≒データ型)を如何に正しく設計するかということが極めて重要になる。しかしながら、ドメインをどう設計すべきかという議論はあまりされていないように思う。その結果、ドメインについての理解はあまり進まず、データベース設計に失敗しているパターンが多いように思われる。 というわけで今日のテーマはドメインである。 集合を定義するリレーショナルモデルにおけるデータ型とは何か。リレーショナルモデルを実践するにはまずその点から理解する必要がある。 リレーショナルモデルでは、データ型はドメインと呼ばれる。ドメインとは、その属性(≒カラム)に入るべき値はどういったものかを集合として定義したものだ。言い換えると、属性値とはある集合の要素の一つであると言える。従って、ドメインを設計する際には、SQLで言うところのデータ型、つまりINTやCHARといったものだけでなく、その

    リレーショナルモデルのドメイン設計についての議論
    YaSuYuKi
    YaSuYuKi 2013/12/09
    ナチュラルキーをユニークキーとしない運用は、歴史的な理由でそうできない(キーとされていながら実はキーでない)場合以外ありえない/「ユーザーに見せるキー」はUIの一部なのでデータモデルに入れるべきではないよな
  • InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる

    この記事はMySQL Casual Advent Calendar 2013 3日目の記事です。 はじめに 以前にSELECT ... FOR UPDATEとロックの挙動 - walf443's blogの記事にTwitterで少し言及したんですが、それの補足というか、InnoDBのロックの範囲について僕はこう理解していますよという話です。 MySQLといえば、InnoDBをネットワークサーバとして使うためのフレームワークであり、SQLはInnoDBのインデックスにアクセスするためのDSLといっても過言ではないでしょう。 InnoDBのロックとはつまるところインデックス行のロックなので、InnoDBのロックの範囲を理解するためにInnoDBのインデックスについて少し前置きしておきます(だいぶ端折ったけど長くなった…)。 クラスタインデックスとセカンダリインデックス すでにInnoDBのイン

    InnoDBのロックの範囲とネクストキーロックの話 - かみぽわーる
    YaSuYuKi
    YaSuYuKi 2013/12/04
    SQL Serverだと、該当する目的の挙動は、分離レベルがSerializableの場合にしか起こらないようだ
  • SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?

    コードゴルフという競技があります。与えられた問題(例えばFizzBuzz)を解くコードを、いかに短いプログラムで実現できるかというものです。 脆弱性の世界でもXSS Golfというものは既にあるようで、我らが はせがわようすけ氏にも、「短いXSSの話」というプレゼン資料が公開されています。第2回のOWASP Japanローカルチャプターミーティングでの講演ですね。これ、面白いので、まだ見ていない方はぜひご覧になって下さい。 XSSがあるならSQLインジェクションはどうかということで、ちょっと考えてみました。この手の遊びは、問題のルールが命というというところはありますが、最初なのであまり厳密に考えずにだらだらとやってみます。 攻撃対象プログラム やはり、SQLインジェクション攻撃でみなさまおなじみの認証回避がよいのではないかと思いました。拙著「体系的に学ぶ 安全なWebアプリケーションの作り

    SQLインジェクションゴルフ - 認証回避の攻撃文字列はどこまで短くできるか?
  • エンジニアのための『仕事・職場・転職』応援サイト Tech総研

    ヘルプ リーダーインタビュー エンジニアあるある 仕事魂 最新技術 キャリアアップ 勉強会・イベント 技術豆知識 ビジネススキル 職場環境 会社訪問 人間関係 メンタルヘルス 給与・ボーナス 貯蓄・投資 採用全体動向 IT・Web系 モノづくり系 建築・土木系 IT・Web系 モノづくり系 転職体験談 職務経歴書・面接 健康 恋愛結婚・家庭 こだわりのアレ 指定されたURLは存在しません。 プライバシーポリシー ご利用にあたって お問い合わせ エンジニアライフ応援サイト Tech総研

    YaSuYuKi
    YaSuYuKi 2013/04/07
    トランザクション内でDDL発行できたり、意外とやってくれるんだよな、SQL Server
  • SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?

    OpenJDKのコミッタってどんなことしたらなったの?解決してきた技術課題の事例から見えてくる必要な知識と技術(JJUG CCC 2023 Spring)NTT DATA Technology & Innovation

    SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?
    YaSuYuKi
    YaSuYuKi 2012/12/07
    「例が単純すぎる」というのはプレゼンとして提示するのが無理だからなだけで本質的な指摘ではない。本当に、複雑なクエリーに応用できないの?/例はSQL文と直結する記述ばかりなので最適化もしやすそう
  • 開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!

    米国で行われているMySQL Connectというイベントで、ついにMySQL 5.6 RC(リリース候補版)が発表された。リリース候補版ということは、これが次の正式版になるということだ。MySQL 5.5は5.1から凄まじい進化を遂げたバージョンであった。だが、MySQL 5.6はさらにそれを上回る進化を遂げている!正直ここまでの進化を誰が予想しただろうか、いや誰も出来なかったであろう。これまで、α版が出たときから何度か新機能について紹介してきたが、今回改めてMySQL 5.6の新機能を振り返ってみようと思う。すべてまとめるともの凄い内容だ。興奮して夜も眠れなくなること請け合いだ。MySQLの進化が止まるのでは?などという心配は吹き飛び、もはやもうちょっと小出しにしなくて良かったのか?と心配してしまうレベルである。 それではMySQL 5.6の新機能について紹介していこう。 InnoDB

    開発スピードアクセル全開ぶっちぎり!日本よ、これがMySQL 5.6だッ!!
  • http://atnd.org/events/25146

    http://atnd.org/events/25146
    YaSuYuKi
    YaSuYuKi 2012/02/07
  • スケーリングMongoDB

    スケーラブルかつハイパフォーマンスなNoSQLデータベースであるMongoDBに関する書籍です。書では、アプリケーションが直面するデータの増大に対応するため、MongoDBクラスタを構築するための知識を紹介します。シャーディングによるMongoDBクラスタの構築方法、クラスタを効率よく用いるデータ構造の選択方法、監視やバックアップなどの管理方法までを解説します。書はEbook版のみの販売となります。 はじめに 書で使用されている表記規則 サンプルコードの利用について 書に関するお問い合わせ 1章 分散コンピューティングへようこそ! シャーディングとは何か 2章 シャーディング データの分割 バランシング configサーバー クラスタの構造 3章 クラスタのセットアップ シャードキーの選択 新規あるいは既存のコレクションのシャーディング 容量の追加・削除 4章 クラスタの扱い クエ

    スケーリングMongoDB
  • データベースの差分表示·DiffKit MOONGIFT

    DiffKitはデータベース/CSVファイル間の差分を抽出する。 [/s2If] DiffKitJava製のオープンソース・ソフトウェア。適切なデータベース管理を行っていない状態で運用を続けていると、いつの間にか開発環境と実行環境で構造の不一致がおこる。カラムの順番が違う程度ならいいが、なぜあるのか分からないカラムが出てきたりすると厄介だ。 データベースの構造不一致は様々な問題を引き起こす可能性がある。早めの対処が必要だ。そのためにはまず現状分析を行う必要があるだろう。手作業で行う必要はない、DiffKitを使えば容易に知ることができる。 DiffKitは二つのデータベース間における構造不一致を表示するためのツールだ。Diffツールのデータベース版ともいえる。特徴としてJDBCによるデータベース接続をサポートする他、CSVファイルにも対応していることが挙げられる。片方がCSV、片方がデー