こんなに違うよ MySQLとPostgreSQL /2024年6月22日に開催された「第14回 関西DB勉強会 」での、 『こんなに違うよ MySQLとPostgreSQL ～MySQLとPostgreSQLのニッチな違いを語る～』 の発表資料です。 https://kansaidbstudy.connpass.com/event/316348/
検索が爆速になるデータベース設計を公開します
こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/
SQLを速くするぞ―お手軽パフォーマンス・チューニング
このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL 第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた
[OCI]Autonomous Databaseに関するよくある誤解と実際のところどうなのかをまとめてみた - Qiita
はじめに Autonomous Databaseに関して、古い情報に基づくよくある誤解と、現状は実際のところどうなのかをまとめてみました。 1. 文字コード（文字セット）がUTF8で固定されている 以前は文字コード（文字セット）がUTF8（AL32UTF8）で固定されていましたが、現在はAutonomous Databaseインスタンスの作成時にコンソールから文字セットを指定できるようになっています。 2. SYSDATE、SYSTIMESTAPの戻り値がUTCになる 以前は、SYSDATE、SYSTIMESTAMPの戻り値のタイムゾーンがUTCで固定となっていましたが、現在はALTER DATABASE文でデータベースのタイムゾーンを'+09:00'に変更し、新しく導入されたパラメータ「SYSDATE_AT_DBTIMEZONE」をTRUEにすることで、SYSDATEおよびSYSTIME
![[OCI]Autonomous Databaseに関するよくある誤解と実際のところどうなのかをまとめてみた - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3602977dd14d44d708125f10289ea8b12829d30d/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-9f5428127621718a910c8b63951390ad.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTkxNiZoPTMzNiZ0eHQ9JTVCT0NJJTVEQXV0b25vbW91cyUyMERhdGFiYXNlJUUzJTgxJUFCJUU5JTk2JUEyJUUzJTgxJTk5JUUzJTgyJThCJUUzJTgyJTg4JUUzJTgxJThGJUUzJTgxJTgyJUUzJTgyJThCJUU4JUFBJUE0JUU4JUE3JUEzJUUzJTgxJUE4JUU1JUFFJTlGJUU5JTlBJTlCJUUzJTgxJUFFJUUzJTgxJUE4JUUzJTgxJTkzJUUzJTgyJThEJUUzJTgxJUE5JUUzJTgxJTg2JUUzJTgxJUFBJUUzJTgxJUFFJUUzJTgxJThCJUUzJTgyJTkyJUUzJTgxJUJFJUUzJTgxJUE4JUUzJTgyJTgxJUUzJTgxJUE2JUUzJTgxJUJGJUUzJTgxJTlGJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LWNsaXA9ZWxsaXBzaXMmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz02MmRhYWU4ZTk1ZDhkYjg1MTQzYTliZWRmMWY1NWM4Mg%26mark-x%3D142%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTcxNiZ0eHQ9JTQwNTAwSW50ZXJuYWxTZXJ2ZXJFcnJvciUyMGluJTIwJUU2JTk3JUE1JUU2JTlDJUFDJUUzJTgyJUFBJUUzJTgzJUE5JUUzJTgyJUFGJUUzJTgzJUFCJUU2JUEwJUFBJUU1JUJDJThGJUU0JUJDJTlBJUU3JUE0JUJFJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzImdHh0LWFsaWduPWxlZnQlMkN0b3Amcz01MDU5ZDMyMmYyYWQ3ZjU2ZWE5Yzk3ZmUyYzlhNzA1Mw%26blend-x%3D142%26blend-y%3D491%26blend-mode%3Dnormal%26s%3Dde20312983e0926b45636d89b3a48033)
ドキュメントDBかリレーショナルDBどっち使う？ - Qiita
はじめに ドキュメントデータベースかリレーショナルデータベース、どちらを選ぶか。 この選択で、アプリケーションのパフォーマンス、コスト、コードの可読性など幅広い影響が出るため、慎重な判断が必要です。この記事では、自分が思う「考慮すべきポイント」を解説したいと思います。 考慮すべきポイント 1. どのデータモデルがアプリケーションコードに最適か スキーマ制約を課さずに、データレコードをドキュメント（つまりJSONオブジェクト）として保存すべきか？それともスキーマを正規化してデータをいくつかのテーブルに分けるべきか？ このような判断をするために、開発しているアプリケーションのモデルの関係性（例: UserとTaskの関係が1:N）と、一度に読み込むデータの種類を見た方がいいです。 ドキュメントDBがおすすめの時 アプリケーションのデータは、以下のような木構造で表現できますか？普段そのデータを一
自作DBを始めたい人におすすめの本 - salachike:blog
この記事は、慶應理工アドベントカレンダー2021の20日目の記事です。 カレンダー全日埋まってすごい 🎉🎉 adventar.org 「Database Design and Implementation」という簡素なDBをスクラッチで作っていく本に取り組んだので、その読了エントリです。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English Edition) 作者:Sciore, EdwardSpringerAmazon こんな人におすすめ MySQLやPostgreSQLを使った経験はあるが、DBの理論やその実装はあまり詳しくない人に特におすすめです。特に自作〇〇*1に興味がある人は間違いなく楽しめると思います。単純に本に紹介されている理論
データベースのクラウド化でDXを加速! アクアシステムズが解説する移行先選びのポイントとは
PR提供：日本オラクル データベースのクラウド化でDXを加速! アクアシステムズが解説する移行先選びのポイントとは 株式会社アクアシステムズは1998年に設立し、Oracle Databaseの性能監視、チューニング支援ツール「Performance Analyzer」「AUDIT MASTER」の提供でビジネスを開始した。同社は創業以来データベース領域で圧倒的な強みを持ち、データ基盤となるデータベースインフラの領域、データのモデリングや移行、データパイプライン設計など、データエンジニアリング領域のコンサルティングを得意とする。現在ではクラウドを含む主要なプラットフォーム、データベース全てを取り扱っていることも大きな特長となっている。 「AWSやAzure、Oracle Cloud Infrastructure（OCI）など、プラットフォームを問わず多数の構築経験があります」とアクアシステ
ゼロから作る時系列データベースエンジン
軽量な時系列データベースエンジンをスクラッチで開発する機会があったので、どのように実装したのかを必要知識の解説を交えながらまとめていきます。 実装はGo言語によるものですが、本記事のほとんどは言語非依存な内容となっています。 モチベーション 筆者は時系列データを扱うツールをいくつか開発しています。その中の一つであるAliは負荷テスト用のcliツールで、メトリクスをクライアント側でリアルタイム描画できるのが特徴です。リクエスト毎にレイテンシーなどの計測結果が際限なく書き込まれてくる中、同時に一定のクエリパフォーマンスが求められます。 これは言ってしまえば、簡易クエリ機能付きのpush型モニタリングシステムを単一ホストで実現するようなものです。 以前までの実装ではヒープ上の可変長配列にデータポイントを追加していくだけだったので、当然ながら時間の経過とともにメモリ使用量が増加していく問題を抱えて
75億ドキュメント以上のデータを保持するMongoDBを、Amazon EC2からMongoDB Atlasへ約3ヶ月で移設した方法 | CyberAgent Developers Blog
75億ドキュメント以上のデータを保持するMongoDBを、Amazon EC2からMongoDB Atlasへ約3ヶ月で移設した方法 はじめに タップル SREの赤野、CAM SREの庭木です。 タップルは2021年3月頃にMongoDB on Amazon EC2(以下EC2 MongoDB)からMongoDB Atlas(以下Atlas)への移設を行いました。 今回はこの移設での取り組みについて紹介します。 Atlasへ移設することになった経緯・目的 タップルでは定期的にキャパシティプランニングを目的とした負荷試験を実施しており、今後のDAU増加のシミュレーションに対してシステムのキャパシティが確保できるかを定期的に確認しています。 タップルSREのキャパシティプランニングの取り組みについては、以前発表させていただいた資料があるのでこちらにも目を通していただけると幸いです。 2020年
SQLite is not a toy database
English • Russian • Spanish Whether you are a developer, data analyst, QA engineer, DevOps person, or product manager - SQLite is a perfect tool for you. Here is why. A few well-known facts to get started: SQLite is the most common DBMS in the world, shipped with all popular operating systems.SQLite is serverless.For developers, SQLite is embedded directly into the app.For everyone else, there is
SQL Server / SQL Database パフォーマンスチューニング & トラブルシューティング シリーズ : SQL Server へのクエリ実行時の「コマンド タイムアウト」の挙動について at SE の雑記
本ブログでは、次の投稿で SQL Server へのクエリ実行時の「コマンド タイムアウト」(クエリ タイムアウト) について触れてみました。 SQL Server へのクエリ実行の「コマンドタイムアウト」の情報取得について考えてみる クエリストアによる、クエリタイムアウトしたクエリの取得 拡張イベントでコマンドタイムアウトが発生したクエリを取得する そもそも「コマンド タイムアウト」とは何なのでしょうか？ 上記の投稿では触れていなかった部分についてもまとめておきたいと思います。 コマンド タイムアウト は SQL Server の設定ではない アプリケーションから、クエリの実行時間が一定時間続いた場合、次のような例外が発生することが「コマンド タイムアウト 」となります。 Execution Timeout Expired. The timeout period elapsed pri
C言語でSQLiteのクローンを作るチュートリアルやった - valid,invalid
2019年12月の冬休みに1週間程かけて"Let's Build a Simple Database"という、C言語でSQLiteのクローンを作るチュートリアルをやりました。この存在を教えてくれた同僚に感謝 :pray: cstack.github.io チュートリアルの内容 Richard Feynman先生の“What I cannot create, I do not understand.”という言葉が掲げられているように、データベースを作ることでデータベースをより深く理解することに主眼が置かれているチュートリアルです。 これは重要事項説明かつタイトル詐欺に関する謝罪なのですが… 残念ながらこのチュートリアルは完成しておらず、Part 13が2017-11-26に公開されたのを最後に更新が止まってしまっており、以下の13章しかありません。 Part 1 - Introduction
実行計画についてのよくある誤解 ～Oracle Database版～ | コーソルDatabaseエンジニアのBlog
渡部です。OracleでSQLチューニングを行うには実行計画を理解する必要がありますが、 適切な説明が少ないこともあり、誤解している人をよく見ます。 過去のDatabase Lounge Tokyo #5発表 のスライドを下敷きにして、 Oracle Databaseの実行計画に関する「よくある誤解」を紹介しながら、実行計画について正しい理解ができるよう説明します。 SQLチューニングの省力化・自動化にはToadのSQL Optimizer for Oracle, SQL Optimizer for SQL ServerのSQLチューニング機能が有効です。Oracle Database Standard Edition 2におけるTuning Packの代替となりうるツールです。購入検討の際はコーソルまでぜひお声がけください！ https://cosol.jp/license/toad/
負荷テストデータ作成に関するTips — 指定率行の抽出・更新 —
JPOUG Advent Calendar 2019の13日目のエントリーです。 負荷テスト用データは件数が重要 最近、負荷テストの支援をすることが多いのですが、負荷テスト用のデータ準備にはいつも悩まされます。 経験から述べると、アプリケーション開発者にデータの準備をお願いすると大抵はうまく行かないことが多いです。 開発者はプログラムが仕様通り動くかどうかを確認する必要最小限のデータを準備することに関心はありますが、実際の業務を想定した量のデータを準備することはあまり考えていません。 また、本番環境の実データを使うにはセキュリティ上いろいろな制約があるため、機微な情報をマスク化する等の加工に時間がかかりただでさえ厳しいテスト工程を圧迫します。 結論から言うと、負荷テストでは値のリアルさよりも件数の妥当性の方が重要だと思います。 何年か前に参画したプロジェクトでは、アプリケーションの仕様を十
PostgreSQL 10 new features OSC hiroshima 2017
2. 自己紹介 篠田典良（しのだのりよし） – 所属 – 日本ヒューレット・パッカード株式会社 Pointnext事業統括 – 現在の業務 – PostgreSQLをはじめOracle Database, Microsoft SQL Server, Vertica, Sybase ASE等 RDBMS全般に関するシステムの設計、チューニング、コンサルティング – オープンソース製品に関する調査、検証 – Oracle Database関連書籍の執筆 – 弊社講習「Oracle DatabaseエンジニアのためのPostgreSQL入門」講師 – 関連する URL – 「PostgreSQL 虎の巻」シリーズ – https://community.hpe.com/t5/forums/searchpage/tab/message?q=%E8%99%8E%E3%81%AE% E5%B7%BB
RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！
「ユーザー目線」のシステムを目指して RDBが従来の階層型DBに比べて優れていた点はいくつか挙げることができますが、シェアを伸ばすうえで最も大きな影響は、ユーザーが使いやすいデータ構造とインタフェースにこだわったことです。すなわち、「テーブル」と「SQL」の発明です。 RDBでは、すべてのデータを「テーブル」というただ一つのデータ形式によって表現します。テーブルは、見た目が「二次元表」に似ているため*3、Microsoft ExcelやGoogle ドキュメントなどのスプレッドシートを使い慣れた人が見ると、データを格納する方法が直観的にイメージしやすいという利点があります。実際、こうした二次元表によるデータ管理は、Excelなどのソフトウェアが登場する前から一般的な方法だったため、RDBが登場した当時の人々にとっても受け入れやすいものでした。 テーブルが画期的だった点は、もう一つあります。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
履歴データテーブルとの向き合い方_PHPerKaigi2024
PostgreSQLとMySQLのメジャーバージョンアップのためのチートシート作った - そーだいなるらくがき帳
Oracle Database 最新情報(Oracle Cloudウェビナーシリーズ: 2020年6月25日)
OTN Japan マニュアル