【51CTO精选译文】编辑注：本文作者是BugSense公司的创始人兼首席技术官Jon Vlachogiannis。BugSense是一家专门报告错误、度量质量的服务商，每天跟踪成千上万个应用程序。移动应用程序崩溃时，BugSense可以帮助开发人员准确查明问题，并解决问题。这家新兴公司的客户包括VMWare、三星、Skype以及数千家独立应用软件开发商。跟踪2亿多种设备需要有一套运行速度快、容错性强、成本又低廉的基础设施。
在最近六个月，我们决定使用自己的BigData基础设施，为用户们提供评估应用程序性能和稳定性的度量指标，好让他们知道出现的错误给其用户群和经营收入带来了怎样的影响。
我们清楚，自己的解决方案自一开始就应该具有良好的扩展性，因为外面所有的智能手机中超过4%会开始向我们发送大量数据，实际上无异于分布式拒绝服务攻击（DDoS）。
我们希望能够做到以下这几点：
■抽取应用程序逻辑，并以JSON格式向浏览器传送数据
■实时运行复杂算法
■尝试处理数据，不需要专门的Hadoop集群
■预处理数据，然后存储数据（减少存储空间）
■能够在每一个节点上处理1000多个并发请求
■每个应用程序对超过1.25亿行进行“联结”操作
■不需要把大笔钱投入到服务器上，即可做到这一点
解决方案使用了：
■在Azure平台上运行的不到20个大实例
■内存中数据库
■使用C语言编写的完全成熟的自定义LISP语言，以实现查询，其速度要比让虚拟机（附带废料收集器）一直在线运行快好多倍。
■用于节点之间联系的Erlang语言
■经过改动的TCP_TIMEWAIT_LEN，足足少了4万条连接，节省了处理器、内存和TCP缓冲器等方面的资源。
内存中数据库万岁！
我们知道，我们要处理这一切流量，唯一的办法就是使用内存中数据库。
为了迅速解答针对庞大数据集的临时特定问题（比如“一个多星期以来，多少不重复的三星设备用户遇到了这个特定的错误？”），你不仅要应对内存方面的局限性，还要应对在数据处理前后的数据串行化和并行化工作。这就是我们启动LDB项目的原因。
LDB项目介绍
你是否相信能做到这点：可以将来自不同数据源（甚至上千个不同数据源，如移动设备）的数据传送到某个系统中，描述你用仅仅几行代码想提取什么样的信息，然后让所有这些信息触手可及？而且以实时方式实现，同时不影响系统的正常运行？
LDB与其说是个数据库，还不如说是款应用服务器。尽管它是内存中数据库，但是数据实际上存储在硬驱中，并且复制到其他节点上。
有了LDB，我们并不运行查询，而是运行算法，因为我们有一种使用C语言编写的完全成熟的自定义LISP语言，它可以访问与数据库同样的地址空间。这意味着，你能够以极快的速度搜索数据、增加计数器以及进行get/put操作等。
拥有LISP的优点在于，你可以轻松创建类似SQL的语言，比如Hive，并且实时查询数据，就像这样：
LDB工作起来像这样：
每一个应用程序都有各自的LDB。这意味着它有自己的内存空间。这样一来，我们就可以把就流量而言更庞大的应用程序轻松转移到不同的机器上。
当请求来自移动设备时，主LDB节点接受连接（使用erlang线程池），并将该数据转发到某个特定的数据库（DB）。这种请求处理机制是用不到20行Erlang代码实现的。这也是我们选择Erlang用于节点之间联系的另一个原因。
当请求被“流式传送”到LDB后，一个名为“process.lql”的文件负责分析和标记数据，并创建各种计数器。这一切都是实时进行的，对每个请求而言都是如此。
我们之所以能够这么做，是因为针对每个请求，开启我们的LISP虚拟机、处理所有这些过程仍比让虚拟机（附带废料收集器）一直在线运行快好多倍。
借助LDB，我们只要用短短的3行代码，就能创建时间序列和聚合数据。
比如说，下列代码为不重复用户创建了7天的时间序列：
替代办法
我们在测试过程中发现，SQL数据库之所以不是很适合，正是由于这一点：我们的数据以非结构化数据为主，我们需要许多复杂的“联结”（和许多索引）。另一方面，就NoSQL数据库而言，我们无法在系统运行的同时针对数据运行我们的算法，而拥有mappers/reducers使得整个事情处理起来既复杂又缓慢。我们需要一种没有大锁或数据库锁的高并发系统，可以用仅仅几KB就能跟踪数百万个不重复事件，而且、扩展起来很容易。
一个很好的替代办法就是使用Stream数据库（比如Storm）。我们的主要问题在于，单个节点有许多变化因素，而且存在性能问题。借助LDB，我们有了这个优点：能够以极快的速度处理数据（数据驻留在同一个内存空间），把它们作为聚合计数器或符号来存储（因而能够将数GB数据塞入到数KB空间），然后让特定领域语言（DSL）来实时处理我们想要进行的任何关联操作。没有串行化/并行化，没有网络调用，也没有废料收集器。这就好比是将汇编代码映射到你的数据上。
除此之外，借助LDB，我们有了可以扩展并处理入站数据的接收器、一切仅用几行代码就可以定义的流式组件以及存储引擎（Storage Engine）和复制引擎（Replication engine）。
优化内核
较之于每秒处理大量请求的其他服务，我们进行分析时的独特地方在于，移动设备与服务器之间的对话极少（3个TCP握手数据包、1个有效载荷数据包和3个TCP终结数据包）。
不过，TCP在设计时并没有考虑到这种情况（也就是说设备之间的对话很少），而是实现了一种名为TIME_WAIT的状态（在2.6 Linux内核中持续时间约1分钟）：上一个FIN（完成）数据包被发送后，该特定连接tuple的TCP状态仍保持一段时间的开启状态，目的是为了接收可能延误的任何杂散数据包（也就是说，在连接关闭之前）。不过就我们的情况而言，这用处不大（我们希望酷似UDP行为，但又有TCP保障），因为有效载荷只是1个数据包（浏览请求多达4个或5个数据包），于是我们决定改动内核源代码，把这个参数的常量减小到20秒。结果就是足足少了4万条连接，数量惊人，因而节省了处理器、内存和TCP缓冲器等方面的资源。
我们所打的补丁在这个文件中：
linux-kernel-source/include/net/tcp.h #define TCP_TIMEWAIT_LEN (60*HZ)
换成
#define TCP_TIMEWAIT_LEN (20*HZ)
使用这种架构，我们就能为我们的所有付费客户提供实时分析和了解移动应用程序的功能，不到20个大实例在Azure平台上运行，包括退守服务器和备用服务器。
原文：BigData Using Erlang, C And Lisp To Fight The Tsunami Of Mobile Data
