• 使用する文字はCrockford base32 ULIDとは What is ULID Excerpt from the specifications • 128-bit data • Capable of having 1.21e+24 unique keys every 1 millisecond • Lexicographically sortable • 26 characters long • Uses Crockford's base32 alphabet
a certain product. We switched the writer instance to recover, but it was not the ideal method. As a result, after the network was restored, the database became double-active, causing a secondary failure. ある日、あるプロダクトのDBでNW障害 が発生 ライターインスタンスを切り替えて復旧し たがやり方がよくなかった この結果、NW復旧後にDBがダブルア クティブになってしまい、2次障害を起こ してしまった。
double-active state, the application started accessing both DB instances randomly. Furthermore, because we were using auto-increment IDs in the RDB, we ended up creating data in each instance for different merchants having the same ID, which should never have happened. Table name: users DB instance-A DB instance-B
generating trillions of IDs at the same time without any sign of overlap • The specification is lightweight and clear • Unlikely to have updates to the specification • Timestamp-based IDs are compatible with RDB • IDs can be generated on the application layer • 同一時刻に数兆個のIDを生成してぶ つかる気配のない確率 • 仕様が軽量で明確 • 仕様の更新がなさそう • タイムスタンプベースのIDのため、 RDBと相性が良い • アプリケーションでIDを払い出せる
ライブラリ選定 Select a library Requirements for the library (p.s. we use Kotlin): • Capable of generating ULID at the type level • Uploaded on Maven Central • Meets the specifications for the random part
ライブラリ選定 Select a library Candidates (At that time) • JonasSchubert/kULID • Aallam/ulid-kotlin • kobil-systems/ulid-kt ULID libraries generally do not require updates, so the last commit is usually about five years ago
a library 上２つが痒いところに手が届かず、 一番下のは機能的には理想だったけど、 Maven Centralに上がってなかった。。。 Candidates (At that time) • JonasSchubert/kULID • Aallam/ulid-kotlin • kobil-systems/ulid-kt The top two options didn't quite meet the needs, and while the bottom one was functionally ideal, it wasn't available on Maven Central...
ライブラリ選定 Select a library I ended up creating it myself. • Capable of generating ULID at the type level • Uploaded on Maven Central • Meets the specifications for the random part
• At the time, the test data did not assert against random data, so there was the tedious task of assigning ULIDs one by one (some of which still remain) • Member variables related to IDs had to be replaced with ULID types (simply replacing them was tedious) ULIDへの移行で大変だったこと Problems faced during the transition to ULID
• At the time, the test data did not assert against random data, so there was the tedious task of assigning ULIDs one by one (some of which still remain) • Member variables related to IDs had to be replaced with ULID types (simply replacing them was tedious) ULIDへの移行で大変だったこと Problems faced during the transition to ULID • テストデータはランダムで生成して具体的な値 を自分たちでは一切書かないでテストしてれ ば楽だった。 • 例えLongでもID抽象型を付けておけば良 かった • It would have been easier if the test data was generated randomly and we tested without writing specific values ourselves. • For example, even with Long, it would have been better to have an abstract ID type in place.
ンドの処理性能が上がる • 移行はめんどいので、最初から使うと 良いよ（心の声） まとめ Conclusion • If the ID is made independent of the database, it will no longer inadvertently be associated with different data. • ULID is monotonically increasing, which makes them well-suited for compatibility with RDB. • Generating IDs in the app improved backend processing performance. • Migration is a hassle, so it's better to use it from the start (from the bottom of my heart).
rasmusluckow
sferik
hannesfritz
lemiorhan
soudai
sugarenia
davidbonilla
wjessup
jakevdp
reverentgeek
tammyeverts
palkan
