pictBLandとpictSQUAREに対する不正アクセスがあり、パスワードがソルトなしのMD5ハッシュで保存されていたことが話題になっています。 2023年8月16日に外部のフォーラムにpictSQUAREより窃取した情報と主張するデータ販売の取引を持ち掛ける投稿が行われた(中略)パスワードはMD5によるハッシュ化は行われているもののソルト付与は行われていなかったため、単純なパスワードが使用されていた29万4512件は元の文字列が判明していると投稿。(それ以外の26万8172件はまだMD5ハッシュ化されたままと説明。) 不正アクセスによるpictBLand、pictSQUAREの情報流出の可能性についてまとめてみた - piyolog より引用 これに関連してMD5ハッシュやソルトに関するツイート(post)を観察したところ、どうもソルトの理解が間違っている方が多いような気がしました。
はじめに 今回は各大学が公開している、エンジニア向けの資料をまとめていきます。 東京大学 ChatGPT活用法 ChatGPTの基礎的な内容から実際にどのように活用すべきかが解説されている。 Pythonプログラミング入門 Pythonについて環境構築から始まり、基本文法、応用的な使い方まで分かりやすく解説されている。 AWS入門 ハンズオン形式でAWSの学習ができる。 AI・データサイエンスの活用事例 データサイエンスやAIの活用事例を学べる。 人工知能・深層学習を学ぶためのロードマップ AIやデータサイエンスの具体的な活用事例が学べる。 京都大学 プログラミング演習 Python 統計学 統計学やデータ分析、検定を学べる。 慶應大学 ChatGPTの活用資料 ChatGPTを用いた開発方法が学べる。 東京工業大学 機械学習 筑波大学 データベース データベースの基本から正規化や設計とい
すべてのフェーズでミスが重なった ―全銀ネットとNTTデータ、全銀システム通信障害の詳細を説明 全国銀行資金決済ネットワーク(以下、全銀ネット)とNTTデータは12月1日、2023年10月10日~11日にかけて全国銀行データ通信システム(以下、全銀システム)で発生した通信障害に関する報道関係者向けの説明会を開催しました。本件についてはNTTデータが11月6日に行った途中経過報告の内容をもとにレポートしましたが、今回、全銀ネットとNTTデータが揃って会見を行ったことで、より詳細な障害の原因が判明したので、あらためてその内容を検証してみたいと思います。 説明会の登壇者。左から、全銀ネット 企画部長 千葉雄一氏、事務局長兼業務部長 小林健一氏、理事長 辻松雄氏、NTTデータ 代表取締役社長佐々木 裕氏、取締役副社長執行役員 鈴木正範氏 なお、全銀ネットとNTTデータは、今回の障害に関して金融
はじめに 本稿では分析用クエリをスラスラ書けるようになるまでの勉強方法や書き方のコツをまとめてみました。具体的には、自分がクエリを書けるようになるまでに利用した教材と、普段クエリを書く際に意識していることを言語化しています。 想定読者として、SQLをガンガン書く予定の新卒のデータアナリスト/データサイエンティストを想定しています。 勉強方法 基礎の基礎をサッと座学で勉強してから、実践教材で実際にクエリを書くのが望ましいです。 実務で使える分析クエリを書けるようになるためには、実務経験を積むのが一番良いですが、だからといって座学を御座なりにして良いというわけではありません。SQLに自信がない人は、一度基礎に立ち返って文法の理解度を確認した方が良いと思います。 書籍 SQL 第2版: ゼロからはじめるデータベース操作 前提として、SQLに関する書籍の多くがデータベース運用/構築に関する書籍がほ
はじめに タスク管理はクリエイターの永遠の課題だと思います。 普段の案件に関するタスクはもちろんですが、案件とは関係ない事務作業やデータの整理、後で読みたい記事、試してみたい技術など、私たちには様々なタスクがあります。 膨大なタスクを管理する方法を日々模索し続け、ようやく自分の中で「これ!」というのが固まってきたので、私なりのNotionを用いたタスク管理方法を解説していこうと思います。 Notionとは 様々な情報やドキュメントを一元管理できるサービスです。公式サイトに書かれている通り、様々なドキュメント管理ツールをひとつに集約したのがNotionになります。 日々の業務は「案件に関するタスク」と「案件とは関係ないタスク」の2つに分けられます。 「案件に関するタスク」は期日や案件の詳細情報、自分の担当範囲などを分かりやすく管理することが重要です。「案件とは関係ないタスク」は業務改善や事務
これはなに ども、レバテック開発部のもりたです。最近めっちゃ元気!! 今回は『データベースについて勉強したいあなたに送る技術書17冊(+11冊1講義7link)』として、もりたがここ半年くらいでわーっと集めたデータベース周りの書籍(とか)を紹介していきます。アプリケーションって結局はデータベースみたいなところがあると思うんですが、おれは長いことデータベースをどう学んだら良いのか分かりませんでした。同じような気持ちを抱えているITエンジニアの人もいると思うので、学習ロードマップと合わせて紹介していきます。 なお具体的な対象読者は業務でなんとなくSQL書いてるけど、ウィンドウ関数とか言われると分からんな……くらいの人です。 扱う領域と扱わない領域 扱う領域としてはだいたい以下 再入門本 SQL 内部構造 論理設計 周辺知識 データベース理論 その他高度なもの モデリング、NoSQL、分散データ
先日は住所の件でお楽しみでしたね。 私も楽しくなってしょうもないツイートをしたところ、@masanorkさんから有用な情報をいただいてしまいました。 異体字に加えて外字も根深いですし、日付型に収まらない住基の生年月日とか、屋号を含んだ個人事業主の口座名義とか、外国人氏名における住民登録のアルファベットと口座名義のカタカナとの解離とか、旧姓併記の例外処理とか、文字列型に刻まれたバッドノウハウの塊ですね https://t.co/GOaytijfst — Masanori Kusunoki / 楠 正憲 (@masanork) June 6, 2023 このとき、私はごく簡単な「名寄せの難しさ」の社内研修資料を作っている最中だったのですが、この情報が大変参考になりました。 一方、私だけが得をしているのがなんとなくムズムズしてきたので、ここにアウトプットしてスッキリしようと思います。 なお、住所
はじめに 『達人に学ぶSQL徹底指南書 第1版』は、CodeZine連載とミック氏ウェブサイトの掲載記事をもとに、加筆・編集されたものです。 CodeZine連載、および、ミック氏ウェブサイトは、どちらもオンラインの無料公開コンテンツです。 今回、「書籍と元コンテンツの対応表」を作成しました。 書籍のために書き下ろされた一部コンテンツや演習問題は見れませんが、その一方、編集で割愛された内容などが含まれるので、書籍以上のことを学べる箇所もあります。 すでに新版『達人に学ぶSQL徹底指南書 第2版』が出ていますが、各テーマは第1版でも大きく変わっておらず、現在でも通用する基本的で面白い内容なので、一見の価値はあると思います。 書籍と元コンテンツの対応表 No. 目次 CodeZine連載 ミック氏ウェブサイト テーブル定義 サポートページ
これはなに ども、レバテック開発部のもりたです。 今回はSQLのサブクエリについてまとめます。仕事でクエリを書く際、サブクエリは頻出の構文だと思うんですが、同時にサブクエリの書き方を完全に理解しているよという人は案外少ないのではないでしょうか?[1] 実際、MySQLの公式ドキュメントを見ると12ページくらいを割かれており、意外と奥深いのがサブクエリです。使いこなせると便利ですし、何よりちょっとSQLのコツみたいなのがわかって面白いよ、ということで記事にしてみました。 前提 この記事は以下の前提を含んでいます。 環境 MySQL8.0系 読者の知識 なんとなくサブクエリが書ける けど相関サブクエリとかになると「あーっ」つってGoogle meetを閉じてしまうくらいのレベル感 記事のボリューム 18,000文字 おれの卒論が20,000文字だった マサカリ 間違ってたら投げてくれ〜〜 それ
GitHub、1200台以上のMySQL 5.7を8.0へアップグレード。サービス無停止のまま成功させる GitHubが提供するGitHub.comは、世界最大のソースコード管理システムを始めとするソフトウェア開発者向け支援サービスを提供しています。 そのGitHub.comはRuby on Railsで構築されており、同社はつねにRubyとRuby on Railsをアップデートし続けていることを今年(2023年)4月に明らかにしています。 参考:GitHubは200万行規模のRailsアプリケーションであり、毎週RailsとRubyを最新版にアップデートし続けている そして同社はこのGitHub.comを支える1200台以上のMySQL 5.7を、GitHub.comのサービスレベルを維持したまま1年以上かけてMySQL 8.0にアップグレードしたことをブログで明らかにしました。 Up
2023/10/18 歴史的地名の「行政区画変遷」を大規模オープンデータ化 ~『日本歴史地名大系』を平凡社地図出版との協働により機械可読データとして強化~ 情報・システム研究機構 データサイエンス共同利用基盤施設 人文学オープンデータ共同利用センター(以下ROIS-DS CODH、センター長 北本朝展)と株式会社平凡社地図出版(代表取締役 西田裕一)は、『日本歴史地名大系』の機械可読データ化に向けた協働を推進し、このたび歴史的地名の「行政区画変遷」に関する大規模オープンデータを公開しました。 『日本歴史地名大系』(用語解説1)とは、全国の歴史研究者の協力を得て地名研究・地域史研究の全成果を結集し、株式会社平凡社が25年(1979年~2004年)をかけて出版した50巻51冊の地名辞典です。この地名辞典の編集にかつて関わった人々の全面的な協力を得て、地名辞典の内容の更新や位置情報(緯度経度)の
個人的なJavaScriptの情報収集の方法についてまとめてみます。 JSer.infoなどをやっているので、JavaScriptの情報については色々な情報源を見るようにしています。 JSer.infoの範囲の中での情報源については、次の記事でまとめています。 JSer.info 13周年: JavaScriptの情報源を整理する - JSer.info この記事では、少しスコープを広げてJavaScriptの情報収集についてまとめてみます。 かなりスコープが広がってしまうので、万人向けの方法ではなく、個人的な情報収集方法としてまとめています。 この記事では、膨大な情報の中から見つけるというアプローチをとっているので、人によって向き不向きがあると思います。 情報収集の方法 情報の元となる情報源はさまざまなサイトや人になると思います。 しかし、そのサイトや人ごとに見ていくというのはかなり大変
はじめに みなさんはDBのインデックスを正しく使えていますか? 私はなんとなく「DBのパフォーマンスを向上するためのもの」という認識はあったのですが、 どのような場面で使うものなのか、逆にどのような場面では使うべきでないのかなど 明確に理解できていませんでした。 今回はそんなインデックスについての理解を深めたいと思います。 インデックスとは インデックスとは、その名の通り「索引」です。 表現の仕方と変えると、(x, a)という形式の配列であるとも言えます。 xというキー値とそれに結びつくaというデータ情報があり、 これを利用することですべてのデータを網羅して見ることなく、 まさに本の索引のように目的のデータにたどり着くことができます。 インデックスはSQLのパフォーマンスを改善するための非常にポピュラーな手段であり、 理由としては下記の3点が挙げられます。 アプリケーションのコードに影響を
質問されることが多いのでPostgreSQL初学者が運用を行うためにしっておく知識に必要な内容をまとめる。 PostgreSQLの基本的なアーキテクチャ PostgreSQLのアーキテクチャを知らないと自分がやっている作業が危険な作業かどうかわからないし、パラメータの意味もわからない。 そこで以下のリンクを読むと良い。 富士通が後述の資料を参考にまとめたのだろうなと思われる記事。 非常によくまとまっているのでわかりやすい。 www.fujitsu.com もっと細かく知りたいならPostgreSQL Internalsがおすすめ。 富士通の資料と重複するところがあるがこっちが本家。 Githubで管理されているので誤字脱字などあったら気軽にPRを出してほしい。 www.postgresqlinternals.org PostgreSQL Internalsが少し古いので最新事情で知りたい場
# 参考資料 - 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
近年のデータベースの新潮流にNewSQLと呼ばれる一群のデータベース製品群の登場がある。そのコンセプトを一言でいうと、RDBとNoSQLのいいとこどりである。SQLインタフェースと強いデータ一貫性(ACID)というRDBの利点と水平方向のスケーラビリティというNoSQLの長所を兼ね備えた夢のようなデータベースである。下図に見られるように、RDBとNoSQLが鋭いトレードオフを発生させていたのに対して、NewSQLではそれが解消されているのが分かる。 RDB vs NoSQL vs NewSQL本当にそのような夢の実現に成功しているか、というのはまだ議論が続いているが(クエリのスループットを出すためにレイテンシを犠牲にしているので本当にトレードオフを解消はしていない、などの問題が指摘されている)、商用でも利用可能な製品としてGoogle Spanner、TiDB、YugabyteDB、Coc
データベースとテーブルの作成 テスト用のデータベースtestdbを作成し、パフォーマンスチューニングを検証するためのcompanyおよびpersonテーブルを定義します。 CREATE DATABASE testdb; USE testdb; CREATE TABLE company ( company_id INT AUTO_INCREMENT PRIMARY KEY, company_name VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE person ( person_id INT AUTO_INCREMENT PRIMARY KEY, company_id INT, person_name VARCHAR(255) NOT NULL, email VARCH
MySQLのインデックスですが、B-treeではなくB+treeを使用するのはどうしてなのでしょうか? 端的に言うと性能が良いからです。 これを理解するにはバッファプールへの理解が必要です。ディスク指向のデータベースの上では有限のメモリを最大限活用することでメモリに入り切らない巨大なデータ群に対して良好な参照性能を出す必要があります。バッファプールとはディスク上のデータの羅列を固定サイズのページ(InnoDBの場合16KB)の羅列であるとして読み書きに必要な分だけをメモリに移し取り複数の書き込みをできる限りメモリ内で受け止めて後でまとめてディスクに書き戻すという、ライトバック型のキャッシュのような機構です。 この中においてバッファプールは有限のサイズしか無いので適宜プール内のデータを書き戻して入れ替えながら上手くやっていく必要があります。 さてB+treeとB-treeの最大の違いは木のリ
Webシステムにおいて「画像や帳票等のファイルはDBへ格納すべきなの?」を調べてみた(ファントムファイル)oracleWeb この記事は、 JPOUG Advent Calendar 2023 24日目の記事です。 23日目は multilayer さんの記事『OCIのLanding Zoneについて調べてみた!』でした。 想定読者 ファントムファイルについてよく知らない、帳票の扱い方をあまり考えたことがない人 イントロダクション 皆さん、世の中のWebシステムで利用される画像や帳票ファイルがどこに保存されているかご存知でしょうか? 帳票や大きな画像ファイルなどを扱う際、大きく分けて2つの設計方針があります。 ・DBに直接保存する ・DB外部に保存し、パスなどをDBに保存する オライリーのSQLアンチパターンの、”ファントムファイル”という章にはこのあたりのことが書いています。 [Amaz
はじめに 最近エンジニア界隈では「リーダブルコード」が話題なっていますね。 リーダブルコードでは、このような定理が紹介されています。 「コードは他の人が最短時間で理解できるように書かなければいけない。」 Dustin Boswell リーダブルコード P.3 より引用 SQLでも同じことが言えそうです。 リーダブルなSQLを書いてないと結婚できない時代が今まさに到来しようとしています。 皆さん、クソSQL1を読んだことがありますね? クソSQLを書いたことがありますね? 僕は、あります。 そこで、本記事ではどうしたらリーダブルなSQLが書けるかというアイデアを紹介します。 処理の流れの順に上から読めるようにする 人間のメンタルモデルは、問題やタスクを小さなステップに分割し、それぞれを順番に実行することに適しています。 サブクエリを使ったSQLでは、処理の流れは上から下ではなく、ネストされた
SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBのCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基本的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre
DB設計の管理や作成に疲弊してません?こんにちは。ukmshiです。今日はDB設計の共有と管理に便利なツール、dbdocsについてお話しします。dbdocsを使えば、設計の可視化や共有がめちゃくちゃ簡単になるんです。今回は、その魅力と利点、そして実際の使い方について詳しく説明します。 dbdocsとは? dbdocsは、コードベース(DBML)でDB設計を管理し、URLで共有することが可能なツールです。データベースのテーブル構造や関係性を可視化し、それを他のチームメンバーやステークホルダーと手軽に共有することができます。 DBMLについてはこちらを参考に dbdocsの利点 dbdocsの利点について詳しく見ていきましょう。 無料 まず最初に、dbdocsは基本無料です。コストを気にせずに利用できるので、チームの誰もがアクセス可能です。 コードベースで管理 dbdocsはコードベースでDB
概要 この記事では、SQLクエリをより効率的に記述するためのベストプラクティスとテクニックに焦点を当てています。データベースのクエリはシステム全体のパフォーマンスに直結するため、最適な書き方を知ることは重要です。インデックスの効果的な活用方法、適切な結合の選択、そして条件の効果的な書き方など、SQLの最適化に関する具体的な手法を解説します。各SQL文に関する実行計画の結果も掲載していますので、ぜひご確認ください。 なお、Oracle19cとOracle12cでの利用実績がありますが、他のデータベースやバージョンにおいての検証は行っておりません。 新しい情報は随時追加されますので、お楽しみにしてください。 SQLの最適化に関連する基本的なアイデア 以下の通りと考えています。 1.インデックスの利用 2.正しいJOINの選択 INNER JOIN、LEFT JOIN、RIGHT JOINなど、
こんにちは、一休.comスパ(以下、「スパ」)の開発を担当しているshibataiと申します🙏 今回はスパのデータベースの在庫の持ち方で試行錯誤した話をさせていただきます。 背景 2024-03-29追記: 一休.comスパにおける在庫の特徴について 一休.comスパが扱う「在庫」は、「ある日付の特定の時間に対する空き枠」です。以降の説明では、スパ施設ごと、日付ごと、また時間ごとに増えていく「在庫」をいかに効率よく扱うかについて説明しています。 詳細については次のスレッドも参照してください! https://t.co/Y0SPmDE4yZ この記事のコメントみてると、少し我々のシステムの要件が伝わってないというかそこの説明が記事に不足しているように思った。ので以下その補足— naoya (@naoya_ito) March 29, 2024 現在の実装 スパは予約を受け付けるために在庫の
世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」を開発― 処理性能456万TPSと応答遅延219ナノ秒を実現 ― 日本電気(株)と(株)ノーチラス・テクノロジーズはNEDOの「高効率・高速処理を可能とするAIチップ・次世代コンピューティングの技術開発」(以下、委託事業)において、世界最速レベルの性能を持つリレーショナルデータベース管理システム「劔(Tsurugi)」(以下、劔)を開発しました。 劔は、次世代のデータベースに用いられるハードウエア環境(メニーコア・大容量メモリーなど)に適合したシステムであり、ハードウエアの性能が向上するほどシステムの性能も高まる特性を有しています。32以上のコア数を有するハードウエアにおいては、世界最速レベルの処理性能456万TPSと219ナノ秒の応答遅延を実現しました。 劔の導入によって、複雑なバッチ処理とオンライン
はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
どうもキャッシュバスターズ、 id:Soudai です。 Cache(以下、キャッシュ)は特定の場面に置いて劇的な効果を発揮し、様々な問題を解決する反面、新たなコンポートやミドルウェアが追加され、複雑性が上がり、運用のレベルが上がるため、扱いに注意する必要があります。 キャッシュを活用することで、パフォーマンスの改善や負荷軽減が行われ、コンピュータリソースの最適化によるサーバコストの削減や、レスポンスの改善によるユーザエクスペリエンスの改善がされます。 反面、その劇的な効果に毒され安易に多用すると、サービスが強くキャッシュに依存してしまい、非常に壊れやすくなり、運用が難しくなってしまいます。これをWeb界隈では「キャッシュは麻薬」と比喩されて、戒められてきました。 そのためキャッシュを使わずにサービスが運用できるのであれば使わないに越したことはないのですが、ある一定以上の規模になった際にコ
はじめに 「テーブル・DBを設計するときのさいきょうの極意」を完全に理解したので 初心者(私)向けに共有する記事です。 どうぞ揉んでいただければ幸いです。対戦よろしくお願いします。 さいきょうの極意 初心者が「テーブル・DB設計して」と言われると、 「アソシエーションってあったよね・・・バリデーションも?中間テーブルを使うときと使わないときと・・・」と大変に混乱し、何から手をつけていいかわからなくなります。 そんなあなたにこれ! テーブル・DB設計は「属性」と「関係」の2つだけ 「属性」は必要なものを書くだけ 「関係」は 1:1 / 1:N / N:N しかない(しかも、ほとんど 1:N) これが極意だ!!! 一般的な、「ユーザーがいて、投稿ができて、コメントといいねができるサービス」で考えてみましょうか。 users / posts / comments / likes のテーブルが必要
はじめに Web技術は日進月歩で新しい技術が増えているが、実務でそれらすべてを触る機会はない。そこで、今回の記事では2023年下半期に赤の他人に勧めたいWeb技術を個人の独断と偏見で解説する。 対象者 これから何をすればいいのかわからないプログラマー 新しい技術に興味があるひと スキルセットを拡大したいひと タイトルでなんとなく気になったひと フレームワーク FastAPI FastAPIはPythonでAPIを開発するために開発された軽量のWebフレームワークだ。FastAPIでは、主に以下の特徴がある。 Node.jsやGo言語に匹敵する高速なアプリケーションを開発できる 構造が簡単(Flaskの影響を受けている) Pythonに型定義を含められる 環境構築がコマンド一つで終了する 非同期処理を簡単に実装できる Pythonで開発されているので、機械学習との相性が抜群 RESTとGra
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く