建站
咨詢
售后
建站咨詢
新聞中心
隨著互聯(lián)網(wǎng)和大數(shù)據(jù)時代的到來，企業(yè)數(shù)據(jù)量越來越大，對數(shù)據(jù)庫的存儲和管理提出了更高的要求。傳統(tǒng)單機數(shù)據(jù)庫存儲已經(jīng)無法滿足當(dāng)前的需求，一種新的數(shù)據(jù)庫存儲方案——分區(qū)擴容應(yīng)運而生。它利用多個小型數(shù)據(jù)庫服務(wù)橫向擴展來提高數(shù)據(jù)存儲的效率和可擴展性。本文將從定義、實現(xiàn)原理、使用場景及優(yōu)劣勢等方面來詳細(xì)介紹數(shù)據(jù)庫分區(qū)擴容的相關(guān)知識。
江蘇網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)于2013年成立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。
1.分區(qū)擴容的定義與原理
分區(qū)擴容技術(shù)是將一個大型數(shù)據(jù)庫拆分成多個小分區(qū)分別存儲，并由多個數(shù)據(jù)庫服務(wù)器來管理這些分區(qū)。其中，每個分區(qū)可以簡單理解為一個獨立的數(shù)據(jù)庫實例，擁有自己的數(shù)據(jù)表、索引和存儲引擎等。必要時，還可以根據(jù)數(shù)據(jù)特性和操作頻率等因素動態(tài)地添加或刪除分區(qū)。
分區(qū)擴容的實現(xiàn)原理為將大型數(shù)據(jù)庫按照某種規(guī)則（如按日期、按地域等）分割成多個小型數(shù)據(jù)庫，同時將這些小型數(shù)據(jù)庫部署在多個獨立的服務(wù)器上。每個小型數(shù)據(jù)庫就是一個獨立的分區(qū)，負(fù)責(zé)管理自己的數(shù)據(jù)和索引，同時通過分布式的方式將這些小型數(shù)據(jù)庫整合成一個整體。
2.使用場景
2.1 網(wǎng)絡(luò)流量大、用戶多的應(yīng)用場景
在互聯(lián)網(wǎng)應(yīng)用中，容易出現(xiàn)大量用戶同時對同一數(shù)據(jù)表進(jìn)行操作，由于單臺服務(wù)器的處理能力有限，容易造成系統(tǒng)性能瓶頸。采用數(shù)據(jù)庫分區(qū)擴容技術(shù)，將表數(shù)據(jù)分布在多個數(shù)據(jù)庫之間，可以更大化地提高系統(tǒng)的并發(fā)處理能力，有效緩解服務(wù)器壓力。
2.2 數(shù)據(jù)增長快、存儲需求高的應(yīng)用場景
隨著數(shù)據(jù)的不斷增長和業(yè)務(wù)的不斷發(fā)展，單臺服務(wù)器存儲能力逐漸達(dá)到瓶頸。采用分區(qū)擴容技術(shù)，可以將大型數(shù)據(jù)庫分割成多個小型數(shù)據(jù)庫，分別存儲，有效提高總的數(shù)據(jù)存儲能力，同時保證數(shù)據(jù)的可用性和可靠性。
2.3 海量數(shù)據(jù)查詢分析領(lǐng)域
在大數(shù)據(jù)分析領(lǐng)域，數(shù)據(jù)表通常非常大，查詢操作也極其復(fù)雜，單臺服務(wù)器的性能無法滿足要求。采用分區(qū)擴容技術(shù)，可以通過分布式架構(gòu)的方式，將龐大的數(shù)據(jù)表拆分成多個小型的數(shù)據(jù)表，利用多臺服務(wù)器并行查詢來提高系統(tǒng)的查詢效率。
3. 分區(qū)擴容的優(yōu)劣勢分析
3.1 優(yōu)勢
（1）性能優(yōu)化：通過分區(qū)存儲、分區(qū)索引，提高數(shù)據(jù)查詢和更新的速度。
（2）可擴展性：由于分區(qū)數(shù)據(jù)相互獨立，可以方便地分布式擴展，增加服務(wù)器數(shù)量，提高系統(tǒng)的處理能力。
（3）減輕服務(wù)器壓力：分區(qū)擴容使得多個服務(wù)器同時處理數(shù)據(jù)，分擔(dān)了單臺服務(wù)器的負(fù)荷，提高了系統(tǒng)的穩(wěn)定性。
3.2 劣勢
（1）成本高：采用分區(qū)擴容技術(shù)需要多個服務(wù)器來支持，需要更多的硬件設(shè)備和人力資源。
（2）數(shù)據(jù)分布不均：分區(qū)擴容需要分析數(shù)據(jù)特點，根據(jù)特點盡可能平均地分配數(shù)據(jù)，否則可能會導(dǎo)致某些服務(wù)器過于繁忙，而導(dǎo)致系統(tǒng)性能下降。
4.
綜上所述，數(shù)據(jù)庫分區(qū)擴容技術(shù)是一種有效的大型數(shù)據(jù)庫存儲方案，它可以實現(xiàn)數(shù)據(jù)的分布式存儲、并行查詢等功能，不僅提高了數(shù)據(jù)庫處理的速度，還可以方便地進(jìn)行系統(tǒng)擴展和維護(hù)。隨著互聯(lián)網(wǎng)和大數(shù)據(jù)技術(shù)的發(fā)展，分區(qū)擴容技術(shù)在實際應(yīng)用中也得到了廣泛的應(yīng)用，為企業(yè)帶來了更高效、更可靠的數(shù)據(jù)處理服務(wù)。
相關(guān)問題拓展閱讀：
- Oracle數(shù)據(jù)庫分區(qū)表操作方法
- 開源數(shù)據(jù)庫Sharding技術(shù)[1]
Oracle數(shù)據(jù)庫分區(qū)表操作方法
在大型的企業(yè)應(yīng)用或企業(yè)級的數(shù)據(jù)庫應(yīng)用中 要處理的數(shù)據(jù)量通?？梢赃_(dá)到幾十到幾百GB 有的甚至可以到TB級 雖然存儲介質(zhì)和數(shù)據(jù)處理技術(shù)的發(fā)展也很快 但是仍然不能滿足用戶的需求 為了使用戶的大量的數(shù)據(jù)在讀寫操作和查詢中速度更快 Oracle提供了對表和索引進(jìn)行分區(qū)的技術(shù) 以改善大型應(yīng)用系統(tǒng)的性能
使用分區(qū)的優(yōu)點
·增強可用性 如果表的某個分區(qū)出現(xiàn)故障 表在其他分區(qū)的數(shù)據(jù)仍然可用
·維護(hù)方便 如果表的某個分區(qū)出現(xiàn)故障 需要修復(fù)數(shù)據(jù) 只修復(fù)該分區(qū)即可
·均衡I/O 可以把不同的分區(qū)映射到磁盤以平衡I/O 改善整個系統(tǒng)性能
·改善查詢性能 對分區(qū)對象的查詢可以僅搜索自己關(guān)心的分區(qū) 提高檢索速度
Oracle數(shù)據(jù)庫提供對表或索引的分區(qū)方法有三種
·范圍分區(qū)
·Hash分區(qū)（散列分區(qū)）
·復(fù)合分區(qū)
下面將以實例的方式分別對這三種分區(qū)方法來說明分區(qū)表的使用 為了測試方便 我們先建三個表空間
以下為引用的內(nèi)容
create tablespace dinya_space
datafile /test/demo/oracle/demodata/dinya dnf size M
create tablespace dinya_space
datafile /test/demo/oracle/demodata/dinya dnf size M
create tablespace dinya_space
datafile /test/demo/oracle/demodata/dinya dnf size M
分區(qū)表的創(chuàng)建
范圍分區(qū)
范圍分區(qū)就是對數(shù)據(jù)表中的某個值的范圍進(jìn)行分區(qū) 根據(jù)某個值的范圍 決定將該數(shù)據(jù)存儲在哪個分區(qū)上 如根據(jù)序號分區(qū) 根據(jù)業(yè)務(wù)記錄的創(chuàng)建日期進(jìn)行分區(qū)等
需求描述 有一個物料交易表 表名 material_transactions 該表將來可能有千萬級的數(shù)據(jù)記錄數(shù) 要求在建該表的時候使用分區(qū)表 這時候我們可以使用序號分區(qū)三個區(qū) 每個區(qū)中預(yù)計存儲三千萬的數(shù)據(jù) 也可以使用日期分區(qū) 如每五年的數(shù)據(jù)存儲在一個分區(qū)上
根據(jù)交易記錄的序號分區(qū)建表 以下為引用的內(nèi)容
SQL> create table dinya_test
(
transaction_id number primary key
item_id number( ) not null
item_description varchar ( )
transaction_date date not null
)
partition by range (transaction_id)
(
partition part_ values less than( ) tablespace dinya_space
partition part_ values less than( ) tablespace dinya_space
partition part_ values less than(maxvalue) tablespace dinya_space
);
Table created
建表成功 根據(jù)交易的序號 交易ID在三千萬以下的記錄將存儲在之一個表空間dinya_space 中 分區(qū)名為:par_ 在三千萬到六千萬之間的記錄存儲在第二個表空間
dinya_space 中 分區(qū)名為 par_ 而交易ID在六千萬以上的記錄存儲在第三個表空間dinya_space 中 分區(qū)名為par_
根據(jù)交易日期分區(qū)建表
以下為引用的內(nèi)容
SQL> create table dinya_test
(
transaction_id number primary key
item_id number( ) not null
item_description varchar ( )
transaction_date date not null
)
partition by range (transaction_date)
(
partition part_ values less than(to_date( yyyy mm dd ))
tablespace dinya_space
partition part_ values less than(to_date( yyyy mm dd ))
tablespace dinya_space
partition part_ values less than(maxvalue) tablespace dinya_space
);
Table created
這樣我們就分別建了以交易序號和交易日期來分區(qū)的分區(qū)表 每次插入數(shù)據(jù)的時候 系統(tǒng)將根據(jù)指定的字段的值來自動將記錄存儲到制定的分區(qū)（表空間）中
當(dāng)然 我們還可以根據(jù)需求 使用兩個字段的范圍分布來分區(qū) 如partition
by range ( transaction_id transaction_date)
分區(qū)條件中的值也做相應(yīng)的改變 請讀者自行測試
Hash分區(qū)（散列分區(qū)）
散列分區(qū)為通過指定分區(qū)編號來均勻分布數(shù)據(jù)的一種分區(qū)類型 因為通過在I/O設(shè)備上進(jìn)行散列分區(qū) 使得這些分區(qū)大小一致 如將物料交易表的數(shù)據(jù)根據(jù)交易ID散列地存放在指定的三個表空間中
以下為引用的內(nèi)容
SQL> create table dinya_test
(
transaction_id number primary key
item_id number( ) not null
item_description varchar ( )
transaction_date date
)
partition by hash(transaction_id)
(
partition part_ tablespace dinya_space
partition part_ tablespace dinya_space
partition part_ tablespace dinya_space
);
Table created
建表成功 此時插入數(shù)據(jù) 系統(tǒng)將按transaction_id將記錄散列地插入三個分區(qū)中 這里也就是三個不同的表空間中
復(fù)合分區(qū)
有時候我們需要根據(jù)范圍分區(qū)后 每個分區(qū)內(nèi)的數(shù)據(jù)再散列地分布在幾個表空間中 這樣我們就要使用復(fù)合分區(qū) 復(fù)合分區(qū)是先使用范圍分區(qū) 然后在每個分區(qū)內(nèi)再使用散列分區(qū)的一種分區(qū)方法 如將物料交易的記錄按時間分區(qū) 然后每個分區(qū)中的數(shù)據(jù)分三個子分區(qū) 將數(shù)據(jù)散列地存儲在三個指定的表空間中
以下為引用的內(nèi)容
SQL> create table dinya_test
(
transaction_id number primary key
item_id number( ) not null
item_description varchar ( )
transaction_date date
)
partition by range(transaction_date)subpartition by hash(transaction_id)
subpartitions store in (dinya_space dinya_space dinya_space )
(
partition part_ values less than(to_date( yyyy mm dd ))
partition part_ values less than(to_date( yyyy mm dd ))
partition part_ values less than(maxvalue)
);
Table created
該例中 先是根據(jù)交易日期進(jìn)行范圍分區(qū) 然后根據(jù)交易的ID將記錄散列地存儲在三個表空間中
分區(qū)表操作
以上了解了三種分區(qū)表的建表方法 下面將使用實際的數(shù)據(jù)并針對按日期的范圍分區(qū)來測試分區(qū)表的數(shù)據(jù)記錄的操作
插入記錄
以下為引用的內(nèi)容
SQL> insert into dinya_test values( BOOKS sysdate);
row created
SQL> insert into dinya_test values( BOOKS sysdate+ );
row created
SQL> insert into dinya_test values( BOOKS to_date( yyyy mm dd ));
row created
SQL> insert into dinya_test values( BOOKS to_date( yyyy mm dd ));
row created
SQL> insert into dinya_test values( BOOKS to_date( yyyy mm dd ));
row created
SQL> insert into dinya_test values( BOOKS to_date( yyyy mm dd ));
row created
SQL> mit;
Commit plete
SQL>
按上面的建表結(jié)果 年前的數(shù)據(jù)將存儲在之一個分區(qū)part_ 上 而 年到 年的交易數(shù)據(jù)將存儲在第二個分區(qū)part_ 上 年以后的記錄存儲在第三個分區(qū)part_ 上
查詢分區(qū)表記錄 以下為引用的內(nèi)容
SQL> select * from dinya_test partition(part_ );
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
BOOKS : :
BOOKS : :
SQL>
SQL> select * from dinya_test partition(part_ );
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
BOOKS
BOOKS
SQL>
SQL> select * from dinya_test partition(part_ );
TRANSACTION_ID ITEM_ID ITEM_DESCRIPTION TRANSACTION_DATE
BOOKS
BOOKS
SQL>
從查詢的結(jié)果可以看出 插入的數(shù)據(jù)已經(jīng)根據(jù)交易時間范圍存儲在不同的分區(qū)中 這里是指定了分區(qū)的查詢 當(dāng)然也可以不指定分區(qū) 直接執(zhí)行select * from dinya_test查詢?nèi)坑涗?/p>
在也檢索的數(shù)據(jù)量很大的時候 指定分區(qū)會大大提高檢索速度
更新分區(qū)表的記錄
以下為引用的內(nèi)容
SQL> update dinya_test partition(part_ ) t set em_description= DESK where
t transaction_id= ;
row updated
SQL> mit;
Commit plete
SQL>
這里將之一個分區(qū)中的交易ID= 的記錄中的item_description字段更新為 DESK 可以看到已經(jīng)成功更新了一條記錄 但是當(dāng)更新的時候指定了分區(qū) 而根據(jù)查詢的記錄不在該分區(qū)中時 將不會更新數(shù)據(jù) 請看下面的例子 以下為引用的內(nèi)容
SQL> update dinya_test partition(part_ ) t set em_description= DESK where
t transaction_id= ;
rows updated
SQL> mit;
Commit plete
SQL>
指定了在之一個分區(qū)中更新記錄 但是條件中限制交易ID為 而查詢?nèi)?交易ID為 的記錄在第三個分區(qū)中 這樣該條語句將不會更新記錄
刪除分區(qū)表記錄
以下為引用的內(nèi)容
SQL> delete from dinya_test partition(part_ ) t where t transaction_id= ;
row deleted
SQL> mit;
Commit plete
SQL>
上面例子刪除了第二個分區(qū)part_ 中的交易記錄ID為 的一條記錄 和更新數(shù)據(jù)相同 如果指定了分區(qū) 而條件中的數(shù)據(jù)又不在該分區(qū)中時 將不會刪除任何數(shù)據(jù)
分區(qū)表索引的使用
分區(qū)表和一般表一樣可以建立索引 分區(qū)表可以創(chuàng)建局部索引和全局索引 當(dāng)分區(qū)中出現(xiàn)許多事務(wù)并且要保證所有分區(qū)中的數(shù)據(jù)記錄的唯一性時采用全局索引
局部索引分區(qū)的建立
以下為引用的內(nèi)容
SQL> create index dinya_idx_t on dinya_test(item_id)
local
(
partition idx_ tablespace dinya_space
partition idx_ tablespace dinya_space
partition idx_ tablespace dinya_space
);
Index created
SQL>
看查詢的執(zhí)行計劃 從下面的執(zhí)行計劃可以看出 系統(tǒng)已經(jīng)使用了索引
以下為引用的內(nèi)容
SQL> select * from dinya_test partition(part_ ) t where em_id= ;
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Bytes= )
TABLE ACCESS (BY LOCAL INDEX ROWID) OF DINYA_TEST (Cost=
Card= Bytes= )
INDEX (RANGE SCAN) OF DINYA_IDX_T (NON UNIQUE) (Cost=
Card= )
Statistics
recursive calls
db block gets
consistent gets
physical reads
redo size
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
SQL>
全局索引分區(qū)的建立
全局索引建立時global 子句允許指定索引的范圍值 這個范圍值為索引字段的范圍值
以下為引用的內(nèi)容
SQL> create index dinya_idx_t on dinya_test(item_id)
global partition by range(item_id)
(
partition idx_ values less than ( ) tablespace dinya_space
partition idx_ values less than ( ) tablespace dinya_space
partition idx_ values less than (maxvalue) tablespace dinya_space
);
Index created
SQL>
本例中對表的item_id字段建立索引分區(qū) 當(dāng)然也可以不指定索引分區(qū)名直接對整個表建立索引 如
以下為引用的內(nèi)容
SQL> create index dinya_idx_t on dinya_test(item_id);
Index created
SQL>
同樣的 對全局索引根據(jù)執(zhí)行計劃可以看出索引已經(jīng)可以使用
以下為引用的內(nèi)容
SQL> select * from dinya_test t where em_id= ;
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE (Cost= Card= Bytes= )
TABLE ACCESS (BY GLOBAL INDEX ROWID) OF DINYA_TEST (Cost
= Card= Bytes= )
INDEX (RANGE SCAN) OF DINYA_IDX_T (NON UNIQUE) (Cost=
Card= )
Statistics
recursive calls
db block gets
consistent gets
physical reads
redo size
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
SQL>
分區(qū)表的維護(hù)
了解了分區(qū)表的建立 索引的建立 表和索引的使用后 在應(yīng)用的還要經(jīng)常對分區(qū)進(jìn)行維護(hù)和管理 日常維護(hù)和管理的內(nèi)容包括 增加一個分區(qū) 合并一個分區(qū)及刪除分區(qū)等等 下面以范圍分區(qū)為例說明增加 合并 刪除分區(qū)的一般操作
增加一個分區(qū):
以下為引用的內(nèi)容
SQL> alter table dinya_test
add partition part_ values less than(to_date( yyyy mm dd ))
tablespace dinya_spa
ce ;
Table altered
SQL>
增加一個分區(qū)的時候 增加的分區(qū)的條件必須大于現(xiàn)有分區(qū)的更大值 否則系統(tǒng)將提示ORA partition bound must collate higher than that of the last partition 錯誤
合并一個分區(qū)
以下為引用的內(nèi)容
SQL> alter table dinya_test merge partitions part_ part_ into partition part_ ;
Table altered
SQL>
在本例中將原有的表的part_ 分區(qū)和part_ 分區(qū)進(jìn)行了合并 合并后的分區(qū)為part_ 如果在合并的時候把合并后的分區(qū)定為part_ 的時候 系統(tǒng)將提示ORA cannot reuse lower bound partition as resulting partition 錯誤
刪除分區(qū)
以下為引用的內(nèi)容
SQL> alter table dinya_test drop partition part_ ;
Table altered
SQL>
刪除分區(qū)表的一個分區(qū)后 查詢該表的數(shù)據(jù)時顯示 該分區(qū)中的數(shù)據(jù)已全部丟失 所以執(zhí)行刪除分區(qū)動作時要慎重 確保先備份數(shù)據(jù)后再執(zhí)行 或?qū)⒎謪^(qū)合并
總結(jié)
lishixinzhi/Article/program/Oracle/202311/17329
開源數(shù)據(jù)庫Sharding技術(shù)[1]
從 Shard 到 Sharding
Shard 這個詞英文的意思是 碎片 而作為數(shù)據(jù)庫相關(guān)的技術(shù)用語 似乎最早見于大型多人在線角色扮演游戲(MMORPG)中的 Sharding 姑且稱之為 分片
Sharding 不是一門新技術(shù) 而是一個相對簡樸的軟件理念 如您所知 MySQL 之后才有了數(shù)據(jù)表分區(qū)功能 那么在此之前 很多 MySQL 的潛在用戶源頃都對 MySQL 的擴展性有所顧慮 而是否具備分區(qū)功能就成了衡量一個數(shù)據(jù)庫可擴展性與否的一個關(guān)鍵指標(biāo)(當(dāng)然不是唯一指標(biāo)) 數(shù)據(jù)庫擴展性是一個永恒的話題 MySQL 的推廣者經(jīng)常會被問到 如在單一數(shù)據(jù)庫上處帶裂哪理應(yīng)用數(shù)據(jù)捉襟見肘而需要進(jìn)行分區(qū)化之類的處理 是如何辦到的呢? 答案是 Sharding
Sharding 不是一個某個特定數(shù)據(jù)庫軟件附屬的功能 而是在具體技術(shù)細(xì)節(jié)之上的抽象處理 是水平擴展(Scale Out 亦或橫向擴展 向外擴展)的解決方案 其主要目的是為突破單節(jié)點數(shù)據(jù)庫服務(wù)器的 I/O 能力限制 解決數(shù)據(jù)庫擴展性問題
事關(guān)數(shù)據(jù)庫擴展性
說起數(shù)據(jù)庫擴展性 這是個非常大的話題 目前的商業(yè)數(shù)據(jù)都有自己的擴展性解決方案 在過去相對來說比較成熟 但是隨著互聯(lián)網(wǎng)的高速發(fā)展 不可避免的會帶來一些計算模式上的演變 這樣很多主流商業(yè)系統(tǒng)也難免暴露出一些不足之處 比如 Oracle 的 RAC 是采用共享存儲機制 對于 I/O 密集型的應(yīng)用 瓶頸很容易落在存儲上 這樣的機制決定后續(xù)擴容只能是 Scale Up（向上擴展） 類型 對于硬件成本 開發(fā)人員的要求 維護(hù)成本都相對比較高
Sharding 基本上是針對開源數(shù)據(jù)庫的擴展性解決方案 很少有聽說商業(yè)數(shù)據(jù)庫進(jìn)行 Sharding 的 目前業(yè)界的趨勢基本上是擁抱 Scale Out 逐漸從 Scale Up 中解放出來
Sharding 的應(yīng)用場景
任何技術(shù)都是在合適的場合下能發(fā)揮應(yīng)有的作用 Sharding 也一樣 聯(lián)機游戲 IM BSP 都是比較適合 Sharding 的應(yīng)用場景 其共性是抽象出來的數(shù)據(jù)對象之間的關(guān)聯(lián)數(shù)據(jù)很小 比如IM 每個用戶如果抽象成一個數(shù)據(jù)對象 完全可以獨立存儲在任何一個地方 數(shù)據(jù)對象是 Share Nothing 的 再比如 Blog 服務(wù)提供商的站點內(nèi)容 基本為用戶生成內(nèi)容(UGC) 完全可蠢碼以把不同的用戶隔離到不同的存儲 而對用戶來說是透明的
這個 Share Nothing 是從數(shù)據(jù)庫集群中借用的概念 舉例來說 有些類型的數(shù)據(jù)粒度之間就不是 Share Nothing 的 比如類似交易記錄的歷史表信息 如果一條記錄中既包含賣家信息與買家信息 如果隨著時間推移 買 賣家會分別與其他用戶繼續(xù)進(jìn)行交易 這樣不可避免的兩個買賣家的信息會分布到不同的 Sharding DB 上 而這時如果針對買賣家查詢 就會跨越更多的 Sharding 開銷就會比較大
Sharding 并不是數(shù)據(jù)庫擴展方案的銀彈 也有其不適合的場景 比如處理事務(wù)型的應(yīng)用就會非常復(fù)雜 對于跨不同DB的事務(wù) 很難保證完整性 得不償失 所以 采用什么樣的 Sharding 形式 不是生搬硬套的
Sharding與數(shù)據(jù)庫分區(qū)(Partition)的區(qū)別
有的時候 Sharding 也被近似等同于水平分區(qū)(Horizontal Partitioning) 網(wǎng)上很多地方也用 水平分區(qū)來指代 Sharding 但我個人認(rèn)為二者之間實際上還是有區(qū)別的 的確 Sharding 的思想是從分區(qū)的思想而來 但數(shù)據(jù)庫分區(qū)基本上是數(shù)據(jù)對象級別的處理 比如表和索引的分區(qū) 每個子數(shù)據(jù)集上能夠有不同的物理存儲屬性 還是單個數(shù)據(jù)庫范圍內(nèi)的操作 而 Sharding 是能夠跨數(shù)據(jù)庫 甚至跨越物理機器的
lishixinzhi/Article/program/SQL/202311/16326
關(guān)于數(shù)據(jù)庫分區(qū)擴容的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
成都網(wǎng)站推廣找創(chuàng)新互聯(lián)，老牌網(wǎng)站營銷公司
成都網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)(www.cdcxhl.com)專注高端網(wǎng)站建設(shè),網(wǎng)頁設(shè)計制作,網(wǎng)站維護(hù),網(wǎng)絡(luò)營銷,SEO優(yōu)化推廣,快速提升企業(yè)網(wǎng)站排名等一站式服務(wù)。IDC基礎(chǔ)服務(wù)：云服務(wù)器、虛擬主機、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗、服務(wù)器租用、服務(wù)器托管提供四川、成都、綿陽、雅安、重慶、貴州、昆明、鄭州、湖北十堰機房互聯(lián)網(wǎng)數(shù)據(jù)中心業(yè)務(wù)。
網(wǎng)站題目：數(shù)據(jù)庫分區(qū)擴容，實現(xiàn)更高效的數(shù)據(jù)存儲 (數(shù)據(jù)庫分區(qū)擴容)
網(wǎng)站路徑：http://www.fisionsoft.com.cn/article/djdhpdc.html
