並び順

ブックマーク数

期間指定

  • から
  • まで

521 - 560 件 / 1318件

新着順 人気順

SQLの検索結果521 - 560 件 / 1318件

  • Bizgram (ビズグラム) | ビジネスモデルデータベース

    Bizgram (ビズグラム) はビジネスモデルを図解で紹介するデータベースです。ビジネスモデル2.0図鑑を執筆した株式会社図解総研が運営しています。

      Bizgram (ビズグラム) | ビジネスモデルデータベース
    • [レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO

      さがらです。 11月8日20時~22時に、datatech-jp(データエンジニアリング関係のコミュニティ)主催でみんなの考えた最強のデータアーキテクチャというイベントが開催されました。 本記事はこのイベントのレポートブログとなります。 イベント概要 ※connpassより引用 datatech-jpで集ったデータエンジニアが、それぞれみんなの考えた最強のデータアーキテクチャを紹介し合うという夢のような企画が実現しました! たくさんの新しいプロダクトが群雄割拠する現在、モダンデータスタックなどという言葉も登場しています。 今こそ、どんなプロダクトを選び、どのようなデータ基盤を作れば、効率的にやりたいことが実現できるのか。 5人の猛者からおすすめの構成をご紹介いただきながら、参加者のみなさんとも一緒に考えていく時間としたいと思います。 おまけ:当イベントの応募者数 このイベントですが、なんと

        [レポート]みんなの考えた最強のデータアーキテクチャ #datatechjp | DevelopersIO
      • Gormにおける「仕様通り」なSQLインジェクションの恐れのある実装についての注意喚起 - ANDPAD Tech Blog

        ANDPADボードチームの原田(tomtwinkle)です。 Node.jsの mysqljs/mysql の仕様に起因するSQLインジェクションが話題に上がっていたので、それGolangのORMであるGormでも同じような「仕様」があるよ! という注意喚起の意味も込めて筆を執りました。 ※ 2022/02/21追記 コードレビューを自動化して指摘してもらう記事を公開しました! tech.andpad.co.jp Node.jsのMySQLパッケージにおけるエスケープ処理だけでは防げない「隠れた」SQLインジェクション | 株式会社Flatt Security TL;DR GormのQuery Conditions関数に関する危険な仕様 対策 締め TL;DR GormのConditions関数(Find, First, Delete...)を使用する際、第2引数の値にStringを引き渡

          Gormにおける「仕様通り」なSQLインジェクションの恐れのある実装についての注意喚起 - ANDPAD Tech Blog
        • 勘でリレーションを張っていないか? - Qiita

          はじめに 今回は外部キーを張るときに最低限意識したいことについて書きました。 何か間違えがあったり、もっとこういうところも意識してますという人がいたらコメントお願いします。 この記事で伝えたいこと ①リレーションシップ先のデータを消したときに同時にリレーションシップ元のデータが消えても自然な状態を作る ON DELETE CASCADEをうまく利用できる状態を作る つまり親子関係を正確に表現する。 リレーションシップ先は親テーブル、リレーションシップ元は子テーブルを意味しています。 ②データを作成するときのことを考えてデータの生成順序がおかしくならないように外部キーを張る ③関連を表現するときに中間テーブルを利用したほうが良い場面がある 注意 下記【例を交えながら説明】の説明に出てくるテーブル設計に関しては、上記の【この記事で伝えたいこと】の①と②と③の項目に対して想像しやすいように、理解

            勘でリレーションを張っていないか? - Qiita
          • 如何にデータベースが重要でなぜ私達が学ぶのか / Reasons for learning a database

            参考資料 - https://soudai.hatenablog.com/entry/2021/02/02/200104 - https://soudai.hatenablog.com/entry/2021/12/31/114009 - https://about.gitlab.com/blog/2017/02/01/gitlab-dot-com-database-incident/ - https://devblog.thebase.in/entry/bsucon - https://eh-career.com/engineerhub/entry/2018/12/11/110000 - https://speakerdeck.com/soudai/soudai-evolution

              如何にデータベースが重要でなぜ私達が学ぶのか / Reasons for learning a database
            • 無料の API 自動生成ツールを使って、Excelファイルから REST API を生成してみる:CData API Server - Morning Girl

              今月はじめに CData API Server というAPIの自動生成ツールで無料版・freeのライセンスがリリースされました! 今日はこの CData API Server を使ってExcel ファイルから REST API を生成する方法を解説したいと思います。(ちなみに機能的にはExcel だけでなく、MySQL などのRDBからもAPIの生成が可能です。というかそっちの方がメインです) ちなみに今回作ったAPIは以下の内容で公開しています。 O'Reilly Demo API ID:user Token:7y3E6q4b6V1v9f0D2m9j CData API Server って何? こんな REST API を生成するよ 実施手順 1. Excel データソースの接続設定を追加する 2. ExcelのシートをAPIリソースとして追加する 3. アクセス用のユーザーを追加する

                無料の API 自動生成ツールを使って、Excelファイルから REST API を生成してみる:CData API Server - Morning Girl
              • dbtで見やすいER図を生成する - yasuhisa's blog

                背景: dbtを使っていてもER図は欲しい! どうやってER図を生成するか どうやってER図を見やすくするか まとめ 背景: dbtを使っていてもER図は欲しい! dbtはモデル間のリネージなど可視化が得意なツールではありますが、万能なわけではありません。モデルの生成過程などはリネージで担保できますが、分析時に「どれとどのモデルがJOINできて、JOINする際のキーはこれを使って」というER図で扱うような可視化はディフォルトではできません。 DWHを作っている側からすると「このテーブルはあの辺のテーブルと一緒に使うと便利で、いつもあのキーでJOINして」というのが頭の中に入っていることが多いため、ER図がなくてもどうにかなることも多いでしょう。しかし、分析に慣れていない人や分析に慣れている人であっても、普段と異なるドメインのテーブルを触るときはER図が提供してくれる情報は有用です。ちなみに

                  dbtで見やすいER図を生成する - yasuhisa's blog
                • MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ?(N回目)

                  はじめに こんにちは、令和トラベルでバックエンドエンジニアをしている飯沼です。 MySQLでは、UUID (v4)などのランダム性の高いIDをプライマリキーに設定すると、パフォーマンスが低下すると言われています。私自身もこの問題については認識しておりアンチパターンとして避けて来ましたが、イマイチ理由を理解できず何度も調べていたので自分の理解を整理しました。 ※ この記事は令和トラベルのTech LT会で共有した内容を記事にしたものです。社外の方にもご参加いただけるTech LT会は connpass にて告知しています。 UUIDをプライマリキーにするユースケース そもそもUUIDをプライマリキーにするユースケースはどのようなものがあるのでしょうか? いくつかの観点から考えてみます。 パフォーマンス観点 大量の同時書き込みが発生するような状況でauto incrementを利用してIDを発

                    MySQLでUUIDv4をプライマリキーにするとパフォーマンス問題が起きるのはなぜ?(N回目)
                  • DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions

                    gotanda.rb#52@オンライン "DB外の副作用をトランザクションから分離しよう"

                      DB外の副作用をトランザクションから分離しよう / Isolate out-of-DB side effects from transactions
                    • はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog

                      この記事は、はてなエンジニア Advent Calendar 2023の2024年1月17日の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog id:hagihala です。先日、はてなブログの DB を RDS for MySQL 5.7 から 8.0 へアップグレードしたので、工夫した点などを共有します。 Aurora MySQL 3.x にしなかった理由 MySQL 5.7 -> 8.0 で対応した変更点 character set や collation のデフォルトが変更される explicit_defaults_for_timestamp がデフォルトで有効になる SQL mode の変更 デフォルトの認証プラグインが caching_sha2_password になり、 mysql_native_passw

                        はてなブログの DB を RDS for MySQL 8.0 にアップグレードした話 - Hatena Developer Blog
                      • Redisの25倍のスループットDragonflyを試してみる

                        インメモリデータストアを現代風に再実装したら? 高速なデータアクセスのためのインメモリデータストアとしては、RedisやMemcachedが有名です。ただし、これらは10年以上前に設計されており、Memcachedに至っては、2003年と約20年前です。 長い年月を経て、機能追加や最適化が進む一方で、どうしても設計の古さも目立ってきます。 その課題を解決すべく開発されたのがDragonfly です。 全ての操作がアトミック 高スループットでもミリ秒未満のスループット を目指し、Redis/Memcached互換なAPIを提供します。 Redisの25倍のスループットを誇り、1インスタンスで百万オーダーのQPSをさばけます。 開発者が実施したAWS EC2上のベンチマークによると、Dragonflyは本家RedisやRedisのマルチスレッドforkであるKeyDBよりも圧倒的なスループット

                          Redisの25倍のスループットDragonflyを試してみる
                        • オレ的EXPLAIN技を語っちゃうゾ - Qiita

                          メリークリスマス 本記事はPostgreSQL Advent Calendar 2021の25日目です。今年も面白い記事がたくさん揃いましたね!!! さて、みなさん今年のPostgreSQLライフはどんな感じでしたでしょうか? 私はというと、なんだかチューニングばっかりやってました。1案件でいろいろお手伝いすることはまあまああったのですが、複数から次々チューニングの相談をもらって、歴代継承者の個性を発現したデクくんのごとく駆け回ったのが今年のハイライトです。 (この綱渡り感、、、伝われ!!!) 俺たちは雰囲気でチューニングしている 今回上手くいったけど、あの時たまたまひらめいた1案をぶつけてみたら効果でたのであって、次善の策なんてなかったけど??って毎回思ってるから、雰囲気でやっていると思う、マジで。コミュニティのノリだと笑いが起きていいんですけど、少しでも勝率を上げるために、若手の前でド

                            オレ的EXPLAIN技を語っちゃうゾ - Qiita
                          • DMBOKを用いたアセスメントでデータマネジメントを加速させる - MonotaRO Tech Blog

                            こんにちは、データ基盤グループの吉田(id:syou6162)です。データ基盤やデータマネジメントに興味を持たれている方はDMBOKを持っている / 読んだことがあるという方も多いのではないでしょうか。このエントリではDMBOK中に紹介されているデータマネジメント成熟度アセスメント(以下、アセスメントと省略)をモノタロウでどう活用しているかについて紹介します。 背景 初手: 自社のデータ基盤の歴史を振り返る アセスメントの実施 データ活用者 / システム提供者 / 意思決定者へのヒアリングの実施 アセスメントを実施した結果 最後に 背景 まず、モノタロウでなぜアセスメントを行なったかについて説明します。モノタロウは20年以上歴史のある企業であり、データ基盤自体も10年以上の歴史があります。単一事業ではあるものの、受注 / 売上 / 商品 / 在庫 / 顧客 / 行動履歴など、対象となるドメ

                              DMBOKを用いたアセスメントでデータマネジメントを加速させる - MonotaRO Tech Blog
                            • 安全なウェブサイトの作り方~失敗例~ - goruchan’s blog

                              安全なウェブサイトの作り方を読んだので、理解した内容を自分なりにまとめておきます。資料 上記は3章構成になっていてそれぞれ長めの内容なので、ここでは3章の『失敗例』について、Ruby on Rails ではどうするかについてをまとめます。 SQL インジェクション OS コマンドインジェクション パス名パラメータの未チェック例(ディレクトリトラバーサル) 不適切なセッション管理例(セッション ID の推測) クロスサイト・スクリプティングの例(エスケープ処理) CSRFの例 HTTP ヘッダ・インジェクションの例 メールヘッダ・インジェクションの例 参考 SQL インジェクション 参考資料内の SQL インジェクション例を見て、Ruby on Rails ではどのように対策できるかを確認しました。 例えば、下記ような $uid, $pass をユーザ入力とし、SQL 文を動的に生成する場合

                                安全なウェブサイトの作り方~失敗例~ - goruchan’s blog
                              • BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場

                                BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場 Google Cloudは、BigQueryに対してMySQLやPostgreSQL、Oracle Databaseからニアリアルタイムで直接データのレプリケーションを可能にする新サービス「Datastream for BigQuery」をプレビューリリースしました。 オンプレミスやクラウドで稼働するMySQLやPostgreSQL、Oracle DatabaseでのOLTPによるデータ操作が、ETLツールなどを挟むことなくほぼリアルタイムでBigQueryに反映されるため、プライマリとなるデータベースのOLTP処理に負荷をかけることなく並行してBigQueryによる大規模データの分析処理が容易になります。 To stay compet

                                  BigQueryへMySQLやPostgreSQLから直接ニアリアルタイムでレプリケーション可能に。「Datastream for BigQuery」登場
                                • PayPayカード、メインフレームの基幹システムをAWSに移行--業界で前例なき規模

                                  PayPayカードは4月21日、メインフレームで運用していた基幹システムのインフラをAmazon Web Services(AWS)に移行して4月に本格稼働を開始したと同日開催の「AWS Summit Tokyo」で発表した。国内クレジットカード業界では前例のない規模といい、専務執行役員 最高技術責任者(CTO)の信太宏之氏がその舞台裏を語ってくれた。 同社は、1963年設立の国内信販を源流として楽天KC、KCカードと変遷し、現在はPayPayの完全子会社として「PayPayカード」ブランドのクレジットカード事業などを手掛ける。2022年3月に1000万会員を突破し、5500万の決済ユーザーを抱えるPayPayとの連携推進など事業拡大を図り、会員数の倍増を目指している。 2015年にソフトバンクグループとなってからビジネスが大きく変わり、「『ネット屋の金融を目指す』というトップのビジョンの

                                    PayPayカード、メインフレームの基幹システムをAWSに移行--業界で前例なき規模
                                  • 法令データベース

                                    日本研究のための歴史情報 法令データベース 本データベースについて 検索 全文 法令名のみ 法律 勅令 全て選択 全て解除 詳細検索 公布日 日付指定 範囲指定 年 月 日 〜 年 月 日 法令番号 年 第 号 検索 リセット

                                    • Active Recordともっと仲良くなって自然に優しいコードを書くぞ - SmartHR Tech Blog

                                      こんにちは。SmartHRでRails顧問業をしています @willnetです。最近は主にリファクタリングをしています。 SmartHRのバックエンドは基本的にRubyで書かれています。しかし入社してくるバックエンドエンジニアは必ずしもRubyやRailsを長年使ってきた人だけではなく、前職では他言語を使っていてRuby(Rails)はほとんど使ったことがないという人もいます。 webアプリケーションを作る、という点ではどの言語でも抑えるべき点は同じですが、RubyやRailsに特化した考え方や書き方もありますよね。SmartHRではそれを効率よく習得してもらうために読書会を開催したり、社内のドキュメントツールに知見を書いて共有したりしています。 僕も社内のドキュメントツールにActive Recordの付き合い方ついて書いたところ、評判が良く「テックブログにしたら?」と言われたので今回一

                                        Active Recordともっと仲良くなって自然に優しいコードを書くぞ - SmartHR Tech Blog
                                      • Aurora MySQL でレコードが存在するのに SELECT すると Empty set が返ってくる事象を調査した話

                                        こんにちは。 KINTO テクノロジーズの DBRE チーム所属のp2skです。 DBRE(Database Reliability Engineering)チームでは、横断組織としてデータベースに関する課題解決や、組織のアジリティとガバナンスのバランスを取るためのプラットフォーム開発などを行なっております。DBRE は比較的新しい概念で、DBRE という組織がある会社も少なく、あったとしても取り組んでいる内容や考え方が異なるような、発展途上の非常に面白い領域です。 弊社における DBRE の取り組み例としては、あわっち(@_awache)による DBRE ガードレール構想の実現に向けた取り組みについてというテックブログや、今年の AWS Summit の登壇内容を是非ご覧ください。 今回の記事は、データベースに関する課題解決の事例として「Aurora MySQL でレコードが存在するのに

                                        • ANAシステム障害の発端はDB両系ダウン、原因特定へ「書き込み処理を絞り込み中」

                                          全日本空輸(ANA)は2023年4月4日、4月3日午後に発生した旅客系基幹システム「able-D」の障害について記者会見を開いた。この中で同社は、障害の発端はable-Dに連なるデータベースが2系統同時にダウンしたことだと明らかにした。同社ではソフトウエアに何らかの原因があるとみて、引き続き原因の特定を進めている。 続報(2023年4月7日) ANAシステム障害の原因判明、DB並列参照時にパッチ未適用の既知バグでフリーズ ANAではable-Dについて、障害対策の観点で同一構成の「A系」「B系」の2系統を用意しており、本番系と待機系を定期的に入れ替えている。またA系、B系のそれぞれについて、「DB1」「DB2」という2系統のデータベースを接続しており、DB1とDB2は常にデータが同期されている。 今回のシステム障害が発生した4月3日の午後2時16分ごろ、本番運用中だったA系の基幹システムに

                                            ANAシステム障害の発端はDB両系ダウン、原因特定へ「書き込み処理を絞り込み中」
                                          • SQLite Internals: Pages & B-trees

                                            SQLite Internals: Pages & B-trees Author Name Ben Johnson @benbjohnson @benbjohnson Image by Annie Ruygt Fly.io runs apps close to users around the world, by taking containers and upgrading them to full-fledged virtual machines running on our own hardware around the world. Sometimes those containers run SQLite and we make that easy too. Give us a whirl and get up and running quickly. Ok, I’ll admi

                                              SQLite Internals: Pages & B-trees
                                            • はじめてのPostgreSQLモニタリング入門 / PostgreSQL 11 Monitoring

                                              多言語化対応における TypeScript の型定義を通して開発のしやすさについて考えた / TSKaigi TypeScript Multilingualization

                                                はじめてのPostgreSQLモニタリング入門 / PostgreSQL 11 Monitoring
                                              • SQLiteの正式なWebAssembly版「SQLite3 WASM/JS」が登場

                                                SQLiteの公式Webサイトに、SQLite3をWebAssembly化した「SQLite3 WASM/JS」プロジェクトのページが公開されました。 これまでさまざまなWebAssembly版SQLiteの試みが行われてきたなかで、初めてSQLiteの正式なサブプロジェクトとして開発されるWebAssembly版SQLiteになります。 下記はドキュメント「About the sqlite3 WASM/JS Subproject」からの引用です。 this subproject is the first effort "officially" associated with the SQLite project, created with the goal of making WASM builds of the library first-class members of the fa

                                                  SQLiteの正式なWebAssembly版「SQLite3 WASM/JS」が登場
                                                • MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス

                                                  はじめに MySQL(InnoDB)でSQLのパフォーマンスチューニングをするときに役に立つ知識をエッセンスとしてまとめました。結合(JOIN)やB-treeインデックスの探索の仕組み、実行計画の基本的な見方を紹介します。 想定する読者は、SQLのパフォーマンスを改善する必要があるが実行計画をみてもいまいちピンと来ない方です。インデックスの作成の経験や、複合インデックスやカーディナリティの知識があることを前提にしています。目標は、実行計画の内容がよく分からない読者が、実行計画をみただけでクエリが実行される様子をイメージでき、自信を持ってクエリの改善にあたることができるようにすることです。 ストレージエンジンはInnoDBを前提としています。また、インデックスはB-treeインデックスを想定しています。全文検索の転置インデックスや空間検索のR-treeインデックスについては触れません。 イン

                                                    MySQL(InnoDB)のSQLパフォーマンスチューニングのエッセンス
                                                  • 本当にあった Web アプリケーションの脆弱性

                                                    この記事の目的 今まで Web アプリケーション製作を行った経験が無い方が「ちょっと個人開発で何か作ってみようかな!」と思ったときにうっかり脆弱性を作りこんでしまうことを少しでも防げたらいいなと考えました。 そのためにはまず脆弱性を他人事だと考えないことが大事だと思ったので、私が過去の開発現場において実際に遭遇したことがある Web アプリケーションの脆弱性の事例を幾つか紹介します。 紹介の前に注意喚起をします。 自分が管理しているわけではない Web アプリケーションに対し、依頼されてもいないのに脆弱性を探す行為は絶対にしないでください。その行為の内容によっては犯罪になる可能性もあります。 外部から渡されたデータを何の対策もなしに SQL に埋め込んでいる SQL インジェクション攻撃の説明でよくみられる例ですが、ログイン処理でユーザーが入力した ID とパスワードに一致するユーザー情報

                                                      本当にあった Web アプリケーションの脆弱性
                                                    • 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
                                                      • explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ

                                                        はじめに こんにちは、バックエンドエンジニアのSakiです!バックエンドでPHPを書いたり、PHPという言語そのもののメンテナーもしています。 この度、注文データダウンロードAppのパフォーマンスをアップさせるため、とても入念にデータベースまわりの処理を見直しました。その中でも特に速度に関わってくる「index」についての考え方をまとめたいと思います。 この記事はMySQL(InnoDB)についての記事であり、他のRDBについては当てはまらない場合もあるということにご注意ください。 indexとは何か、おさらい ご存知の方ももちろん多いと思いますが、indexについておさらいさせてください。 indexとは辞書でいうところの目次に相当するもので、目的のデータをいち早く検索するために重要なものです。もし辞書に目次が存在しなかった場合、目的の情報を探すのにとても苦労するだろうというのは想像しや

                                                          explainだけじゃわからない!MySQLのindexの考え方 - BASEプロダクトチームブログ
                                                        • Cloud Native時代のデータベース

                                                          2021/6/11 #InfraStudy 2nd Season

                                                            Cloud Native時代のデータベース
                                                          • Aurora MySQL のバックアップは本当にそれでいいのだろうか? | CyberAgent Developers Blog

                                                            技術本部 サービスリライアビリティグループ(SRG)の長谷川 @rarirureluis です。 #SRG(Service Reliability Group)は、主に弊社メディアサービスのインフラ周りを横断的にサポートしており、既存サービスの改善や新規立ち上げ、OSS貢献などを行っているグループです。 また Amazon Aurora MySQL(以下:Aurora MySQL)の話です。何でこんなに Aurora MySQL に関する記事ばっか書いてるのか僕も分かりません。 前回の Aurora MySQL のアップグレード方法のベストプラクティスはこちらです。 RDS Graviton2 に少ないリスクで切り替える方法を考えてみる【アップグレード編】 | CyberAgent Developers Blog 今回はバックアップについてです。 そのクラスター、間違ったクエリ流したときに

                                                              Aurora MySQL のバックアップは本当にそれでいいのだろうか? | CyberAgent Developers Blog
                                                            • ChatGPT、Bingによるプロンプトの生成・変換(NyaFuさんバージョン)|BD

                                                              すっごいネタ来ました! この記事を読んでできるようになること ・プロンプトの自然言語←→羅列表記変換 ・適当な文章(日英問わず)のプロンプト化 ・作成したプロンプトのランダム生成 ・日本語での要約 ・プロンプトの微調整 まずは、こちらを読んでください! 間にJSON変換をかませるだとっ!? こんな面白いネタ、そりゃもうやっちゃいますよね。 てことで、半クローズな環境でNyaFuさんにすっごいGPTプロンプトを見せてもらったので、さっそくどんどんと手を入れてしまいました。(NyaFuさん、その節はすいませんでした) その後、快く了承いただけたので、今回はコラボ記事を書かせていただきます!みんなもNyaFuさん、フォローしようぜ! 仕組みと考え方についてはNyaFuさんの記事でしっかりと確認しておいてください。使い始めてから自分用にカスタマイズしやすくなります。 ChatGPT-4もしくはBi

                                                                ChatGPT、Bingによるプロンプトの生成・変換(NyaFuさんバージョン)|BD
                                                              • MySQLでIn句に大量の要素を渡すとまずい理由

                                                                概要 MySQLでIN句を使用する時はIN句に渡す要素数に注意する必要があるとよく先輩エンジニアの方から聞いていたのですが、実際に大量の要素を渡すと何がまずいのかはっきり分かっていなかったので調べてみました。 この記事で伝えたいこと MySQLでIn句に大量の要素を渡すとまずい理由 まずい状況を回避するために気をつけるべきポイント 先に結論 MySQLでIN句に大量の要素を渡すとインデックスを貼っていたカラムだとしてもフルスキャンが発生しスロークエリになる可能性があります。 フルスキャンが発生してしまう条件はテーブルに設定してあるインデックスの内容とrange_optimizer_max_mem_size の設定値に依存しており、MySQL8でデフォルトの設定値 & シンプルなテーブルであってもおおよそ数万件の要素数をIN句に渡すとフルスキャンが発生する可能性があると考えられます。 検証環

                                                                  MySQLでIn句に大量の要素を渡すとまずい理由
                                                                • NULL嫌いのUPDATEしないDB設計 #DBSekkeiNight / DB design without updating

                                                                  DB設計したいNight #6 正規化 [online] https://dbnight.connpass.com/event/177859/

                                                                    NULL嫌いのUPDATEしないDB設計 #DBSekkeiNight / DB design without updating
                                                                  • IPA DBスペシャリスト試験が秋に実施されると聞いたのでPostgreSQLと絡めて紹介してみる

                                                                    第17回 PostgreSQL アンカンファレンス@オンライン 2020/09/24

                                                                      IPA DBスペシャリスト試験が秋に実施されると聞いたのでPostgreSQLと絡めて紹介してみる
                                                                    • Railsでpumaやsidekiqのスレッド数とコネクションプールの数ってどうやって決めるんですか | 働くひとと組織の健康を創る iCARE

                                                                      この記事はiCARE Dev Advent Calendar 2022 第1レーン24日目の記事です。 Railsの基本原則の一つに「メニューはおまかせ」があり、デフォルトで設定を良い感じにしてくれています。しかし、本当に自分のユースケースでも問題ない設定だと自信を持って言うためには、なぜこの設定になっているのかの背景知識が必要になります。例えばrails newをするとpumaのスレッド数はデフォルト5、データベースのコネクションプール数も5になっています。これは自分のユースケースで適切な値なのでしょうか?どういうときにいくつに設定するのが正しいのでしょうか? pumaのスレッド数をどうやって決めるのか pumaはRailsのデフォルトのアプリケーションサーバであり、複数プロセス、複数スレッドで動くアプリケーションサーバです。この記事を執筆している時点で最も利用率の高いアプリケーションサ

                                                                        Railsでpumaやsidekiqのスレッド数とコネクションプールの数ってどうやって決めるんですか | 働くひとと組織の健康を創る iCARE
                                                                      • 5000万件越えのRDS大量データをFirestoreに移行する勘所 - ANDPAD Tech Blog

                                                                        はじめまして、開発部の@taikishiinoです。 2020年3月にアンドパッドにジョインし、約一年が経ちました。 現在、チャットサービスの開発・運用をするチームに所属しており、その中で最近、RDSからFirestoreへのデータ移行を行いました。 本記事では、その際の課題やそれに対して実際に行ったことなどを中心にご紹介していきます。 データ移行の背景 僕たちのチャットサービスを開発するチームでは、現在、プロダクトのデータベースをRDSとFirebase RealtimeDatabaseのミックスからFirestoreに移行する大規模プロジェクトが行われています。 旧環境「RDSとFirebase RealtimeDatabase」の課題として、 チャットのアクセスを処理しているAPIサーバーのバックグラウンド処理は複数プロダクト共通で利用しており、チャット起因で負荷が高まってしまうとい

                                                                          5000万件越えのRDS大量データをFirestoreに移行する勘所 - ANDPAD Tech Blog
                                                                        • 2024年版:データエンジニア向け推薦本リスト|zono

                                                                          世間ではデータエンジニアリングが流行しており、エンジニアからは人気が出て、企業からはその能力が求められています。 データエンジニアは、データの収集、蓄積、分析、活用に必要なデータ基盤を構築・運用する職種です。データエンジニアとして活躍するためには、非常に幅広い知識と能力が求められます。 データベース プログラミング システム開発 クラウドサービス データ分析 etc……. 私は多少データエンジニアとして経験を積んできており、業務を行う上で読んで良かったと心から思える本があったのでこちらで紹介します。どなたかの一助になれば幸いです。 初級向けデータエンジニアリング 本ではありませんが、データエンジニアリングに必要な知識がスライドやPDFに綺麗にまとまっています。初めて学ぶ方には適しています。後半はAzure製品について記載されているので、前半のデータエンジニアリングの箇所だけ参考にして下さい

                                                                            2024年版:データエンジニア向け推薦本リスト|zono
                                                                          • 保守性と生産性を両立する分析用SQL構造化の4原則 〜 構造化プログラミングの考え方をSQLに適用する

                                                                            ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!広告のデータマーケティングソリューション(以下、DMS)を開発しているデータアナリストの薄田です。 みなさんは、中間テーブル同士が複雑に絡み合い変更しようにも影響範囲を推定できず、手がつけられない分析パイプラインの保守で苦労された経験はないでしょうか? 私のチームでは数千行におよぶ分析用SQLをリファクタリングして、保守性と生産性を両立する分析パイプラインに生まれ変わらせることができました。 この記事ではリファクタリングを通して確立した、分析用SQLを構造化するための4原則を紹介します。4原則を意識しながらSQLを書くことで、高凝集・疎結合な分析パイプラインを作ることができます。 この記事では凝集度と結合度

                                                                              保守性と生産性を両立する分析用SQL構造化の4原則 〜 構造化プログラミングの考え方をSQLに適用する
                                                                            • ユーザー企業のOracle技術者が足りない、高まる技術的負債のリスク

                                                                              20年以上前に構築した古い基幹系システムを使い続けるユーザー企業が5社に1社の割合で存在するとされるなか、「枯れた技術」の維持管理に危機が迫っている。枯れた技術としてはCOBOLが有名だが、今回取り上げるのは別の技術だ。 リレーショナルデータベース(RDB)である。とりわけ最大シェアを誇る米オラクル(Oracle)の「Oracle Database(Oracle DB)」を扱える技術者が足りないとささやかれ始めている。 クラウドシフトとAI人気が原因? 「今まで1度も取引のないユーザー企業からOracle DBに障害が発生したといきなり連絡を受け、復旧作業を頼まれるケースが増えている」。こう証言するのはDBの導入や運用保守を専門とする、日本エクセムの後藤大介CEO(最高経営責任者)だ。 こうした依頼が増えた理由について、後藤CEOは「ユーザー企業が自社システムのクラウド移行を進めた結果、社

                                                                                ユーザー企業のOracle技術者が足りない、高まる技術的負債のリスク
                                                                              • 関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita

                                                                                大量のメソッドを保有し、数千、数万行単位にぶくぶく膨れ上がった巨大クラス。別名「神クラス」とも「大きな泥団子」とも呼ばれる、長大で複雑で、様々なクラスと密結合で極めて変更が困難なアイツ。 そんな巨大クラスの退治に有効な、命名に関する考え方を紹介致します。 解決したい課題、狙う効果 数千、数万行単位の巨大クラスの登場を抑止する。 巨大クラスを爆砕し、小さなクラス群に分割する。 クラス結合度を下げ、影響範囲を小さくすることで保守コストや変更コストを下げる。 ダメな例 例えばECサイトの「商品」を考えてみます。 よくありがちなのは、商品をそのまま「商品クラス」と設計してしまうこと。 単純な商品クラスは、往々にして出品、予約、注文、発送など、様々なユースケースのクラスと結合してしまいがちです。 商品クラス自体も、結合したクラスに関連する知識(ロジック)を持ち始め、どんどん巨大化複雑化していきます。

                                                                                  関心の分離を意識した名前設計で巨大クラスを爆殺する - Qiita
                                                                                • You Don't Need AWS ~お前にAWSは必要ない~

                                                                                  はじめに タイトルはこちらから拝借しました。この記事は他のパブリッククラウド(Azure, GCP)を薦める記事でもなければ、プライベートクラウドを薦める記事でもありません。また私自身、エンジニアキャリアの中でAWSはたくさん使ってきましたし、今でもソフトウェア開発のわがままに答えてくれる素晴らしいサービスだと思っているので、AWSを貶めるような記事でもありません。むしろ以下に紹介するサービスはAWS上に構築されていることが多く、間接的にもますます世界中の基盤として発展していくはずです。 PaaSアーキテクチャ 前提条件 前提として、現在でも主流なSPAを中心としたフロントエンド、バックエンド、データベースサービスからなるアプリケーションを想定します。 この場合、 フロントエンド → CDN + Static Hosting バックエンド → Container Deploy(Auto S

                                                                                    You Don't Need AWS ~お前にAWSは必要ない~