並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 15 件 / 15件

新着順 人気順

snowflakeの検索結果1 - 15 件 / 15件

  • ID生成大全 - Qiita

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

      ID生成大全 - Qiita
    • Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita

      まえがき データにIDを持たせたいとき、単純な方法としては、DBの提供するauto incrementを使う場合やUUIDを利用することがある。それぞれの方法の利点欠点は以下の通り。 データベースのauto incrementを使う場合 利点: 特別な実装が必要ない 欠点: DBを1台で運用するとデータベースがパフォーマンス・障害のボトルネックになる DBを二台にするとIDのユニークさや順序の保証が困難 UUID(v4)※1を利用する場合 利点: 分散環境で各々がIDを生成しても衝突しない IDを公開したくない場合に、推測されにくいIDを生成できる 欠点: 128ビット必要、DBのインデクシングやプログラミング言語で扱うときに不利なことがある IDから時間の情報が失われる、例えば2つのIDを比べてどちらが古い投稿か判断できない 世界の大企業がどうしてるか 調べてみると多くの企業がブログなど

        Facebook, Twitter, Instagram等がどうやってIDを生成しているのか まとめ - Qiita
      • Twitterにおける大規模システム構築、3つの原則

        4月に米サンタクララで行われたMySQL Confernce & Expo 211では、TwitterのJeremy Cole氏が「Big and Small Data at @Twitter」と題して、同社のシステムにおける原則とシステム構成について紹介したプレゼンテーションが行われました。 1日に1億5000万以上のツイートが行われているTwitterのシステムはどのように構築されているのか、その内容を紹介しましょう。 Twitterにおける原則 TwitterのJeremy Cole氏。

          Twitterにおける大規模システム構築、3つの原則
        • Quine Tweet: 自分自身へのリンクを持つ再帰的ツイート - まめめも

          This tweet is recursive. https://t.co/bZISaPd3Ts— Quine Tweet (@quine_tweet) 2016年9月19日 「このツイートはありません」となっていますが、URL をクリックすれば自分自身に飛べます。 以下、このツイートが生まれるまでの経緯を長々と書きます。 問題設定 そのツイート自身の URL を埋め込んだツイートを作ります。ツイートの URL はツイートをした後でないと決まらないし、ツイート文面を後から更新する手段はない(と思う)ので、単純ですが意外に難しい問題です。 調査 ご存知のように、現在のツイートの URL は次のような形式です。 https://twitter.com/<username>/status/<id>username はそのままなので、id を事前に予測できれば解決です。*1 調べてみるとこの id

            Quine Tweet: 自分自身へのリンクを持つ再帰的ツイート - まめめも
          • 注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools

            公開日 2024/05/27更新日 2024/05/27注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 現代のITサービスは、ユーザーに高品質で安定した体験を提供するために、より効率的で柔軟な技術選定が不可欠です。 本特集では、注目企業のシステムアーキテクチャ設計に携わるエンジニアの方々より、それぞれの技術選定における工夫と、未来を見据えた展望についてご寄稿いただいています。 各企業がどのように課題を乗り越え、開発生産性や品質を向上させるためにどのようなアプローチを採用しているのか ー この記事を通じて、実際の現場で活用される最先端の技術や戦略を学び、皆さんのプロジェクトに役立つ洞察を得ていただければ幸いです。 ※ご紹介はサービス名のアルファベット順となっております airCloset - 株式会社エアークローゼット エアークローゼットは日本初・国内最大級、女

              注目のITサービスを支えるアーキテクチャ特集 技術選定のポイントと今後の展望 - Findy Tools
            • データ分析基盤まとめ(随時更新)

              はじめに データ分析基盤の資料を力尽きるまで追記していきます。 構成図にあるアイコンや記事の内容から技術要素を調べて記載していますが、不明分は未記載にしています。修正のコメント頂ければ助かります。 あと、この記事追加してっていう要望も歓迎いたします。 テンプレート 記事公開日 : 会社名(サービス名) データソース : データ処理 : アウトプット : 画像 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

                データ分析基盤まとめ(随時更新)
              • TwitterのステータスIDが53bitを越えたお話 - tmytのらくがき

                僕の記事の間違いを指摘していただいているすばらしい記事です。僕の記事よりこちらの記事をご覧ください。 http://archive.guma.jp/2010/12/twitter-json.html 先日、29日の7時過ぎごろにTwitterのステータスIDが53bitを越えました。 こんな中途半端なビット数を超えただけでなぜこんな記事にするかというと、一部のクライアントで動作がおかしくなることがあるからです。 (14:14 追記しました) (14:31 もひとつ追記しました) TwitterのAPIはXMLとJSONの2種類で結果を取得できます。このうちXMLで処理してる場合は内部で64bit INTで処理していれば特に問題は起きません。 問題が起きるのはJSONの場合です。JSONはJavascriptでevalすればそのまま中身が取り出せることからもわかるように、Javascript

                  TwitterのステータスIDが53bitを越えたお話 - tmytのらくがき
                • 分散ユニークID採番機 katsubushi と Web アプリケーションへの応用例 / katsubushi

                  YAPC::Fukuoka

                    分散ユニークID採番機 katsubushi と Web アプリケーションへの応用例 / katsubushi
                  • ツイートID生成とツイッターリアルタイム検索システムの話

                    Brainf*ckで実用的なプログラムが書けるようになろう!というスライドです. このスライドは関西情報系学生団体交流会の勉強会で用いたスライドを誤字訂正などの若干の修正を加えたものです. 勉強会の時間の都合上上級編はありません. 入門編:forループ,初期化,代入,値の移動,足し算,引き算,値のコピー,掛け算,スタック,再帰 初級編:ifイディオム,大小比較,割り算,配列 中級編:多倍長精度整数・多倍長精度浮動小数点数 番外編:Brainf*ckでメタプログラミング This document discusses the concept of "simple" and "easy" as it relates to programming languages and Clojure in particular. It explores the differences between co

                      ツイートID生成とツイッターリアルタイム検索システムの話
                    • BigQuery と Snowflake を徹底比較

                      最初にBigQueryとSnowflakeの概要と、登場の背景を説明します。 その後、ユーザにとっての使い勝手と、管理者にとっての使い勝手を、ベンダーフリーな立場でそれぞれします。 最後に、BigQueryとSnowflakeどっちが速いのか?といった疑問に対して、アーキテクチャをもとに考察します。

                        BigQuery と Snowflake を徹底比較
                      • 分散環境でユニークなidを発番するGo製プロダクト「katsubushi」のご紹介 - KAYAC engineers' blog

                        Lobiチームの長田です。 今回はkatsubushiというアプリケーションを紹介します。 https://github.com/kayac/go-katsubushi katsubushiはid発番を行うアプリケーションです。 水平分割されたデータベースに対してユニークなidを発番するために作られました。 なお、本記事中の「データベース」はMySQLを指します。 katsubushiの特徴 Snowflakeと同様のアルゴリズムでid発番 SnowflakeはTwitter社がかつて公開していたid発番アプリケーションです。 https://github.com/twitter/snowflake/tree/master 既にメンテナンスされておらず、masterブランチにはその旨が書かれたREADMEしか残されていません。 タグが切られているので、ソースコード等はそちらで確認できます。

                          分散環境でユニークなidを発番するGo製プロダクト「katsubushi」のご紹介 - KAYAC engineers' blog
                        • 雪の結晶が作れるページ

                          © 2007 Barkley all rights reserved. | Terms of Service and Privacy Policy Please help us keep the snowflakes clean. Report offensive snowflakes when you click the snowflake.

                          • 7年使ったRedshiftから6ヶ月かけてSnowflakeへ移行した話 〜手の内全部お見せします〜

                            SNOWDAY JAPAN 2023で「7年使ったRedshiftから6ヶ月かけてSnowflakeへ移行した話 〜手の内全部お見せします〜」というタイトルで登壇した資料です。 https://www.snowflake.com/about/events/snowday-japan-2023/?lang=ja 独自のテレビ視聴質データを利用したCM効果分析サービスを提供するREVISIO株式会社の片岡が、7年間使用してきたRedshiftからSnowflakeへ移行した際の手法やツール、検証内容や両DWHの差異などについて詳しく語りました。 スライド内で発表した移行ツールはOSSで公開中です。 https://github.com/tvision-jp/redshift-to-snowflake-migration-utils https://revisio.co.jp/

                              7年使ったRedshiftから6ヶ月かけてSnowflakeへ移行した話 〜手の内全部お見せします〜
                            • Twitter: 大きなトラフィックに耐えうるアーキテクチャーへの変更 - ワザノバ | wazanova.jp

                              https://blog.twitter.com/2013/new-tweets-per-second-record-and-how 少し前、8月のTwitterエンジニアブログのエントリーですが、アーキテクチャー変更について触れているポストなので、取り上げてみます。 1) 背景 2010年のワールドカップ時点でのトラフィックがさばききれなかった時点での状況は、 200人のエンジニアが、単一のRailsのコードベースで大量のユーザとトラフィックに対応する構造であった。 MySQLのストレージシステムは、一つのマスタと一時的にシャーディングされるスレーブの構成で、読込み/書込みともにスループットの限界にきている箇所がでていた。 フロントエンドのRubyマシンは期待通りのトラフィックをさばけていなかったが、技術的な解決ではなく、サーバの追加でしのいでいた。 コードベースは、可読性とパフォーマン

                              • 軽量なTime-based ID生成器”shakeflake(仮称)”について | SmartNews開発者ブログ

                                大平です。今回はさだまさしネタは特に無しです。 先日、サービスのクローラーで使用しているID生成器について置き換えを行いました。非常に地味な話になりますが、本記事ではその辺の内幕の話をしたいと思います。  ID生成にまつわる苦悩 弊社ゴクロの提供しているSmartNewsは表向きはニュースアプリですが、裏側の仕組みは検索エンジンに近似しています。ユーザーの方々の興味関心や、アクセス傾向をクエリーとし、その内容に応じた話題のニュースを検索結果として返却する、という風に捉えていただくと、なんとなく私が言わんとしている事を想像していただけるかと思います。 SmartNewsはTwitterのつぶやき情報を用いたトレンド分析をベースとしており、話題になっているニュースを選定するためには、大量のTwitter上のtweet、ならびにその中に含まれているURLに対してクロールを行う必要があります。日々

                                1