何が起きたか 時刻ベース（ナノ秒）でUnique IDを割り振っていた 速度を向上させた UnitTestの実行速度が向上した みんなも使おうRyzen TR 人類皆RAM 64GB 何故かテストが落ちまくる ランダムで落ちまくる ランダムで成功する 1時間位頭抱えてた 問題点を見つめ直す FirestoreのIndexが貼られるまで時間かかるせいか？とか考えた Sleep適当に入れてもダメなものはダメ 仕方ないのでラブライブのBlu-Rayを再生した 何が起きていたか Unique IDの割り振り部分が早くなりすぎて、同じIDが複数発生してしまっていた どうやって解決したか UnitTestのUID割り振りをatomic intでインクリメントさせるようにした 反省点 やっぱ時刻でIDとってるようなのはダメだな やはりラブライブ！のライブblu-rayを再生しているとバグが取れる
snowflake は、Twitter 社が作成した、ユニークなID生成のネットワークサービスです。いくつかの簡単な保証で高いスケーラビリティを実現しています。Twitter 社が、MySQLから Cassandra に移行するにあたって、Cassandra にシーケンシャルな id 生成の仕組みが無かったことから作成したそうです。 snowflake についてはTwitter IDs, JSON and Snowflakeに書いてあります。 snowflake のコードは、Apache License, Version 2.0 でSnowflakeに公開されています。 スケーラブルな採番、背景的な話 Cloudでスケーラビリティのあるサービスを見据えてコードを書いていると採番に関する問題が必ず出てきます。従来、RDBの自動採番などに頼っていたのがコスト、スケーラビリティ、耐障害性の観点か
はじめに このページでは、MySQL InnoDBの介在する大規模サービスにおいて考慮すべきインサート性能の問題と、ID生成戦略として、ゆるやかに増える64bit(8byte)の整数値を使う方法と、UUIDを問題を回避して用いる方法について説明します。 100万行以上でおこるインサート性能問題 MySQL InnoDBで大規模サービスを設計/運用している方なら周知の事実かもしれませんが、MySQLのInnoDBには、int(4byte)よりも大きなサイズのカラムにインデックスが貼られたテーブルに、カーディナリティの高いランダムなデータを入れてインサートをしようとすると100万行以上で急激にインサート性能が落ちるという問題があります。 MySQL InnoDB Primary Key Choice: GUID/UUID vs Integer Insert Performance 、というサイ
約1年前の Instagram Engineering Blog で ID のシャーディングについて解説されていたのでメモ。 Sharding & IDs at Instagram http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram 背景 毎秒大量に行われる写真投稿やユーザーの行動をデータベースに保存するために、Instagram ではシャーディングを行なっている。 データベースにデータ格納するにあたり、シャードが別であっても、写真といったコンテンツごとにユニークなIDを振らないといけない。 Before writing data into this set of servers, we had to solve the issue of how to assign uniqu
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く