Deliver trusted data with dbt | dbt Labs
Explore FusionLearn more about Fusion, the next-generation dbt engine that’s powering a more responsive developer experience, cost efficiencies, and the future of analytics VS Code extensionThis free tool brings the full power of the dbt Fusion engine into your local environment with features like live error detection, lightning-fast parse times, insights and rich lineage all in VS Code or Cursor.
Materialize: Streaming SQL on Timely Data with Arjun Narayan and Frank McSherry - Software Engineering Daily
Materialize: Streaming SQL on Timely Data with Arjun Narayan and Frank McSherry Distributed stream processing frameworks are used to rapidly ingest and aggregate large volumes of incoming data. These frameworks often require the application developer to write imperative logic describing how that data should be processed. For example, a high volume of clickstream data that is getting buffered to Ka
`*sql.DB` を観察する #golang | Wantedly Engineer Blog
Photo by Abo Ngalonkulu on UnsplashPeople tribe / Backend squad の @izumin5210 です。もう12月ですね。自分は Advent Calendar に登録しすぎて後悔するのが得意です。 この記事は Go3 Advent Calendar 2019 の4日目です。 TL;DRSQL のメトリクス・トレースを収集したいは driver.Driver をラップするのが常套手段コネクション取得までの待ち時間まで見たい場合は、DBStats を見るのがよさそうことの発端Wantedly では Application Performance Monitoring に New Relic を利用しています。New Relic APM には様々な機能が存在しますが、例えばエンドポイントごとに「どの処理でどれくらいの時間がかかっているか
Goではどんなライブラリがデータベースにアクセスするときにベストか考える - ぷらすのブログ
この記事はGo5 Advent Calendar 2019の 1 日目の記事です。 はじめに Go のメジャーバージョンはいつの間にか 5 まで到達していたようですね、@p1assです。 Go でデータベースにアクセスするときに使うライブラリはdatabase/sqlや それをラップしたsqlx, gorm, gorpなど様々なライブラリがありますが、皆さんはどのライブラリを使っていますか？ おそらく様々な理由があってどれか(ここに挙げられていないものかもしれない)を使っているでしょう。 しかし、それは本当にベストな選択だったのでしょうか？ この記事では、Go でデータベースをアクセスする際に、どんな機能が必要かを考えつつ、上に挙げたのライブラリを比較していきます。 あくまでこの記事で述べるのは僕個人の意見ですが、この記事を通して皆さんが改めてライブラリ選定を考えるきっかけになれば幸いです
PartiQL :: PartiQL
PartiQL's extensions to SQL are easy to understand, treat nested data as first class citizens and compose seamlessly with each other and SQL. This enables intuitive filtering, joining and aggregation on the combination of structured, semistructured and nested datasets. PartiQL enables unified query access across multiple data stores and data formats by separating the syntax and semantics of a quer
Announcing PartiQL: One query language for all your data | Amazon Web Services
AWS Open Source Blog Announcing PartiQL: One query language for all your data Data is being gathered and created at rates unprecedented in history. Much of this data is intended to drive business outcomes but, according to the Harvard Business Review, “…on average, less than half of an organization’s structured data is actively used in making decisions…” The root of the problem is that data is typ
SQLアンチパターンもりもりDBを設計しよう！ - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 概要 名著SQLアンチパターンを読み終えたので、それの復習のために悍ましいデータベースを作ろうと思った。 まず前半では、SQLアンチパターンを意図的に盛り込み、目も当てられない酷い設計をします。 そのあとリファクタリングを行なったER図に書き直していきます。 なお、真面目に書くと参考書の丸写しになってしまうので、この記事は アンチパターンもりもりのER図を見て嫌悪感を学習し、設計に役立てようという趣向のもと、詳しい説明は省きます。 とても良い本なので読んでください。 想定するシステムの概要と状況 目的において適切かはわかりませんが、とり
6 Technical Challenges Developing a Distributed SQL Database | Yugabyte
You can join the discussion on HackerNews here. We crossed the three year mark of developing the YugabyteDB database in February of 2019. It has been a thrilling journey thus far, but not without its fair share of technical challenges. There were times when we had to go back to the drawing board and even sift through academic research to find a better solution than what we had at hand. In this pos
「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho
引き続き「SQLアンチパターン」について、自分なりのチェックポイントを言語化していきたいと思います。 「SQLアンチパターン」を避けるためのチェックリスト①（DB論理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト②（DB物理設計編） - log4ketancho 「SQLアンチパターン」を避けるためのチェックリスト③（SQLクエリ設計編） - log4ketancho 【本記事】 「SQLアンチパターン」を避けるためのチェックリスト④（アプリケーション設計編） - log4ketancho この記事では、SQL クエリを作成するときに抑えておきたい勘所について整理します。 SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入:
MySQLのクエリの良し悪しはrows_examinedで判断する - かみぽわーる
仕事やらなんやらでMySQLのクエリの良し悪しを判断する必要があるとき、EXPLAINの内容だけだとどのぐらい良くなったり悪くなったのか分からないので SET long_query_time = 0; してrows_examined (そのクエリでrows_sent行の結果を返すために何行に触ったのか)も一緒に提示するようにしている(少なくともMySQL 5.7時点ではrows_examinedはslow_query_logでしか確認できないはずperformance_schemaが有効ならevents_statements_historyやその仲間たちで確認できるとのこと*1 MySQL :: MySQL 5.6 リファレンスマニュアル :: 22.9.6 パフォーマンススキーマステートメントイベントテーブル)。 例: 上の例のBeforeは、もともとDBAが書いた温かみのあるSQLでO
Data Models
Data Models: A Comprehensive Guide to Structuring Information for Optimal Insights and Decision-Making In the realm of data management, the use of effective data models plays a pivotal role in organizing and representing information in a structured and meaningful way. Data models serve as the blueprint for databases, facilitating efficient data storage, retrieval, and analysis. This article delves
SQL アンチパターン （Bill Karwin,和田卓人,和田省二,児島修 オライリージャパン） - サポンテ 勉強ノート
SQLアンチパターン 作者:Bill KarwinオライリージャパンAmazon 免責 この本を読んだことがない人が、このノートから本の内容を脳内に展開することはできません。見出し部分は Amazon などで「目次」の内容として公開されている範囲にとどまります。 この本を買うかどうか悩んでいる人は是非購入しましょう。これは価値のある本です。 本の紹介 SQL つまり RDBMS を使ったアプリケーション開発や運用の中で遭遇する「アンチパターン」についてまとめられている本です。出版年を見ると歴史が古いことがわかりますが、Amazon で見ると最近も非常に人気があるロングセラーであることがわかります。読んでみると、それは確かに納得のいくものでした。 アンチパターン、つまり「やらない方がよい手法」を集めたものですが＿＿多くの人が共感してくれると思いますが＿＿よくやってしまう手法でもありました。な
Differences in SQL Statement
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
kamipo TRADITIONALでは防げないINSERT IGNOREという名の化け物 | おそらくはそれさえも平凡な日々
インスパイア元→kamipo traditional (というかSTRICT_ALL_TABLES) では防げないMyISAMという名の化け物 タイトルが全てです。ピンときた方は読み進む必要はありません。 データがなかったらINSERTして欲しいけど既に入っている場合には何もして欲しくないみたいな処理をするときに、 INSERT IGNORE を使ってしまうことがありますが、 INSERT IGNORE はユニークキー制約違反だけじゃなくて、あらゆるエラーをIGNOREしてしまいます。つまりkamipo TRADITIONALすらIGNOREしてしまうのです。なので使わないほうが安全です。 様子です。 mysql> SET SESSION sql_mode='TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BY'; Query OK, 0
RDB - 実例で学ぶ、JOIN (NLJ) が遅くなる理屈と対処法 - Qiita
"Nested Loop Joinしか取り上げて無いのにタイトルが大きすぎないか" と指摘を頂いたので、タイトルを修正しました。Merge JoinとHash Joinのことはまた今度書こうと思います。 「JOINは遅い」とよく言われます。特にRDBを使い始めて間がない内にそういう言説に触れた結果「JOIN=悪」という認識で固定化されてしまっている人も多いように感じています。 たしかに、JOINを含むようなSELECT文は、含まないものに比べて重たくなる傾向があることは事実です。また、本質的に問い合わせたい内容が複雑で、対処することが難しいものも存在します。しかし、RDBの中で一体どういうことが起きているのかを知り、それに基いて対処すれば高速化できることも少なくないと考えています。 本稿では、JOINの内部動作を解説した上で、Webサービスを作っているとよく出てくるJOIN SQLを例題に
ルーク！MySQLではkamipo TRADITIONALを使え！ | おそらくはそれさえも平凡な日々
よくMySQLはゆるふわだから 値が勝手に切り詰められる エラーが起きずに変な値/日付が入る 不正なスキーマが入ってしまう など言われることがあります。ただそれは、そもそもの設定が悪いのです。(確かに昔デフォルトがゆるふわなのはいけなかったんですが) ということで、データベースには不正な値が入らないように設定はとにかく厳しくしておくのがオススメです。 じゃあどうするか。 MySQLはSQL Modeによって、その辺りの制約をコントロールすることができます。以前、MySQLのsql-modeで一番厳しいやつはTRADITIONAL、というのを書いたのですが、実はそれだけでは不十分で、TRADITIONAL,NO_AUTO_VALUE_ON_ZERO,ONLY_FULL_GROUP_BYとするのがより安心なようです。 これはkamipoさんに教えてもらいました。 @songmu TRADITI
実行計画が解れば怖くない。SQL実践入門 - プログラマでありたい
技術評論社さんから、SQL実践入門を献本いただきました。ありがとうございます。 SQL実践入門の主題 この本の目的は、「パフォーマンスの良いSQLの書き方、特に大量データを処理するSQLの性能向上の方法を理解すること」とあります。そのパフォーマンス向上の為の解として、SQLが内部的にどう処理されているかを表す実行計画の読み解き方を、いろいろなケースを上げながらひたすら解説しています。そして、何故その実行計画になるのか、データ構造やDBの動きとともに説明しています。ということで、実行計画大事という基本かつ当たり前のことを、正面から取り扱っている良質のSQL本です。 SQL実践入門の構成 SQL実践入門の章立ては、下記の通りです。 第1章：DBMSのアーキテクチャ──この世にただ飯はあるか 第2章：SQLの基礎──母国語を話すがごとく 第3章：SQLにおける条件分岐──文から式へ 第4章：集約
トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる
こっちに移動 qiita.com
![トランザクション分離レベルについて極力分かりやすく解説してみた[SQL] - 明日になったら本気出せる](https://cdn-ak-scissors.b.st-hatena.com/image/square/865d91d3f7d8bc0ecea2db1b383f8dd9abc67ed5/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F12921228815712380847%2F12921228815712778346%2F1508923711)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サービス終了のお知らせ
#jpoug ハイパフォーマンスを実現する設計方法とSQLチューニング実践講座@JPOUG> SET EVENTS 20151017のまとめレポ - もぐめぽろぐ
