並び順

ブックマーク数

期間指定

  • から
  • まで

281 - 299 件 / 299件

新着順 人気順

mysqlの検索結果281 - 299 件 / 299件

  • やさしいActiveRecordのDB接続のしくみ

    https://kaigionrails.org/2023/talks/kubo/

      やさしいActiveRecordのDB接続のしくみ
    • Supabase | The Open Source Firebase Alternative

      Build in a weekendScale to millionsSupabase is an open source Firebase alternative. Start your project with a Postgres database, Authentication, instant APIs, Edge Functions, Realtime subscriptions, Storage, and Vector embeddings.

        Supabase | The Open Source Firebase Alternative
      • Amazon RDSからAuroraへ Mackerelのデータベース移行で何が改善したか - Hatena Developer Blog

        こんにちは、MackerelチームでSREをしている id:heleeen です。 2023年3月に実施したMackerelのメンテナンスでは、データベースをAmazon RDSからAmazon Auroraに移行しました。この記事ではAuroraを選択した背景や、移行で考慮したことについてお伝えします。 データベースのアップグレードを機に検討 Auroraへ移行することによるメリット パフォーマンスの改善 マイナーバージョンアップのダウンタイムが短く サイジングを適切にできリソース活用も効率的に リードレプリカの運用負荷も改善 Auroraのリードレプリカを利用した移行 RDSにAuroraのリードレプリカを作成する リードレプリカの昇格と切り替え 本番のAurora移行に向けて準備したこと 検証環境で移行して課題を確認 本番メンテナンス時のバックアッププランを用意 Mackerelのメ

          Amazon RDSからAuroraへ Mackerelのデータベース移行で何が改善したか - Hatena Developer Blog
        • GitLab令和最初のリプレイス。フルコンテナ化ポスグレ移行 - pixiv inside

          こんにちは、sue445です。 先日社内で使ってるGitLabのリプレイスをしたのでその辺の話をしたいと思います。 リプレイスの内容 今回のGitLabリプレイスでは主に下記を行いました。 サーバ移設に伴いURL以外全部変えた レガシーな環境で運用されていたGitLabを全てDockerコンテナに載せた MySQLからPostgreSQLに移行 以上を1時間弱のメンテでやりきった 構成 ざっくり書くと、SSL終端のフロントサーバのみ同じで、それ以外のバックエンドを全部変えました。 旧 APサーバ Debian Wheezy CPU: Intel Xeon E5-2640v2 * 2 Memory: 40GB Disk: 64G + 512G MySQL兼Redisサーバ Debian Wheezy CPU: Intel Xeon X3430 Memory: 8GB Disk: 256G M

            GitLab令和最初のリプレイス。フルコンテナ化ポスグレ移行 - pixiv inside
          • Webアプリケーションのパフォーマンス勉強会を開催しました! - ANDPAD Tech Blog

            はじめまして、サーバサイドエンジニアの立木です。 特定業種向けポータルサイトやスマートフォンゲーム開発などを経て、昨年3月に入社し、現在はANDPADの開発に従事しています。 アンドパッドでは、技術顧問をして頂いてる三谷(mita2)さんによる、データベースに関する勉強会が定期的に行われております。 tech.andpad.co.jp 先日もデータベースの観点から、Webアプリケーションのパフォーマンスをいかにして監視し、改善していくかという勉強会を開催していただきました。 今回はその勉強会について気になったポイントをまとめてみたいと思います。 当日の資料 概要 ANDPADの現状について分析 Datadogによる分析手法 よくある改善パターン 質疑応答 ANDPADの現状について分析 Webサイトのパフォーマンスは大事当たり前ですが、Webサイトにとってパフォーマンスはとても重要です。

              Webアプリケーションのパフォーマンス勉強会を開催しました! - ANDPAD Tech Blog
            • RDSのDBメンテナンスについて

              内容 らくがき記事、RDSでダウンタイムなしの24-365構成ってどうすればと思い書いている記事です。 とりあえずはRDSでメンテナンスやアップデート処理が走る時に、サービスダウンするのか否かを整理した資料となります。 RDS(MySQL)の整理 機能概要 最大 64 TiB のデータベースサイズをサポート 汎用インスタンスクラス、メモリ最適化インスタンスクラス、およびバースト可能パフォーマンスインスタンスクラスをサポート 自動バックアップとポイントインタイムリカバリをサポート。 単一のリージョン内または 5 つのリードレプリカのクロスリージョン内で、インスタンスごとに最大 15 個のリードレプリカをサポート 可用性と耐久性 3種類のオプションが選択可能 単一DBインスタンス スタンバイインスタンスのない単一の DB インスタンスを作成します。 マルチAZ DBインスタンス 別のアベイラビ

                RDSのDBメンテナンスについて
              • New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS | Amazon Web Services

                AWS News Blog New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS When updating databases, using a blue/green deployment technique is an appealing option for users to minimize risk and downtime. This method of making database updates requires two database environments—your current production environment, or blue environment, and a staging environment, or green environment. Y

                  New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS | Amazon Web Services
                • SQLチューニング_理論と改善の実例_/pgcon19j_t4

                  # SQLチューニング 理論と改善の実例 - 2019-11-15 開催のPostgreSQL Conference Japan 2019 の発表スライドです

                    SQLチューニング_理論と改善の実例_/pgcon19j_t4
                  • PostgreSQL: 「OR」を避けてパフォーマンスを向上させよう(翻訳)|TechRacho by BPS株式会社

                    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: avoid OR for better PostgreSQL query performance - Cybertec 原文公開日: 2018/05/07 著者: Laurenz Albe サイト: CYBERTEC -- データサイエンス分野でのPostgreSQLサポートやコンサルティングを行っている企業です ※挿絵は原著者自らによるものです。 生きるべきか『OR』死すべきか、それが問題だ」 「帰れ!」「非効率!」「同義反復!」 © Laurenz Albe 2018PostgreSQLクエリのチューニングは私たちCybertecの日常的な業務ですが、チューニング中にクエリにORを1つでも見つけた瞬間、恐ろしさに身の毛もよだつ思いがします。たいていの場合、ORはクエリのパフォーマンス低下の原因となるからです。 言うまでもないこ

                      PostgreSQL: 「OR」を避けてパフォーマンスを向上させよう(翻訳)|TechRacho by BPS株式会社
                    • データ基盤のメタデータを継続的に管理できる仕組みを作る - Hatena Developer Blog

                      こんにちは。MackerelチームでCRE(Customer Reliability Engineer)をしているid:syou6162です。 CREチームではカスタマーサクセスを進めるため、最近データ分析により力を入れています(参考1, 参考2)。データ分析を正確に行なうためには、データに関する正確な知識が必要です。今回はより正確なデータ分析を支えるためのメタデータを継続的に管理する仕組みについて書いてみます。 データに対する知識: メタデータ データ分析を正確に行なうためには、データ自身に関する知識(=メタデータ)が必要です。例えば、Mackerelのデータ分析タスクでは以下のような知識が必要とされることが多いです。 このテーブル / カラムは何のためのテーブルなのか 似たようなカラムとの違い 集計条件の違い、など データがどのような値を取り得るか SELECT column, COU

                        データ基盤のメタデータを継続的に管理できる仕組みを作る - Hatena Developer Blog
                      • 入門 B-link tree

                        概要 DBMS で広く利用されている B+ tree には様々な variant が存在するが、B-link tree もその1つ。 シンプルなラッチプロトコルで並行アクセスをさばけるよう、リーフノード以外のノードにも右の隣接ノードへのポインタを持たせた構造となっており、PostgreSQL で使われていることでも有名。 この記事では主にこの B-link tree に焦点を当てる。 B+ tree 全般やその他インデックス技術自体に興味がある場合は「最強DB講義 #10 いまどきのデータベース索引技術(石川佳治 教授)」の講義資料を読むのがおすすめ。 B-link tree 理解する上で必須な知識「ラッチ」 「ラッチ」というのはいわゆるロックのことだが、DB においては「ロック」というとトランザクション分離のための高価な(数千CPUサイクルを要する)処理を指すことが多く、「ラッチ」という

                          入門 B-link tree
                        • Django実践開発入門 - Qiita

                          この記事について Djangoを使用する際に実践開発に近いフローを簡単に再現します。 「Djangoを勉強しているけど、実務での開発はどうなっているでしょう」という方の参考になれば嬉しいです。 また本記事の内容は最善とは言えませんので、ぐれぐれもご容赦ください。 本記事の環境 python3.7.1 Django 2.1.5 PyCharm 先ずは設計から Explicit is better than implicit. 暗示するより明示するほうがいい。 --pythonの禅 何かを作る前に先ず頭にあるアイディアを具現化しましょう。 いかに簡単そうなものでも設計図があった方がいい。 特に会社のプロジェクト、制作途中、新しくメンバーが入ってくることがよくあります。 設計図があれば、プロジェクトを理解するための時間が短縮されます。 今回のデモは簡単なスクール学生管理システムと設定します モデ

                            Django実践開発入門 - Qiita
                          • InnoDBのすゝめ(仮)

                            InnoDBの特性など考慮しつつ、ゲーム向けのDBやSQLを設計する上でのヒントや、注意するポイントなどです。Read less

                              InnoDBのすゝめ(仮)
                            • 【Kubernetes】1週間かかる処理を1.5時間で終わらせた【並列処理】 - ニートの言葉

                              こんにちはあんどう(@t_andou)です。 今回はKubernetesを使って並列処理させた記録です。 まだ「とりあえずそれっぽく動くまで試してみた」という段階で、kubernetesを理解できてはいないので自分用のメモを公開しているという認識でご覧ください。 間違っている部分や、よりスマートなやり方がありましたらご指摘いただけると幸いです。 この記事の概要 機械学習に使う特徴量の作成で1週間かかりそうな処理を10分くらいで終わらせられないかと考え、GKE(=GoogleのKubernetes環境)を使い試行錯誤した記録です。 今回は一部失敗して完了時間が1.5時間になったものの、設定を上手く出来れば15分程度で終わる見込みです。 対象読者 ・Kubernetesの概要は知っているくらいのレベルの人 ・KubernetesのJobを使った並列処理をしたい人 目次 この記事の概要 対象読者

                                【Kubernetes】1週間かかる処理を1.5時間で終わらせた【並列処理】 - ニートの言葉
                              • Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog

                                こんにちは ハタ です。 Mirrativのインフラ内で実際に開発・運用している内製のRedisサーバについてお話したいなと思っています。 前回の記事 は、今回紹介する内製Redisサーバで起きたメモリリーク対策に関するお話しとなっておりますので、もし未読であればあわせて読んでいただければと思います。 今回はなぜ Redis サーバを内製することにしたのかの経緯や実装についての簡単な紹介が出来たらなと思っています Redis 導入の経緯 課題感: 揮発しないでほしい 課題感: 生存時間が短いデータを保持したい 課題感: 日次データをなんとかしたい 候補 Redis Cluster のヨシアシ: slot 管理 Dynomite のヨシアシ: sharding/replication radisha = Raft + Redis + HA Raft クラスタ コマンドとデータストア レプリケ

                                  Raft + Redis な内製Redisサーバの紹介 - Mirrativ Tech Blog
                                • DbGate | Open Source SQL+noSQL Database Client

                                  Free and open source Free to use for any purpose, source code available under MIT license Cross database Supports MySQL, PostgreSQL, MS SQL, MongoDB, SQLite and others

                                  • RDS Proxyが無意味になる恐怖の現象「ピン留め」を回避するための基本的な設定値について | DevelopersIO

                                    CX事業本部@大阪の岩田です。 RDS Proxyを利用するとRDS ProxyにプールされたDB接続を複数のDBクライアントで使い回すことができ、限られたDB接続を効率的に利用することが可能になります。しかし複数のDBクライアントが安全にDB接続を共有できない場合、RDSProxyはコネクションプール内のDB接続を特定のDBクライアントに対して固定してしまいます。これが「ピン留め」と呼ばれる現象で、このピン留めが発生するとRDS Proxyを利用するメリットが失われてしまいます。 このブログでは「ピン留め」を回避するための基本的なパラメータ調整についてご紹介します。 環境 今回利用した環境です こちらのブログとほぼ同様の設定にしてクライアントからの同時接続数が実質1に制限されるようにしています。 RDS for PostgreSQL 11.8-R1 インスタンスクラス db.t3.mic

                                      RDS Proxyが無意味になる恐怖の現象「ピン留め」を回避するための基本的な設定値について | DevelopersIO
                                    • クエリログを使ったPostgreSQLの負荷テスト - カンムテックブログ

                                      SREの菅原です。 この記事はカンム Advent Calendar 2022の4日目の記事になります。 少し前にサービスで使っているPostgreSQLをRDSからAuroraに移行しました。 Auroraに移行するため色々と作業を行ったのですが、その中でAuroraの性能を測るために行った負荷テストについて書きます。 pgbench まず最初にpgbenchを使って、単純なワークロードでのRDSをAuroraの性能差を測ってみました。*1 以下がその結果です。 MySQLで同様のテストをmysqlslapを使って行ったことがあって、そのときは概ねAuroraのほうが性能が高かったので、同様の結果になると考えていたのですが、RDSのほうが性能が高い結果になったのは予想外でした。 ただAuroraのアーキテクチャを考えると、pgbenchのような細かすぎるトランザクションの場合はRDSのほ

                                        クエリログを使ったPostgreSQLの負荷テスト - カンムテックブログ
                                      • Using Amazon RDS Proxy with AWS Lambda | Amazon Web Services

                                        AWS Compute Blog Using Amazon RDS Proxy with AWS Lambda Update – June 30, 2020: Amazon RDS Proxy support for MySQL and PostgreSQL is now generally available. Update – April 8, 2020: We have announced Postgres compatibility with the Amazon RDS Proxy. Version 10.11 and 11.5 are supported in the preview. The AWS Serverless platform allows you to build applications that automatically scale in response

                                          Using Amazon RDS Proxy with AWS Lambda | Amazon Web Services