# BigData 使用 Erlang，C 和 Lisp 對抗移動數據海嘯 > 原文： [http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html](http://highscalability.com/blog/2012/11/26/bigdata-using-erlang-c-and-lisp-to-fight-the-tsunami-of-mobi.html)  *這是 [Jon Vlachogiannis](http://www.linkedin.com/in/johnvlachoyiannis) 的來賓帖子。 Jon 是 [BugSense](http://www.bugsense.com/) 的創始人和首席技術官。* BugSense，是一個錯誤報告和質量指標服務，每天跟蹤數千個應用程序。 當移動應用崩潰時，BugSense 可幫助開發人員查明并解決問題。 該初創公司向其客戶提供一流的服務，其中包括 VMWare，三星，Skype 和數以千計的獨立應用程序開發人員。 跟蹤超過 200M 的設備需要快速，容錯和廉價的基礎架構。 最近六個月，我們決定使用我們的 BigData 基礎架構，向用戶提供有關其應用性能和穩定性的指標，并讓他們知道錯誤如何影響他們的用戶群 和收入。 我們知道我們的解決方案應該從第一天開始就可以擴展，因為超過 4％的智能手機將開始使用 DDOS 向我們提供數據。 我們希望能夠： * 提取應用程序邏輯并使用 JSON 填充瀏覽器 * 快速運行復雜算法 * 無需專用 Hadoop 集群即可進行數據實驗 * 預處理數據，然后將其存儲（減少存儲） * 能夠在每個節點上處理超過 1000 個并發請求 * 每個應用程序“加入”超過 1.25 億行 * 做到這一點，而無需花費大量的服務器時間 該解決方案使用： * 在 Azure 上運行的大型實例不到 20 個 * 內存數據庫 * 一種用 C 語言編寫的功能齊全的自定義 LISP 語言，用于實現查詢，這比始終使 VM（帶有垃圾收集器）聯機的速度快很多倍 * Erlang 用于節點之間的通信 * 修改后的 TCP_TIMEWAIT_LEN 可以驚人地減少 40K 連接，節省了 CPU，內存和 TCP 緩沖區 ## 內存數據庫萬歲 我們知道，處理所有這些流量的唯一方法是使用內存數據庫。 不僅要處理巨大的數據集上的即席問題（例如，“有多少個使用三星設備的唯一用戶在一個星期內有此特定錯誤”）， 內存限制還與數據處理前后的數據序列化和反序列化有關。 因此，我們啟動了 LDB 項目。 ## LDB 項目 您是否相信可以將來自各種來源（成千上萬種不同資源，如移動設備）的數據饋送到系統中，在幾行代碼中描述要提取的信息，然后將所有這些信息掌握在您的指尖中 ？ 實時。 系統持續運行時？ LDB 不僅是數據庫，更是一個應用程序服務器。 即使是內存中數據，實際上也將數據存儲在硬盤驅動器中并在其他節點之間復制。 對于 LDB，我們不會運行查詢。 **我們之所以運行算法，是因為我們擁有用 C 語言編寫的完整的自定義 LISP 語言，該語言可以訪問與數據庫**相同的地址空間。 這意味著您可以非常快速地搜索數據，增加計數器，獲取/放置等。 擁有 LISP 的優點是，您可以輕松地像 Hive 這樣創建類似于 SQL 的語言并實時查詢數據，如下所示：  LDB 的工作方式如下： 每個應用都有自己的 LDB。 這意味著它自己的內存空間。 這樣，我們可以輕松地將較大的應用程序（在流量方面）移動到不同的計算機上。 ［HTG1］ ［HTG2］ ［HTG3］ ［HTG4］ ［HTG5］ ［HTG6］ ［HTG7］ ［HTG8］ ［HTG9］當請求來自移動設備時，主 LDB 節點接受連接（使用 erlang 線程池）并將數據轉發到特定的數據庫。 此請求處理機制用少于 20 行的 Erlang 代碼實現。 我們選擇 Erlang 進行節點間通信的另一個原因。 當請求“流式傳輸”到 LDB 時，名為“ process.lql”的文件負責分析，標記數據并創建任何計數器。 所有這些都是即時完成的，并可滿足每個請求。  我們能夠做到這一點，因為啟動 LISP-VM 并針對每個請求執行所有這些過程仍然很多次 始終使 VM（帶有垃圾回收器）聯機的速度更快。 使用 LDB，我們可以使用不超過 3 行代碼來創建時間序列和匯總數據。 例如。 這樣會為唯一用戶創建 7 天的時間序列：  ## 備擇方案 在我們的測試中，我們發現 SQL 數據庫不太適合，因為我們的數據是非結構化的，并且我們需要很多復雜的“聯接”（和許多索引）。 另一方面，對于 NoSQL 數據庫，我們無法在數據上運行算法（在系統運行時），而使用映射器/約簡器會使整個過程變得復雜而緩慢。 我們需要一個沒有大鎖或 DB 鎖的高并發系統，該系統可以在僅幾個 KB 的時間內跟蹤數百萬個唯一事件，并且非常容易擴展。 一個很好的替代方法是使用 Stream 數據庫（例如 [Storm](http://storm-project.net/) ）。 我們的主要問題是有很多活動部件和單個節點的性能。 使用 LDB，我們的優勢是能夠非常快速地處理數據（它們駐留在相同的內存空間中），將它們存儲為聚合計數器或符號（因此，千兆字節的數據以 KB 為單位），然后讓 DSL 執行任何關聯 我們要在飛行中。 沒有序列化/反序列化，沒有網絡調用，也沒有垃圾收集器。 就像將匯編代碼映射到您的數據上一樣。 在 LDB 之上，我們還有可以縮放和處理傳入數據的接收器，一個流組件，其中的所有內容都在幾行代碼中定義，一個存儲引擎和一個復制 發動機。 ## 優化內核-TCP 的 UDP 行為 與每秒處理大量請求的其他服務相比，進行分析時的獨特之處在于，移動設備與服務器之間的對話非常小（3 個 TCP 握手數據包，1 個有效負載數據包和 3 個 TCP 終止數據包 ）。 但是，TCP 在設計時并未考慮到類似問題（即設備之間的小對話框），并實現了稱為 TIME_WAIT 的狀態（持續時間約為 1） 分鐘 （在 2.6 Linux 內核中），在該時間之后，最后一個 FIN 數據包發送之后，該特定連接元組的 TCP 狀態保持打開狀態一段時間，以便接收可能已延遲的任何雜散數據包（即 連接關閉）。 在我們的例子中，這有點沒用（我們想要類似于 UDP 行為但具有 TCP 保證的東西），因為有效負載只有 1 個數據包（對于查看請求，最多 4 或 5 個數據包），因此我們決定修改內核源并減少 常量，此常量降至 20 英寸。結果是驚人地減少了 40K 連接，節省了 CPU，內存和 TCP 緩沖區。 我們應用的補丁在文件中： linux-kernel-source / include / net / tcp.h #define TCP_TIMEWAIT_LEN（[ 60 * HZ ） 至 #define TCP_TIMEWAIT_LEN（ 20 * HZ ） 使用此架構，我們可以為所有付費客戶（運行少于 20 個大型實例）提供有關移動應用程序的實時分析和見解。 在 Azure 上，包括后備和備份服務器。 ## 相關文章 * [關于 HackerNews](http://news.ycombinator.com/item?id=4833052) 既然沒有垃圾收集器，如何在 LISP 實現中回收內存？ 謝謝。 好貼！ 我特別喜歡 TCP 技巧。 您能否分享每天有多少事件和多少數據進入？ 另外，您要從中提供查詢的內存數據集大小是多少？ 我對您正在執行的聯接大小特別感興趣。 噢親愛的。 `tcp_tw_reuse`或`tcp_tw_recycle`有什么問題？ 何俊！ 我非常喜歡閱讀！ 我是一位經驗豐富的 Erlang 程序員，我很想閱讀有關 Lisp 實際使用的更多信息。 如果您有任何有關 List 的良好介紹性文章的鏈接，那就太好了！ 非常感謝您的精彩文章！ 本文充滿了不尋常的陳述和設計決策，我懷疑 BugSense 是由外星人控制的：） 有什么問題：echo“ 20” > / proc / sys / net / ipv4 / tcp_fin_timeout？ 不工作？ 在每個請求上啟動 LISP VM 的速度要比一直保持 VM 聯機的速度快？ 好的，我明白了，Lisp VM 不能很好地完成 GC。 但是有一個 JVM 和 Clojure（Lisp 方言順便說一句） LISP + Erlang 的組合？ 有人非常了解 Lisp 和 Erlang :)。 嗯-而不是在服務器上浪費 TCP 時間，您難道不就讓客戶端在服務器之前關閉 TCP 連接嗎？ 這將給客戶端增加“等待時間”的負擔。 我猜您的協議目前已經廣泛部署，因此更改它為時已晚？ 我愿意在這方面尋找另一面，但是我仍然看不到在提出了如此精美高效的體系結構之后，您選擇使用 Windows Azure，這是最糟糕的此類產品（IaaS / PaaS） 。 ..我一直在煩我..這似乎引入了各種性能和財務瓶頸。 除非您對支持 Windows Phone 設備有何需求（極不可能）。 因此，我得出的結論是，您獲得了免費優惠或其他優惠。請幫助我理解。 對于建議使用 tcp_tw_reuse 的人： http://serverfault.com/questions/303652/time-wait-connections-not-being-cleaned-up-after-timeout-period-expires tcp_fin_timeout 設置套接字在 FIN-WAIT-2 狀態下花費的時間。 此參數不會影響在 TIME_WAIT 狀態下花費的時間。 嘗試 netstat -o 并觀察處于 TIME_WAIT 狀態的套接字的計時器值（選擇 tcp_fin_timeout 值）。 @Sumit R：你的意思是...？ 您是否閱讀了整個 serverfault 線程，特別是有關`tcp_tw_reuse`問題的答案？ 您實際上曾經使用過`tcp_tw_reuse=1`嗎？ Lisp 解釋器的內存處理由我們完成。 我們使用世代容器，并在每個“簡短”腳本完成時回收分配的內存（對于“年輕”條目。由于系統體系結構/設計，無需收集“頑固”條目。通常，我們分為三代） 有自己的收集策略）。 因此，無需擁有成熟的垃圾收集器。 我們不使用 JVM 或任何其他托管 VM 解決方案（Clojure，F＃等），因為我們只希望每個 VM（以及特定 VM 上的語言）提供的功能的子集，并且有大量空間可以優化 滿足我們自己的“特殊”需求。 此外，Scheme（Lisp）還提供了構建具有表達力的程序所需的一切，這些程序通常具有功能范式的抽象和形式/模式。 你好 真的很想知道有關 Lisp（方案）實現以及它們如何與 Erlang 一起工作的更多信息。 您是否有可能開源示例或框架的一部分？ 無論如何，感謝您的文章。 此致 尼古拉斯