有這樣乙個應用場景：使用者有兩個連續的操作a和操作b，必須是操作a完成後才能執行操作b，如果操作a沒有完成就觸發了操作b，則顯示使用者需要先執行操作a，即在操作b執行需要查詢操作a是否執行過。這裡引申出來的問題是，記錄使用者參與記錄，提供針對使用者和操作的查詢方法。當不同的資料量時，我們的儲存方案會大不相同，隨著資料的增長，方案不斷演變。
1、資料量較小，使用者操作行為固定：
儲存：mysql
方案：我們以uid為key，一行乙個使用者，每個使用者包括的使用者作為列儲存，比如uid=100，固定儲存為操作a和操作b，則表結構大致如下：
table_operation
uid operation_a operation_b
100 1 1
如果我們要查詢使用者是否參與a或b時，直接使用sql: select * from table_operation where uid=100 and action_a=1就可以達成目標。
問題：使用者操作固定，擴充套件較難，如果需要增加使用者操作行為，則需要增加欄位或增加表儲存，增加欄位的方法在一定的資料量級以下（比如100萬）是可行的，如果行為間無關，則增加表儲存方案的表現會很不錯。
2、資料量較小、使用者操作行為不固定：
與場景1相比，當前場景除了uid這個變數，增加了使用者操作變數，即我們需要關注使用者和使用者操作兩個變數。
儲存：mysql
方案1：增加操作表，生成操作id，使用者操作行為表儲存uid和oid。當使用者執行乙個新的操作時就在操作行為表插入一條記錄。其表結構大致如下：
table_operation_info
oid name
1 operation_a
2 operation_b
table_operation
uid oid
1 11 2
當需要查詢使用者1是否執行過操作a時，使用sql：select * from table_operation where oid=1 and oid=1。
問題：當使用者的操作行為較多時，使用者操作行為增長速度很快，資料量也為逐漸增大，可能mysql單錶無法負載。解決方案在後續場景中說明。
3、資料量較大，使用者行為固定
儲存：mysql
方案：與場景1相比，當前場景不同在於資料量比場景1大，資料量大到mysql單錶負載不過來。此方案解決的就是這個問題，當單錶太大時，價效比較高的方法一般是採用分表。我們當前場景的變數是uid，只要依據uid按水平分表即可。
4、資料量較大，使用者行為不固定
儲存： mysql
方案1：此方案應用於使用者的操作行為可以分類的情況，即在場景1的基礎上增加兩次分表操作，按操作行為類分表和按使用者分表。當前方案中我們需要應對兩個變數：操作行為和使用者。兩次分表分別對應這兩個變數，按業務規則做操作行為的分表操作，按使用者id水平切分減少資料量。
方案2：此方案是完全的水平分表操作，在場景2的方案基礎上，按使用者水平切分。
5、資料量超大
儲存： mysql
方案1：分庫分表，此時乙個庫已經無法滿足需求，規則依據前面的場景實現，根據實際的需求可以考慮把不同的庫放不同的機器上。
方案2：在分庫分表的基礎上，按位儲存，因為乙個操作行為有沒有執行過是乙個是否的狀態，即0，1狀態，因此我們可以用乙個位來儲存，64位可以儲存64個操作行為的標記。
其它儲存
key-value資料庫
我們的需求實際上並不需要太多的關係型資料庫的功能，簡單的 k-v資料庫就可以實現我們的功能，並且在效能上也會有所提公升，畢竟做得少，會快。
先不管是選擇基於記憶體的，還是非記憶體的（可以根據實際需求來選擇，也可以是熱點資料在記憶體，沉默資料在非記憶體中），假設我們有足夠的空間儲存。
方案1：
以uid+oid為key，值可以儲存狀態，也可以只儲存是否參與（0和1），但是會存在key太多的情況，特別是當資料量超大時，uid的個數*oid的個數，可能是你無法相像的量級。
方案2：
一般來說，使用者操作行為的資料量完全小於使用者的量級，並且使用者操作行為的資料可控。如果要減少key的個數，我們可以使用oid+使用者分割槽索引id作為key，這裡所謂的使用者分割槽索引是指將使用者以某個數量分成乙個區，所有的使用者都記錄在這個這個區間內，比如以10000為乙個區間，則uid為1到9999的使用者分到區間0，這裡可以以1和0儲存使用者是否執行了此操作，乙個key對應的value初始化儲存10000個0。當uid=100的使用者執行了某操作，則將第100個0置為1。
方案3：
在方案2的基礎上，將10000個0轉換為10000個01位，假設乙個位儲存50位，則總共只需要200個。
方案4：
當使用者量超大時，大多數的使用者對於某個操作可能都是沒有參與的，則在方案3的基礎上我們增加簡單的稀疏矩陣壓縮，給每個儲存位新增索引，當儲存值不為0時才會儲存。
方案5：
我還沒想到，期待你的分享
小結?隨著資料量的增大，總的思路是分冶，當乙個表搞不定時分表，當乙個庫搞不定時分庫，當一台機器搞不定時加機器。
?對於不同的儲存介質選擇需要考慮成本和需求，所有的選擇都是平衡後的結果。
?節省空間，按位儲存。
?不要過早優化。
使用者參與記錄儲存的演變
有這樣乙個應用場景 使用者有兩個連續的操作a和操作b，必須是操作a完畢後才幹執行操作b，假設操作a沒有完畢就觸發了操作b，則顯示使用者須要先執行操作a，即在操作b執行須要查詢操作a是否執行過。這裡引申出來的問題是，記錄使用者參與記錄，提供針對使用者和操作的查詢方法。當不同的資料量時，我們的儲存方案會...
選擇使用者 儲存選定的使用者
功能要求 1 選擇使用者介面以彈出框方式顯示 2 頁面選項動態載入 部門及使用者 3 儲存勾選的使用者 實現分析 儲存已選使用者邏輯 刪除原來已選擇的使用者記錄列表 相當於清空操作 加入新選擇使用者記錄列表 1 儲存共享檔案 儲存共享檔案 function sharefile catch excep...
提高使用者參與度與黏性的兩種技巧
如果你的應用，是有頻繁的使用需求的非常好用的工具，像qq，那使用者黏性就不是什麼問題了。這裡我要討論的不是通過馬斯洛心理需求層次分析之類的方法，選擇乙個前景大好的產品方向，來從戰略層面解決使用者黏性問題，而是說兩種戰術層面的手段。除了好奇會害死貓，佔小便宜也會害死貓。你可能沒有購買某商品的需求或沒有...