最近勉強を始めたコンテナ技術に関する基礎的な知識をまとめました。 [訂正と注釈] p.27-30: 「Deployment」内の「Version: 1」 => 「Version: 2」 p.37: 「終了コードをから」 => 「終了コードから」 p.39: 「HTTPSが利用できない」=> AWS上では、SSL終端するLBがサポートされています。https://kubernetes.io/docs/concepts/services-networking/service/#ssl-support-on-aws p.40: 「ユーザがingress controllerをmaster上にセットアップする必要」 => master上にセットアップしなければならないという制約はありません。例えばGCEのingress controller(GLBC)はPodとして動作します。https://gi
みなさんこんにちは、株式会社kubell（旧Chatwork株式会社）で エンジニアリング・マネージャー（まだ見習い）兼プロダクトオーナー（これも半人前）をやっております、辻（@crossroad0201）です。 この記事は弊社 kubell の Advent Calendar 2024 、12月20日の記事です。 こちらのアドベントカレンダーではエンジニアのみならず、プロダクトマネージャーやデザイナー、弊社のさまざまな職種のメンバーが記事を寄せていますので、ぜひほかの記事も見てみていただければと思います。 この記事では、私の所属チームが今年取り組んだ仕事の中でも最も規模が大きかった「メッセージDBリプレイスプロジェクト」についてふりかえりたいと思います。 技術的なことは後日エンジニアが記事を書いてくれるはず（！）なので、私からはプロダクトオーナー目線、プロジェクト運営の観点から見てみます
開発者向けのSQLインデックス解説サイト、管理についての間違いない知識を提供します。 インデックスは開発時には忘れられがちである一方で、非常に効果的なSQLのチューニング方法です。Use The Index, Lukeでは、HibernateなどのORMツールの解説にとどまらず、SQLのインデックスについて基礎から説明します。 Use The Index, LukeはSQLパフォーマンス詳解のWeb上の無料版です。サイトを気に入って頂けたら、ぜひ書籍も購入してみて下さい。また、このサイトの運営をサポートする様々なグッズも販売しています。 MySQL、Oracle、SQL ServerなどにおけるSQLのインデックスUse The Index, Lukeでは、ベンダにとらわれないインデックスの説明を心がけています。製品特有の事柄については、以下のような表示をしています。 Db2 (LUW)U
はじめに この記事では、リレーショナルデータベースで製品データをモデリングするための5つの一般的なアプローチを探り、それぞれの長所と短所を強調し、ニーズに最適なアプローチを選択するためのガイダンスを提供します。 1. 単一テーブル継承 (Single Table Inheritance, STI) 説明: 各製品タイプが必要とする属性を一つのテーブルにまとめて保存する方法です。これにより、製品タイプによって意味のない属性が発生し、多くの属性にNULLが割り当てられます。 長所: 単純で直感的なテーブル構造 実装と理解が容易 短所: 多くのNULL値によるスペースの無駄 特定の製品タイプに対する制約条件を適用するのが難しい 多くの列があるため、パフォーマンスの問題が発生する可能性。 例スキーマ: CREATE TABLE products ( id INT PRIMARY KEY, name
この記事は Merpay Tech Openness Month 2022 の17日目の記事です。 はじめに こんにちは。Credit Design Teamでバックエンドエンジニアをしている@tk8です。主にメルペイスマート払いに関わるマイクロサービスの開発や運用をしています。 この記事では、私のチームでの持続可能なデータベースドキュメントへの取り組みに関して紹介します。 背景 私が担当しているマイクロサービスでは歴史的経緯（*1)もあり複雑なスキーマ設計をしています。また、領域的にドメイン知識が複雑なものも多く、バックエンドエンジニアでもデータとスキーマの関連に関して理解が難しいことが多々ありました。 さらに私のチームではQAエンジニアやPMもデータベースに関するドキュメントを読むことがあり、不明点があれば都度詳しそうな人に聞いたり過去のSlackでの会話を調べたりするなど非効率な状態
B-Tree インデックス (B-Tree Index) オラクルのインデックス、すなわち、デフォルト時のインデックスは B-Tree インデックス(※1) になる。 B-Tree インデックスとはバランスド・ツリーインデックスの略である(1969 年頃に既に考案されている)。プログラミングを始めたときにソートアルゴリズムやデータ構造で勉強したであろうと思う二分木 (Binary-Tree) の進化版みたいなものである。 一部のブランチが異常に成長しないように平衡を保つように再編成(バランス)する仕組みによって、常にインデックスによる検索性能を高い状態に保つことができる(※2)。 RDBMS によっては色々な種類のインデックスが存在しているが、現在においても B-Tree インデックスが多くのケースで優れたパフォーマンスを出していることには変わりないようである。 (※1) B-Tree に
なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか？ これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま
Basic support for relational databases: MySQL, SQL Server, PostgreSQL and others Data Editor SQL Editor Database schema editor DDL Basic ER Diagrams Basic charts Data export/import Task management Database maintenance tools All DBeaver Community featuresAdvanced securityAdvanced support for relational databasesConnection through ODBC driversNoSQL databases support: MongoDB, Cassandra, Redis, Couch
BASEアドベントカレンダー2021 10日目の記事です。 BASEアドベントカレンダー2021 10日目 BASE BANKでエンジニアをしている @budougumi0617 です。 マイグレーションファイルが含まれたPull Request（PR）が作られたとき、自動更新したER図をPRに追加するGitHub Actionsを作りました。 本記事では紹介するGitHub Actionsを利用すると次のようなメリットが得られます。 マイグレーションファイルをPRに出すだけでPRに更新されたER図が追加される 開発者は面倒なER図の更新作業から開放される レビューアはマイグレーションファイルを含んだPRをER図を見ながらレビューできるようになる プロジェクト関係者は常にメインブランチのマイグレーションファイルの状態と一致したER図を確認できる サンプルPR 自動生成したER図 TL;DR
Cloud Nativeなシステムを構築するにあたって手助けとなる、アプリケーション開発と運用のアジリティ、可用性、拡張性を支えるさまざまなデータベースを学ぶ「Cloud Native Database Meetup #1」。ここで「NewSQLへの誘い」をテーマに小林氏が登壇。NewSQLが登場するまでの流れと、NewSQLのストレージエンジンと分散トランザクションについて紹介します。 自己紹介とセッションのアジェンダ 小林隆浩氏（以下、小林）：では、さっそく本セッションに入っていきますが、まずは私のほうでイントロダクションをこのままやります。 イントロダクションのテーマは、「NewSQLへの誘い」というかたちで進めていきます。私は小林と言い、データベースに関する連載や、書籍の翻訳なんかをしているエンジニアです。 いろいろなデータベースをつまみ食いするのが好きで、評価したり検証したり。あ
こんにちは。エンジニアのゆきちです。 普段はGoでアプリケーションを書いたりAWSでインフラ構築をしたりしてます。 HRBrainという企業の目標管理サービスを作っています。 なので、弊社では様々な企業さんの大切な情報を取り扱っています。 それにはもちろん個人情報も含まれるわけですが、そうなると僕ら管理スタッフが直接データを見ることができてはいけません。 とはいえ、こういうエラーが出たんですが...などの問い合わせに対応するためには、時によって本番のデータにアクセスして調査する必要があります。 制限も何もなければ当然丸っとそのまま見れちゃうわけですが、それができてしまってはSaaS企業としてのプライドが廃る！という所存でやっていきます。 そんな時にはどうすればいいんでしょうか？ 答えは、 データを匿名化すること です。 今回、本番環境のデータベースのデータをマスキングして、調査者が見れる環
この記事は移行しました！最新の内容はこちらをご覧ください😀 はじめに 今週末はデータベーススペシャリスト試験ですね。 DBの正規化について、毎回忘れて勉強し直すのでまとめておこうと思います。 試験でも実務でも第３正規化まで出来れば大概OKですね。 下記順序で進めるのがポイントです。 非正規形 第1正規形にする 候補キーを探す ←ここがミソ！ 主キーを探す ←ここもミソ！ 第2正規形にする 第3正規形にする Qiitaなので記事テーブルを例に考えてみましょう。 記事テーブル（記事ID, 記事タイトル, カテゴリID, カテゴリ名, カテゴリ内での表示順, 作成者ユーザID, コメント番号, コメント本文, コメント投稿者ユーザID） 参考:2017年度春期試験の午後Ⅰ 電子会議投稿（電子会議番号, 議題, 分野番号, 分野名, 表示順, 作成者ユーザID, 投稿番号, 投稿本文, 投稿者ユ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
