Webサービスのフォームに住所を入力するとき、丁目や番地などを入れる欄について、数字やハイフンを全角で書かなければいけない「全角縛り」をやっているフォームをよく見ます。半角文字を入力してしまってエラーになったり、咄嗟に変換方法を思い出せなかったり、全角と半角の見分けが付きづらかったり、「全角縛り」であることが明示されていなかったり、「ハイフン」としてどの文字を使うべきかわからなかったり……と、鬱陶しさを感じることが多くあります。 「住所は全角のみ」（数字やハイフンも絶対に半角を受け付けない）という仕様がどういう経緯で生まれて、どう広まっていったのかが気になってる。いま存在しているのは過去の仕様や慣習の踏襲として理解できても、そもそもなぜそれらが生まれたのかが理解できない。 https://t.co/ZLz0Pw9GOK — ymrl (@ymrl) July 29, 2024 これについて

はじめに データベース（DB）の設計は、システムの性能や保守性に大きな影響を与えます。 この記事では、最低限パフォーマンスの低下や管理の複雑化を引き起こさないようにするために覚えておくべきことを、アンチパターンとしてまとめました。 本記事は、 現在仕事でデータベースを扱っており、データ設計について今一度おさらいしたい データベースについての基礎知識やお作法を身に付けたい という人を対象として想定しています。 これらに当てはまる方はぜひ一度確認してみてください！ 弊社Nucoでは、他にも様々なお役立ち記事を公開しています。よかったら、Organizationのページも覗いてみてください。 また、Nucoでは一緒に働く仲間も募集しています！興味をお持ちいただける方は、こちらまで。 DB設計アンチパターン 早速、DB設計におけるアンチパターンを紹介します。 それぞれアンチパターンのテーブルを見て

はじめに みなさんはDBのインデックスを正しく使えていますか？ 私はなんとなく「DBのパフォーマンスを向上するためのもの」という認識はあったのですが、 どのような場面で使うものなのか、逆にどのような場面では使うべきでないのかなど 明確に理解できていませんでした。 今回はそんなインデックスについての理解を深めたいと思います。 インデックスとは インデックスとは、その名の通り「索引」です。 表現の仕方と変えると、(x, a)という形式の配列であるとも言えます。 xというキー値とそれに結びつくaというデータ情報があり、 これを利用することですべてのデータを網羅して見ることなく、 まさに本の索引のように目的のデータにたどり着くことができます。 インデックスはSQLのパフォーマンスを改善するための非常にポピュラーな手段であり、 理由としては下記の3点が挙げられます。 アプリケーションのコードに影響を

はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名（サービス名） データソース : データ処理 : アウトプット : 画像 URL 2025年 2024/03/14 : 株式会社エス・エム・エス（カイポケ） データソース : Amazon Aurora データ処理 : Datastream、BigQuery、dbt アウトプット : Looker Studio 2024/03/12 : 株式会社マイナビ データソース : SQL Server、Amazon S3 データ処理 : Embulk、Amazon MWAA、Apache Airflow、Snowf

PHPerKaigi2024 の登壇資料です。 履歴データテーブルとの向き合い方 https://fortee.jp/phperkaigi-2024/proposal/47cf9f17-825a-4021-bf33-86e4a62bc222

PHPカンファレンス関西の登壇資料です。 WEB+DB PRESS Vol.134に詳細があります https://gihyo.jp/magazine/wdpress/archive/2023/vol134

はじめに Nostrという、SNSのようなものはご存知でしょうか？ ご存知でなければ、ぜひまず一度触ってみることをお勧めします。 割と普通にSNSっぽく使えます。 分散系SNSっぽいシステム Nostrは、分散系のSNSっぽいネットワークです。 図で表すとこんな感じ。普通に想像するWebサービスとは随分形が違うと思います。 各所のリレーサーバーに、ユーザーは投稿をばらまき、ユーザーがそれを見る形です。 分散の責任がユーザー(クライアント)側にあって、リレーサーバーが落ちたり消えたりしても影響が起きにくい仕組みです。 より詳しい説明は上記でやってるのですが、端的に言って 中央管理者がいない(各リレーに管理者はいる) 冗長で災害に強い Websocketのリアルタイム通信 オープンでシンプルで、でも拡張し放題な仕様 数多のサーバーによる分散ネットワーク といった特徴があります。 ※P2P技術は

データベースシステムに関する入門。データベースの基本概念、データモデリング、リレーショナルデータモデル、データベース言語SQL、リレーショナルデータベース設計論、物理的データ格納法、問合せ処理等について講述する。 （2018年度） 【教科書】 「データベースシステム」(北川博之著、オーム社) 北川 博之筑波大学　計算科学研究センター教授1978年東京大学理学部物理学科卒業。1980年同大学理学系研究科修士課程修了。日本電気（株）勤務の後、筑波大学電子・情報工学系講師、同助教授を経て、現在、筑波大学計算科学研究センター教授。理学博士（東京大学）。データベース、データ統合、データマイニング、ストリーム処理、情報検索、ビッグデータ等の研究に従事。著書「データベースシステム」（オーム社）等。日本データベース学会会長、ACM SIGMOD日本支部委員長等を歴任。情報処理学会フェロー、電子情報通信学会

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

Instagramは2010年10月にサービスを開始後、2011年12月までのわずか1年間で1400万人に利用されるほど巨大なサービスに成長しました。こうしたスケールに対応できるシステムを組み上げたのはたった3人のエンジニアだったとのことで、どのように少人数でスケールするシステムを組み上げたのかについて、エキスパートエンジニアのレオナルド・クリードさんが解説しています。 How Instagram scaled to 14 million users with only 3 engineers https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million レオナルド・クリードさんは、Instagramが3人のエンジニアで安定して巨大なサービスを提供できた理由として、下記の3つの原則を守ったからだと述べています

YAMLは「便利なJSON」として使われることが多い一方、その複雑性から落とし穴も多く、しばしば批判の対象になります。 なぜYAMLはそこまで複雑なのでしょうか? その背景のひとつは、本来のYAMLがJSONとは大きく異なる目的意識で作られているからです。 本稿ではYAML specに従う形でYAMLのコンセプトを解説することを目指します。残念ながら、ここに書かれているYAMLの思想は実際には実用されているとは言い難いですし、これらの背景を理解しても「YAMLは複雑だ」という事実がひっくり返ることはないでしょう。それでも、YAMLの複雑さの源泉を体系的に理解し、YAMLとほどほどの距離感で付き合う助けにはなるのではないかと思います。 この記事ではこういう話をしますYAMLはJSONとは独立に、異なる目的で生まれた野心的な仕様であるアンカーやタグなどの強力な構文は、これらの目的を満たすために

まいえすきゅーえりたい　ぽすぐれない　おらくるってる（狂ってる）tomoです。 今日はいつものMySQLリファレンスを読むではなく、夏休みの宿題にしていたこれをやってみます。 MySQLとOracleDBの実行計画を比較してみた さて同じようなテーブルで同じデータを載せて。 実行計画を取ってみた時、どのくらい情報量が違うのか簡単に違いを見てみましょう。 前提として、以下をご認識ください。 一方はOSSのDBエンジン、もう一方はガチガチ商用DBエンジンです。情報量が違うのは当たり前であって、良し悪しを比較したいのではありません。そして製品比較をしたいのではありません。いつも商用DBメインで使っているエンジニアが、OSSのDBにこうゆう情報も出してほしいな！というのをお願いしたいと思っていて、それを考える元ネタメモだと思ってください。 OSSでこれだけの情報出せるMySQLや、今回紹介しません

PostgreSQLには、用途や環境に応じて様々な構成を組み、最適なパフォーマンスで動作させられるよう、設定ファイルpostgresql.confに多くのパラメーターが存在します。そのパラメーターを正しく設定し調整を行うためには、PostgreSQLのアーキテクチャーを理解する必要があります。ここでは、押さえておきたい、PostgreSQLの基本的なアーキテクチャーについて説明します。なお、この記事で対象にしているPostgreSQLのバージョンは9.5以降です。 1. PostgreSQLの基本構成 PostgreSQLの基本的な構成について説明します。はじめに、主なプロセス、メモリー、および、ファイルについての構成図を示します。 図1 PostgreSQLの基本構成 PostgreSQLを構成する主なプロセス、メモリー、ファイルについて、その用語と概要を説明します。 リスナープロセス

「デザイナーこそ、スプレッドシートに強くなれ」とずっと言い続けています。先日、とあるセミナー（#D2デザインダンジョン）で発したところ、「具体的にはどういうことでしょうか？」と質問いただきました。 よい機会なのでまとめてみました。重要なのは、スプレッドシートは数字はもちろんだけど、数字以外でも使いますよね、ということです。 なお、この記事では、次をまとめて「スプレッドシート」と記します。 Excel（デスクトップ版、オンライン版） Google スプレッドシート スプシ 表計算 Apple Numbers 「スプシ」という言葉には、なかなか慣れません… スプレッドシートは「思考の道具」である私自身、「マインドマップ」はよく使います。 マインドマップは思考を“発散”するには向いていますが、“収束”には不向き。たとえば、異なる“枝”のアイテムの関係性を表現できません。 詳しくは、こちらの記事に

最近、「AIを理解したくて代数幾何の教科書を勉強しているんですよ」という人によく会う。 五年前くらい前に、note株式会社の加藤社長も「社内で代数幾何学の勉強会を開いてるんですよ」と言っていた。僕はその都度「それは全く遠回りどころか明後日の方向に向かってますよ」と言うのだがなかなか聞き入れてもらえない。 確かに、AI、特にディープラーニングに出てくる用語には、ベクトルやテンソルなど、代数幾何学で使う言葉が多い。が、敢えて言おう。 代数幾何学とAIはほとんど全く全然何も関係していないと。 なぜこのような不幸な誤解が生まれてしまうかの説明は後回しにして、意地悪をしても仕方ないので、AIを理解するために最低限知っておかなければならない用語を5つだけ紹介する。 テンソル(スカラー、ベクトル、行列など)おそらく、「テンソル」という言葉が人々を全ての混乱に向かわせている。 Wikipediaの説明は忘

ID生成について聞かれることが多いので、独自の観点でまとめてみます。タイトルは適当です…。 DBはMySQL(InnoDB)を想定しています。あしからず。 ID生成を知りたいなら ID生成に関しては以下の記事がよくまとまっているので参考にしてみてください。値形式など詳しく書かれています。 ID生成大全 Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ ID生成方法 以下のID生成方法は、お手軽に採用しやすいもの順で列挙します。 DB採番/連番型 AUTO_INCREMENT DBのAUTO_INCREMENTで採番する方法。 Pros 数値型で扱える 普通は64ビットの整数型を採用することが多い 単調増加する連番ですので、ソート可能でかつインデックスの空間効率がよい 単調増加するので、キャパシティを予測しやすい 64ビットあればあまり気に

セッションIDやアクセストークン、はたまた業務上で使う一意の識別子など、いろんなところで一意のIDを生成しなきゃいけないケースが存在します。 そこで世間で使われているIDの生成方法について調べてみました。 選択基準 ID生成における要求として、以下の観点が上げられるかと思います。 生成の速度 大量にデータを短期間で処理し、それらにIDを付与する場合、ID生成そのものがボトルネックとなることがあります。 推測困難性 IDを機密情報と結びつける場合、IDを改ざんされても、機密データが見れないようにできている必要があります。 順序性 採番した順にデータをソートする必要がある場合は、IDがソートキーとして使えないといけません。 それぞれについて各生成手段を評価します。 ID生成の手段 データベースの採番テーブル 採番用のテーブルを作り、そこで番号をUPDATEしながら取得していくやりかたです。古い

統計データを用いた分析事例を知り、 統計リテラシーを学ぶ ・大人がデータサイエンスを学ぶべき理由 ・統計データからわかること① ・統計データからわかること② ・統計データからわかること③ ・統計リテラシーの重要性 ・統計を利用する際の注意点 データ分析に必要な統計学の基礎を学ぶ ・データの種類 ・代表値～平均・中央・最頻値 ・ヒストグラムと相対度数 ・四分位・パーセンタイル・箱ひげ図 ・分散・標準偏差 ・相関関係 ・回帰分析 ・標本分布 ・信頼区間 データの見方と 適切なグラフの選び方を学ぶ ・統計表の見方 ・比率の見方①－クロスセクションデータ－ ・比率の見方②－使い方と注意点－ ・時系列データの見方① ・時系列データの見方② ・グラフの選び方① ・グラフの選び方② ・グラフを作る時・読む時の注意点 誰もが使える公的統計データの取得方法と 使い方を学ぶ ・公的統計とは ・公的データの入手

こんにちは。エンジニアの谷井です。 フォルシアでは、Spookと呼んでいる技術基盤を用いて、主に旅行業界やMRO業界に対して、膨大で複雑なデータを高速検索できるアプリケーションを提供しています。 今回はその高速検索のノウハウのうち、特にDBの扱いに関連する部分について、ベテランエンジニアへのインタビューを通してそのエッセンスをまとめてみました。 一般的なベストプラクティスだけでなく、検索性能を高めることに特化しためずらしいアプローチもあるので、ぜひご覧ください。 フォルシアにおける検索DBについて まず前提としてフォルシアで扱うデータについて軽く説明します。 扱うデータの複雑さ たとえば、旅行会社向けのアプリケーションであれば、宿泊素材の情報としては ホテルの情報「〇〇ホテル」（~約2万件） プランの情報「朝食付き・ロングステイ△△プラン」（0~1500件/施設） 客室の情報（~100件/

インターネットやAIを駆使しながら、領域に捉われずにさらなる挑戦を行うDeNAの取り組みを紹介する「DeNA TechCon 2023」。ここで成田氏が登壇。PocochaのDBをマイグレーションしたことについて話します。 新卒1年目が100億レコード超のDBマイグレーションをした話 成田篤基氏：発表を始めます。みなさんはじめまして。成田と申します。私は2021年にディー・エヌ・エーに新卒で入社して、現在入社から2年が経とうとしています。 私は新卒1年目で、大規模なデータベースマイグレーションを行う貴重な経験ができました。本日はそのマイグレーションプロジェクトについて、体験から得た学びをみなさんにお伝えします。題して「新卒1年目が100億レコード超のDBマイグレーションをした話」です。どうぞよろしくお願いいたします。 目次です。本日はこちらの目次に沿って発表を進めていきます。 まずは私たち