タグ

databaseとprogrammingに関するnatu3kanのブックマーク (5)

  • 100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋

    要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事Java + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある

    100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
    natu3kan
    natu3kan 2020/08/13
    ドキュメントはだいたい救ってくれる>autoCommitがtrueになっている場合は、カーソルが使えないようです。
  • リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi

    リトライを肴に一晩酒が飲める古橋です。 大規模なデータに触れることが日常茶飯事になっている今日この頃。この分野のおもしろいところは、いつまで経っても終わらないプログラムを簡単に作れてしまうことかもしれません。エラー処理、リトライそして冪等性*1の3つを抑えていないプログラムは、小規模なデータなら問題ないが、データ量が多くなると使い物にならなくなる可能性が大です。 大規模データをバッチ処理するケース以外でも、リトライは一般にプログラムの信頼性に関わる重要な問題です。 そんなわけで、リトライに関わるいくつかのデザインパターンを、連載でまとめておこうと思います*2。 では、第1回は背景から: なぜリトライが必要なのか プログラムは色々な理由で失敗する。例えば、 A) 通信先のプログラムが高負荷すぎて応答できなかった B) メモリを消費しすぎてメモリ確保に失敗した。またはOOM KIllerに殺さ

    リトライと冪等性のデザインパターン - Blog by Sadayuki Furuhashi
  • 続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi

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

    続・リトライと冪等性のデザインパターン - リトライはいつ成功するか - Blog by Sadayuki Furuhashi
  • 続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi

    いつも心に冪等性。古橋です。 リトライと冪等性のデザインパターンの完結編です。 だいぶ間が空いてしまいましたが! 最後に冪等性を実装する汎用的な実装手法についてまとめていきます。 パターン6:操作ログとリクエストIDでUPDATEを冪等にする 同じIDで識別される値がUPDATEされる場合、つまりmutableである値の管理は、一般に冪等に行うのが難しい。 例えば、ユーザーごとに「最後に購入したアイテム」を更新する操作を考えてみると: 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する(UPDATE) 2. ユーザーAが最後に購入したアイテムをアイテム2に変更する(UPDATE) この操作に何の対策もなくリトライを実装した場合、後続のUPDATE処理の結果を古い内容で上書きしてしまう可能性がある: 1. ユーザーAが最後に購入したアイテムをアイテム1に変更する(UPDATE)→

    続々・リトライと冪等性のデザインパターン - あらゆる操作を冪等にする方法 - Blog by Sadayuki Furuhashi
  • 3値論理とNULL

    要するに、データベースにnullが1つでも含まれていれば、クエリから正しくない結果が返される可能性がある。しかも、一般的には、どのクエリから正しくない結果が返されるのかを知る方法はないので、すべての結果があやしく見えてくる。nullが含まれたデータベースから正しい結果が得られることは確信できない。筆者に言わせれば、この状況はまさにお手上げである。 ――――C.J.デイト はじめに 多くのプログラミング言語が、真理値型(BOOL型、BOOLEAN型)というデータ型を持っています。もちろん、SQLにも真理値型が存在します。ユーザーが直接扱えるデータ型として定義されたのはSQL-99ですが、WHERE句などの条件の評価時にも真理値の演算が行なわれています。 ところで、普通のプログラミング言語の真理値型とSQLの真理値型の違いをご存知でしょうか? それは、普通の言語の真理値型が、true、fals

    3値論理とNULL
  • 1