MySQL的鍵值儲存以及與MongoDB的對比
Faster and faster, that is what we want from our databases. And the biggest roadblock for the MySQL Dragster is the speed of the hard disk, right? No, I'm not going to debate that, that is just the case. And how do you fix that then? Well, if what is limiting your dragster is a roadblock, then either you drive round the roadblock of you make it disappear faster, or in computer terms:
1. Avoid using the disk by instead putting as much data as you can in RAM
2. Use faster disks (like SSDs)
Now, to be honest, this analogy isn't that good because the performance limiting factor of the disk is so huge, and contrary to popular belief, it's not getting any better! But we have SSDs you say? Yes, that makes the hard drive faster, but the CPU and RAM are getting even faster! But let's assume that we have enough memory so we do not need the disk? Will just about everything go at the speed of light? Nope, what happens here is that stuff that wasn't even noticeable in terms of limiting performance when the disk was there, as disk-I/O is such a huge bottleneck, suddenly shows it's dirty face!
Like this: As the CPU cores are getting faster, but not that much faster anymore, due to physical limitations, we have more and more of these CPU cores instead. And suddenly, any limitation in getting those CPUs to work well together suddenly turns into a major headache! Like a mutex shared by all threads. Like the Query Cache mutex in MySQL for example!
1. Avoid using the disk by instead putting as much data as you can in RAM
2. Use faster disks (like SSDs)
Now, to be honest, this analogy isn't that good because the performance limiting factor of the disk is so huge, and contrary to popular belief, it's not getting any better! But we have SSDs you say? Yes, that makes the hard drive faster, but the CPU and RAM are getting even faster! But let's assume that we have enough memory so we do not need the disk? Will just about everything go at the speed of light? Nope, what happens here is that stuff that wasn't even noticeable in terms of limiting performance when the disk was there, as disk-I/O is such a huge bottleneck, suddenly shows it's dirty face!
Like this: As the CPU cores are getting faster, but not that much faster anymore, due to physical limitations, we have more and more of these CPU cores instead. And suddenly, any limitation in getting those CPUs to work well together suddenly turns into a major headache! Like a mutex shared by all threads. Like the Query Cache mutex in MySQL for example!
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/301743/viewspace-742703/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 實現鍵值對儲存(二):以現有鍵值對儲存為模型模型
- KV儲存的對比
- 實現鍵值對儲存(一):什麼是鍵值對儲存,為什麼要實現它
- 實現鍵值對儲存(三):Kyoto Cabinet和LevelDB的架構比較分析架構
- 進階篇_map容器(儲存鍵值對)
- 實現鍵值對儲存(0):目錄
- 簡單的鍵值儲存測試
- 實現鍵值對儲存(四):API設計API
- MySQL和Oracle對比之儲存過程MySqlOracle儲存過程
- MySQL與MongoDB設計例項對比QYMySqlMongoDB
- SQL與MongoDB的詳細對比SQLMongoDB
- MySQL 的 NULL 值是怎麼儲存的?MySqlNull
- 檔案系統儲存與oracle資料庫儲存對比Oracle資料庫
- MySQL 儲存過程引數IN OUT INOUT對比MySql儲存過程
- 981-基於時間的鍵值儲存
- Android鍵值對儲存成XML檔案SharedPreferencesAndroidXML
- 實現鍵值對儲存(五):雜湊表實現
- MySQL Innodb 儲存結構 & 儲存Null值 解析MySqlNull
- 面向不同需求的物件儲存系統對比:Ceph與Swift物件Swift
- 資料儲存加密的主流方案對比與難點解析加密
- MySQL三種InnoDB、MyISAM和MEMORY儲存引擎對比MySql儲存引擎
- mysql 儲存過程中變數的定義與賦值操作MySql儲存過程變數賦值
- MongoDB 儲存引擎與內部原理MongoDB儲存引擎
- 用鍵值儲存實現MVCC模式MVC模式
- 儲存結構的種類與比較
- 基於 SmartX 分散式儲存的 RDMA 與 TCP/IP 技術與效能對比分散式TCP
- MYSQL多表更新刪除以及和ORACLE的對比MySqlOracle
- 庫存-Mysql中的事務、鎖與儲存引擎MySql儲存引擎
- Js 比較兩個物件的鍵名與鍵值是否相等JS物件
- mysql 儲存過程,以及mybatis如何呼叫MySql儲存過程MyBatis
- 提升Raft以加速分散式鍵值儲存Raft分散式
- 儲存技術對比:NVMe與SATA孰強孰弱?
- [ 丹臣]INNODB與ORACLE單行儲存長度對比Oracle
- MySQL和MongoDB設計例項對比MySqlMongoDB
- 物件儲存服務與圖片伺服器的優缺點對比物件伺服器
- MySQL null值儲存,null效能影響MySqlNull
- MySQL儲存引擎MyISAM與InnoDB的優劣MySql儲存引擎
- 儲存過程中SELECT與SET對變數賦值儲存過程變數賦值