アプリケーションに保存されているすべてのドキュメントにハッシュを提供する方法を設計する必要があります。
既存のハッシュ ライブラリ (BCryptなど) を使用し、BSON でさえ、適切ObjectIdな "ハッシュ" または "キー" を生成しますが、かなり長いです。
また、短いハッシュを実現する唯一の方法は、より少ない文字列をハッシュすることであることも理解しています（間違っていなければ）。ハッシュLongIDが見つめている0, 1, 2, 3ように。
ただし、考えるのは簡単ですが、Google App Engine (GAE) データストアに実装するのはかなり難しいか、または今までこの必要性を実際に超えていませんでした。
GAE Datastore は、複数のサーバー、さらには複数のデータセンターにまたがるエンティティを格納します。自動インクリメント ID は、実際にはこの目的には使用できません。
これを達成するための戦略は何ですか？
私が理解している限りでは、文書の短い一意の英数字識別子を生成する方法を探しています。URL 短縮サービスの種類 ( TinyURL.com に似た短い URLを作成する、またはTinyURLに似た短いハッシュを作成する最良の方法は何ですか?またはPython で一意の短い URL を作成する方法は? などの質問を参照してください。 ）。私の答えは、この仮定に基づいています。
データストアは一意の自動インクリメント ID を生成するため、信頼できます。複数のデータセンターは問題ありません。ID は一意で短く (少なくとも最初は)、衝突はありません。これはおそらく tinyurl や同様のサービスがそれを実現する方法です。
DatastoreService.allocateIds()を使用して、新しいドキュメントをデータストアに永続化する前に、1 つ以上の一意の ID をリクエストすることもできます。次に例を示します。
KeyRange keyRange = dataService.allocateIds("MyDocumentModel", 1);
long uniqueId = keyRange.getStart().getId();
次に、この ID を「ハッシュ」するか、整数 ID を Base64 (または Base36 または独自の文字を定義するその他のベース) に変換するだけで、さらに短い英数字 ID を取得できます。偶然の言葉）。
予測可能性が問題になる場合は、この英数字 ID にランダムな文字をプレフィックス/サフィックスとして付けることができます。