1.
需求朋友的一家公司，拿到了風投，準備做條碼**商軟體。
簡單說起來，就是提供整套的條形碼技術解決方案給製造業產商。讓產品從生產到入庫到銷售的整個流程通過條形碼被我方系統記憶。
產品的簡單需求如下：
a. 條碼**系統是saas的網際網路產品。要求高實時性，高可靠性。
b. 條形碼預先由我方系統生成並且記錄。
c. 客戶方購買我方的條形碼，並且在生產，製造，銷售各個環節將包括該批次使用的條形碼資料用xml檔案傳給我方系統。
d. 我方系統實時的讀入這些xml檔案，並且比對我方資料，更新該條碼的使用情況，更新該商品的情況
e. 我方系統對公眾提供介面，可以通過購買商品的條形碼可以實時的查詢該商品的產地，原料，生產日期等等資訊。
2.
現有系統的架構
目前最大的效能瓶頸：db
3.
我的建議
首先要對db切分。
3.1 先根據業務邏輯橫切db
根據廠商 -> 商品 -> 日期(最好能縮小到天為單位)切分表。
另外根據現有需求，不同廠商之間的資料不存在大範圍的同步。所以可以將不同的廠商作成不同的db伺服器，每個廠商資料庫考慮建立雙備份。
每個db伺服器進去以後先有乙個商品id的hash表做路由，連線到不同的商品表上去。然後再有乙個商品-> 日期的路由表 (考慮按年份分割開來) -> 條形碼資料。
3.2 接下來，我們來將同一表上的查詢壓力和更新壓力分開
我的建議是，在db前面加上memcached的記憶體伺服器，將常用待查詢資料cache入memcached中。雖然不能避免對資料庫的查詢，但是應該能分擔一定的壓力。
另外，技術選型上我推薦用mysql。
3.3稀釋廠商實時大批量上傳更新資料的壓力
廠商會實時性的向我們系統上傳大資料量的xml檔案。隨著產品的成熟，可以想見未來的效能壓力。
所以，我建議，
a. 用hadoop
分析廠商上傳的xml檔案。讀取當前的xml檔案，讀入記憶體中，然後用按照廠商 -> 商品 -> 日期的規範分割資料，快速定位到所在db的所在表，執行更新。
b. 在效能壓力巨大的場景下，可以考慮廠商上傳xml檔案之後不適時性的返回成功與否的標識。稍後用郵件的方式通知客戶。這樣就能降低廠商的實時性要求。
3.4我建議的架構模型
補充問題基本上解決了。但是還是很笨重。
這個問題的本質是兩個大資料量集合的比較和匹配。
這其實是個數學問題，比如用特徵碼，用演算法抽象特徵值都能更好的解決。
大資料量下的分頁
大資料量下的分頁 郭紅俊 select from orders where orderid between 10248 and 10253 select from orders where orderid in 10248,10249,10250,10251,10252,10253 order by...
大資料量下的sort
sort在linux命令列下面是乙個非常好用的工具，有人把它當做每個程式設計師都應該知道的8個linux命令之一，最近在處理大資料的時候發現兩點。1.用sort u 而不是sort uniq。sort應該是按照歸併的思想來的，先分成乙個個小檔案，排序後再組合成最後拍好序的檔案。所以，sort u 要...
統計各供應商的零件供應量
本題目要求編寫select語句，在spj資料庫中，統計每個 商的零件 量總和。要求 僅對那些每次 零件的數量都在100以上 含100 的 商進行統計。如 商s2 工程專案j5 的p3零件數量為50，則不統計 商s2 select a.sno as 商號,sname as 商,sum qty as 總...