でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。
SQLは滅ぶべきか｜ミック
でかい釣り針が来たので釣られてみる。とりあえず以下の資料を読んでいただきたい。そんなに長くないのでサクッと読める。 SQLの記述順序と思考の順序が違うので書きにくいし、エディタの補完機能の恩恵が受けられないのが嫌だ、という意見はもう大昔からある。何度も何度も何度も繰り返されてきた議論である。以下の2011年のスレッドでも「SQLはFROM句が最初に来るべきではないか？」という問いが提起されている。すぐに出てこないが、筆者はこれより古い文書も見た記憶がある。
CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
CockroachDB はどのくらい「しぶとい」のか？ / How tough is CockroachDB?
TSKaigi 2024 ref: https://tskaigi.org/talks/tockn
この記事はTSKaigi2024での以下の私の発表内容を書き下ろしたものです。 なぜAPIに型をつけたいのか 現代のWebのシステム開発において、クライアント・サーバーともに型のある言語で開発されることが増えてきました。静的な型検査はコードの堅牢性やよりよいメンテナンス性の向上をもたらします。 プログラミング内部だけで型検査をするだけでも十分メリットはありますが、外部I/Oに対する型付けが不十分だとそのメリットを最大限に発揮してるとは言えません。外部I/Oとは、例えばWebフロントエンドだとLocalStorageやDOMからの入力値、それからネットワーク通信（今回はこれをAPIと呼びます[1]）などですね。サーバー側でいうとAPIからの入力・レスポンスやデータベースへの読み書きが該当します。 個人的な経験から言うと、Webシステムの開発におけるエラーの多くはAPIやデータベースとのやり取
シンプルフォーム株式会社でインフラエンジニアをしている守屋です。 本記事では Aurora MySQL の OOM(メモリ不足)エラーについて、原因となるクエリを特定するために役立つ Tips を弊社での実例を交えてご紹介します。 発端 突如 Slack に鳴り響く不吉な通知。 「パターン青！障害です！！」 どうやら本番環境の Aurora クラスターがフェイルオーバーしてアプリケーションが DB コネクションエラーを引き起こした模様です。幸いインスタンスは冗長化していて Aurora のフェイルオーバーは高速であるため、ユーザー目線では瞬断が発生した程度の比較的影響が小さめな障害に留まりました。しかしインフラエンジニアとしては捨ておけない状況です！早速原因の調査を始めました。 フェイルオーバーの原因 結論から言うとメモリ使用量がスパイクして OOM エラーが発生したことが原因でした。根拠
Amazon RDS ブルー/グリーンデプロイを利用してMySQLのアップグレードをした話 - Pepabo Tech Portal
こんにちは。技術部プラットフォームグループのharukinです。 この記事では、私たちが提供するネットショップ作成・運用のためのECプラットフォーム「カラーミーショップ」のデータベースを、Amazon RDSのブルー/グリーンデプロイを利用し、MySQLのバージョン5.7.38から8.0.35へアップグレードした経験についてご紹介します。カラーミーショップにおいてはこれが初の試みでした。Amazon RDS固有のファーストタッチレイテンシーの解除方法や、ダウンタイム時間の計測についてもお伝えします。 Amazon RDSのブルー/グリーンデプロイを活用するメリットは、本番環境に準ずるステージング環境を構築し事前検証が可能であることです。ステージング環境は約1分で本番環境に昇格させることができ、昇格時に許容ダウンタイムを超えたり、レプリケーションやインスタンスの問題が生じた場合は、自動的にプ
pytest でテストケース毎に DB を自動的に初期化して、テスト開発体験を向上させる - SalesNow Tech Blog
概要 Web バックエンドのテストコードを書く場合、その多くは DB に依存していることが多いです。 DB 関連のテストは、テストデータの準備やテストケース毎の DB 処理化を適切に行うことが重要ですが、手間がかかる場合あるため、Mock で擬似的にテストしてしまうことも多いかと思います。 ただ、Mock を使ったテストは本質的な問題を検知できない意味のないテストになってしまう可能性があり、可能な限り DB の Mock を行わずに、実際の DB を使用してテストすることが望ましいと考えています。 本記事では、pytest、sqlalchemy、PostgreSQL を使った場合に、テストケース毎に DB を簡単に初期化しつつ、テストケース毎の前提データ登録も簡単うことでテスト開発体験を向上させる方法を紹介します。 前提環境 本記事では、以下の環境を前提として説明いたします。 python
SNSを通じた「ギブ&テイク型情報収集術」と、後悔しない技術選定を叶える方法【DBエンジニア｜こば】 レバテックラボ（レバテックLAB）
SNSを通じた「ギブ&テイク型情報収集術」と、後悔しない技術選定を叶える方法【DBエンジニア｜こば】 2024年5月8日 データベースエンジニア／DBソムリエ こば -Koba as a DB engineer-（@tzkb／小林隆浩） 基盤担当のエンジニアとして様々なプロジェクトで経験を積み、中でもデータベースに関する設計、運用、トラブルシューティング等を専門とする。得意とするDBMSはOracle DatabaseおよびPostgreSQL。オライリー社刊行・書籍「詳説 データベース」監訳者。itmediaにてクラウドネイティブなDBやNewSQLに関する連載を持つ。 X Zenn Qiita connpass SpeakerDeck 技術や業界など仕事についての情報収集の基盤として多くのエンジニアを支えていたTwitter（現X）が、以前とは異なる姿となってゆく今、必要な情報を過不足
導入 こんにちは、株式会社ナレッジセンスの須藤英寿です。普段はエンジニアとして、LLMを使用したチャットのサービスを提供しており、とりわけRAGシステムの改善は日々の課題になっています。 本記事では、Pinterest社のエンジニアチームが紹介していた、実運用環境におけるText-to-SQLの構築方法に関する記事の紹介をします。 Text-to-SQLを実際の運用レベルで実現するための手法が解説されているので、その内容を解説、そして考察していきたいと思います。 なおこの手法には特に名前などは設定されていなかったので、以降Pinterest社の提案するText-to-SQLをPinterest Text-to-SQLと呼称します。 サマリー Pinterest Text-to-SQLは、RAGのシステムを最適化することで 検索に必要なTableのより正確な抽出 実際に使用されている値に準拠
Oracle Cloud Hangout Cafe Season8 #4
本記事は最近読んだ次の記事からインスピレーションを得ました。 RのdplyrやPythonのpolarsのようなパッケージでデータフレームの操作に慣れている人ならば、Rのdbplyrを使うことで、バグが少ない上に早くサブクエリを構築することができます。 何千回も実行するSQLならば時間をかけてチューニングされたSQLを構築したほうがよいと思いますが、分析の試行錯誤のサイクルを早く回したい場合など数十回ぐらいしか実行しないSQLならば、dbplyrから実行したほうがよいでしょう。 それではざっくり元記事に沿って例を説明します。 カラムのサブクエリ 大分類（major_category）で絞って、該当する作品を表示する例をお借りします。 まず素直にms_categoriesテーブルから該当するcategory_idを抜き出しておいて、%in%で求めると、 category_id_fiction
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Prisma ORMを2年運用して培ったノウハウを共有する
TypeScriptとGraphQLで実現する型安全なAPI実装
Aurora MySQLのメモリ不足の原因を特定する
Pinterest社で運用されているText-to-SQLを理解する
NewSQL Landscape
米Oracle、「Oracle Database 23ai」クラウド版を提供開始 AIを意識して名称を変更
Rのdbplyrでサブクエリを構築すると分かりやすい