MongoDB 分片片键如何选择
本文探讨了如何合理设置MongoDB片键以发挥分片机制的优势,作者为Bugsnag.com的工程师Conrad Irwin。Bugsnag为移动应用开发者提供实时的Bug追踪及检测服务,Bugsnag使用MongoDB存储超过TB级的文档数据。 简而言之,使用{_id: ‘hashed’}或{projectId: 1, _i
本文探讨了如何合理设置MongoDB片键以发挥分片机制的优势,作者为Bugsnag.com的工程师Conrad Irwin。Bugsnag为移动应用开发者提供实时的Bug追踪及检测服务,Bugsnag使用MongoDB存储超过TB级的文档数据。
简而言之,使用{_id: ‘hashed’}或{projectId: 1, _id: 1}来作为片键。
几个月前,我们对MongoDB集群进行分片(shard)处理,数据设置了两个副本集合(replica set)。上周,我们添加了一个新的分片。首次分片花了一些功夫,不过我们仍然在没有停机的情况下完成了这个工作,如今添加一个新的分片是很轻而易举的事情。
MongoDB的分片是如何工作的?
MongoDB的分片机制能够帮助你将你的数据库划分到多个服务器,通常在生产环境中可以将数据集划分到多个副本集中。但分片最好在数据库建立早期划分,因为一旦你的数据大于512GB那么分片划分就不是那么容易了。这受到MongoDB纵向扩展能力的限制。
为了实现分片,你必须向MongoDB指定使用哪个索引作为片键,然后MongoDB会根据你的设置将你的数据划分到有着相同片键的数据块(Chunk)中。而后这些数据块将根据片键的大致顺序分散到副本集中。
正如你所见,分片之后数据的存放位置依赖于片键,所以合理的选择片键十分重要。
好片键的要素
MongoDB的内部机制保证了每个副本集(RS)包含了同样数量的块,在上图中一个RS包含两个块,而在Bugsnag.com的集群中,每个RS包含6300个块。但这几乎是唯一的保证机制了。
片键的选择决定了三个重要的方面:
1. 读和写的分布
其中最重要的一点是读和写的分布。如果你总是朝一台机器写,那么这台机器将会成为写瓶颈,则你的集群的写性能将会降低。这无关乎你的集群有多少个节点,因为所有的写操作都只在一个地方进行。因此,你不应该使用单调递增的`_id`或时间戳作为片键,这样将会导致你一直往最后一个副本集中添加数据。
相类似的是如果你的读操作一直都在同一个副本集上,那么你最好祈求你的任务能在机器内存所能承受的范围之内。通过副本集将读请求划分开能够使你的工作数据集大小随着分片数线性扩展。这样的话你能够将负载压力均分到各台机器的内存和磁盘之上。
2. 数据块的大小
其次是数据块的大小。MongoDB能够将大的数据块划分成更小的,但这种情况仅仅在片键不同的情况下发生。如果你有巨量的数据文档都使用了同样的片键,那么你相应的会得到巨大的数据块。出现巨大块是非常不好的,不仅仅因为它会导致数据的不平均分布,还因为一旦这个数据块的大小超过某个值,那么你就不能够在分片之间移动它了。
3. 每个查询命中的分片数目
最后一点,如果能够保证大部分的查询请求都能够命中尽可能少的分片那就最好了。对于一个查询请求来说,其延迟直接取决于最慢的那个命中服务器的延迟;所以你命中的分片越少,那么理论上来说查询将会越快。这一点并不是硬性的规定,不过如果能够做到充分考虑那么应该是很有利的。因为数据块在分片上的分布仅仅是近似的遵循片键的顺序,而并不是严格的强制指定。
好片键是如何炼成的?
上面说了这么多,那么怎么才能设计一个好的片键呢?
Hashed id
作为第一个方案,你可以使用数据文档_id的哈希作为片键。
db.events.createIndex({_id: 'hashed'})
这个方案能够是的读和写都能够平均分布,并且它能够保证每个文档都有不同的片键所以数据块能够很精细。
似乎还是不够完美,因为这样的话对多个文档的查询必将命中所有的分片。虽说如此,这也是一种比较好的方案了。
多租户混合索引(Multi-tenant compound index)
如果想击败哈希索引模式,那么你需要将关联的文档在索引中尽可能聚集在一起的方法。在Bugsnag,我们通过project聚合文档,因为在我们的业务场景中,我们的app大部分的查询请求都在project范围内。所以对于你的app来说你得指定适合你的聚合方式。
但是我们不能简单地使用projectID作为片键,因为那会导致巨大块的产生,所以我们引入了_id来将大project打散到多个块中。这些打散的块仍旧是索引连续的,所以仍然会分布在用一个分片上。
db.events.createIndex({projectId: 1, _id: 1})
这个方案很适合我们,因为对于一个project来说,读和写几乎是独立于project存在时间的,并且旧的project通常都会被删除掉。如果情况改变,我们可能会看到在新的project会有微小的负载上升情况。
为了避免这种问题,我们未来可能会在当MongoDB支持哈希值的混合索引之后,将索引设置为{projectId: ‘hashed’, _id: 1}。相关文档(SERVER-10220)
总结
找一个好的片键是很难的,不过这真的只有两种方案。如果在应用中找不出一个好的聚合键,那么对_id做哈希吧。如果你能够找到,那么将它与`_id`聚合以避免巨大块的产生。请记住无论你使用何种聚合键,它都需要能够将读和写平均分布以充分利用集群中的每个节点。
转自: https://bugsnag.com/blog/mongo-shard-key http://blog.jobbole.com/68854/
原文地址:MongoDB 分片片键如何选择, 感谢原作者分享。

熱AI工具

Undresser.AI Undress
人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool
免費脫衣圖片

Clothoff.io
AI脫衣器

Video Face Swap
使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱門文章

熱工具

記事本++7.3.1
好用且免費的程式碼編輯器

SublimeText3漢化版
中文版,非常好用

禪工作室 13.0.1
強大的PHP整合開發環境

Dreamweaver CS6
視覺化網頁開發工具

SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)

.NET 4.0 用於創建各種應用程序,它為應用程式開發人員提供了豐富的功能,包括:物件導向程式設計、靈活性、強大的架構、雲端運算整合、效能最佳化、廣泛的程式庫、安全性、可擴展性、資料存取和行動開發支援。

本文介紹如何在Debian系統上配置MongoDB實現自動擴容,主要步驟包括MongoDB副本集的設置和磁盤空間監控。一、MongoDB安裝首先,確保已在Debian系統上安裝MongoDB。使用以下命令安裝:sudoaptupdatesudoaptinstall-ymongodb-org二、配置MongoDB副本集MongoDB副本集確保高可用性和數據冗餘,是實現自動擴容的基礎。啟動MongoDB服務:sudosystemctlstartmongodsudosys

在開發一個電商網站時,我遇到了一個棘手的問題:如何為用戶提供個性化的商品推薦。最初,我嘗試了一些簡單的推薦算法,但效果並不理想,用戶的滿意度也因此受到影響。為了提升推薦系統的精度和效率,我決定採用更專業的解決方案。最終,我通過Composer安裝了andres-montanez/recommendations-bundle,這不僅解決了我的問題,還大大提升了推薦系統的性能。可以通過一下地址學習composer:學習地址

本文介紹如何在Debian系統上構建高可用性的MongoDB數據庫。我們將探討多種方法,確保數據安全和服務持續運行。關鍵策略:副本集(ReplicaSet):利用副本集實現數據冗餘和自動故障轉移。當主節點出現故障時,副本集會自動選舉新的主節點,保證服務的持續可用性。數據備份與恢復:定期使用mongodump命令進行數據庫備份,並製定有效的恢復策略,以應對數據丟失風險。監控與報警:部署監控工具(如Prometheus、Grafana)實時監控MongoDB的運行狀態,並

直接通過 Navicat 查看 MongoDB 密碼是不可能的,因為它以哈希值形式存儲。取回丟失密碼的方法:1. 重置密碼;2. 檢查配置文件(可能包含哈希值);3. 檢查代碼(可能硬編碼密碼)。

CentOS系統下MongoDB高效備份策略詳解本文將詳細介紹在CentOS系統上實施MongoDB備份的多種策略,以確保數據安全和業務連續性。我們將涵蓋手動備份、定時備份、自動化腳本備份以及Docker容器環境下的備份方法,並提供備份文件管理的最佳實踐。手動備份:利用mongodump命令進行手動全量備份,例如:mongodump-hlocalhost:27017-u用戶名-p密碼-d數據庫名稱-o/備份目錄此命令會將指定數據庫的數據及元數據導出到指定的備份目錄。

CentOS系統上GitLab數據庫部署指南選擇合適的數據庫是成功部署GitLab的關鍵步驟。 GitLab兼容多種數據庫,包括MySQL、PostgreSQL和MongoDB。本文將詳細介紹如何選擇並配置這些數據庫。數據庫選擇建議MySQL:一款廣泛應用的關係型數據庫管理系統(RDBMS),性能穩定,適用於大多數GitLab部署場景。 PostgreSQL:功能強大的開源RDBMS,支持複雜查詢和高級特性,適合處理大型數據集。 MongoDB:流行的NoSQL數據庫,擅長處理海

MongoDB與關係型數據庫:深度對比本文將深入探討NoSQL數據庫MongoDB與傳統關係型數據庫(如MySQL和SQLServer)的差異。關係型數據庫採用行和列的表格結構組織數據,而MongoDB則使用靈活的面向文檔模型,更適應現代應用的需求。主要區別數據結構:關係型數據庫使用預定義模式的表格存儲數據,表間關係通過主鍵和外鍵建立;MongoDB使用類似JSON的BSON文檔存儲在集合中,每個文檔結構可獨立變化,實現無模式設計。架構設計:關係型數據庫需要預先定義固定的模式;MongoDB支持
