spi flash的優點就是相對
eeprom
的儲存容量更大，相對於大容量的
sd卡和
u盤，**有優勢，但其缺點是每次寫入的資料空間都要是沒有寫過的，否則可能都要去擦除一次扇區，在去寫入資料，在擦除扇區之前還要對這個扇區之前的資料進行儲存，擦除完成後，再將老資料和新資料一起寫入。好的器件擦個十幾萬次可能都沒問題，不好的器件可能幾萬次都扛不住。
如何解決這樣的缺點？針對不同的系統可能有不同的方案。因為最近在做spi flash
的資料儲存和查詢，所以想到了一些方案，寫出來供以後再深究。
1.根據該系統能提供的最長歷史記錄的時間來設計。
假設我的系統最長能提供3
個月的歷史記錄查詢，那麼我只要估計出每個月我的系統，最大的歷史記錄條數是多少？一條歷史記錄的位元組數是多少？這裡假設每個月我的系統最大的歷史記錄條數是
1000
條，一條歷史記錄的位元組數是
40個位元組，那麼乙個扇區
4096/40
，這樣乙個月的記錄大概需要十個扇區，這樣
3個月的記錄加上乙個輪詢的緩衝就需要
40個扇區來完成這樣的系統設計。
40*4094/1024=160kbyte,
這樣的容量的
spifalsh
是很小的，所以你可以提供半年的歷史記錄查詢都可以。優點：每個扇區的擦除次數可能
3個月才有一次，查詢資料快，不需要考慮資料的
copy
工作。但是這樣設計系統有自己的限制：
1）受制於系統的rtc
，倘若系統沒有
rtc，或者
rtc故障，會直接影響資料的可靠和實時性。
2）每個月我的系統，最大的歷史記錄條數是多少？這個問題可能不是由我確定的，而是使用者確定的，你不能限制使用者。
3）如果最長要提供一年的歷史記錄，或者一條歷史記錄就有100byte,
你會發現這樣的設計也很吃
flah
的。2.根據該系統最多能提供多少條歷史記錄來設計。
假設我能提供10000
條記錄，每條的記錄資訊佔
80個位元組，則我大約需要
197個扇區。首先看優點：不受限於
rtc，不受限於使用者每個月的操作的次數。缺點：查詢資料的範圍變大，響應可能變慢，
10000
條資料一旦寫完，回頭再寫時，每個扇區的老資料是儲存還是不儲存？不儲存可能會引起使用者不滿，儲存，勢必要不斷的擦除扇區，在寫入資料。這裡一定要注意扇區的擦除次數是有限的，要是產保3年，
flash
能不能扛的了，是要關注的首要問題。
處理上面的問題，方法可能有很多？最長見的可能是不對舊資料儲存，乙個扇區一旦再被寫，直接先扇區擦除（如果資料很久遠也到無所謂）。第二種：劃出2
個197
個扇區，或者更多，在第乙個
197個扇區寫滿
8萬次的時候（這裡自己設計到底寫完多少次？）啟用第二個
197個扇區去儲存資料，這樣對資料的查詢變得更為複雜......
EventStore檔案儲存設計
enode是乙個cqrs event sourcing架構的開發框架，event sourcing需要持久化事件，事件可以持久化在db，但是db由於面向的是crud場景，是針對資料會不斷修改或刪除的場景，所以內部實現會比較複雜，效能也相對比較低。而event store實際上對資料只有新增和查詢的需...
雲儲存設計需求
在網上看到乙個pdf，題目叫 cloud storage solution technical requirement 講述了雲儲存的設計需求，個人覺得寫的還不錯，於是為了鍛鍊自己的e文，同時又方便其他童鞋，將它翻譯了下。翻譯不當之處還請見諒。由於我所在的公司也做雲儲存 順便推廣下哈 我將它的需求和...
單機儲存原理與設計
1 單機儲存引擎 儲存引擎是儲存系統的發動機，決定了儲存系統能夠提供的功能和效能。儲存系統提供功能 create update read delete curd 儲存引擎型別有 雜湊儲存引擎 b樹儲存引擎 lsm儲存引擎 2 雜湊儲存引擎 基於雜湊表結構的鍵值儲存系統，陣列 鍊錶的方式實現，支援持c...