Google稱霸搜尋器業務，是一個無可致疑的事實。從一個搜尋器專家的角度看。Google的運算能力大大超越了其它同類型公司，甚至是將全球所有除了Google以外其他搜尋器的運算力總和，也不足以對抗Google。 這些運算力的差異在那些地方呢？計算機的數量、管理系統、硬件、軟件，所有的因素，Google也在其考量之中。 Google 最初的成立公司時以家裡的車房作為中心，以平價電腦加open source的管理系統組成。這訂下了發展的方針，以大量低價的電腦，匯集成今天聞名的Google電腦海。 相對於yahoo剛成立時，記憶中它是用雙核版本的太陽電腦，是那個時代的頂尖電腦。 由於引入公開源碼的Linux使得Google得心應手地改良，看它公開的那個Google Chrome OS可想而知已經很早就將Linux打做成高速的雲端管理系統。 Google 連資料庫軟件也不放過，早就放棄了32bit的舊式設計，突破單一物件4GB記憶上限，更將運行模式大幅修改為雲端模式，成為名叫Big Table的傳說級資料庫。 Google的技術暫時沒有能平起平座的對手，因為天生是雲端的本質，會比其他對手更優勝。 下一步要走的路，就是硬件的優化。將軟體的運算樽頸，轉為以硬件運算，例如，硬件加密，硬件搜尋。 如果未來的電腦能有硬件搜尋的Big Table，能利用硬件Regular Expression的電腦語言，能使用GPU的矩陣運算，有Physic Engine等等的硬件優化。甚至利用GPU的平行矩陣來優Big Table，用Regular Expression來改良現有搜尋機制。利用硬件加密來強化Google的保安設施。 如果這些都是由Google研發，一定會一統資訊科技界。
Archive for the ‘System Design’ Category
如何使Google一統資訊科技界，成為真正的霸主
Posted in Cutting Edge Technology, IT Philosophy, System Design, tagged Big Table, Cloud Computing, Cloudg computer, Cutting Edge Technology, Google, Google Chrome OS, GPU Big Table, GPU cloud computing, Hardware Big Table, Hardware DB, Hardware Regex, Hardware Regular Expression Engine on January 29, 2011 | Leave a Comment »
「流程管理系統」
Posted in computer language, IT Management, System Design, tagged C#, flow chart, JSON, SQL, UML, Workflow Design, Workflow Management, Workflow System, Workflow System Design, XML, 流程, 流程系統, 流程系統設計 on January 24, 2011 | 1 Comment »
昨天跟一位中學的師兄在電話上談論IT的技術。師兄以前是從事會計，對IT也很有興趣。由於對工作的環境不滿意，放棄了高薪的會計工作，轉了入一間知名的會計軟件公司。由於他對上市公司的合拼帳的運作很熟悉，負責設計新的會計系統。 在電話裡跟他談了很多不同的電腦技術。其中一樣比較新鮮的就是設計「流程管理」軟件，我的師兄說他的公司已經開發了一套「流程管理」Workflow的軟件，由於規模比較大，難於應用在小規模的計劃內。那套「流程管理」的軟件是從收購其他公司而得回來，未能融合在其他產品之上。他的公司曾經花了很多時間和資源去從新開發另一套「流程管理」的系統，但結果不理想，內部人士的評語是設計了另一套解讀c#的c#。這個奇怪的評語，指的就是，用一套類似c#的語言來表達整個流程，包括表達圖片及表真正的流程及其相關的邏輯。 令我想起了我公司那套專為「中介付款系統」背後的「流程管理系統」。設計者是其中的一位同事，是兩年多年的產物。主要的原理是利用邏輯而產生出SQL語言，然後將SQL執行的結果，轉換成流程。 我師兄的老闆是C#高手，而我的同事是SQL高手。他們在設計時難免會以自己最熟悉的技術出發。本來，這種思維模式是理所當然的。可是，c#或SQL太不像圖象，用他們來做圖象介面，不太合適。C#不能直接翻譯，所以用來表達「流程」的邏輯，吃力不討好，SQL處理邏輯不太靈活。這兩種電腦語言，用在「流程管理」上是「相去甚遠」。就算設計者是「神」級也要花巨大的氣力才可以勉強成事。 所以，每當我們要去解決自己熟悉的領域之外的問題時，要細心想想，自己所習慣的模式是否「相去甚遠」呢？ 回到原先的問題，本人覺得，古老的「流程圖」還是最合適表達「流程」。則DOM是種很好的描述畫面的中介語言。最後，JSON是一種很好的溝通及直譯的電腦語言。所以，我們可以採用「流程圖」->「DOM」->「JSON」的方式來將「流程」轉化為「JSON」。「JSON」可以被儲存、提取及轉化為真的「流程」及其邏輯。 當然，我們亦可以考慮用XML取代JSON的角式，也可以用UML代替「流程圖」。設計理念是差不多的。
淺談各種系統分析方法
Posted in IT Philosophy, System Analysis, System Design, tagged Collection Oriented Programming, 系統分析方法, 結構方塊圖, Data Flow Diagram, DFD, Entity Relation Diagram, 集合論, 面向物件編程, 面向集體編, 資料流程圖, Object Oriented Programming, Set Theory, UML, 方塊圖, 流程圖 on January 3, 2011 | 1 Comment »
作為資訊科技重要的一個環節，系統分析，從來也不是一件容易的事。 對談論系統分析，應從最早期的流程圖、方塊圖、結構方塊圖、等等早期沒有物件理念的圖開始。這個系統分析的萌芽期之後，出現了跟「個體理念」相關的系統分析方法，例如：「個體關係圖」Entity Relation Diagram或者是「數據流程圖」Dataflow Diagram都，他們都試圖用單一圖表的方法，希望可以將系統的每個環節分析及表達出來。 「個體理念」的出現，是系統分析的成長期。除此之外「個體理念」，也曾經有電腦學家用數學中的「集合論」Set theory作為分析方法。用「集合論」作為分析的工具，結果當然是用「集合論」的符號來表達。 最近的廿年，是系統分析的成熟時期，當中最較流行的系統分析方法，莫過於UML。UML鼓吹使用多種不同類形的圖表，捨棄了單一圖表的方法。這也是理所當然的。系統分析員所涉及的工作越來越複雜，單一的圖表往往不能有效地將情況作出分析，而且分析得出的圖表也未必容易轉化為電腦程式。 UML算是一個比以往更全面、更有系統的圖表分析方法。 而且，它也是其中一種針對「面向物件編程」的分析方法。使得分析後的結果，更容易就可以轉換成「面向物件編程」的程式。 至於本人主張的有關「面向集體編程」，現在還沒有配合的分析方法，在這方面，我會在之後文章再探討。
