AWS、SQL互換の新問い合わせ言語「PartiQL」をオープンソースで公開。RDB、KVS、JSON、CSVなどをまとめて検索可能
Amazon Web Services（以下AWS）は、SQL互換の新しい問い合わせ言語およびそのリファレンス実装である「PartiQL」をオープンソースとして公開したことを発表しました。 PartiQLはSQL互換の構文に最小限の拡張を施すことで、リレーショナル形式のデータベースだけでなく、KVSやJSONなどを含むNoSQLデータベースやCSVファイルなど、さまざまなデータソースに対して横断的に検索できる問い合わせ言語およびそのリファレンス実装です。 下記はPartiQLを発表したブログからの引用です。 Today we are happy to announce PartiQL, a SQL-compatible query language that makes it easy to efficiently query data, regardless of where or in
※2020年6月に公開された記事です。 日本PostgreSQLユーザ会の理事を務める合同会社Have Fun Techを起業した曽根壮大（@soudai1025）と申します。元株式会社オミカレ副社長兼CTOです。直近では、『失敗から学ぶ RDBの正しい歩き方』を執筆しました。 今回はデータベースをテーマとして、魅力やMySQLとPostgreSQLの違い、アンチパターンの見極めなどの基礎知識に加え、勉強法などもご紹介します。 RDB関連の求人検索はこちら データベースを学ぶ魅力をエンジニア目線で考察 1.知識の費用対効果が高い エンジニアがデータベースを学ぶ利点という観点から言うと、データベースの特徴は寿命が長いことと私は考えています。 Webアプリケーションの界隈では1年単位でバージョンアップしたり流行っている言語が変わってしまうことがザラにありますが、データベースは10年、20年とい
はじめに現在所属しているプロジェクトではWebAPIやバッチ処理の設計の一環としてPlantUMLを利用しています。効率よく品質高くアウトプットを出すためには、プログラミング言語に対してコーディング規約があるように、UMLに対してもチームで設計するにあたり一定のルールを決める必要があります。 そこでプロジェクト内のPlantUMLを使用するうえでのガイドラインやルールをまとめる機会があり、せっかくなのでそれを記事化します。 記事のゴール シーケンス図設計におけるPlantUMLの標準化 必要最低限のルールだけに絞ってチーム設計の生産性と品質を上げる 記事の前提 ルールの想定の利用シーン： チームで大量生産する業務機能の処理フローを表現するために使う場合を想定。 また、この記事に記載されているルールはRDBを中心的に使用したAPI処理やバッチ処理等を念頭に置き決められたものです。 ルールの想
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
前々からこの手のことを書きたいとは思ってたけど id:k0kubun さんの下記エントリに触発されて書きました。 k0kubun.hatenablog.com tl;dr; 個人アプリ開発歴 前提 Heroku GCP Google App Engine Cloud Run Firebase Cloud Functions GitHub Pages 2022/8/14追記 GitLab Pages 2022/5/7 17:00追記：ブコメレス tl;dr; HerokuやFirebaseを駆使すれば割と無料でいける 若干お金を払えばもっと選択肢は増える 個人アプリ開発歴 2001～2002年あたりから個人HPでアプリを公開。後にVectorにも公開 アカウントは残ってるのでいまだにVectorからのレポートメールが毎月届いてます 2009年くらいから色々ウェブアプリを開発 Google A
おはようございます、ritou です。 qiita.com これの初日です。 なんの話か 皆さんは今まで、こんな記事を目にしたことがありませんか？ Cookie vs JWT 認証に JWT を利用するのってどうなの？ JWT をセッション管理に使うべきではない！ リンク貼るのは省略しますが、年に何度か見かける記事です。 個人的にこの話題の原点は最近 IDaaS(Identity as a Service) として注目を集めている Auth0 が Cookie vs Token とか言う比較記事を書いたことだと思っていますが、今探したところ記事は削除されたのか最近の記事にリダイレクトされてるようなのでもうよくわからん。 なのでそれはおいといて、この話題を扱う記事は クライアントでのセッション管理 : HTTP Cookie vs WebStorage(LocalStorage / Sess
サーバーサイドからみたGraphQL Serverlss Meetup#19 2021/03/31 に行われた Serverlss Meetup#19 で上記のタイトルで登壇してきました。サーバーサイドの話をしようと思ったけどGraphQLの解決している話をしようと思ったらクライアントの事もかなりはいってしまったので記事のタイトルは変えました。 以下内容です。記事の最後に資料を書くにあたって参考になった資料のリンクを置いてます。 GraphQL and me この1年書いたQiita記事 GraphQLの特徴を分解する ~API インターフェース・Universal BFF・API Gateway~ GraphQLはサーバーサイド実装のベストプラクティスとなるか GraphQLの全体像とWebApp開発のこれから 今回話す事 そもそもGraphQLはなんで作られたのか、何を解決しようとして
Webアプリケーションのパフォーマンス・チューニングの勘所 / web tuningperformance
# 参考資料 - https://speakerdeck.com/hanhan1978/purohuairawoshi-tutaphpapurikesiyongai-shan-falsekan-suo - https://speakerdeck.com/hanhan1978/web-application-tuning-guildline - https://speakerdeck.com/soudai/basic-of-rdb - https://speakerdeck.com/soudai/shi-xing-ji-hua-falsehua - https://fortee.jp/phpcon-2021/proposal/1e11a6b1-08d9-4044-9909-4c90105ea726 - https://fortee.jp/phperkaigi-2021/proposal/1d
この記事は？ それぞれが専門にしている領域に関わらず、Webエンジニアリングの基礎知識として知っておきたいと思う事を対話形式でまとめていく。知識はインプットだけではなく、技術面接や現場では、専門用語の正しい理解をもとにした使用が必要なので、専門がなんであれ理解できるようなシンプルな回答を目指したものになっています。解答の正しさはこれまでの実務と各分野の専門書をベースに確認してはいますが、著者は各技術の全領域の専門家ではなく100%の正しさを保証して提供しているものではないので、そこはご認識いただき、出てきたキーワードの理解が怪しい場合各自でも調べ直すくらいの温度感を期待しています。なお、本記事で書いている私の回答が間違っている箇所があったりした場合、気軽にコメント欄などで指摘いただけるとありがたいです。 Webエンジニアリングの基礎 この記事でカバーしている領域は、以下のような領域です。W
こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2021年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2021年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの？」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2020年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 205個 です。 まとめるにあ
NewSQLはデータベースに革命を起こすか - NetflixにおけるCockroachDBのユースケース｜ミック
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性（ACID）というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが（クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている）、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
AWS Lambda を使用した Web アプリケーションの開発プロジェクトで、バックエンド・フロントエンド・インフラを一貫して開発をしてきました。 改めてどのように開発をしていたのか、使った技術スタックや各サービスをどのように活用したかを整理したいと思い記事にしました。今後サーバーレス開発を行う際の技術選定の参考にしていただければ幸いです。 前提 Web アプリケーションです。 管理画面用の内部 Web API、外部のサービスと連携するための外部 Web API があります。 処理としてはリソースの CRUD がメインです。 管理画面は SPA で、バックエンドの Web API にリクエストします。 開発メンバーは 4 人ほどで、フロントエンドエンジニア、バックエンドエンジニアといった区分けはしていませんでした。 機能ごとにメンバー全員がバックエンドからフロントエンドまでを一気通貫で実
自作RDBMSやろうぜ!
Skip to the content. 自作RDBMSやろうぜ! このサイトの目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されたサイトや書籍で、必要な情報・情報源がまとまったものがないことに気づきました そこで、叩き台として、本サイト管理人および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSするための道筋をある程度整理して書き記してみました 各々の情報・情報源はあいかわらず多くが英語で記述されていますが、その点はご容赦下さい なお、本サイトは技術的な解説を提供するのではなく、適切と思われる情報・情報源をポイントするようなサイトとなることを想定しています
※本記事はOracleの下記Meetup「Oracle Big Data Jam Session」で実施予定の内容です。 ※セミナー実施済の動画に関しては以下をご参照ください。 本記事の対象者 これから機械学習を利用した開発をしていきたい方 機械学習のトレンド技術を知りたい方 なるべく初歩的な内容から学習したい方 はじめに Transformerの登場以降、著しい技術革新が続くここ数年、特にOpenAI社のChatGPTのサービス開始以降、おびただしい数の技術ブログや記事がインターネット上に存在する中、本記事に目を留めていただいてありがとうございます。 この勉強会では、専門用語や難解な公式を極力排除し、初学者の方々を対象に、「そもそも自然言語の機械学習ってどういうもの？」、「言語モデルって要するに何？」というところからGPTをざっくり理解することを目的としています。従って、本記事に記載のあ
ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ
自走プログラマー表紙 「自走プログラマー」という本が出ます！ この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。 僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕（著者全員）が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー（とPythonプロフェッショナルプログラミング）を読んでもら
1000万ユーザに耐えるサーバを作ってみた
概要 スケーラビリティが高く1000万ユーザに耐えるAPIサーバを作成しました。TwitterのようなSNSです。実装はGitHubで公開しています。 開発環境は次の通りです。 Node 16.14 Express 4.17.3 DynamoDB 2012-08-10 機能要件は次の通りです。 ツイート機能 ツイートに対してコメント機能 フォロー機能 タイムライン機能 導入 Facebook、Amazon、Youtubeのような数億人のユーザを抱えるサービスでは大量のトラフィックを捌く必要があります。大量のトラフィックを捌くためのアプローチとして一般的に使われるのはスケールアップではなくスケールアウトです。スケールアップは性能の高い機器を使うためにコストが高いです。また、1つのサーバで運用するためにパフォーマンスの限界が存在します。 スケールアウトについて考えます。アプリケーションは大きく
Twitterの内部構造を読解してみる 前口上 Twitterのようなマイクロブログサービスでは短時間で書き込みも多く、特にタイムライン周りは単にRDBのデータを出し入れるするだけではスケールしなくなります。 インターネット上に断片ながらTwitterの中の人がアーキテクチャについて解説した記事や動画がいくつか落ちていたので、Twitterがタイムラインをどうやってキャッシュしているかについてまとめてみたいと思います(推測を含みます)。 Twitterのテーブル構造 単純なTwitterのテーブル定義をRDBで定義すると以下のようになると思います。 tweets ツイート id user_id contents tweet_at followers フォロワー source_user_id destination_user_id users ユーザー id user_name timeli
働いてみないとわかりにくいIT業界の構造 SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス” 総工費4億円のラボから生中継！CTOが語る、これからのエンジニアに求められる技術 #1/3 ウイングアーク１ｓｔ・CTO 島澤甲氏 島澤甲氏：みなさんこんにちは。私はウイングアークでCTOをしている、島澤と申します。このセッションでは、これから技術者を目指されているみなさんに対してなにかヒントになるようなものを伝えられたらいいかなと思っています。 （スライドを示して）まずウイングアークですが、私たちは、帳票やBIと呼ばれるところでトップシェアを占めています。今日は、「このセッションは会社の宣伝をしなくてもいいよね」という話をしたら「別にかまわん」ということだったので、会社の宣伝はもうしません。気になる方はちょっとホームページを見てもらえればと思います。業績などもありますが、順
安く早く開発するための個人開発アーキテクチャ
はじめに 最近趣味で個人開発をしながらアーキテクチャの検討を行なっていたのですが、自分なりにいい感じの結論に辿り着いたので今回はそのアーキテクチャの紹介しようと思います！ インフラ、バックエンド、フロントエンドの各セクションに自分が使用しているテンプレートのリポジトリのリンクを載せてあるので興味のある方は参考にしてください。 また今回紹介するアーキテクチャはあくまで一例なので、間違いや不備などがあればご指摘いただければ幸いです。 前提条件 個人開発で使用するアーキテクチャを考える上で、自分の中でいくつか前提条件があります。 ランニングコストを抑える いくつか前提条件がある中で、個人的に一番重要な要素になります。 バズるサービスを作りたいという気持ちはありますが、そのためにいくらでもコストをかけられるかと言われるとそうではありません。むしろ個人開発となると、抑えられるコストはできる限り抑えた
2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て
Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル） - Qiita
Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの？」を調べてみた（ファントムファイル）oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた！』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか？ 帳票や大きな画像ファイルなどを扱う際、大きく分けて２つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなどをDBに保存する オライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz
Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという
【初心者必見】プログラミング未経験から3年間のPython学習ロードマップ完全版 - 仮想サーファーの日常
近年、Pythonの求人数・案件数が増加すると同時に単価も上がってきており、エンジニアの中で人気が高まっています。 これからプログラミング言語Pythonを学んで、Webアプリケーション開発エンジニアや機械学習エンジニアになりたいと思っている方も多いのではないでしょうか。 この記事では以下のような方向けに、Pythonを未経験からどのような手順で学びPythonエンジニアになるのか、またPythonエンジニアになった後にどのように学び続けていけばいいのか、具体的な方法をまとめています。 この記事の対象読者 エンジニアではないけど、未経験からPythonエンジニアに転職したい方 エンジニアではないけど、未経験からPythonでデータ分析や業務効率化をしたい方 非Web系の会社で働いているけど、Web系のPythonエンジニアに転職したい方 Pythonとは Pythonとは何か Python
概要 AI革命のインフラを目指すSaaS系スタートアップのFastLabel（最近資金調達しました！記事はこちら）で働いているが、今までGCPで動かしていたインフラを訳あってAWSに基盤を載せ替えることになった。 スタートアップは何よりスピードが求められるが、だからといってセキュリティやモニタリング、可用性を疎かにはできないし、大きなインフラコストに耐えられるほど体力もない。 アプリケーション要件を満たしつつ、以下を実現するアーキテクチャを設計する。 シンプルな構成・構築の容易さ スピーディな開発・適用 可用性の担保 セキュリティの担保 最低限のモニタリング 低コスト（リソース・運用） ここで紹介するアーキテクチャは実際に運用まで行っており、問題なく稼働しているし、先日AWSの方にレビューしてもらったが、「なかなかイケてる」というお言葉をもらい、特に改善点も指摘されなかった。 結論（アーキ
Adobe Firefly で生成PdMむけの記事でこのような記事がある。 「プロダクトマネージャーこそ、戦略的に読書せよ！」── 最短で成果を出すための読書地図 (1/6)|ProductZine（プロダクトジン） これのエンジニア向けの記事がないかなと思っていたがなさそうだったので作ろうと思った。しかし客観的な視点でこれがおすすめというのは難しいので自分が参考になったと思った本を家の本棚を見ながらまずは100冊リストアップしてみた。 紹介する本は10年読まれていたり、近年発売のものであれば10年後にも読まれているだろうというものを選ぶようにしている。個別のプログラミング言語やフレームワークなどの本はバージョンアップに追随ができないことが多いので選んでいない。 入門本プリンシプル オブ プログラミングリーダブルコード定番中の定番。おそらくこの2冊はあちらこちらで紹介されている。とりあえず
はじめに 最近、AWSのシステム構成図を見ることが多くなり、AWS上で動いているシステムのシステム構成図を理解できるようになるために個人的に知っておきたいと思ったAWSの用語・サービスをまとめてみました。 私自身も勉強がてら作成したので、わかりづらい部分も多くあると思いますが、AWSのサービス全くわからん→なんとなく雰囲気把握した、となっていただけたらと思います。 2018年10月に新しくなったAWSアーキテクチャアイコンを使用しています。 サーバ・クライアントなどの説明についてはここではしていませんが、以下の記事でとてもわかりやすくまとめてくださっています！ 超絶初心者のためのサーバとクライアントの話 知っておきたい用語 リージョン AWSがサービスを提供している拠点（国と地域） リージョン同士はそれぞれ地理的に離れている（例えば日本とオレゴンとか） 日本はap-northeast-1（
みなさま、認可の設計に苦しんでいるでしょうか？私は苦しんでいます。苦しまなかった瞬間などありません。昔「アプリケーションにおける権限設計の課題」を執筆しましたが、あれから3年以上が経ちます。 当時は認可の設計に関する情報がうまくまとまっている記事などほとんど無く、調べに調べて得たナレッジを書き記したのが上記の記事です。3年以上経ちますが、苦悩が今も特に変わっていないことが驚きです。 ただし、世の中的には認可のライブラリであったりサービスというのは少しずつ増えてきている印象があります(Auth0の OpenFGA であったりOsoの Oso Cloud 、Asertoの Topaz )。 認可の設計に関する記事も少しずつ増えている印象があり、その中でも本記事で紹介したいのがAuthorization Academyです。 これは認可サービスである Oso Cloud やOSSのライブラリ o
Reactチュートリアル2：レビューサイトを作ろう
本資料について 本資料は日本大学文理学部情報科学科の開講科目「Web プログラミング」の教材として作成されました。本資料は下記のライセンスの範囲内で、当授業以外でも自由にご利用いただけます。 対象読者 本資料は、以下の教材を学習済み、もしくはそれと同等以上の知識を持っていることを前提としています。 React チュートリアル：犬画像ギャラリーを作ろう 基本情報技術者試験レベルの関係データベースの知識 本資料で学ぶこと 本資料では以下の内容を学びます。 Express と Sequelize による API サーバー開発 React と API サーバーの連携 Cross-Origin Resourcer Sharing React によるルーティング Auth0 によるユーザー認証 Heroku による API サーバーの公開 ライセンス この作品はクリエイティブ・コモンズ 表示 4.0
RDBのレコードに、作成日時や更新日時を自動で入れ込むコードを書いたりすることあると思いますが、それに対する個人的な設計指針です。ここでは、作成日時カラム名をcreated_at、更新日時をupdated_atとして説明します。 tl;dr レコード作成日時や更新日時をRDBのトリガーで埋めるのは便利なのでやると良い ただ、アプリケーションからそれらのカラムを参照することはせず別に定義した方が良い MySQLにおける時刻自動挿入 MySQL5.6.5以降であれば、以下のようにトリガーを設定すれば、レコード挿入時に作成日時と更新日時を、更新時に更新日時を、DATETIME型にも自動で埋めてくれます。いい時代になりました。(MySQLが遅すぎたという話もある) `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_
SQL滅ぶべし | ドクセル
SQL • リレーショナルデータベースシステムと会話するための言語 • 1970年 Codd が RDB モデルと同時に提案 (Alpha言語) • 1974年 Chamberlin と Boyce が改良 • 元々は SEQUEL (Structured English Query Language) だったが、商標登録されていた • 読み方は エスキューエル とそのまま読む (Glliespie 2012)
「Firebase は安いし楽だしマジ最高」という一心で技術選定してしまったプロダクトが成功して見えてきた課題、割高なコスト・権限管理・カスタマイズ性、そして （特性やスキルセット的に）RDB 製品が適していたのに無理やり Firestore を採用したことによるデータ不整合。 その結果チーム内で Firebase を抜ける機運が高まるも、Firebase べっとりなアプリケーションすぎて移行しづらいといった問題に出会うかもしれません。 そのような場合に備え、Firebase の存在を隠蔽して開発することに挑戦してみましょう。 注意: Firebase を剥がしているときに「俺、次は絶対そうするわ」と感じたものを書いているだけであり、まだ実際にはこのパターンでプロダクション導入していません。 あくまで個人開発で試してみていけそうと思ったので、提案しますという体です。 また Firebase
えふしんさんに何の恨みも無いのだけれど わからないことを偉そうに書いて怒られて進化したいという芸風なので書いてみました。 Web3というテロリズム｜えふしん #note https://t.co/84SoYtIzDC — えふしん (@fshin2000) 2022年2月17日 というのだから技術的に正確なツッコミを入れて欲しいという事だと信じて書く。まさか後釣り宣言など来ないだろう。 Web3という言葉は、既存の権力構造に対する宣戦布告と考えれば、割と素直に受け入れられる。 ここは本当にその通りで「下剋上」の雰囲気感だけで業界が振り回されているのは見るに耐えない。権力構造を敵対視するあまり、本当に味方に付けるべきエンドユーザーの事がなおざりになっているとすら感じている。市場経済で世の中が動く中、エンドユーザーは確かな利益が無ければ動かないし、利益無しで人やお金を動かさせたら詐欺である。こ
かつての失敗談。ついった初めたばかりのころにはまった次のような悪い循環です。 すごい人をたくさんフォローする すごい人達がすごいこと言ったりやったりする それに比べて自分は大したことできないと自信喪失する 何もしなくなる フォローする人が多くなればなるほどこの傾向は加速していきました。なぜかというと、それぞれのすごい人達の凄い部分を全部合成した完璧超人と戦おうとしていたからです。 たとえば次のような3人をフォローしたとします。 RDBにめちゃくちゃ詳しい人 カーネルめちゃくちゃ詳しい人 特定のプログラミング言語にめちゃくちゃ詳しい人 ここで私は「RDBにもカーネルにも特定のプログラミング言語にも全部めっちゃ詳しい超人」を脳内で作って、その架空の超人を見上げて自信喪失していたのです。 この誤解が解消したのは、のちのち各種カンファレンスや勉強会などに参加して彼らに出会う幸運に恵まれたときでした
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
データベースのスペシャリストとして知られる曽根壮大（そね たけとも）さん。ベンチャー企業のCTO（最高技術責任者）やインターネット企業のCRE（Customer Reliability Engineering・顧客信頼性エンジニアリング）を務めるなど、エンジニア系のコミュニティーをけん引している。講演者としても一流で、イベントにも引っ張りだこ。その世界では「そーだいさん」として、多くの人に頼られる存在だ。 しかし、そのスタートは警察官という全く別分野だった。新たな道へ進んだのは、プログラミングの知識もなかった23歳の頃のこと。 何かを始める場合、人によっては「今更始めても遅いかも……」と躊躇（ちゅうちょ）するかもしれない。高度なスキルが求められるIT業界で、そーだいさんがいまの地位までたどり着いた理由はどこにあるのだろうか。 そーだいさんならではの「学び」への姿勢、そして新しいことを始める
こんにちは！LayerXの mosa_siru (榎本) です。 LayerX インボイスでは、もともと github.com/go-swagger/go-swagger を利用してREST APIを開発していましたが、最近開発したワークフロー機能 のコンポーネントではGraphQLを取り入れました。 GraphQLには様々なメリットがあり、RESTとの比較記事は多くありますが、なぜ僕らは移行したのか、その結果どうなったのかを紹介していきます。 GraphQLのメリット GraphQLのメリットは、様々な箇所で語られています。例えばこの記事によれば、 強力に型付けされたスキーマであること アンダーフェッチとオーバーフェッチがないこと（後述） Apollo, Relayなどの、クライアントライブラリにより、フロントエンド開発が迅速になること 複数のGraphQL APIからの統合が可能 強力
こんにちは、エムスリー エンジニアリンググループ の鳥山 (@to_lz1)です。 ソフトウェアエンジニアとして 製薬企業向けプラットフォームチーム / 電子カルテチーム を兼任しています。 ソフトウェアエンジニアという肩書きではありますが、私は製薬企業向けプラットフォームチームで長らくデータ基盤の整備・改善といったいわゆる "データエンジニア" が行う業務にも取り組んできました。 本日はその設計時に考えていること / 考えてきたことをデータ基盤の設計パターンという形でご紹介しようかと思います。多くの企業で必要性が認識されるようになって久しい "データ基盤" ですが、まだまだ確立された知見の少ない領域かと思います。少しでもデータエンジニアリングを行う方の業務の参考になれば幸いです。 データ基盤の全体像 収集部分の構成 RDBデータ ログデータ 活用部分の構成 データマートの実例 「データ基
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気（株）と（株）ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」（以下、委託事業）において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」（以下、劔）を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境（メニーコア・大容量メモリーなど）に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン
PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
最強データベース（RDB）設計とは？アンチパターンの見極め方法も - FLEXY（フレキシー）
チームで機能設計するためのPlantUML標準化 | フューチャー技術ブログ
実はDDDってしっくりこないんです - タオルケット体操
なるべくお金をかけずに個人アプリを運用したい - くりにっき
Webアプリケーションのセッション管理にJWT導入を検討する際の考え方 - r-weblife
GraphQLが解決する問題とその先のユースケース
【Web】知っておきたいWebエンジニアリング各分野の基礎知見80
【2021年】AWS全サービスまとめ | DevelopersIO
最近の業務での AWS サーバーレス開発を振り返ってみた | DevelopersIO
ChatGPTのコア技術「GPT」をざっくり理解する - Qiita
2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ
Twitterはタイムラインをどうやってキャッシュしているか - Qiita
働いてみないとわかりにくいIT業界の構造 SI系・プロダクト系それぞれで異なる“求められる能力”と“キャリアパス”
マイクロサービスに次に来るかもしれない言葉について - arclamp
Webフルスタックエンジニアになるためのチェックリスト
SaaS系スタートアップのリアルなAWSアーキテクチャ設計
ソフトウェアエンジニアにおすすめしたい本を100冊選んでみた | gennei's blog
基本的なシステム構成図を理解するためのAWS基礎をまとめてみた - Qiita
認可のアーキテクチャに関する考察（Authorization Academy IIを読んで）
RDBの作成時刻や更新時刻用カラムに関するプラクティス | おそらくはそれさえも平凡な日々
Firebaseの存在をフロントエンドから隠蔽するために
Re: Web3というテロリズム - Software Transactional Memo
実体の無い完璧超人と戦っていた過去の失敗談 - 覚書
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
何かを学ぶことに「今更遅い」、なんてない。｜曽根 壮大（そーだい）
GraphQLでバックエンドのコードをすっきりさせた話 - LayerX エンジニアブログ
エムスリーのデータ基盤を支える設計パターン - エムスリーテックブログ
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag