こんにちは！エンジニアの福間（fkm_y）です。 先日、弊社でデータベースの技術顧問をして頂いてる三谷（mita2）さんに開発部向けのMySQLロックのデータベース勉強会を実施したのでそのレポートをお伝えします。 開催背景 弊社では三谷さんによるデータベース勉強会を定期的に開催しています。以前にもロックに関するMySQL勉強会を開催していたのですが、1年半経過しており参加していない開発メンバーのほうが多くなっていたことやプロダクトの成長によりデッドロックなどのロックに起因する問題が目立ち始めていたことから増強版のMySQLロックのデータベース勉強会を開催することになりました。 概要 データベースのロックについて ロックタイムアウトについて デッドロックについて まとめ データベースのロックについて なぜデータベースにロック機構があるのかから知ることが重要です。性能と安全性を両立するためにあ
SIerの輪廻から解脱するための技術｜はまあ
モチベーション最近「SIer界の輪廻からどうやって解脱したらいいですか？」 という話をちょくちょく耳にすることが増えた。 それに対する"解答"というわけではないのだけど、輪廻からの解脱を目指すにあたり、どんな要素技術を学ぶべきかについてはある程度指針を示せると思ったので今回は、選ぶべき技術と、その理由について解説していきます。 SIer界で輪廻転生を繰り返したい人はジャバ言語のラムダ式を禁止にすべきか議論するほうが大事だと思うので、こんな記事にクソリプする前にさっさと帰って、どうぞ。 TypeScript解脱への第一歩は、なにはともあれTypeScriptだろう。 正直、この言語だけ覚えておけば、FaaS(Lambda, Cloud Functions)も書けるし、ReactによるSPAとか、なんならReact Nativeでアプリも書けるし、モダンな開発環境に必要なスキルセットがすべてま
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気（株）と（株）ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」（以下、委託事業）において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」（以下、劔）を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境（メニーコア・大容量メモリーなど）に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン
最近SELECT ... FOR UPDATEでデッドロックする話を何度かしたので。 前職のときにUPDATE同士がデッドロックしてたときに、SELECT ... FOR UPDATEで排他ロックを取ってからUPDATEしてデッドロックを防ぎますってPRをレビューしてたときのことで、複数レコードの排他ロックは一瞬ですべてのレコードのロックを取れるわけではなく、ロックを取る順番が揃っていないと簡単にデッドロックしますよという話です。 https://gist.github.com/kamipo/0bb4e37d58ba18a8cefb8aa02f778231 # frozen_string_literal: true require "mysql2" def client Mysql2::Client.new( host: "localhost", username: "root", dat
WEB+DB PRESS Vol.122に特集「Rustで実装！作って学ぶRDBMSのしくみ」を書いた - Write and Run
KOBA789 です。 時が経つのは早いもので、気づけば2月末に無職になってから1ヶ月以上が過ぎていました。 その間に何をしていたのかといえば、表題の特集記事の執筆をしていました。 宣伝 このブログ記事は WEB+DB PRESS Vol.122 を読みたくなるためのものです。ぜひ買ってね。買ったらちゃんと読んでね。 作って学ぶ RDBMS のしくみ、書きました。みんな大好き Rust を使って解説してます https://t.co/nm526qQYnm— KOBA789 (@KOBA789) April 8, 2021 gihyo.jp 使用言語は Rust だし、RDBMS はそもそも難しいトピックだしで結構重めの内容ですが、まずは読み物として寝転びながらでもいいので読んでみてほしいです。 ゴールデンウィーク*1の自由研究のお供にもどうぞ。たぶんちょうどいい分量なんじゃないかなぁ。ゴー
PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134
自作RDBMSやろうぜ!（Zenn出張版）
Disclamer 本記事は自作DBMSやろうぜ！ のページの 22/05/27 JST 22:38 の時点での内容をZenn記事向けに修正して作成したものです 元コンテンツのライセンスについては以下をご参照ください LICENCE 元コンテンツの方は更新が継続されていますので、よろしければそちらもご覧ください この記事の目的 RDBMS（いわゆるリレーショナルデータベース）というものはプログラミング言語の処理系や、OSなどと同様に、世の中で広く使われているソフトウェアであるにも関わらず、いざ自作してみようと思うと日本語で記述されている必要な情報・情報源がまとまったサイトやブログ記事がないことに気づきました そこで、叩き台として、筆者および数名のコミッタで開発している自作RDBMSである SamehadaDB が軌道に乗るまでの経験をベースに、自作RDBMSに関する情報をある程度整理して書
はじめに みなさんこんにちは。Sansan事業部プロダクト開発部のiOSエンジニア荒川です。 以前はRDBMSの記事*1を寄稿し、好評いただいたこともあり、定期的に車輪の再発明系の記事を書いていこうと思います。 さて本日はタイトルの通り、VimやEmacsに代表されるターミナルで動作するインラインテキストエディタをGoで開発してみました。 ソースコードは以下のリポジトリに置いているため、ぜひ参考にしてください。 github.com 完成品 文字だけだとイメージも湧きにくいので、まずは完成品をお見せします。 最低限エディタの動きは出来ている、というレベルの完成度ですね🙏 特徴 1000行インラインエディタ 文字入力/挿入/削除 画面スクロール キーボードショートカット ファイル読み込み/保存 Goのコードハイライト機能 実装の方針 今回はただ開発するだけではなく、いくつかのこだわりポイン
先日のAmazon SQSの障害には色々と肝を冷やした人も多いのではないでしょうか。 classmethod.jp 今回のようなケースとは別に障害は大小あれど、みなさん日々戦っていることだと思います。 障害対応はエンジニアの花形であるものの、サービスに対する知識やソフトウェアの知識など経験と技術の両方が必要です。 そのため、どうしてもトラブルシューティングはエースエンジニアなどの一部の人に依存してしまう…などの問題が発生しがちです。 そこで今日は私の経験から障害対応のいろはを書いて行きたいと思います。 今回のスコープの外 実際に障害時の具体的な対応、例えば障害切り分けやRDBMSのボトルネックの探し方などの話はしません。 まずissueを作ると良い 本題です。 トラブルを認知したらまずはissueを作りましょう。 issueを作るときはtemplateが事前に設定されていると便利です。 g
はじめに データ分析とデータ品質改善に従事してきた筆者が、SQLを用いた分析の基本である「ウィンドウ関数」の使い方とデータ品質の調査改善を行う手法をまとめてみようと思います。 こちらの記事は、SQLの知識向上と振り返りを主題としているので、ABC分析、バスケット分析、RFM分析などの「データ分析の手法」について説明している記事ではありません。(反響やコメントによって別投稿するかもしれません) 背景 SQLはエンジニアの大多数が利用しており、多くの方はWebサービス開発などでデータの登録画面や検索画面を作る際にSQLを利用したり、またはシステムの運用保守で障害の原因調査のためにSQLを利用して原因を特定すると思います。そのため、テーブル結合・サブクエリ・集計関数といったSQL構文は理解されている人が多いと思いますが、分析関数を理解して使っている人となると、ぐっと減ると思います。 私は以前、社
RDBMS 理解度の壁: プロダクションや運用保守で困らないシステムを作れる知識 ＜＜＜それっぽく動くものを作れる知識 実際のシステムで遭遇・見聞きした事象をもとに、上記のスキマにある各種 RDBMS 知識を説明します。 RDBMS 本体の運用よりも、現実のアプリケーションにおける設計・実装上のハマリどころが中心。
どうもキャッシュバスターズ、 id:Soudai です。 Cache（以下、キャッシュ）は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
chriskiehlのブログより。 考えを改めたもの 過去の自分なら言い争っていたであろうことが、今では信じられるようになったこと。 様々な経験レベルを持つ人がいるチームで仕事をする場合は、型付き言語の方が適している スタンドアップは、実際に新人を注目するのに役立つ スプリント・レトロスペクティブは、実際の軌道修正のためのものであって(「つまり、なんてこった、うまく行かなかった!」)、皆の時間を無駄にするようなアジャイル/スクラムマスター的なものでない限り、その場に相応しいものである ソフトウェア・アーキテクチャは、おそらく他の何よりも重要である。優れた抽象化のクソみたいな実装は、コードベースに正味の害を与えません。悪い抽象化や欠落したレイヤーは、すべてのものを腐らせる Javaはそれほどひどい言語ではない 巧みなコードは通常、良いコードではない。明瞭さは、他のすべての懸念事項に勝る どん
秋のブログ週間の9本目のエントリーになります。この企画もこんなに書く人が出てくるように育っていいですね。 「中間層を増やして柔軟性を高めるのがソフトウェアの歴史」 これは大学時代に2つ上の先輩が言っていた言葉です。例えばマシン語を直接書くのではなく、アセンブラで書けば、変換（コンパイル）の手間はかかりますが、他のCPUへの移植はしやすくなります。高級アセンブラと名高いC言語を使えばさらに移植性は上がります。C言語で書かれたVMを使う言語、例えばJava、Python、Rubyなんかはさらに移植性は上がります。 ストレージもそうです。最終的にストレージはビット列を保存するものですが、それにOSのファイルシステムというレイヤーがあり、そこにスキーマで管理されたデータを入れるDBMSが乗っかり、SQLなどの問い合わせ言語でデータ取得できるようにします。DBMSを挟むことで、レプリケーションでバッ
Oracle データベースの内部構造に着目して、さらなるチューニングを行うために必要な基礎知識をまとめた資料です。
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する
なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決するShellScriptUNIXSQLitePOSIXQiitadelika 「利用者は数十億人！？ SQLiteはどこが凄いデータベース管理システムなのか調べてみた」の続きです。 はじめに 複雑な構造のデータを扱うのであればシェルスクリプトや Unix (POSIX) コマンドでデータ管理を行うのは避けるべきだと思います。解決不可能な問題が多いからです。しかしそれでも何かしらの理由でやろうと考える（やらなければいけない）のであれば SQLite を使うのをおすすめします。シェルスクリプトや Unix コマンドは行単位の単純なテキストデータをシーケンシャルにデータ処理するのが前提となっており、改行や空白が含まれるデータや複雑な構造のデータ扱うのは苦手です。またシェル
PySpa統合思念体です。 某チャットで、「今時のOSSのプロジェクト管理とかのベストプラクティスが書いてある本ないかな、陳腐化早そうだしないか」みたいな話題が投入されました。その中で、エキスパートPythonプログラミングとか、Pythonプロフェッショナルプログラミングとかは思い出して紹介したけど、他の人からはShip It、Manage It、Release It三部作とか、達人プログラマーとかも出てきました。 このあたりの源流を辿ると、そういえば今流行ってる開発の源流としてはエクストリームプログラミングの開発系のプラクティスの遺伝子を受け継いでいるのが多いよな、そういえば当時から見て今ってどう変わっているのかな、という話題に。せっかくなので20年前を思い出しつつ、当時と今でどういう風に変わってきたのか適当にまとめてみます。 20年前の状況 XP白本こと、eXtreme Progra
1. はじめに 仕事の都合で DB/SQL の性能問題を調査する機会が少なくありませんが（決してメインの仕事ではないですが）、その中でよく出くわす問題の１つに「ぐるぐるSQL」（もしくは「ぐるぐる系」）といわれる、ループで大量の SQL 文を呼び出しているものがあります。 感覚ですが、私の周りでは OLTP 系システムの DB/SQL の性能問題の原因の割合は以下のように感じています。 30%：ぐるぐる SQL 20%：SQL 文の書き方が不適切 15%：索引がない or 不適切 15%：パーズが遅い 10%：データモデルがおかしい 10%：その他 （大昔は２番目 / ３番目がほとんどだったのですが、最近はなぜがぐるぐる SQL が多い…） ぐるぐる SQL の実装では、ネットワーク通信や、アプリ側のクエリ生成 / 結果データ構築、DB 側のクエリ受信 / 結果送信といった、処理の本質的で
Amazon DynamoDB の特性 フルマネージド型の NoSQL データベースサービス 3つの Availability Zone に保存されるので信頼性が高い 性能要件に応じて、テーブルごとにスループットキャパシティを定義するキャパシティの Auto Scaling、オンデマンドキャパシティといった設定も可能 ストレージの容量制限がない DynamoDB のテーブル DynamoDB におけるテーブルはRDBMSにおけるテーブルと概念が異なります。 テーブルを作成する際に、Primary Key を指定する必要があります。 Primary Key はテーブルの各項目を一意に識別するために使います。Primary Key は、Partition Key および Sort Key で構成されます。(Sort KeyがなくPartition Keyのみの場合もあります) Item は R
以前は、DDDでどう実装したらいいかなぁって考えてたんだけど、最近は、そういうことへの興味があまりなくなっている。エンティティや値オブジェクト、集約やリポジトリなど、そのあたりにあまり興味がない。ヘキサゴナルアーキテクチャなども、そんなに考えなくなった。 TypeScriptを使うことが多いので、型でしっかり守るとかカプセル化するとか、そのあたりがどっちでもいっかという気持ちになっていることが影響してるとは思う。TypeScriptでクラスを使おうとはあまり思わないし。BrandedTypeみたいなのを使ってまで型で守ろうとは思わない。 じゃあ何に興味があるんだっけ？って考えてみると、トランザクション境界とユビキタス言語かな。 トランザクション境界 トランザクションの境界を作って、DB（RDBMS）を小さく保ちたいと思っている。DBが大きくなると、すぐに複雑になっていく感じがする。 だから
厳格なOLTPと高速なOLAPを両立 新RDBの特徴は厳格なOLTP（オンライントランザクション処理）が可能でありながら、ビッグデータ分析にも使用できる高いOLAP（オンライン分析処理）性能を有していることだ。OLTPとOLAPの両立はHTAP（Hybrid Transaction／Analytical Processing）と呼ぶ。OLTPで用いる行方向のデータは不揮発性メモリーを採用する主記憶（メインメモリー）に格納し、OLAP用の列方向のデータを2次記憶装置に格納する。2次記憶装置にも不揮発性メモリーを使用する。 OLTPに関しては、トランザクション処理の分野で一般的なベンチマークである「TPC-C」において1ノードで1000万トランザクション／秒（TPS）の達成を当面の目標とする。そしてトランザクション処理においては、一貫性と隔離性のレベルを示す「トランザクション分離レベル」が最も
Rustでリレーショナルデータベースを自作したときの成果と反省と学び - Yoshisaurのメモ
はじめに この記事では、個人プロジェクトとしてRust言語でリレーショナルデータベースを開発した経験（もう五ヶ月も前...）について、その成果と反省、得た学びを共有します。 DBMSを自作した理由 自分がDBMSの自作に着手したのは、『Designing Data-Intensive Applications』という本の内容を深く理解するためでした。 この本は、データシステムの設計と運用において最も大切な「信頼性」、「拡張性」、「保守性」を保証する方法論を、豊富な文献を引用しつつ、理論と実践の橋渡しを巧みに行いながら、丁寧に説明している名著です。読んだことがない人は速攻購入してくだい。本当にいい本です。 この本は、データベースの内部構造に関する話も豊富に含まれていたので、「データベース自作してみようか...」という気持ちになりました。 Rustを採用した理由 データベースの実装のついでに、
Transcript SQL 株式会社 AI Shift 三宅 悠太 1. データベース 2. SQL I 3.トランザクション 4. データベース設計 5. インデックス 6. 実行計画 7. SQL II データベース データベースとは “A database is an organized collection of inter-related data that models some aspect of the real-world “ (CMU) データベースとは、実世界のある側面をモデル化した、秩序 だった、相互に関連したデータの集まり DBMS • データベース管理システム（DBMS）は、データベースを管理するソフトウェア ◦ 例：MySQL, Oracle Database, SQLite, MongoDB • DBMSの目的は、アプリケーションが簡単にデータベースにデー
分散データシステム入門の決定版『データ指向アプリケーションデザイン』をたった30分で学んでみた #DataEngineeringStudy | DevelopersIO
基調講演「30分でわかるデータ指向アプリケーションデザイン」 ・ スピーカー 斉藤 太郎氏 Twitter：@taroleo / Github：@xerial Principal Software Engineer , Treasure Data 東京大学理学部情報科学科卒。情報理工学 Ph.D。データベース、大規模ゲノムデータ処理の研究に従事。その後、スタートアップであるTreasure Dataに加わり、アメリカ、シリコンバレーを拠点に活動中。日本データベース学会上林奨励賞受賞。OSSを中心にプログラミングやデータ処理を簡単にするためのプロダクトを作成している。 「30分でわかるデータ指向アプリケーションデザイン」最新の論文にも触れながら、分散データシステムの世界の魅力を伝えていきます。後半、@tagomoris https://t.co/TQ2TnsFIOT… — Taro L.
ID生成方法についてあれこれ
ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に
idをautoincrementして何が悪いの？
idをautoincrementしない方が良い理由 こんにちは。株式会社プラハCEOの松原です。 最近プラハチャレンジの参加者とお話している際に 「PKのidはautoincrementするとして...」 とナチュラルにid=autoincrementするものという前提が見えたので、「本当にidをautoincrementしても良いものだろうか？」と気になったことを書いてみようと思います。もしフレームワークが自動的にautoincrementでテーブルを作るからなんとなく使っているという方がいたらご一読いただいた後、それでも連番を使いたい理由があれば教えて欲しいです・・！ 不必要に情報を晒すことになる スクレイピングされたり もしも僕が某大手に勤めているエンジニアで「競合サービスAにのってる物件情報、全部コピーして新しいサービス作ろうぜ」と指示されたらですよ？「人としてそれはやっちゃダメで
はじめに Herokuの無料枠がもうすぐ消滅する(2022/11/28)ので、ソフトウェアエンジニアリングを勉強中の初学者の方々は、ポートフォリオの置き場所に頭を抱えることが確定しています。本稿では、その代替手段として、お金をかけず、かつなるべくアプリケーションの知識だけで、ポートフォリオの本番稼働を実現できる最適なプラットフォームを決定し、具体的な導入方法までを説明したいと思います。 オルタナティブHeroku まず海外にはオルタナティブHerokuを謳っているプラットフォームはそれなりにあります。その中で無料枠があってポートフォリオを公開するのに適していそうなプラットフォームは以下の通りです。 Cyclic Deta Fly.io Koyeb Railway Render AWSやGCPなどのメジャーなクラウドベンダーの中にも、それに類するサービスは存在しますが、場合によってはコンテナ
前回の転職エントリから3.5ヶ月、すなわちトヨタに入社してから3.5ヶ月が経ちました。 3.5ヶ月間とても気持ちよく働けたので、振り返り記事を書いていきます。座右の銘は「後ろを振り返らない」だったのに、歳を取ると振り返りがちになるんでしょうか。 インターネットの向こうの皆様にもぜひ弊社に興味を持っていただきたいので、弊社の良いなと思うところを書きます。嘘で興味持ってもらっても誰も得しないので、嫌だなと思うところもちゃんと書きます。 目次 前提: 所属とか経歴とか よかったこと1: 機会がめちゃ多い よかったこと2: 分散データ処理屋にとっては最高の戦場では？ よかったこと3: 伸び伸び研究開発させてもらえる よかったこと4: 偉い人はすごい びっくりしたこと1: 同じ会社に知らない部署がすごいある びっくりしたこと2: 組織をまたいだディレクションがすごく緩い ﾁｮｯﾄ嫌なこと1: コミュ
注目すべき最新データベース技術（パート１）
この記事は、著者の許可を得て配信しています。 https://blog.pragmaticengineer.com/the-developer-culture-test/ 私はデータベースの大ファンで、いわゆる「NoSQL」データベースに関する本を書いたり、影響力の高い分散型データベースRiakに携わったりと、技術職として最も実りある年のいくつかを過ごし、昨年は楽しみのためにPurpleというデータベースを構築したりもしました。 当然のことながら、私はTwitterやReddit、HackerNewsなどをさらっと読む場合、データベースやDB関連ツールの新しくて刺激的な開発に常に気にして見ています。今回の記事では、私が興味をそそられる最近登場した3つのデータベース技術についてお話したいと思います。 TileDB Materialize Prisma 後半では次の３つについてお話したいと思っ
［速報］Google、Amazon Auroraに対抗する高性能DB「AlloyDB for PostgreSQL」発表。通常のPostgreSQLよりOLTPが4倍高速、OLAPが100倍高速と
Google Cloudは開催中のイベント「Google I/O 2022」で、PostgreSQLフル互換の高性能な新データベースサービス「AlloyDB for PostgreSQL」のプレビューリリースを発表しました。 Google Cloudは以前からPostgreSQLのマネージドサービス「Cloud SQL for PostgreSQL」を提供しています。今回発表された「AlloyDB for PostgreSQL」は、Googleのクラウドインフラや機械学習の技術を積極的に投入し、より高性能かつミッションクリティカル向けのデータベースサービスとして構築したものです。 AWSと比較するならば、一般用途向けのデータベースサービスである「Amazon RDS」に対抗するのがGoogle Cloudの「Cloud SQL」であり、データベースをクラウドネイティブなアーキテクチャとして
TypeScriptでWebサービス開発（Apollo Server/Prisma/Next.js etc...)
最近開発しているBtoB SaaSサービスの技術スタックを、RailsからNode.jsに移行した。 これにより、フロントエンドもバックエンドも全てをTypeScriptで統一することができた。 特にNode.jsのWebバックエンドの構成について、まだまだ世の中に知見が少ない気がしているので記事にしておく。 Webバックエンド - Node.js(TypeScript) Nexus/Apollo Server (Webサーバー) GraphQLサーバーとして、Apollo ServerのコードファーストなアプローチでのラッパーであるNexusを使っている。 Railsからの移行を決断できたのも、Apollo ServerとPrismaにより、外部との通信が型付きで、かつ開発体験よく書けるようになたから、というのが大きくある。 数年前の段階だと、素のexpressを使ってWebサーバーを立
はてなリモートインターンシップ2021の講義資料を公開します - Hatena Developer Blog
CTOのid:motemenです。2021年8月から9月にかけて開催した「はてなリモートインターンシップ2021」も無事に終了しました。 今年のインターンシップは下記のエントリーで発表したように、前半の1週間が講義、後半の2週間は開発を実践する2部構成で、ともにオンラインで実施しました。 はてなリモートインターンシップ2021のカリキュラムを発表します！ このうち講義パートは、Web技術に関するエンジニアリング講義とブートキャンプ、そしてエンジニアリング以外の領域をとりまぜて実施しました。この記事では、それぞれの講義で使用したスライド資料を公開するとともに、内容を簡単に紹介します。 エンジニアリング講義で使用したスライド資料 Web API ─ REST GraphQL gRPC Webサービスインフラ入門 コンテナ技術とDocker Kubernetesの仕組みとハンズオン マイクロサー
大きく変化した「人とシステム」の関係 企業におけるDX（デジタルトランスフォーメーション）の取り組みが加速する中で、「マイクロサービスアーキテクチャ」（以下、マイクロサービス）の注目度が増している。マイクロサービスは、複数の小さなサービスを組み合わせて一つのシステムを構成するという考え方だ。 マイクロサービスのような「疎結合アーキテクチャ」自体は以前からあるが、「クラウド」「モバイル」といった技術や考え方が普及したことで最近特に注目されている。こう語るのは、Scalarの深津 航氏（CEO、COO＜最高執行責任者＞）だ。 「技術の進歩によって人とシステムの関係が大きく変化した2000年ごろは、社内の情報は社内のシステムに格納され、他社と情報をやりとりするのは主に“人”だった。しかし、2010年ごろになると企業と企業のやりとりも、メールや電話だけでなく、スマートフォンのアプリケーションやWe
こんにちは、しんざきです。週に一回ファミコン版のイーアルカンフーを遊ぶ習慣がもう15年くらい続いておりまして、そろそろ一度知見を集積しようかと思っているところです。面白いですよね、イーアルカンフー。 この記事で書きたいのは、大体以下のようなことです。 ・「評価されやすいエンジニア」とは、「ちゃんと自分の成果を言語化してアピール出来るエンジニア」です ・「アピール」というと苦手意識を持つ人が多いのですが、必要なのは自分を大きく見せることではなく、具体的な達成状況の可視化です ・「自分の成果を言語化出来るか」というのは、日々の仕事で能力を発揮する上でもとても大事です ・成果を言語化する上では、ちゃんと「ストーリー」を考えることも大事です ・ストーリーといっても、別にありもしない物語を作れという話ではなく、組織が持っているビジョンや方向性に合致する成果になっているか、という話です ・特に新人さん
齊藤明紀 on Twitter: "客が逃げにくいようにしてからバンバン値上げというORACLE DB商法が怖いのでOracle Cloudは使う気になれない。「複数のOracleDB利用システムがあれば、全部保守に入るか全部入らないかどっちかしか選べない」とかいろ… https://t.co/PghH9SiMx0"
客が逃げにくいようにしてからバンバン値上げというORACLE DB商法が怖いのでOracle Cloudは使う気になれない。「複数のOracleDB利用システムがあれば、全部保守に入るか全部入らないかどっちかしか選べない」とかいろ… https://t.co/PghH9SiMx0
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
RDBの限界とNoSQLの登場
事実世界のインターネット人口が増えたのは1990年代からだ。 [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h10/html/98wp2-3-1f.html [引用] http://www.soumu.go.jp/johotsusintokei/whitepaper/ja/h29/html/nc144210.html __NoSQL__の登場 1990年に入るとインターネットの利用人口が急激に増加することになる。 この頃からトランザクションに最適化されて設計されたDBでは性能劣化が始まり、システムはデータベースに対しスケール性能を必要とし始める。 多くの開発者は、単一の強力なサーバーでリレーショナル・データベースを実行するのではなく、リレーショナル・データベース管理システム (RDBMS) のパーティショニング (シャー
お久しぶりです、かとじゅん(@j5ik2o)です。テックブログを書くのは何年ぶりか…。 サービスが停止したり応答性が低下すると、お叱りや逆に励ましをいただきますが、エンジニアとして設計レベルからそういった問題に対処するにはどうするか、日々精進しているところですmm。この記事はそういう論点で注目されている「リアクティブ原則」についてまとめてみたいと思います。 それなりのボリュームになってしまったので、時間があるときに読んでいただければと思います。 さて、Linux Foundation内の新たなトップレベルプロジェクトであるReactive Foundationが主催する、Reactive Summit 2020が11月10日にオンラインで開催されたので参加しました。 www.reactivesummit.org 参加されていたスピーカーはLightbendをはじめ、Netflix, Fac
私の Rust 学習記録 2021
※ この記事は 2021/10 時点での内容です。 社内勉強会で 2021 年に発表した内容で、外部公開しようと思って寝かせてしまっていました。 記事としての鮮度は落ちてますが、頑張って書いたものなので Zenn に公開しておきます。 概要 社内異動を機に業務で Rust を書けることになった私の Rust 学習記録です。 今までの言語経験はメインが Ruby、少し JS/TS、趣味で Go をやっていたぐらいです。 学習の方針 なんでもかんでも Rust で書く。 Rust は GC のないシステムプログラミング言語として大体 C 言語と同等のレイヤーからカバーできるので、書こうと思えば OS から Web アプリまで書ける。 yew のような UI 構築用のライブラリもあるので、フロントエンド開発もできる。 というわけでなんでもかんでも Rust で書ける。 リポジトリ運用 デプロイの
こんにちわ。せじまです。今回は地味で泥臭い話をします。ただ、割と平易な内容かと思いますので、初学者の方にもオススメです。 はじめに ゲームでは、受取期限のついたログインボーナス的なものがよくあります。ユーザが期限までに受け取らないと、ユーザからそのデータは不可視になりますが、必ずしも、不可視になった瞬間にデータベースから直ちに削除される、というわけでもありません。バッチジョブか何かで、ガベージコレクションのように削除するケースが多いのではないでしょうか。 また、論理削除という概念もあります。論理削除についてはいろいろ意見や考え方があるかと思いますので、ここでそれについては論じませんが、「削除フラグが立ってユーザから不可視になった後、三ヶ月以上経過したデータを削除したい」みたいなことは、ゲームに限らず、しばしばあるんじゃないかなと思います。 こういった、ユーザから不可視になってしばらく経過し
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQLロックについて〜基礎編〜 を開催しました！ - ANDPAD Tech Blog
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔（Tsurugi）」を開発
SELECT ... FOR UPDATE同士でデッドロックさせる - かみぽわーる
RDBアンチパターンと戦う - 削除フラグ 完全攻略ガイド / delete flag
Goで作るテキストエディタ - Sansan Tech Blog
障害対応時にまずはissueを作ると良い - そーだいなるらくがき帳
そろそろSQLのウィンドウ関数を理解したい - 連載1/3話 - Qiita
RDBMS in Action
キャッシュを活用するために必要な知識と勘所 - そーだいなるらくがき帳
業界6年目で考えが変わったソフトウェア開発のトピック
データベースと向き合う決意 | フューチャー技術ブログ
理屈で考える、データベースのチューニング / Database tuning How-To
20年でソフトウェア開発の景色はどのぐらい変わったのか？ - Qiita
ぐるぐるSQLは止めてくださいという話 - Qiita
DynamoDB の設計について考えてみる。 - Qiita
DDDの実装にはあまり興味がなくなっている - Mitsuyuki.Shiiba
NEDOが25億円投じ日の丸RDBを開発中、「国産にも勝機あり」と自信を見せる理由
SQL Training 2021
サヨナラHeroku 〜アプリケーションの知識だけで本番稼働を実現できる無料のプラットフォームを追い求めて〜
トヨタの3.5ヶ月のソフトウェアエンジニア（研究開発）生活を振り返る
マイクロサービス化による「DB分割」で開発、運用が難しくなるこれだけの理由
評価されやすいエンジニアとは、成果を効果的にアピール出来るエンジニアのこと。
データベースのドキュメント管理を自動化した話 - estie inside blog
リアクティブは難しいが役に立つ - Chatwork Creator's Note
受取期限の過ぎたデータをMySQL上から削除する話 | GREE Engineering