タグ

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

タグの絞り込みを解除

sqlに関するclavierのブックマーク (287)

  • セマンティックレイヤー / Headless BIとは

    この記事は何 2023年、世間はLLMで大騒ぎですが、データの業界ではセマンティックレイヤー・Headless BIへの注目も高まっています。 これは、まだ国内では黎明期ともいえるそんな技術が、今後どんな存在となりうるのかを、筆者の個人的な解釈と妄想をもとに述べる長文ポエムです。 セマンティックレイヤーとは まず最初にセマンティックレイヤーについて解説します。 セマンティックレイヤーとは セマンティックレイヤーとは、データベースとデータ利用者の間に入り、両者間のやりとりを円滑にする存在です。 データ統合プラットフォームを提供するAirbyte社は、セマンティックレイヤーをデータとビジネスユーザーの中間に位置する、複雑なデータを理解可能なビジネスの概念に変換・翻訳するレイヤーと説明しています。 A semantic layer is a translation layer that sits

    セマンティックレイヤー / Headless BIとは
  • サブクエリの書き方を2万文字弱かけてすべて解説する

    これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ

    サブクエリの書き方を2万文字弱かけてすべて解説する
  • Pinterest社で運用されているText-to-SQLを理解する

    導入 こんにちは、株式会社ナレッジセンスの須藤英寿です。普段はエンジニアとして、LLMを使用したチャットのサービスを提供しており、とりわけRAGシステムの改善は日々の課題になっています。 記事では、Pinterest社のエンジニアチームが紹介していた、実運用環境におけるText-to-SQLの構築方法に関する記事の紹介をします。 Text-to-SQLを実際の運用レベルで実現するための手法が解説されているので、その内容を解説、そして考察していきたいと思います。 なおこの手法には特に名前などは設定されていなかったので、以降Pinterest社の提案するText-to-SQLPinterest Text-to-SQLと呼称します。 サマリー Pinterest Text-to-SQLは、RAGのシステムを最適化することで 検索に必要なTableのより正確な抽出 実際に使用されている値に準拠

    Pinterest社で運用されているText-to-SQLを理解する
  • AWS Glue × Apache Iceberg で構築する更新可能なデータレイクテーブル

    こんにちは。シンプルフォーム株式会社 にてインフラエンジニアをしています、山岸です。 社内向けに運用しているデータ分析基盤について現状抱えているいくつかの課題を克服すべく、最近は更改に向けた検証に取り組んでいます。今回は取り組みの一つである「AWS Glue と Apache Iceberg によるデータレイクテーブル構築」についてご紹介したいと思います。 概要 当社ではデータ分析基盤の ETL 処理に AWS Glue を使用しています。社内のデータ分析業務等のため、RDS データベース等のデータソースから日次で S3 上に構築された DWH に連携しています。 現行のデータ分析基盤では、DB テーブル上のデータを毎日全件洗い替えています。このような処理方法は ETL 実装や問題発生時の復旧が簡単である一方、ETL 処理のコスト効率が悪く、データ量の増加に伴って処理時間も長くなっていきま

    AWS Glue × Apache Iceberg で構築する更新可能なデータレイクテーブル
  • データ分析のためのSQLを書けるようになるために

    はじめに 稿では分析用クエリをスラスラ書けるようになるまでの勉強方法や書き方のコツをまとめてみました。具体的には、自分がクエリを書けるようになるまでに利用した教材と、普段クエリを書く際に意識していることを言語化しています。 想定読者として、SQLをガンガン書く予定の新卒のデータアナリスト/データサイエンティストを想定しています。 勉強方法 基礎の基礎をサッと座学で勉強してから、実践教材で実際にクエリを書くのが望ましいです。 実務で使える分析クエリを書けるようになるためには、実務経験を積むのが一番良いですが、だからといって座学を御座なりにして良いというわけではありません。SQLに自信がない人は、一度基礎に立ち返って文法の理解度を確認した方が良いと思います。 書籍 SQL 第2版: ゼロからはじめるデータベース操作 前提として、SQLに関する書籍の多くがデータベース運用/構築に関する書籍がほ

    データ分析のためのSQLを書けるようになるために
  • どのレイヤー(層)でトランザクションを実装すべきか

    このように、層ごとに関心事の分離を行うことで、保守性の高い(変更容易性や再利用性等)アプリケーションを実現できます。 しかし、「トランザクション」においてはどうでしょうか。 トランザクションはビジネス領域においても、技術領域においても関心事がある内容です。 そういう曖昧なものは「ひとまず usecase 層に入れてしまえ」という方針になりがちです。 ですが、DB 固有の知識を usecase 層の関心事にしてしまっては、関心事の分離をするメリットが得られません。 そのため、関心事の分離を実現しつつトランザクション実装をする方法を模索してみました。 前提 1. クリーンアーキテクチャを採用している(オニオンアーキテクチャやレイヤードアーキテクチャも含む) そもそもビジネス知識と技術知識を分離していないアーキテクチャを採用している場合、メリットは得られません。 そのため、オニオンアーキテクチャ

    どのレイヤー(層)でトランザクションを実装すべきか
  • dbtのDWHをRedshift(serverless)からSnowflakeに切り替えたときのおはなし|あきよん

    フリーランスでアナリティクスエンジニア的なお仕事をしています。 最近(2023年10月 ~ 12月頃)、データウェアハウスをRedshift (serverless)からSnowflakeに切り替える作業の一旦を担いました。 備忘録を兼ねて、私が担当したdbtに関連する切り替え作業の中で、印象に残った部分をいくつかご紹介したいと思います。 カラム名が小文字(Redshift)から大文字へ(Snowflake) Redshiftはカラム名が小文字、snowflakeはカラム名が大文字です。Snowflakeに移行する上で、これが一番苦労する要因になった違いでした。 ドキュメント(yamlファイル)を作成する際に、dbt-osmosisを使用しています。 ここではdbt-osmosisの詳細は述べませんが、DWHの内容から自動でドキュメントを作成してくれます。 新規で作成したものはドキュメント

    dbtのDWHをRedshift(serverless)からSnowflakeに切り替えたときのおはなし|あきよん
  • RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag

    PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134

    RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
  • The Querynomicon

    Upon first encountering SQL after two decades of Fortran, C, Java, and Python, I thought I had stumbled into hell. I quickly realized that was optimistic: after all, hell has rules. I have since realized that SQL does too, and that they are no more confusing or contradictory than those of most other programming languages. They only appear so because it draws on a tradition unfamiliar to those of u

  • PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳

    質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場

    PostgreSQLの仕組みから学ぶために必要な資料 - そーだいなるらくがき帳
  • 型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog

    SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre

    型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
  • 高効率なSQLクエリの書き方 - Qiita

    概要 この記事では、SQLクエリをより効率的に記述するためのベストプラクティスとテクニックに焦点を当てています。データベースのクエリはシステム全体のパフォーマンスに直結するため、最適な書き方を知ることは重要です。インデックスの効果的な活用方法、適切な結合の選択、そして条件の効果的な書き方など、SQLの最適化に関する具体的な手法を解説します。各SQL文に関する実行計画の結果も掲載していますので、ぜひご確認ください。 なお、Oracle19cとOracle12cでの利用実績がありますが、他のデータベースやバージョンにおいての検証は行っておりません。 新しい情報は随時追加されますので、お楽しみにしてください。 SQLの最適化に関連する基的なアイデア 以下の通りと考えています。 1.インデックスの利用 2.正しいJOINの選択 INNER JOIN、LEFT JOIN、RIGHT JOINなど、

    高効率なSQLクエリの書き方 - Qiita
  • DjangoのORMを触るあるSQLおじさんの悩み

    Deno に Web 標準 API を実装する / Implementing Web Standard API to Deno

    DjangoのORMを触るあるSQLおじさんの悩み
  • 実践Immutable Data Model - 紙箱

    ランキング参加中プログラミング はじめに この記事では、Immutable Data Modelと呼ばれる設計手法をもとに、リレーショナル・データベースにおける、テーブル設計の話を書いています。また、今回の実践で利用する、別の考え方の背景を理解するために、Out of the tar pitという小論文の内容にも言及します。 「状態とは何か?」というややこしい話がたくさん出てきますし、データベースのテーブル設計についての話であることから、たくさんのSQLが出てきます。なので、データモデリングとか状態管理とか、特にSQLとかに興味がない人には面白くないと思います。 そのあたりに興味ある方は、読んでみて欲しいです。 Immutable Data Modelを、実際のアプリケーションで使うデータベースに採用するにあたり、どういう考え方で、どのようにテーブルを構成したか、自分なりの経験を書いていま

    実践Immutable Data Model - 紙箱
  • 原因不明だったRDS負荷のスパイクを改善できた話 - Qiita

    概要 当時数ヶ月間誰も原因がわからなかった一時的にRDSの負荷(CPU使用率)がスパイクする現象の原因を調査できる環境を整えて、原因分析〜改善まで実施したときの話です。 1つ1つの取り組み自体は大きなことはやっていませんが、一連の動きで得られたものも多かったのでアウトプットしようと思い記事にまとめました。 取り組んだ課題 原因を特定するためのツールがない そもそも何が原因でRDSのCPU負荷が高まっているのかを調べるための情報がCPU使用率以外に全くない状況でした。 そこでRDSの負荷原因を探る方法を調べると、Performance InsightsやCloudWatch Logsへのスロークエリログ出力を使う記事をいくつか見つけたのでこの2つについて調べることにしました。 Performance Insights データベース負荷をSQLなどの単位で時系列で可視化したり、トップSQLやD

    原因不明だったRDS負荷のスパイクを改善できた話 - Qiita
  • dbtのテンプレートSQLをJinja2テンプレートで大量生成する話 〜クラシコム様での事例〜 - KAYAC engineers' blog

    この記事はdbt Advent Calendar 2023の5日目です。 こんにちは、その他事業部SREチーム所属の@mashiikeです。 カヤックは様々な事業・プロジェクトを展開しておりますが、その一つとして『北欧、暮らしの道具店』を運営する株式会社クラシコムとの協業プロジェクトがあります。 www.kayac.com こちらのプロジェクトでは2019年より継続して、クラシコム様のデータ基盤の構築・運用のサポートの一部を行っております。 その中で、troccoのdbt連携機能を用いて、データの変換を実装しております。1 今回の記事は、同プロジェクトの中で行われた一風変わったdbtの活用例の紹介になります。 内容の関係上、予めLookerの用語と概念を知っていると読みやすいと思います。 cloud.google.com 背景 クラシコム様のデータ分析基盤では、ビジネスインテリジェンスにL

    dbtのテンプレートSQLをJinja2テンプレートで大量生成する話 〜クラシコム様での事例〜 - KAYAC engineers' blog
  • AirflowでJinjaテンプレートを使ってSQLを実行する - 株式会社ライトコード

    こんにちは、普段は分析基盤や分析のお仕事をしている新田です。 この記事では、AirflowでJinjaテンプレートを活用したSQLクエリを動的に生成し、BigQueryでそのクエリを実行する方法をまとめます。 JinjaはPythonのテンプレートエンジンで、HTMLを動的に生成するために使われることが多いですが、SQLでも「大体同じなのに少し違うクエリ」が複数あるようなときに大活躍しますよ。 AirflowでJinjaテンプレートを使う方法AirflowはなんとデフォルトでJinjaテンプレートエンジンをサポートしています。 特に何もしなくてもDAGでJinjaのプレースホルダや変数をタスクのパラメータやクエリ内で直接使用することができます。 また、Operatorに引数を渡すことで渡した引数を埋め込むことができます。 SQLのテンプレートファイルを作成するまずは、SQLファイルを作成し

    AirflowでJinjaテンプレートを使ってSQLを実行する - 株式会社ライトコード
  • テンプレートエンジンを使ってSQLを書く環境を作ってみた | takemikami's note

    Web界隈ではaltjsやscssのファイル更新を監視して自動コンパイルするのが一般的になってきていると思いますが。 このエントリでは、そういった方法を真似て、SQLをテンプレートエンジンを利用して書いて、自動的に変換する環境を作ってみることにします。 データ界隈の人はpython使う人が多そうなので、pythonで以下のモジュールを使った環境を作ることにします。 ファイル監視はwatchdog テンプレートエンジンはmako エディタはatomでlanguage-atomプラグインを利用 watchdog: https://pypi.python.org/pypi/watchdog mako: http://www.makotemplates.org/ Mako 1.0.4 Documentation » Syntax: http://docs.makotemplates.org/en/

    テンプレートエンジンを使ってSQLを書く環境を作ってみた | takemikami's note
  • DB初心者が自作DBMS始めてみた - Qiita

    この記事は DeNA 24 新卒 Advent Calendar 2023 の 23 日目の記事です。 TL;DR DBMSの基的な仕組みを知るのに有益だったリソース CMUのDBMS講義 先人の素晴らしい自作DBMSの解説記事&ソースコードリーディング 小さな小さな自作DBMSの設計と実装 最小限SELECTやINSERTなど基的なSQLが動く この記事のゴール データベースの内部構成を超ざっくり理解するために有用なリソースを知り、そして(全開発者のロマンである)自作 DBMS に一歩踏み出すきっかけになればうれしいです。 モチベーション 自分は普段業務でアプリケーションのような割と高レイヤーな開発がメインなこともあって、ミドルウェアやOS、ネットワークと言った低めのレイヤーに憧れを持っており、この気持ちをまずは自作DBMSをやってみることによって解放してあげようと思ったことがきっか

    DB初心者が自作DBMS始めてみた - Qiita
  • xlsxファイルにSQLを実行するxlsxsql - Qiita

    xlsxファイルに対してSQLを実できるxlsxsqlというツールを作りました。 GitHubのxlsxsqlからダウンロードできます。 これは何? xlsxsqlは、xlsxファイルに対してSQLを実行するツールです。 また、CSV,LTSV,JSON,YAMLといったファイルに対してSQLを実行することもでき、その結果をxlsxファイルに出力することもできます。 trdsqlにxlsxファイルの読み書き機能を追加したものになります。 使い方 単純にファイルをテーブルとして指定できます。 -oまたは-outオプションは出力ファイル形式を指定します。 CSV, LTSV, JSON, JSONL, YAML, TBLN, AT, MD等が指定できます。

    xlsxファイルにSQLを実行するxlsxsql - Qiita