db的sql查詢所帶來的程式設計方面的靈活，是其他nosql方式的儲存和查詢幾乎無法取代的。
就拿elasticsearch的儲存和查詢來舉例，它是很快，處理億級資料是小case。但是：
1.結構發生變化怎麼辦？舉個例子，很多時候，都會由於業務的變更而某些表增加欄位的情況。對於db來說，只需要alter table *** add column *** 即可以了；但是elasticsearch卻涉及重建索引的問題
2.對很多靈活的查詢，多個條件巢狀子查詢、多表關聯查詢都幾乎不能支援。
今天看了一篇文章，他每天處理3億多條資料，包括入庫和查詢。方式很受啟發。
1.分表，這是必須的
2.如何能夠快速入庫，就是表上不帶任何索引
3.如何能夠快速查詢，就是表上經常查的字段得帶索引；而且寫sql時，帶索引的字段在where中應該居前
可以看到，2和3是相悖的。
那麼就分兩個庫，乙個是讀寫庫乙個是唯讀庫。
讀寫庫只存放1個小時內的資料，要查乙個小時內的資料就從這裡面查。它上面不加任何索引。---保證入庫的速度
唯讀庫定時將讀寫庫中的資料入庫，建立索引。---保證查詢的速度
個人認為，目前的nosql技術不足以取代sql db。至少難以面對業務的變更對儲存的影響，以及靈活查詢的挑戰。未來的大方向應該是結合搜尋引擎和傳統關係型資料庫。
3n 1問題大資料如何處理？
題目來自codevs 3n 1問題是乙個簡單有趣而又沒有解決的數學問題。這個問題是由l.collatz在1937年提出的。克拉茲問題 collatz problem 也被叫做hailstone問題 3n 1問題 hasse演算法問題 kakutani演算法問題 thwaites猜想或者ulam問題。...
php如何處理大資料高併發
大資料解決方案 使用快取 使用方式 1，使用程式直接儲存到記憶體中。主要使用map，尤其concurrenthashmap。使用快取框架。常用的框架 ehcache，memcache，redis等。最關鍵的問題是 什麼時候建立快取，以及其失效機制。對於空資料的緩衝 最好用乙個特定的型別值來儲存，以區...
如何處理死鎖問題
總結如下 1.評估一下程式，看看是否確實需要有兩個mutex？如果只有乙個mutex，就不存在死鎖的問題了。2.避免在鎖住mutex的同時，去呼叫另外的我們不熟悉的函式，因為有可能這個函式包含了另外的鎖，所以我們必須清楚我們所呼叫的其他的函式或者類。3.如果確實需要在同一時間使用兩個以上的mutex...