並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 26 件 / 26件

新着順 人気順

分散システムの検索結果1 - 26 件 / 26件

  • サーバーレス技術の今と未来についてServerlessDays TokyoのPreEventで話してきました - めもおきば

    𝕏にURL貼れなくなっているので、Zennにもマルチポストしています。 ServerlessDays Tokyo 2024 PreEvent 2024-09-21のServerlessDays Tokyo 2024にむけて、去年に引き続き、直前イベントでサーバーレス技術の今と未来について話してきました。 いよいよ明日からメインイベントですので参加お待ちしています! Serverless Update 2024 文字起こし スライド全体はDocswellさんで公開しています。 PreEventはYouTubeでアーカイブがあります。 サーバーレスのおさらい 「サーバーレス」は、誤解を招きやすい技術用語で様々な定義がありますが、ここでは2つの視点で定義します。 運用者の視点としてのサーバーレスは、物理的なマシンや仮想マシン、EC2インスタンスのような「サーバー」を自分で管理するのではなく、そ

      サーバーレス技術の今と未来についてServerlessDays TokyoのPreEventで話してきました - めもおきば
    • サーバーレス技術の今と未来についてServerlessDays Tokyo 2024 直前イベントで話してきました

      ServerlessDays Tokyo 2024 PreEvent 2024-09-21のServerlessDays Tokyo 2024にむけて、去年に引き続き、直前イベントでサーバーレス技術の今と未来について話してきました。 いよいよ明日からメインイベントですので参加お待ちしています! Serverless Update 2024 文字起こし スライド全体はDocswellさんで公開しています。 PreEventはYouTubeでアーカイブがあります。 サーバーレスのおさらい 「サーバーレス」は、誤解を招きやすい技術用語で様々な定義がありますが、ここでは2つの視点で定義します。 運用者の視点としてのサーバーレスは、物理的なマシンや仮想マシン、EC2インスタンスのような「サーバー」を自分で管理するのではなく、その管理をクラウド事業者に任せるという考え方で、要するに完全従量課金型のフル

        サーバーレス技術の今と未来についてServerlessDays Tokyo 2024 直前イベントで話してきました
      • 普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024

        YAPC::Hakodate 2024 で使用したスライドです。 本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、様相論理を用いてその仕様を記述し検査する技術について解説します。 我々はシステムの仕様を保証する際、テスト設計や自動化ツールのような、仕様を「テス…

          普通の Web エンジニアのための様相論理入門 #yapcjapan / YAPC Hakodate 2024
        • Sora Cloud を Akamai Connected Cloud へ移行しました

          2024 年 8 月に、時雨堂の自社サービスである Sora Cloud を DataPacket というベアメタルクラウドサービスから Akamai Connected Cloud (以降 Linode) へ移行しました。 なぜ移行したのか自社製品である WebRTC SFU Sora でスケールアウトが実現できるようになったためです。 Sora Cloud は時雨堂が開発しているパッケージソフトウェアである WebRTC SFU Sora (以降 Sora) のクラウド版です。 この Sora が Raft ベースの分散システムに対応し、スケールアウトを実現できるようになりました。そのため、DataPacket のベアメタルサーバーで高スペックのマシンを利用する必要がなくなり、低スペックなサーバーをたくさん並べることで、好きなだけスケールできるようになりました。 移行先の選定条件として

          • 継続的デプロイメントの継続的な学習 - Continuous Deployment の読書感想文 - じゃあ、おうちで学べる

            自動化は私の忍耐力の限界を補完してくれます。 はじめに 本書「Continuous Deployment」は、継続的デプロイメントの実践に焦点を当てた包括的なガイドです。継続的デプロイメントは、ソフトウェアパイプラインを完全に自動化し、手動介入を必要としない手法です。この方法により、クオリティーゲートを通過したすべてのコードコミットが自動的に本番環境にデプロイされます。 私は、ソフトウェア開発の現場で、オンプレミスの手動デプロイから始まり、Makefileによる自動化、JenkinsやCircleCI、GitHub Actions、GitLab CI/CD、AWS CodePipeline、Cloud Build 、ArgoCD、PipeCDなど、様々なツールや手法を経験してきました。この過程で、継続的デプロイメントが開発プロセスを改善し、ビジネス価値を創出する様子を目の当たりにしました。

              継続的デプロイメントの継続的な学習 - Continuous Deployment の読書感想文 - じゃあ、おうちで学べる
            • 増えすぎたデータベースと計画停止の苦労を、TiDBへの移行で解決できるか? レバテックの挑戦[PR]

              ITエンジニアやクリエイター向けに転職や採用のためのプラットフォームおよびコンテンツメディアなどを提供するレバテックは、マイクロサービス化したことにより増えすぎてしまったデータベースや計画停止に必要な社内調整の困難さに直面していました。 それを解決すべく導入したのがMySQL互換でスケーラブルな特徴を持つ「TiDB」でした。 同社はPoCによってTiDBの十分な性能、アプリケーションを移植可能なMySQLとの互換性、オンラインのままバージョンアップやDDLの実行などが可能な高い可用性などを確認し、現在アプリケーションの移行作業に取りかかっているところです。 同社がいかにTiDBを評価したのか、その内容が今年(2024年)7月に行われたイベント「TiDB User Day 2024」のセッション「TiDBは銀の弾丸になるのか? ~ レバテックの課題と新たな挑戦 ~」で語られました。 本記事で

                増えすぎたデータベースと計画停止の苦労を、TiDBへの移行で解決できるか? レバテックの挑戦[PR]
              • PHPカンファレンス沖縄2024 に参加してワイワイ!記/参加編 #phpcon_okinawa - 大好き!にちようび

                9月28日に、沖縄県は那覇市で行われたPHPカンファレンス沖縄2024に参加して来ました。 楽しかったし色々な刺激に元気をもらえたし、今回の遠征も素敵な時間を過ごせたな〜〜〜が一言目に飛び出してくる感想 😃 主催のカンボさん初め、スタッフの方々お疲れ様でした。ありがとうございました! それに素敵な発表を行っていた登壇者の皆さんや自分と交流してくれた皆さん、ありがとうございました〜〜 ということで #iwillblog !の記事です。 phpcon.okinawa.jp 自分の登壇について CfPにいくつかプロポーザルを出して、ありがたくも採択していただけたので張り切って登壇してきました。 fortee.jp トークの狙いとしては、こんな風に書かれています。 「昔あったオートローダー」たちを見に行ってみましょう! 今や当たり前の「ComposerとPSR-4」以外の世界に触れることで、 日

                  PHPカンファレンス沖縄2024 に参加してワイワイ!記/参加編 #phpcon_okinawa - 大好き!にちようび
                • アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その1【背景編】:ULIDに移行する話 - OLTA TECH BLOG

                  ◇ アノキミモノガタリその壱 はじめに ULIDを採用した背景 整数型自動採番に関する思惑 ULID到来のきっかけ まとめ IDシリーズ記事の一覧 ◇ アノキミモノガタリその壱 アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその目。 令和4年4月1日、ミッドナイトの零時23分、55秒の999ミリ秒、 キミと、出会えた。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその一目惚れ。 なんと可愛らしく、愛しいその目、忘れられない。 はじめに こんにちは、転生したら相変わらずエンジニアだった OLTA(オルタ)プロダクトグループ研究開発チームのタイトルの前置きがとにかく長い B.です。 INVOYカードの開発を担当しています。 今回、UUID*1

                    アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その1【背景編】:ULIDに移行する話 - OLTA TECH BLOG
                  • Valkeyプロジェクト:スケーラビリティと性能向上への挑戦 - Tech Knowledge

                    Written with ChatGPT on Dify Valkeyプロジェクト:Redisの進化形としての可能性 近年、オープンソースソフトウェアの改良とフォークは珍しいことではありませんが、特定のプロジェクトが大きな注目を集めることがあります。その一つが、「Valkey」プロジェクトです。このプロジェクトは、高性能なキーバリューストアであるRedisを基にしてフォークされ、独自の機能や最適化が施されています。本記事では、ValkeyがRedisからどのように派生したのか、どのような技術的特徴を持っているのかを深掘りしていきます。 Valkeyプロジェクトの概要 Valkeyは、Redisの強力な機能を継承しつつ、特に大規模データベース操作と分散システム環境における性能改善を目指して開発されています。Redisがシングルスレッドモデルを採用しているのに対して、Valkeyはマルチスレッ

                      Valkeyプロジェクト:スケーラビリティと性能向上への挑戦 - Tech Knowledge
                    • KotlinとPythonの連携について徹底解説 - Python転職初心者向けエンジニアリングブログ

                      KotlinとPythonの連携について徹底解説 KotlinとPythonは、それぞれ異なる特徴を持つプログラミング言語です。Kotlinは、JetBrainsによって開発され、Android開発やサーバーサイド開発で使われることが多い静的型付け言語です。シンプルでモダンな構文とJavaとの互換性を強みとしています。一方で、Pythonは柔軟で動的な型付けの言語であり、データ分析や機械学習、スクリプト言語として非常に広く使われています。 これら2つの言語を組み合わせることで、それぞれの得意分野を活かしながら、効率的かつ拡張性のあるシステムを構築することが可能です。本記事では、KotlinとPythonを連携させる方法を、具体的なコード例を交えながら、初心者向けにわかりやすく解説します。 KotlinとPythonの連携のアプローチ KotlinとPythonを連携させる方法はいくつかあり

                        KotlinとPythonの連携について徹底解説 - Python転職初心者向けエンジニアリングブログ
                      • Apache Beam と TensorFlow SavedModel に翻弄された記録 | CyberAgent Developers Blog

                        はじめに 2023年10月の1ヶ月間、AI事業本部、極予測AI予測チームで CA Tech Job というインターンシッププログラムに参加させていただきました東京大学大学院情報理工学研究科修士1年の武智將平(@shoheiKU)です。普段の研究では機械学習を利用した予測モデル構築やデータサイエンスのようなことをしています。今回のインターンシップで研究では出会うことの少ない、機械学習モデルをサーバーに組み込む場合の手法や並列化について触れることができました。この記事では Apache Beam を利用した並列化及び、Tensorflow の SavedModel というサービングに適した保存形式について触れます。 タスクについて 極予測AI予測チームはクリエイティブデザインから広告効果を予測する機械学習モデルを構築し、サービスとして提供するチームです。 タスクスタート時点での問題点として 広

                          Apache Beam と TensorFlow SavedModel に翻弄された記録 | CyberAgent Developers Blog
                        • 【マイクロサービス入門】CAP定理 とはなんぞや?🔰

                          はじめに こんにちは、Takeです。都内の自社開発企業でエンジニアとして働いています。 この記事では、マイクロサービスを理解する上で重要なキーワードに焦点を当て、学びを共有できればと思いコンパクトにまとめてみました。 目的 CAP定理について理解すること CAP定理とは マイクロサービスを使用して構築されるような分散システムでは、すべての機能や特性を完全に満たすことは不可能で、必ずトレードオフが発生します。CAP定理は、分散システムにおいて互いにトレードオフとなる3つの特性があることを示しており、故障モードでは、この3つのうち2つを選択することしかできないことを示します。 Consistency(一貫性): どのノードにアクセスしても同じデータが返ってくることを保証します。 Availability(可用性): すべてのリクエストがレスポンスを受け取ることを保証します(システムが常に稼働し

                            【マイクロサービス入門】CAP定理 とはなんぞや?🔰
                          • [Consul入門]Consulの基本的な使い方について

                            昨年の11月入社の佐藤です。 今回は入社して初めて触ったツールのconsulについて学習していきたいと思います。 Consulとは? Consulは、分散システムのためのオープンソースのサービスメッシュ、キー/値ストア、および一貫性のあるサービス発見と監視を提供するツールです。HashiCorp社によって開発され、広く使われています。マイクロサービスアーキテクチャやクラウドネイティブなアプリケーションの開発において、以下のような役割を果たします。 サービスディスカバリとロードバランシング: Consulは、サービスディスカバリのためのDNSまたはHTTPエンドポイントを提供し、新しいサービスの登録や古いサービスの削除を自動的に検出します。これにより、サービス間の通信をシームレスにルーティングし、負荷分散を実現できます。 分散キー/値ストア: Consulは、分散キー/値ストアを提供し、アプ

                              [Consul入門]Consulの基本的な使い方について
                            • アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その5【実戦編】:最適な自己流IDの設計 - OLTA TECH BLOG

                              ◇ アノキミモノガタリその伍・∞ はじめに 最適な自己流のID設計 需要に応じて最適なパーツを組み合わせる Ulid-Flake:64-bitのBitInt型のULID設計 Ulid-Flakeの実装イメージ Ulid-Flake のimplementationについて 感想 最後に IDシリーズ記事の一覧 ◇ アノキミモノガタリその伍・∞ アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその目。 キミに、A.D.10889年の8月2日、UTC黎明5時31分50秒、655ミリ秒、 やっと、ULID宇宙の最後の1ミリ秒で、キミと再会できた。 7ZZZZZZZZZK4SANAG1ZM5T2K9Zよ、キミ。 忘れられない、なんと可愛らしく、愛しいその目。 たとえ、八千八百年

                                アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その5【実戦編】:最適な自己流IDの設計 - OLTA TECH BLOG
                              • ファーストリテイリンググループ採用情報 エンジニア・アーキテクト::テクニカルプログラムマネージャ

                                有明本部:東京都江東区有明1丁目6-7 UNIQLO CITY ※勤務地は、海外含め会社の定める場所に変更することがあります ■募集背景 ファーストリテイリンググループは、従来の小売業という枠組みを超え、"情報製造小売業"(Digital Consumer Retail Company)へと業態を変革するため、全社改革”有明プロジェクト”を推進しています。その実現に向けて、我々デジタル業務改革サービス部は、最新のテクノロジーを活用したグローバル化、クラウド化、モバイル化の推進に留まらず、利益を創出するIT=“攻めのIT”として、全社の業務改革をリードしています。本ポジションでは、組織をスケールアウトし拡大していくために、チーム間の開発からリリースに向けた足並みを揃え、相反する技術的な課題を解決していくテクニカルプログラムマネージャ(Tech PM)を募集します。 ■部署概要 デジタル業務改

                                  ファーストリテイリンググループ採用情報 エンジニア・アーキテクト::テクニカルプログラムマネージャ
                                • Zig製の分散型金融取引向けデータベースTigerBeetleのメモ

                                  TigerBeetleとはどんなヤツなのか 公式サイト TigerBeetle - Track Financial Transactions at Scale | TigerBeetle 安全性(耐障害性)・高パフォーマンス・(金融システムとしての)開発体験に重きを置いたDBであることを謳っている。 安全性 過酷なストレージ障害モデルでも生き残る 例 間違ったディスクセクタに書き込むファームウェア ディスクを誤って表示するカーネルページキャッシュ ログファイルの破損を検出できないファイルシステム Jepsen Testを公開している人がいるようだ nurturenature/jepsen-tigerbeetle: A Jepsen Test for TigerBeetle. 高パフォーマンス インメモリDBより高速だが、トランザクションごとにレプリケーションされた永続化を行う キャッシュ行

                                    Zig製の分散型金融取引向けデータベースTigerBeetleのメモ
                                  • 第六章 バックエンド技術質問 | InterviewCat | テック企業面接対策ガイド

                                    本章ではバックエンドエンジニアとして聞かれる質問内容について書いていきます。バックエンドのドメイン知識は幅広いので募集要項に合わせて準備するのがおすすめです。ここではソフトウェアエンジニアとして必要なNetworking、 Operating Systems、 Databaseなど基礎知識に加えて、システムデザイン面接にもかなり注目される分散システムやVirtualizationなどのトピックも入ってます。 注意点としては回答例はあくまで面接用に簡略化したものなので、より深い知識を得るためには詳しい解説をしている関連リンクから詳細を辿って理解する事をオススメします。

                                      第六章 バックエンド技術質問 | InterviewCat | テック企業面接対策ガイド
                                    • FoundationDBの特徴と制限について - Qiita

                                      Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに クラウドコンピューティングの進化は、データベース技術にも革新をもたらしています。その中で、高度なスケーラビリティ、堅牢性、および柔軟性を兼ね備えた分散型キーバリューストアであるFoundationDBは、注目を集めています。オープンソースプロジェクトとして提供されているこのデータベースは、シンプルなキーバリューモデルを基盤としながら、豊富なデータモデルやAPIをサポートする「レイヤー」を通じて、多様なアプリケーションやサービスに適用可能なデータベース基盤となっています。 今回はFoundationDBの基本的な概要から始めて、

                                        FoundationDBの特徴と制限について - Qiita
                                      • D1の構築:グローバルデータベース

                                        Workerアプリを構築する開発者は、必要なインフラストラクチャではなく作成するものに集中し、Cloudflareネットワークのグローバルなリーチを活用しています。個人的プロジェクトからビジネスクリティカルなワークロードまで、アプリケーションの多くは永続データを必要とします。Workersは開発者のニーズに合わせて、キーバリューやオブジェクトストレージなど、さまざまなデータベースとストレージのオプションを提供します。 リレーショナルデータベースは今日、多くのアプリケーションのバックボーンになっています。Cloudflareのリレーショナルデータベースを補完する D1は、現在一般公開されています。2022年末のアルファ版から2024年4月のGA版までに至るまでの過程では、開発者が慣れ親しんだリレーショナルデータとSQLで本番ワークロードを構築できるようにすることに重点を置きました。 D1とは

                                          D1の構築:グローバルデータベース
                                        • AWS DynamoDBを使ってNoSQLの基礎から実践へ:データベース構築・操作ガイド - Qiita

                                          Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに AWS DynamoDBは、スケーラブルでフルマネージドなNoSQLデータベースサービスです。この記事では、DynamoDBの基本的な使い方について学び、実際にデータベースを構築・操作する手順を解説します。 これからDynamoDBを利用したアプリケーション開発を始める方に向けて、わかりやすく説明していきます。 DynamoDBについて DynamoDBの主な特徴を整理します。まず、DynamoDBはフルマネージドであり、サーバーの管理が不要で、スケーリングやバックアップも自動で行われます。 また、DynamoDBは高いパフォ

                                            AWS DynamoDBを使ってNoSQLの基礎から実践へ:データベース構築・操作ガイド - Qiita
                                          • RPC と REST の違い - API アーキテクチャの違い - AWS

                                            リモートプロシージャコール (RPC) と REST は API 設計の 2 つのアーキテクチャスタイルです。API は、2 つのソフトウェアコンポーネントが一連の定義とプロトコルを使用して相互に通信できるようにするメカニズムです。ソフトウェアデベロッパーは、以前に開発したコンポーネントやサードパーティーのコンポーネントを使用して機能を実行するため、すべてを最初から作成する必要はありません。RPC API を使用すると、デベロッパーは外部サーバーのリモート関数を、あたかもソフトウェアのローカルにあるかのように呼び出すことができます。例えば、別のチャットアプリケーションのメッセージング機能をリモートで呼び出すことで、アプリケーションにチャット機能を追加できます。これとは対照的に、REST API では、リモートサーバー上で特定のデータ操作を実行できます。例えば、アプリケーションでは REST

                                              RPC と REST の違い - API アーキテクチャの違い - AWS
                                            • Amazon OpenSearch Service: Managed and community driven | Amazon Web Services

                                              Amazon Web Services ブログ Amazon OpenSearch Service: Managed and community driven 本投稿は、Director of Solutions Architecture for Search Services at Amazon Web Services である Jon Handler によって 2024 年 9 月 16 日に投稿された記事の日本語版です。 私は常に検索にまつわる課題を愛してきました。検索の本質は、質問を受け取り、その質問を理解し、そして最適な回答を取得することです。私は博士課程で AI ロボティクスのプロジェクトを主導し、計画フラグメントのライブラリを検索を通じて実世界の状況と結びつけました。以前の仕事では、商用検索エンジンを一から構築しました。そして AWS でのキャリアでは、ソリューションアーキテ

                                                Amazon OpenSearch Service: Managed and community driven | Amazon Web Services
                                              • アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その3【選択編】:ULID移行時に整数型IDと入れ替わるべきか?共存させるべきか? - OLTA TECH BLOG

                                                ◇ アノキミモノガタリその参 はじめに 独立・共存問題:整数型IDと入れ替わるべきか?共存させるべきか? 整数型IDとULIDと共存させる時の利点と注意点 まとめ IDシリーズ記事の一覧 ◇ アノキミモノガタリその参 アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。 君の名は、01FZG96YPZK4SANAG1ZM5T2K9Z、忘れないその目。 01FZG96YPZK4SANAG1ZM5T2K9Z のキミ、 一体どこだい? ぼくも、コマちゃんも、キミに会えたいよ。 50年1回の輪廻。 ぼくは、すでに十億億回の輪廻のタイムスリップも、 何度も何度も、何度でも、 何度も、タイムループの中でキミを探していた。 はじめに こんにちは、転生したら相変わらずエンジニアだった OLTA(オルタ)プロダクトグループ研究開発チームのタイトルの前置きがとにか

                                                  アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その3【選択編】:ULID移行時に整数型IDと入れ替わるべきか?共存させるべきか? - OLTA TECH BLOG
                                                • ServerlessDays Tokyo 2024(Day1)前編(9/21) - 構築中。

                                                  日程調整の関係で申し込みが直前になってしまいましたが、個人スポンサー枠が空いていたのでそちらの枠で参加してきました。 serverless.connpass.com 朝早く家を出たら… 実は入口がわからず彷徨ってたら案内係の方がたまたま目の前に出て来られただけ、でした#serverlessdays #serverlesstokyo https://t.co/OIFZC1Ubzd— hmatsu47(まつ) (@hmatsu47) 2024年9月21日 偶然来場者第一号にw 個人スポンサーのTシャツをいただきました (着く前ちょっと近辺を歩き回っていたので汗が引いてから着ます)#serverlessdays #serverlesstokyo pic.twitter.com/9mzkJLfdAE— hmatsu47(まつ) (@hmatsu47) 2024年9月21日 本編開始 ちょっとトラブ

                                                    ServerlessDays Tokyo 2024(Day1)前編(9/21) - 構築中。
                                                  • MySQL における primary key についてメモ - ひらめの日常

                                                    MySQL における primary key について MySQL における primary key (プライマリキー、主キーとも呼ばれる)は、テーブルの中のカラムに対して指定できるもので、以下のような特徴を持ちます テーブルで一つのみ指定できる NULLは許容しない 一意の(ユニークな) ID を付与する インデックスが自動で構築される インデックス構造の基礎知識についてはこちらの記事が非常にわかりやかったのでぜひ参考にしてみてください MySQL with InnoDB のインデックスの基礎知識とありがちな間違い - クックパッド開発者ブログ primary key として何を利用するか? ここで議論となるのは、primary key として何を利用するかという点です。 AUTO_INCREMENT よくあるのは、DB側の機能として AUTO_INCREMENT を利用し、DB側で採番

                                                      MySQL における primary key についてメモ - ひらめの日常
                                                    • アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その2【基礎編】:整数型ID、Snowflake ID、MongoDBのObjectID、ULID、UUIDなどの特徴、比較と選択 - OLTA TECH BLOG

                                                      ◇ アノキミモノガタリその弐 はじめに 整数型ID、Snowflake ID、MongoDBのObjectID、ULID、UUIDなどの特徴と比較 整数型ID、Snowflake ID、MongoDBのObjectID、ULID、UUIDの選択フローチャート 衝突検知と自動回避メカニズム Snowflake IDの仕組み MongoDBのObjectIDの仕組み ULIDの仕組み ULIDにおける広い空間 ULIDにおける単調性問題 ULIDの安全性問題 ULIDの同じミリ秒内の単調性における推測可能問題 ULIDの実現におけるオーバーフロー問題 UUIDの仕組み UUID v1の仕組み UUID v4の仕組み UUID v7の仕組み ULIDとUUIDとの互換性問題 ULIDベースのUUID UUIDv7が正式的に発表された今、ULIDの素晴らしさを再認識 ULIDやUUIDの切り出し問

                                                        アノ日のULID、キミとまた出会えるまで十億億回の輪廻のタイムスリップ、A.D.10889年まで。ーーULID移行から最適な自己流IDの設計まで・その2【基礎編】:整数型ID、Snowflake ID、MongoDBのObjectID、ULID、UUIDなどの特徴、比較と選択 - OLTA TECH BLOG
                                                      1