數據庫設計外文翻譯--java開發(fā)2.0使用 hibernate shards 進行切分

1、<p>　　本科生畢業(yè)設計（論文）外文資料譯文</p><p>　　（ 2011 屆）</p><p>　　外文資料譯文規(guī)范說明</p><p><b>　　一、外文資料譯文：</b></p><p>　　Java開發(fā)2.0：使用 Hibernate Shards 進行切分</p><

2、p>　　橫向擴展的關系數據庫</p><p>　　Andrew Glover，作者兼開發(fā)人員，Beacon50</p><p>　　摘要：Sharding并不適合所有網站，但它是一種能夠滿足大數據的需求方法。對于一些商店來說，切分意味著可以保持一個受信任的 RDBMS，同時不犧牲數據可伸縮性和系統(tǒng)性能。在 Java 開發(fā) 2.0 系列的這一部分中，您可以了解到切分何時起作用，以及何時

3、不起作用，然后開始著手對一個可以處理數 TB 數據的簡單應用程序進行切分。</p><p>　　日期：2010年8月31日</p><p><b>　　級別：中級</b></p><p>　　PDF格式：A4和信（64KB的15頁）取得Adobe®Reader®軟件</p><p>　　當關系數據庫試

4、圖在一個單一表中存儲數 TB 的數據時，總體性能通常會降低。索引所有的數據讀取，顯然是很耗時的，而且其中有可能是寫入，也可能是讀出。因為 NoSQL 數據商店尤其適合存儲大型數據，但是 NoSQL 是一種非關系數據庫方法。對于傾向于使用 ACID-ity 和實體結構關系數據庫的開發(fā)人員及需要這種結構的項目來說，切分是一個令人振奮的選方法。</p><p>　　切分 一個數據庫分區(qū)的分支，不是在本機上的數據庫技術，

5、它發(fā)生在應用場面上。在各種切分實現，Hibernate Shards 可能是 Java? 技術世界中最流行的。這個漂亮的項目可以讓您使用映射至邏輯數據庫的 POJO 對切分數據集進行幾乎無縫操作。當你使用 Hibernate Shards 時，您不需要將你的 POJO 特別映射至切分。您可以像使用 Hibernate 方法對任何常見關系數據庫進行映射時一樣對其進行映射。Hibernate Shards 可以為您管理低級別的切分任務。&l

6、t;/p><p>　　迄今為止，在這個系列，我用一個比賽和參賽者類推關系的簡單域表現出不同的數據存儲技術比喻為基礎。這個月，我將使用這個熟悉的例子，介紹一個實際的切分策略，然后在Hibernate實現它的碎片。請注意，切分首當其沖的工作是和Hibernate沒有必然關系的，事實上，對Hibernate stards編碼部分是容易的。真正難的是搞清楚內容碎片和你的工作方式。。</p><p>&

7、lt;b>　　關于本系列</b></p><p>　　Java的發(fā)展前景已經發(fā)生了根本變化，因為Java技術初現端倪。得益于成熟的開源框架和可靠的租金部署基礎設施，它現在的組裝，測試，運行和維護Java應用開發(fā)的速度和成本降低。在這個系列中，Andrew Glover探討了技術和工具，使這個新的Java開發(fā)有盡可能多的典范。</p><p><b>　　切分簡介

8、</b></p><p>　　數據庫切分是一種劃分成一些小團體的邏輯數據，可以將一塊表的分成不同的小組。例如，如果您正在根據時間戳對一個名為 foo 的超大型表進行分區(qū)，2010 年 8 月之前的所有數據都將進入分區(qū) A，而之后的數據則全部進入分區(qū) B。分區(qū)可以加快讀寫速度，因為它們的目標是單獨分區(qū)中的較小型數據集。</p><p>　　分區(qū)并不總是可用的（MySQL并沒有支持

9、它，直到5.1版），而且與商業(yè)系統(tǒng)一起做讓它的成本可以讓人望而卻步。更何況，在同一物理機上實現最分區(qū)存儲數據，所以你仍然受到硬件基礎的限制。分區(qū)也不能解決可靠性的或硬件不足。因此，聰明的人開始為尋找各種新的方法。</p><p>　　切分基本上是在數據庫級別的：而不是分裂的碎片的數據表的行，數據庫本身是被分割（通常是在不同的機器）的一些邏輯數據元素，而不是分裂成較小的塊表，分割分片成一個完整的數據庫小切分基本上是

10、在數據庫級別的：而不是分裂的碎片的數據表的行，數據庫本身是被分割（通常是在不同的機器）的一些邏輯數據元素，塊。</p><p>　　切分典型的例子是基于大型數據庫存儲劃分各地區(qū)的全球客戶數據：切分 A 用于存儲美國的客戶信息，切分 B 用戶存儲亞洲的客戶信息，切分 C 歐洲，等。這些切分分別處于不同的計算機上，且每個切分將存儲所有相關數據，如客戶喜好或訂購歷史。</p><p>　　對分片

11、（如分區(qū)）的好處是它壓縮大數據：在每個單獨的碎片表 ，它允許更快的讀取和寫入，提高了性能。分片是也可以提高想象可靠性，因為即使一碎片意外失敗，其他人仍然能夠滿足數據。而由于分片是在應用層完成，你可以做的數據庫在常規(guī)下不支持分割它。資金成本也可能降低。</p><p><b>　　主鍵</b></p><p>　　切分利用多個數據庫，所有這些都有自主意識的功能，不干涉其

12、他切分。因此，如果你依賴于數據庫序列（如主鍵自動生成），很可能是相同的主鍵將顯示在一個數據庫上成立。這是可能的，以協(xié)調跨分布式數據庫序列，但這樣做增加了系統(tǒng)的復雜性。最安全的方式，禁止重復的主鍵是讓你的應用程序（這將是一個sharded管理系統(tǒng)反正）生成密鑰。</p><p><b>　　跨碎片查詢</b></p><p>　　大部分（包括Hibernate碎片）分片

13、的實現不允許跨碎片查詢，這意味著你必須去額外的長度，如果你想利用兩對來自不同的碎片的數據集。（有趣的是，Amazon的SimpleDB的還禁止跨域查詢。）如果將美國客戶信息存儲在切分 1 中，還需要將所有相關數據存儲在此。如果您嘗試將那些數據存儲在切分 2 中，情況就會變得復雜，系統(tǒng)性能也可能受影響。這種情況也與先前提出的觀點 - 如果你有點最終需要做跨碎片連接，你最好的管理方式，消除了重復的可能性管理鍵！顯然，你需要充分考慮分片策略，

14、然后再設置你的數據庫。一旦你已經選擇了一種特定的方向，你就或多或少地依賴于它 - 它很難在走動后，一直sharded數據。</p><p><b>　　避免過早分片</b></p><p>　　切分最好采用分片后期。像過早的優(yōu)化，分片的基礎上增長數據的預期可能是一個災難。分片實施的成功是基于一段時間內適當地了解數據增長的應用程序，并推斷未來。一旦你sharded您的數

15、據可能會極其難以走動。</p><p><b>　　一個策略的例子</b></p><p>　　由于分片結合你到一個線性數據模型（即，你不能輕易加入不同碎片的數據），你應該從你的數據清楚地了解每個組織碎片是將如何邏輯的。這通常是最容易由一個域的主節(jié)點成為重點。在一個電子商務系統(tǒng)的情況下，主節(jié)點可以是一個命令或一個客戶。因此，如果你選擇“客戶”作為您的分片策略的基礎，然

16、后與客戶的所有數據將被轉移到各自的碎片，但你還是要選擇哪些碎片去移動這些數據。</p><p>　　對客戶來說，你可以根據位置碎片（歐洲，亞洲，非洲等），或者你可以在別的東西的碎片。這取決于你。您的碎片戰(zhàn)略應當指出，納入均勻分布的碎片之間的所有數據的一些方法。分片整體的思路是，打破大套成小的數據，因此，如果某個特定電子商務領域有一個大的歐洲客戶在設置和美國比較少，它可能不會基于意義的碎片對客戶的位置。</p

17、><p>　　回到比賽——使用切分！</p><p>　　現在讓我們回到我經常提到的賽跑應用程序示例中，我可以根據比賽或參賽者進行切分。在本示例中，我將根據比賽進行切分，因為我看到域是根據參加不同比賽的參賽者進行組織的。因此，比賽是域的根。我也將根據比賽距離進行切分，因為比賽應用程序包含不同長度和不同參賽者的多項比賽。</p><p>　　請注意：在進行上述決定時，我已

18、經接受了一個妥協(xié)：如果一個參賽者參加了不止一項比賽，他們分屬不同的切分，那該怎么辦呢？Hibernate Shards （像大多數切分實現一樣）不支持跨切分連接。我必須忍受這些輕微不便，允許參賽者被包含在多個切分中 — 也就是說，我將在參賽者參加的多個比賽切分中重建該參賽者。</p><p>　　為了簡便起見，我將創(chuàng)建兩個切分：一個用于 10 英里以下的比賽；另一個用于 10 英里以上的比賽。</p>

19、<p>　　實現Hibernate shards</p><p>　　Hibernate stards與現有的Hibernate項目幾乎天衣無縫。唯一的缺點是，Hibernate的碎片需要一些具體資料和你的行為。也就是說，它需要一個碎片訪問策略，碎片，選擇策略，以及碎片，解決策略。這些接口，你必須執(zhí)行，盡管在某些情況下，你可以使用默認的。我們將在后面的部分逐個了解各個接口。</p>&

20、lt;p>　　ShardAccessStrategy</p><p>　　執(zhí)行查詢時，Hibernate Shards 需要一個決定首個切分、第二個切分及后續(xù)切分的機制。Hibernate Shards 無需確定查詢什么（這是 Hibernate Core 和基礎數據庫需要做的），但是它確實意識到，在獲得答案之前可能需要對多個切分進行查詢。因此，Hibernate Shards 提供了兩種極具創(chuàng)意的邏輯實現

21、方法：一種方法是根據序列機制（一次一個）對切分進行查詢，直到獲得答案為止；另一種方法是并行訪問策略，這種方法使用一個線程模型一次對所有切分進行查詢。</p><p>　　我要保持簡單，并利用連續(xù)的戰(zhàn)略，取名為SequentialShardAccessStrategy。我們將很快配置。</p><p>　　ShardSelectionStrategy</p><p>

22、　　當創(chuàng)建一個新的對象（即，當一個新的Race或Runner是通過Hibernate創(chuàng)建），Hibernate Shards需要知道什么碎片相應的數據應該寫入。因此，你必須實現這個接口和代碼邏輯的分片。如果你想有一個默認的實現，有一個被稱為RoundRobinShardSelectionStrategy，它使用了碎片的數據放入循環(huán)賽戰(zhàn)略。</p><p>　　對于賽跑應用程序，我需要提供根據比賽距離進行切分的行為

23、。因此，我們需要實現 ShardSelectionStrategy 接口并提供依據 Race 對象的 distance 采用 selectShardIdForNewObject 方法進行切分的簡易邏輯。（我將稍候在 Race 對象中展示。）</p><p>　　在運行時，當調用是一些保存在我的領域對象類的方法，該接口的行為是在Hibernate杠桿內心深處的核心。</p><p>　　清單

24、1。一個簡單的碎片，選擇策略</p><p>　　正如你可以看到清單1，如果該對象被保存的一場Race，那么它的距離確定，因此，而且（因此）選擇了一個切分。在這種情況下，有兩個切分：0 和 1，其中切分 1 中包含 10 英里以上的比賽，切分 0 中包含所有其他比賽。</p><p>　　如果持久化一個 Runner 或其他對象，情況會稍微復雜一些。我已經編碼了一個邏輯規(guī)則，其中有三個規(guī)定

25、：</p><p>　　一名 Runner 在沒有對應的 Race 時無法存在。</p><p>　　如果 Runner 被創(chuàng)建時參加了多場 Races，這名 Runner 將被持久化到尋找到的首場 Race 所屬的切分中。（順便說一句，該原則對未來有負面影響。）</p><p>　　如果還保存了其他域對象，現在將引發(fā)一個異常。</p><p&g

26、t;　　根據這些你就可以擦你眉頭上的汗水,因為大多數的辛勤的工作都做完了。隨著比賽應用的增長，我所使用的邏輯可能不靈活,但這行得通為執(zhí)行本示范!</p><p>　　ShardResolutionStrategy</p><p>　　要找這個對象的關鍵,Hibernate Stards需要一個辦法決定先切分那個。你就用SharedResolutionStrategy接口去引導。</p

27、><p>　　正如我之前所說的,sharding迫使你對基本有敏銳的鑰匙,你可以管理之行。幸運的是,已經好Hibernate Stards或UUID生成方面表現良好。因此Hibernate Shards 創(chuàng)造性地提供一個 ID 生成器，名為 ShardedUUIDGenerator，它可以靈活地將切分 ID 信息嵌入到 UUID 中。</p><p>　　如果您最后使用 ShardedUUID

28、Generator 進行鍵生成（我在本文中也將采取這種方法），那么您也可以使用 Hibernate Shards 提供的創(chuàng)新 ShardResolutionStrategy 實現，名為 AllShardsShardResolutionStrategy，這可以決定依據一個特定對象的 ID 搜索什么切分。</p><p>　　配置好 Hibernate Shards 工作所需的三個接口后，我們就可以對切分示例應用程序

29、的第二步進行實現了。現在應該啟動 Hibernate 的 SessionFactory 了。</p><p><b>　　外文原文資料信息</b></p><p>　　[1] 外文原文作者：</p><p>　　[2] 外文原文所在書名或論文題目：</p><p>　　[3] 外文原文來源：</p><

30、;p>　　出版社或刊物名稱、出版時間或刊號、譯文部分所在頁碼：</p><p><b>　　網頁地址：</b></p><p><b>　　二、外文原文資料：</b></p><p>　　Java development 2.0: Sharding with Hibernate Shards</p>&

31、lt;p>　　Horizontal scalability for relational databases</p><p>　　Andrew Glover, Author and developer, Beacon50</p><p>　　Andrew Glover is a developer, author, speaker, and entrepreneur with a p

32、assion for behavior-driven development, Continuous Integration, and Agile software development. He is the founder of the easyb Behavior-Driven Development (BDD) framework and is the co-author of three books: Continuous I

33、ntegration, Groovy in Action, and Java Testing Patterns. You can keep up with him at his blog and by following him on Twitter.</p><p>　　Summary:  Sharding isn't for everyone, but it's one way th

34、at relational systems can meet the demands of big data. For some shops, sharding means being able to keep a trusted RDBMS in place without sacrificing data scalability or system performance. In this installment of the Ja

35、va development 2.0 series, find out when sharding works, and when it doesn't, and then get your hands busy sharding a simple application capable of handling terabytes of data.</p><p>　　Date:  31 Aug

36、 2010 Level:  Intermediate PDF:  A4 and Letter (64KB | 15 pages)Get Adobe® Reader® </p><p>　　When relational databases attempt to store terabytes of data in single tables, overall per

37、formance typically degrades. Indexing all that data is obviously expensive for reads, but also for writes. While NoSQL datastores are particularly suited to storing big data (think Google's Bigtable), NoSQL is a pate

38、ntly non-relational approach. For the developer who prefers the ACID-ity and solid structure of a relational database, or the project that requires it, sharding could be an exciting alternative.</p><p>　　Sha

39、rding, an offshoot of database partitioning, isn't a native database technique — it happens at the level of the application. Among various sharding implementations, Hibernate Shards is possibly the most popular in th

40、e world of Java? technology. This nifty project lets you work more or less seamlessly with sharded datasets (I will explain the "more or less" part shortly) using POJOs that are mapped to a logical database. Wh

41、en you use Hibernate Shards, you don't have to specifically map your PO</p><p>　　So far in this series, I've used a simple domain based on the analogy of races and runners to demonstrate various data

42、 storage technologies. This month, I'll use this familiar example to introduce a practical sharding strategy, then implement it in Hibernate Shards. Note that the brunt of the work related to sharding isn't neces

43、sarily related to Hibernate; in fact, coding for Hibernate Shards is the easy part. The real work is figuring out how and what you'll shard. </p><p>　　About this series</p><p>　　The Java dev

44、elopment landscape has changed radically since Java technology first emerged. Thanks to mature open source frameworks and reliable for-rent deployment infrastructures, it's now possible to assemble, test, run, and ma

45、intain Java applications quickly and inexpensively. In this series, Andrew Glover explores the spectrum of technologies and tools that make this new Java development paradigm possible.</p><p>　　Sharding at a

46、 glance</p><p>　　Database partitioning is an inherently relational process of dividing a table's rows by some logical piece of data into smaller groups. If you were partitioning a gigantic table named fo

47、o based on timestamps, for instance, all the data for August 2010 would go in Partition A, while anything since then would be in Partition B, and so on. Partitioning has the effect of making reads and writes faster becau

48、se they target smaller datasets in individual partitions. </p><p>　　Partitioning isn't always available (MySQL didn't support it until version 5.1), and the cost of doing it with a commercial system

49、can be prohibitive. What's more, most partitioning implementations store data on the same physical machine, so you're still bound to the limits of your hardware. Partitioning also doesn't resolve the reliabil

50、ity, or lack thereof, of your hardware. Thus, various smart people started looking for new ways to scale.</p><p>　　Sharding is essentially partitioning at the database level: rather than divide a table's

51、 rows by pieces of data, the database itself is split up (usually across different machines) by some logical data element. That is, rather than splitting up a table into smaller chunks, sharding splits up an entire datab

52、ase into smaller chunks.</p><p>　　The canonical example for sharding is based on dividing a large database storing worldwide customer data by region: Shard A for customers in the United States, Shard B for A

53、sia, Shard C for Europe, and so on. The shards themselves would live on different machines and each shard would hold all related data, such as customer preferences or order history.</p><p>　　The benefit of s

54、harding (like partitioning) is that it compacts big data: individual tables are smaller in each shard, which allows for faster reads and writes, which increases performance. Sharding also conceivably improves reliability

55、, because even if one shard unexpectedly fails, others are still able to serve data. And because sharding is done at the application layer, you can do it for databases that don't support regular partitioning. The mon

56、etary cost is also potentially lower.</p><p>　　Sharding and strategy</p><p>　　Like most technologies, sharding does entail some trade-offs. Because sharding isn't a native database technique

57、 — that is, you must implement it in your application — you'll need to map out your sharding strategy before you begin. Both primary keys and cross-shard queries play a major role when sharding, mainly by defining wh

58、at you can't do.</p><p>　　Primary keysSharding leverages multiple databases, all of which function autonomously, without awareness of their peers. As a result, if you rely on database sequences (such as

59、 for automatic primary key generation), it's likely that an identical primary key will show up across a set of databases. It's possible to coordinate sequences across a distributed database but doing so increases

60、 system complexity. The safest way to prohibit duplicate primary keys is to have your application (which will b</p><p>　　Cross-shard queriesMost sharding implementations (including Hibernate Shards) don'

61、;t permit cross-shard querying, which means you have to go to extra lengths if you want to leverage two sets of data from different shards. (Interestingly, Amazon's SimpleDB also prohibits cross-domain queries.) For

62、instance, if you're storing United States customers in Shard 1, you also need to store all of their related data there. If you try to store that data in Shard 2, things will get complicated, and system </p>&l

63、t;p>　　Clearly, you'll need to fully consider a sharding strategy before you set up your database. And once you've chosen a particular direction, you're more or less tied to it — it's hard to move data

64、around after it's been sharded. </p><p>　　Avoid premature sharding</p><p>　　Sharding is best employed late in the game. Like premature optimization, sharding based on expected data growth co

65、uld be a recipe for disaster. Successful sharding implementations are based on measurably understanding an application's data growth over time, and then extrapolating to the future. Once you've sharded your data

66、it can be extraordinarily hard to move around. </p><p>　　A strategy example</p><p>　　Because sharding binds you to a linear data model (that is, you can't easily join data in different shard

67、s), you should start with a clear picture of how your data will be logically organized per shard. This is usually easiest by focusing on the primary node of a domain. In the case of an e-commerce system, the primary node

68、 could be either an order or a customer. Thus, if you choose "customer" as the basis for your sharding strategy, then all data related to customers will be moved into the resp</p><p>　　For customer

69、s, you could shard based on location (Europe, Asia, Africa, etc.), or you could shard based on something else. It's up to you. Your shard strategy should, however, incorporate some means of distributing data evenly a

70、mong all of your shards. The whole idea of sharding is to break up big data sets into smaller ones; thus, if a particular e-commerce domain had a large set of European customers and relatively few in the United States, i

71、t probably wouldn't make sense to shard based on cus</p><p>　　Off to the races — with sharding!</p><p>　　Getting back to the familiar example of my racing application, I can shard by race or

72、 by runner. In this case, I'm going to shard by race, because I see the domain being organized by runners who belong to races. So the race is the root of my domain. I'm also going to shard based on race distance,

73、 because my racing application holds myriad races of different lengths, along with myriad runners. </p><p>　　Note that in making these decisions, I have already accepted a trade-off: what if a runner partici

74、pates in more than one race, each of them living in different shards? Hibernate Shards (like most sharding implementations) doesn't support cross-shard joins. I'm going to have to live with this slight inconvenie

75、nce and allow runners to live in multiple shards — that is, I will recreate each runner in the shards where his or her various races live.</p><p>　　To keep things simple, I'm going to create two shards:

76、one for races less than 10 miles and another for anything greater than 10 miles.</p><p>　　Implementing Hibernate Shards</p><p>　　Hibernate Shards is made to work almost seamlessly with existing

77、Hibernate projects. The only catch is that Hibernate Shards needs some specific information and behavior from you. Namely, it needs a shard-access strategy, a shard-selection strategy, and a shard-resolution strategy. Th

78、ese are interfaces you must implement, though in some cases you can use default ones. We'll look at each interface separately in the following sections.</p><p>　　ShardAccessStrategy</p><p>　

79、　When a query is executed, Hibernate Shards needs a mechanism for determining which shard to hit first, second, and so on. Hibernate Shards doesn't necessarily figure out what a query is looking for (that's for t

80、he Hibernate Core and underlying database to do), but it does recognize that a query might need to execute against multiple shards before an answer is obtained. So, Hibernate Shards provides two logical implementations o

81、ut of the box: one executes a query in a sequential mechanism (one at</p><p>　　I'm going to keep things simple and utilize the sequential strategy, aptly named SequentialShardAccessStrategy. We'll co

82、nfigure it shortly.</p><p>　　ShardSelectionStrategy</p><p>　　When a new object is created (that is, when a new Race or Runner is created via Hibernate), Hibernate Shards needs to know what shard

83、 the corresponding data should be written to. Accordingly, you must implement this interface and code the sharding logic. If you want a default implementation, there's one dubbed RoundRobinShardSelectionStrategy, whi

84、ch uses a round-robin strategy for putting data into shards. </p><p>　　For the racing application, I need to provide behavior that shards by race distance. Accordingly, I'll need to implement the ShardSe

85、lectionStrategy interface and provide some simple logic that shards based on a Race object's distance in the selectShardIdForNewObject method. (I'll show the Race object shortly.)</p><p>　　At runtime

86、, when a call is made to some save-like method on my domain objects, this interface's behavior is leveraged deep down in Hibernate's core.</p><p>　　Listing 1. A simple shard-selection strategy</p&

87、gt;<p>　　As you can see in LListing 1, if the object being persisted is a Race, then its distance is determined and, accordingly, a shard is picked. In this case, there are two shards: 0 and 1, where Shard 1 holds

88、 races with a distance greater than 10 miles and Shard 0 holds all others. </p><p>　　If a Runner or some other object is being persisted, things get a bit more involved. I've coded a logical rule that ha

89、s three stipulations: </p><p>　　A Runner can't exist without a corresponding Race.</p><p>　　If a Runner has been created with multiple Races, the Runner will be persisted in the shard for th

90、e first Race found. (This rule has negative implications for the future, by the way.)</p><p>　　If some other domain object is being saved, for now, an exception will be thrown.</p><p>　　With tha

91、t, you can wipe the sweat from your brow, because most of the hard work is done. The logic I've captured might not be flexible enough as the racing application grows, but it'll work for the purpose of this demons

92、tration!</p><p>　　ShardResolutionStrategy</p><p>　　When searching for an object by its key, Hibernate Shards needs a way of determining which shard to hit first. You'll use the SharedResolut

93、ionStrategy interface to guide it. </p><p>　　As I mentioned earlier, sharding forces you to be keenly aware of primary keys, as you'll manage them yourself. Luckily, Hibernate is already good at providin

94、g key or UUID generation. Consequently, out of the box, Hibernate Shards provides an ID generator dubbed ShardedUUIDGenerator, which has the smarts to embed shard ID information in the UUID itself. </p><p>　

95、　If you end up using ShardedUUIDGenerator for key generation (as I will for this article), then you can can also use the Hibernate Shards out-of-the-box ShardResolutionStrategy implementation dubbed AllShardsShardResolut

96、ionStrategy, which can determine what shard to search based on a particular object's ID.</p><p>　　Having configured the three interfaces required for Hibernate Shards to work properly, we're ready fo