Movatterモバイル変換


[0]ホーム

URL:


はてなブックマークアプリ

サクサク読めて、
アプリ限定の機能も多数!

アプリで開く

はてなブックマーク

タグ

関連タグで絞り込む (12)

タグの絞り込みを解除

SQLとpostgresqlに関するene0kcalのブックマーク (4)

  • 検索が爆速になるデータベース設計を公開します

    こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」(~約2万件) プランの情報「朝付き・ロングステイ△△プラン」(0~1500件/施設) 客室の情報(~100件/

    検索が爆速になるデータベース設計を公開します
    • 100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋

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

      100万件ぐらいのレコードを扱ったらOOMEが出た話。 - 谷本 心 in せろ部屋
      ene0kcal
      ene0kcal2020/08/13非公開
      「みんな大好きStack Overflow」なにげによく見るよねStack Overflow。AutoCommitがTrueの場合にOOMEかぁ。Cursor使えないとかFetchSize効かないとかそりゃハマるわ。
      • BdashというBIツールをリリースしました - hokaccha memo

        BdashというアプリケーションをElectronで作りました。 bdash-app/bdash: Asimple business intelligence application. 以下からダウンロードしてインストールできます(現状まだMac版だけ)。 https://github.com/bdash-app/bdash/releases ざっくりとこんな感じのことができる。SQLを書いて保存&実行できる 結果を元にグラフを書けるgistで共有できる 現状で対応しているデータソースはMySQL、PostgreSQL(Redshift含む)、BigQuery仕事でRedshiftを使って分析SQLを書くことが増えて、手元ではJupyterNotebookを使ってたんだけど、SQL書いてグラフを書くだけの用途には若干オーバースペックでもうちょっと簡単にできるといいなと思ったのがき

        BdashというBIツールをリリースしました - hokaccha memo
        • 新著が出ます:『SQL実践入門』 - ミックのブログ

          4月中旬ころになりますが、新著が出ます。SQLのパフォーマンスを主題にしたで、実行計画を読むことで、なぜこのSQLは遅いのか、あるいは速いのかをデータベースの内部動作まで把握して理解しよう、という趣旨です。 リレーショナルデータベースというのは、SQLという自然言語を模したインタフェースによって、低次のレイヤーを隠蔽する意図で作られたミドルウェアなので、当は実行計画などという手続レベルの世界をユーザが覗き見るのは、末転倒なところもあります。ただそうはいっても、現実にSQLが遅かったら原因を解析せざるをえないわけだし、大体当にブラックボックスにしたいなら、なんでどのDBMSも実行計画を見られる手段なんか用意してるんでしょうね不思議ですね、という理想と現実の狭間で悩むエンジニアの方々に少しでもベターな解に辿りつけるアプローチを提示できれば、と考えております。 以下まえがきと章立てです。

          新著が出ます:『SQL実践入門』 - ミックのブログ
          • 残りのブックマークを読み込んでいます1

          お知らせ

          公式Twitter

          • @HatenaBookmark

            リリース、障害情報などのサービスのお知らせ

          • @hatebu

            最新の人気エントリーの配信

          処理を実行中です

          キーボードショートカット一覧

          j次のブックマーク

          k前のブックマーク

          lあとで読む

          eコメント一覧を開く

          oページを開く

          はてなブックマーク

          公式Twitter

          はてなのサービス

          • App Storeからダウンロード
          • Google Playで手に入れよう
          Copyright © 2005-2025Hatena. All Rights Reserved.
          設定を変更しましたx

          [8]ページ先頭

          ©2009-2025 Movatter.jp