タグ

sqlに関するt_takataのブックマーク (7)

  • blog.katsuma.tv

    前回、JavaScriptMap Reduceのコードが書けるHadoop Streamingについて紹介しました。 標準入出力さえサポートされてあれば、任意のコードでMap Reduuceの処理が書ける、というものでしたが、エンジニアはそもそも面倒くさがり。コードも書くのも面倒です。 と、いうわけで、今回はもうコードすら書かずにSQLライクでMap ReduceできるHiveというプロダクトについて、まとめたいと思います。 Hive Hiveとは、簡単に言うとHadoop上で動作するRDBのようなものです。 HDFSなどの分散ファイルシステム上に存在するデータに対して、HiveQLというSQLライクな言語で操作できます。 で、面白いのがHiveQLの操作は基的にMap Reduceのラッパーになっていること。 要するに、SELECT文実行すると裏でMap&Reduceのタスクが走り出

  • pns.to

    t_takata
    t_takata 2009/10/22
    2.8.17でもサブクエリがまともに動かない。困った
  • 第4回 行か列か、それが問題だ~スカラサブクエリの使い方 (3)存在の階層 | gihyo.jp

    しかし、残念! このクエリは、My SQL以外ではエラーになります(My SQLの場合も、結果は図10のようにはなりません⁠)⁠。エラーになる理由は、item_nameが集約キー(GROUP BY句に指定される列)ではないからです。 誌Vol.44の「SQLアタマ養成講座」でも述べましたが、GROUP BY句を使用した場合、SELECT句に書ける要素は次の3つに制限されます。 定数 集約キー 集約関数 リスト5のクエリにおけるitem_nameは、このどれにも当てはまらないため、エラーになるわけです。では、なぜそもそもこの3種類以外の要素をSELECT句に記述することが許されないのでしょうか。 一言で言うと、これは存在の階層の差に起因するものです。GROUP BY句を使うということは、テーブルを小分けにして、文字通りいくつかのグループ(集合)を作るということです。そして、SQLにおいては

    第4回 行か列か、それが問題だ~スカラサブクエリの使い方 (3)存在の階層 | gihyo.jp
  • ウノウラボ Unoh Labs: RDBで階層構造を扱うには?

    yukiです。ダイエットを始めて3kg減ったと思ったら、風邪を引いて見事に1kg増量。 運動しないと駄目ですね。あと残り20kg、道のりは遠いです。 さて今回は、「RDBで階層構造を扱うには?」です。 あるサイトを構築中に階層構造をもったカテゴリ構造にすることになり、どのようにDBで扱うか悩みました。 DBMySQLを採用していたので、この時点でぱっと頭に浮かんだ選択肢は以下のようなものでした。 XML-DBを利用する 親カテゴリレコードのプライマリIDを子カテゴリレコードに持たせる 親を含めた『絶対パス』を名称として扱い、取り出した後にパース ファイルシステムに同様のディレクトリ構造を作り、毎回パースする (1)のXMLDBはオープンソースのeXistやXindice、Yggdrasillなど様々な選択肢がありましたが、カテゴリのみの利用な割にメンテナンスコストが高すぎるので見送りま

  • mysqlで自動更新されるtimestampをあえて更新しない

    世間でも言われていますが、mysqlのtimestamp型はいろいろバッドノウハウの固まりではないかと思います。 最近はできるだけdatetime型にするようにしているのですが、すでにtimestamp型依存で動いているコードがある場合、alter tableするのも難しかったりします。 10.3.1. DATETIME、DATE、そして TIMESTAMP タイプや10.3.1.1. TIMESTAMP MySQL 4.1での性質 (いずれもMySQLマニュアル)にも諸々書いてありますが、気になるポイントは以下のあたり。 各テーブルの最初に現れるtimestamp型カラムは、明示的に更新をしていないとUPDATE, REPLACEで現在時刻に自動更新される 各テーブルの二つ目以降のtimestamp型カラムは自動更新されない 扱える期間が1970年~2037年である (datetime型

    mysqlで自動更新されるtimestampをあえて更新しない
  • http://study.rakuto.net/php/sqlitetips/sqlalter/

  • postgresql パフォーマンスチューニング

    このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を PostgreSQL に許すことで改善される可能性が高い。ただし、扱っているデータベースが小さい時には大した効果は望めない。また、そもそもの実装メモリが 256M とか 128M という貧弱な状態では、調整の余地さえなく、単なる悪あがきだ。以下は搭載メモリ 1 ギガを目安に書いている。更に、テーブルの素性とクエリパターンによっては、テーブル自体のクラスタ化が加速を上乗せしてくれるかもしれない -- クラスタリングや適切なインデックスの作成は、メ

  • 1