1.2 產品特點 Laxcus大數據管理系統運行在電腦集群上，特別強調軟體對分佈資源可隨機增減的適應性。這種運行過程中數據動態波動和需要瞬時感知的特點，完全不同與傳統的集中處理模式。這個特性衍生出一系列的新變化，需要重新審視產品的目標，設計新的架構，當我們把這些需求和定位綜合起來，然後逐一分解歸併 ...
1.2 產品特點
Laxcus大數據管理系統運行在電腦集群上，特別強調軟體對分佈資源可隨機增減的適應性。這種運行過程中數據動態波動和需要瞬時感知的特點，完全不同與傳統的集中處理模式。這個特性衍生出一系列的新變化，需要重新審視產品的目標，設計新的架構，當我們把這些需求和定位綜合起來，然後逐一分解歸併後，最終形成與以往完全不同的結果。
1.2.1 以節點為單位的計算集群
在Laxcus設計里，節點是電腦集群的基本單位。相較與物理性質的電腦來說，節點是一個邏輯概念的單位。以一臺實體電腦為例，在它上面可以部署最少一個節點，也可以部署多個節點，共用一臺電腦的資源。按照工作屬性劃分，節點分為四種類型：前端節點、網關節點、工作節點、管理節點。前端節點負責發起任務請求和顯示數據處理結果。網關節點將Laxcus集群分成內外隔絕的兩個部分，它處於“邊界”位置。對外，它接受來自前端節點的任務請求；對內，它將前端節點的任務請求轉發給集群內部的工作節點處理，同時起到對外部屏蔽集群內部拓撲結構的安全作用。工作節點承接網關節點的任務請求，組織和實施具體的數據處理工作，在完成後，將數據處理結果轉發給邊界節點。管理節點在集群里是一個“維護者”的角色，它沒有任何數據處理任務，只負責監測和協調下屬的網關節點和工作節點的工作。在Laxcus集群里，前端節點的部署和維護由是用戶來實施，沒有明確的要求。被大量部署的是工作節點，以及少量的網關節點，和一個管理節點。Laxcus把它們組織起來，來完成許多大型的數據存儲和計算工作。這些大型工作的工作量，通常是一臺幾台電腦不能完成，或者短時間內不能完成的。在實際部署中，一個標準的集群可以擁有數百到數千台不等的電腦。
1.2.2 超大規模集群
“域”是電腦集群的單位。在一個電腦集群里，管理節點處於核心地位，負責監督、維護整個集群的運行，它的作用非常重要。管理節點實質也是一臺電腦，也受到自身CPU、記憶體、網路介面等硬體性能的限制，隨著集群內電腦數量的增加，它的管理負荷也在隨之升高。因為有這樣的限制，在實際部署時，一個集群內的電腦數量是不可能無限增加的。根據我們對多套硬體和數據應用的組合測試顯示，當集群的節點數量達到3000至8000這個範圍時，會達到性能峰值，超過這個範圍，穩定性會大打折扣。但是在實際使用時，用戶對數據存儲和計算需求總是在持續增加的，這樣就產生一個矛盾：如何在保證集群穩定運行的情況下，仍然能夠滿足用戶更大規模存儲數據和計算數據需要？多域並行集群就成為這樣的一個選擇。
Laxcus的多域並行集群是對現有單域集群的升級和改進。通過把原來多個孤立運行的集群連接起來，在這些集群之上，建立更高一層的管理模型，形成一個兩級的管理架構。這個兩級架構的集群，在Laxcus中被稱為“主域集群”，原來的集群成為它下屬的子集群，這個集群被稱為“子域集群”。子域集群接受主域集群的管理，同時向主域集群反饋自己的運行狀態。按照Laxcus對集群的設計定義，子域集群必須集中在一個物理環境里，主域集群可以跨地域分散存在。就是說，如果A子域集群的機房在北京，B子域集群的機房在廣州，天津機房是C主域集群，只要它們之間能夠通過網路進行通信，就可以在天津的C主域集群管理下協同工作。
通過這樣的組合，集群的節點數量獲得巨大的提升，極大地拓展了數據存儲、計算範圍，滿足了當前包括未來一段時間內的需要。在跨域測試中，主域集群管理下的電腦節點數量可以達到百萬級的規模，數據存儲、計算能力可以達到EB級別。
1.2.3 多用戶共用
Laxcus是多用戶系統，支持任意數量的用戶同時使用。每個用戶能夠在任何可以聯網的位置，以遠程登錄的方式進入系統。區分用戶身份的唯一是賬號，賬號由用戶名和密碼組成。在一個系統里，用戶名是唯一的，密碼可以修改。建立賬號，以及後續的賬號管理工作由系統管理員或者擁有管理員許可權的用戶實施。用戶在獲得授權後，就擁了管理、操作數據的權力，可以在自己的集群空間里，執行寫入、更新、刪除、計算操作。從這一點來說，用戶與數據的關係，更接近博客、推特等網路應用，而與關係資料庫中的用戶、數據的定義有所區別。在邏輯空間上，系統中的每一個用戶和用戶持有的數據都是獨立的，彼此不存在關聯，也不會發生衝突。另外，為了充分發揮多集群並行處理能力，實現大規模並行處理效果，Laxcus允許一個賬號同時使用多個地址登錄，同時進行多種數據操作。當然，這也是在獲得操作授權和登錄驗證的前提下取得的。
1.2.4 低成本的硬體設備
大數據系統運行依賴於電腦集群。部署電腦集群，需要大量的電腦，以及連接它們網路通信設備，這對所有運營大數據的企業和機構來說，都是一筆龐大的開支。而大數據分佈處理和“以多勝強”的特點，更強調使用分佈演算法和軟體設計所帶來的效能，對硬體設備本身並沒有太多的要求。所以，低價、性能穩定的硬體設備成為首選。
具備這樣特點的硬體設備，目前有很多選擇，典型如PC架構的X86系統，還有移動架構的ARM系列，Laxcus都實現了支持。
實際上，但是無論上述哪款系列的電腦，在穩定性和可靠性上都不能和專業伺服器相比，發生故障和宕機的可能性比伺服器要大得多。針對這個情況，Laxcus採用了一個簡單的辦法：冗餘，來解決這個問題。實現這項功能的要求是Laxcus具備實時的節點感知能力，當集群內任何一個節點發生故障，都能很快被Laxcus捕獲到。在確認故障節點失效後，Laxcus將執行“隔離”方案，將故障節點從集群中排除，然後從集群中尋找一個新的備用節點，或者通知其它同類型的節點，來分擔故障節點的工作。排除故障的處理過程，都會同步通知給集群的維護管理人員。
這項措施簡單且有效，在多次故障處理中，都驗證了這個結論。
1.2.5 弱中心化管理
在Laxcus集群里，大量電腦被用來執行數據處理工作，管理節點做為集群的核心，起著監督和協調的作用。如果管理節點的工作內容過多或者複雜，勢必將增加管理電腦的工作負荷，降低處理效率，延長處理時間，不能對下級節點的請求及時做出反饋，減弱對集群的監督和協調作用。在此前的幾個運行環境，上述情況都分別發生過，是造成系統穩定性變差，影響集群正常運行的重要原因。所以，進一步分散管理節點的工作內容，減少計算開銷，降低工作負荷，是提高集群穩定性的主要辦法。“弱中心化”思想即由此衍生而來。
鑒於此前的教訓，通過對1.x版本的運行統計和評估，在2.0版本中，管理節點的工作被壓縮到只有兩項內容：監聽節點心跳、記錄節點元數據。這兩項工作由子節點上傳，管理節點負責彙總和分析，網路通信量極少，內容簡單，計算量非常少，並且只有計算記憶體里存儲和執行，不存在計算瓶頸和計算壓力，管理節點的工作負荷因此大幅度減少，從而提高了集群的穩定性。目前因為管理節點問題造成的故障已經基本消失。
1.2.6 松耦合架構和系統群
Laxcus被設計為松耦合架構，與之對應的，我們提出了“系統群”（group of systems）的概念。“系統群”可以理解為：在松耦合架構下為適應複雜分佈運行環境而組織起來的工作模塊。這樣，在松耦合架構和系統群之下，所有運行中的數據處理業務被視為服務，可以自由地加入和退出，分別以離散、獨立、弱依賴的形態存在。從人機交互界面開始，用戶的操作請求通過語句化的操作命令，被解釋成各種數據處理業務，業務的內容和含義由通信雙方決定。集群內的數據處理，採取按需分配的原則，根據不同的屬性分別建立，並遵循查找、發現、關聯、綁定、執行、撤銷的流程運行。集群內的數據管理業務，也遵循同樣的流程，並且與數據處理業務保持非關聯和獨立性。
由於松耦合和系統群的這些特點，使Laxcus在應對越來越複雜的數據業務時，仍然具有極好的靈活性和敏捷性。能夠在不影響既有業務的情況下，快速建立新的業務。在保持強大處理能力的同時，還有足夠的裕度來滿足未來擴展的需要。另外，松耦合和系統群也降低Laxcus系統設計的複雜性和風險，對開發這種複雜的大型軟體系統助益甚多。
1.2.7 命令驅動的數據處理模式
命令驅動是松耦合架構下的一個“系統群”子集，Laxcus數據處理都採用命令驅動的方式進行。系統運行過程中，當收到用戶或者系統自身發出的任務請求時，這些請求被轉換為相應的命令。命令根據任務提出的處理需求，結合集群環境做出解釋，分散作用到集群的不同節點上，執行數據處理操作。在表現形式上，命令通過網路在各節點之間傳遞，形成一條前後關聯的命令鏈。在執行過程中，每道命令鏈都是獨立的，嚴格按照預定的工作軌跡運行。當它們出現在電腦里的時候，實質是一個個對記憶體占用很小的“程式片段”，而命令鏈之間處於完全隔離的狀態。這種“被隔離”和記憶體占用小的特點使它們之間沒有干擾，同時又允許大量存在，即使某一條命令鏈在運行過程中發生故障，產生的影響也只限於這個命令鏈本身，不會出現波及效應。並且這種方式對排查故障原因和故障源頭十分方便。尤其重要的是，因為命令鏈的獨立性，在編寫代碼的時候，每條命令鏈可以按照其自身的需求，被設計得非常細緻和有針對性。這些特點，使它在保證系統穩定運行的過程中，起到重要的作用。
1.2.8 任務調度模型
命令被用來執行一道道具體的數據處理工作，分配、管理、監督這些命令運行的是“Invoke/Produce”任務調度模型。這是一種集成了多種軟硬體控制功能的委托管理模型，能夠對電腦運行過程中的各種資源，包括網路流量、適配器、數據、CPU、記憶體、硬碟，進行實時的監督和隨機的調節。在命令執行過程中，“Invoke/Produce”將持續檢查它們的運行狀態和對資源的使用情況，當任何一項硬體資源的使用比率達到峰值或者接近臨界點時，危機管理機制就被啟動，依次對影響最大的執行任務採取限制措施，包括暫停或者休眠這樣的處理，以及要求它們釋放硬體資源等手段，來達到降低系統載荷的目的。而所有這一切工作的目的，都以保障系統穩定運行為核心，儘可能多地通過軟硬體的結合，為每一道命令在它的運行過程中，實現數據處理效率的最大化。
1.2.9 負載自適應控制
我們已經部署了多個Laxcus系統，這些系統在運營過程中，我們通常不限制用戶發出的命令數量，這種忽略經常導致集群的某個節點涌現大量的計算任務，發生超載現象。例如在此前的一次例行檢測時，就發現有一個計算節點並行著8000多個計算任務。面對如此龐大的計算壓力，如果任由這些現象持續下去而不加以控制，電腦宕機現象隨時可能發生。
在1.x版本中，負載控制是由管理節點來監視和協調控制的。在實地運行中顯示，這種處理方式雖然達到了協同節點工作和平衡集群負載的目的，但是也存在很多隱憂，主要體現以下幾個方面：
1.每個節點的負載情況都被反饋到管理節點上，增加了管理節點的數據存儲量和計算量，不利於管理節點的弱中心化管理。
2. 負載的平衡和分配調度依賴於網路通信，當發生大面積超載時，往往也意味著網路中存在大量數據傳輸，這時的通信成功率會直線下降。實際上為了保證通信成功，就需要進一步加大了管理節點通信量和工作負擔，這種情況對管理節點穩定運行有巨大影響。
3. 負載控制要求實時處理，如果管理節點匯聚了大量任務請求，很難做到實時處理，延時將不可避免發生。同時下屬的節點收不到指令，超載會持續下去，宕機的可能性大幅增加。
4. 整套過載處理機制過於複雜，管理成本頗高，不符合簡單化的設計原則。
鑒於以上問題，2.0版本的負載控制，取消了以管理節點為中心的協同處理方式，改為分散到每個節點的自適應調節。這樣，當節點在執行計算任務的時候，也監視自己的運行負載。如果發生超載現象，可以立即做出反應，停止分配新的計算任務，或者根據運行任務的權重和資源占用比率，有選擇地要求某些任務進入暫停、休眠狀態，以達到即時發現即時處理，降低運行負載的目的。原來管理節點承擔的平衡運行負載的工作，交給網關節點來協調解決。新的負載處理方式避免了上述1.x版本的問題，同時簡化了負載管理的處理流程，提高了運行系統的穩定性。
1.2.10 以大規模的讀操作為主，兼顧少量的寫操作
在我們試驗室的集群中，由於固態硬碟（SSD）使用成本居高不下，承擔數據存儲工作的仍然是傳統的機械硬碟（溫徹斯特硬碟）。根據我們的調查，這種情況在很多運營的集群中也同樣存在。另外我們對多個集群上的數據應用追蹤調查也顯示，由於硬碟的處理效率遠遠滯後於CPU和記憶體，整個數據處理過程中，75%-90%的時間被消耗在硬碟存取上，即使是固態硬碟，也僅比機械硬碟提高一個量級，仍然遠低於CPU和記憶體的處理能力。這種硬體之間的不匹配，導致硬碟成為大數據處理過程中的最主要瓶頸。所以，改善硬碟的處理效率，對提高大數據處理效率有立竿見影的效果，但是機械硬碟工作的特點，又使它與CPU、記憶體這些電子部件在運行效率上存在著巨大的差異。在這種條件下，儘可能多地根據硬碟自身的特點，發揮出它的最大效能，成為解決問題的重要辦法。
與此同時，我們對許多用戶的數據應用追蹤中也發現，大數據處理過程中，96%發生在檢索操作上，3%是添加數據，刪除和更新合計只占不到1%的比例。這個現象促使我們對數據存儲產生了不同以往的定位和思路，將數據存儲設計的重點圍繞著檢索展開，並據此制定了以下的執行策略：首先，為保證大數量高頻度的檢索操作，結合到電腦內的CPU、記憶體、硬碟各主要工作部件的性能，在保證數據的持續吞吐性能上，流式處理效率最高。並行的數據寫入在進入存儲層面時，匯流為串列模式。檢索操作的最終目標是硬碟，硬碟檢索受制於硬碟物理特性的影響，在數據計算過程中，嚴重拖滯了整體性能的發揮，為提高數據處理性能，需要在檢索前對數據進行優化，如關聯和聚湊，同時提供一批優化演算法給用戶，使用戶可以按照自己的意願去組織和檢索數據。刪除不改變數據本身，只對數據做無效記錄。數據更新分解為刪除和添加兩步操作，目的在於簡化和內聚數據處理流程，同時避免發生多次硬碟讀寫現象。
上述處理雖然改善了存取性能，但是不可能從根本改變硬碟慢的特點。若要使性能獲得根本性的提升，必須跳過硬碟這個瓶頸，所以在2.0版本中增加了一套新的數據處理方案：讓記憶體代替硬碟，數據在網路、記憶體、CPU之間流動，以接近CPU的速度運行。這種記憶體處理方案解決了硬碟存取慢的問題，使數據處理性能獲得巨大的提升。根據我們的測試評估結果，這個提升幅度在2個量級左右。在實際應用中，用戶如果有實時性的數據處理需求，且有足夠的記憶體做保證時，記憶體處理方案無疑是最佳的選擇。
1.2.11 數據存儲方案
以上只是針對硬碟存取做的優化，如果根據數據業務不同的需求特點，提供有針對性的數據存儲方案，數據處理效率還能夠獲得進一步的提升。
達成這個目標的辦法是實現兩套數據存儲方案：以“行”為數據單元的行存儲模型（NSM），和以“列”為數據單元的列存儲模型（DSM）。前者將數據處理的重點放在“行”上，每次操作的假定對象是一行中的多列數據，這方面有代表性的就是目前普遍使用的資料庫業務。後者的數據處理重點是“列”，其特點是可以對單一數據進行大批量的讀取操作，比如當前火熱的互聯網數據和數據倉庫應用。前者的數據操作量普遍不多，而後者的數據操作量則非常巨大。在使用時，用戶可以根據自己的業務需求任意選擇。根據我們對現有用戶的追蹤調查，在他們的數據應用中，普遍是採取混合使用兩種存儲模型的辦法來提高數據存取效率的。
1.2.12 流式處理
由於硬碟本身物理性能與記憶體、CPU之間存在的巨大差異，在數據處理過程中，實際上無論給硬碟做怎麼樣的優化設計，都只能減少而不能避免這種差異所造成的影響。要想完全突破硬碟性能滯後所造成的數據處理效率低下的問題，唯一的解決辦法就是跳過硬碟這道瓶頸，只使用記憶體做數據存取，讓數據象“水流”一樣，在集群的各節點的記憶體、CPU之間流動，使它們接近匹配的速率，進行傳遞、轉換、處理。這就是流式處理的由來。
在Laxcus 1.x版本中，流式處理是一項內測功能。在版本發佈後，收到越來越多用戶的快速處理要求，所以重新考慮後，在原來流式處理基礎上，經過調整修改，現在在2.0版本，把它正式公佈出來。兼顧到原來的數據處理方案，流式處理要求用戶在使用前顯示指定，系統會根據當時每台電腦的資源使用情況，有選擇地進行分配。這樣，當用戶要求流式處理的時候，數據處理過程將忽略掉硬碟，完全在集群的網路、記憶體、CPU之間進行。
流式處理主要針對一些快速檢索和計算業務（數據存儲操作仍然要寫入硬碟，不在此列），典型如線上分析 、實時計算這類業務。根據我們對多種流式處理的實地測試顯示，相較於基於硬碟的數據處理，基於記憶體的流式處理可帶來數十倍的效率提升。這種巨大的提升，將使一些用戶的數據處理業務發生根本性的改變。
1.2.13 即時存取
數據即時存取即通常所稱的“所存即所得”，這是衡量大數據系統能否支持實時處理的關鍵性標誌。其表現就是當數據保存到數據系統的分佈存儲環境後，能夠立即生效並且可以使用，而不是之後的某一個時段才能生效和使用。數據即時存取在Laxcus 0.1版本已經實現，又分別在1.0和2.0版本中進行優化，性能獲得進一步提升。由於實現了即時存取，可以保證對整個主域集群數據執行無遺漏的檢索，使Laxcus達到通常關係資料庫才具有的響應能力。即時存取非常重要，尤其是商業用戶，是他們許多數據業務必須滿足的一項功能。
1.2.14 支持事務
現在的大數據應用已經不局限於互聯網，尤其是隨著商業和科研行業的加入，開始呈現出需求多樣化的趨勢。其中有很多商業處理業務，為了防止資源競用造成的數據錯誤，越來越需要獲得事務支持。順應這一發展潮流，經過我們仔細分析研究和設計，從Laxcus 2.0版本開始，提供事務處理能力。
Laxcus事務保持了資料庫對事務定義的基本原貌，即所有數據處理只能有兩種結果：成功或者失敗。如果失敗，數據將回滾到它的開始狀態。在此基礎上，結合大數據運行環境，避免因為事務造成數據處理效率下降，Laxcus事務具有以下特點：
1. 事務基於賬號。
2. 數據處理預設執行事務流程。
3. 事務分成用戶、資料庫、表三種類型。
4. 事務操作分為排它和共用兩種。
更多關於事務的說明請見第二章的介紹。
1.2.15 命名
在Laxcus體系裡，命名是一組由文字和數字組成的有意義的字元串，是網路設備、分佈目錄、任務介面、數據資源等各種實體資源抽象化的表示，被應用在所有與數據處理有關環節上。通過命名，系統在運行過程中，屏蔽了數據處理環節，與網路地址、數據定位、數據檢索有關的工作，簡化了分佈計算方法和計算流程，使複雜的網路運行環境變得簡單，同時減少和避免了因為網路拓撲和數據分散可能導致的錯誤和漏洞。命名只在系統運行過程中產生，被存儲在記憶體里，在節點之間分發，可能隨時間和節點發生變化。每個命名在系統中都是唯一的，不允許出現重疊現象。因為命名只用於系統內部環境，所以它對用戶是透明的，用戶不必在意，也無需瞭解它的使用、執行情況。
設計命名，對簡化系統架構設計，提高系統穩定性、保障系統安全有重要作用。
1.2.16 安全
在當今社會，因為信息產業的快速發展和信息安全管理的相對滯後，由網路安全和數據安全引發的一系列重大事件可謂是層出不窮。當前大數據正在快速融入現代社會，如何保護好這些數據，保證數據只被它的持有人使用，而不會受到非法的監視和竊取，就益發顯得重要了。基於這樣的理念，又鑒於集群的複雜運行環境，如果只是做局部的改善，那麼將無法滿足整體的安全需要，我們從Laxcus 2.0版本開始，納入了全體系的安全管理設計和技術實現。它從用戶操作界面開始，一直延伸到數據存取層面，貫穿系統的每一個環節，形成一道完整的安全屏障。在這道安全屏障後面，用戶執行安全的數據處理成為可能。
不過任何事情都有它的兩面性。換一個角度實事求是地說，我們雖然實現了全體系的安全管理設計，但是這個安全管理的取得是以犧牲集群總體計算性能為代價的。實際上，現在IT行業所有高安全度的技術實現背後，都存在著一個使用CPU進行密集計算的處理過程。尤其對於也是數據密集和計算密集的大數據來說，會嚴重影響到CPU處理數據業務的能力，增加業務處理時間。考慮到這樣的情況，我們在進行安全設計時，對系統的不同環節進行了不同的安全管理規劃，設置了不同的安全等級，提供了不同的安全管理策略，其中大部分的安全管理工作，我們都以配置文件的形式提供給集群管理者，由他們根據自己業務需求做出取捨。但是不管怎麼樣，事實是，這套安全措施啟動後，無論是做為私有雲還是公有雲部署時，Laxcus都已經可以承擔了。
1.2.17 分佈任務組件
Laxcus雖然提供了一個分佈的數據處理環境，但是大量個性化、與用戶業務有關的數據處理工作仍然需要用戶來完成。要達成這個目標，就需要程式員來編寫代碼，然後放到電腦集群上去運行。分佈任務組件就是為完成這個工作而設計的。
在1.x版本中，分佈任務組件只是一個集成了中間件和分佈計算技術，提供了熱發佈能力，在Laxcus架構下運行的模塊。在2.0版本中，我們對分佈任務組件進行了大規模的調整修繕，重新定義了操作規範和API介面，增加了開發、部署、運行、管理等一系列功能，並且從原來的框架下剝離出來，已經獨立發展成為一個完整的子系統，實現了全方位的數據處理和管理服務。
從設計上來說，Laxcus 2.0版本的分佈任務組件確實比1.x版本複雜了很多，但是對程式員來說則變得簡單了。在新的框架下，原來需要由程式員負責的網路通信、遠程存取、分佈操作等代碼被全部屏蔽掉，歸併到系統管理範圍內。新架構只留下了數據輸入輸出介面給程式員，程式員可以不必再去考慮複雜的分佈處理流程，只需要遵循開發規範，調用API介面，象操作本地方法一樣，專註於自己的業務功能實現就可以了。通過本次對分佈任務組件的簡化修改完善，我們希望在減少程式員工作量和運行錯誤的同時，也能夠為程式員快速開發和部署分佈任務組件提供幫助。
1.2.18 人機交互語言
出於簡化數據處理過程、提高數據處理效率、使人機交互界面更加友好等原因，我們設計和開發了分佈描述語言（Distributed Description Language）。這是一種專門針對大數據用戶和集群管理者設計的類自然語句高階語言，由許多命令組成。命令採用英文語句的語法風格，由使用者通過終端輸入，也可以嵌入到驅動程式里使用，語法解釋器負責解釋，轉換成電腦指令後，分發到集群上執行。分佈描述語言的核心要旨是簡單，我們希望能夠藉助分佈描述語言，使用戶在不必瞭解複雜的分佈計算體系和計算流程的前提下，通過簡單的交互語句，就能夠獲得管理和操縱大數據的能力。這種簡化所帶來的效果，對所有使用者，無論是集群管理者還是普通的大數據用戶來說，都是非常重要的。同時，做為對大數據的補充，也為了方便用戶從資料庫轉向大數據環境，我們在分佈描述語言裡面全面相容SQL，包括SQL語言最主要的“INSERT、SELECT、DELETE、UPDATE”語句，以及JOIN語句、SQL函數、SQL數據類型、和其它的管理語句等。截止到目前，Laxcus分佈描述語言仍在發展中，我們希望通過與大家的努力，共同完善它。
