编者按:费用管理公司 Expensify 第一次设计数据库结构,是为了建立自己的公司信用卡系统。与金融机构合作有着严格的要求:响应时间在毫秒内、多台服务器实时复制、每一个交易都必须记录,并进行身份验证等。当时,这些要求对于一个想要建立一个高层次、企业级架构的创业公司来说无疑是矫枉过正的。当公司把精力耗费在昂贵的报告上时,强大的技术处理也是必不可少的。创业公司往往不知道,他们的早期决策是多么得有价值。Expensify 的创始人兼 CEO David Barrett (大卫·巴雷特)也是在后来才意识到早期限制Expensify的数据库架构关系着企业的许多关键性竞争优势。
在超过八年的时间里,巴雷特见证了数据库设计早期的大量投资所带来的优势。这种优势不仅体现在产品的功能,也创新了一个激进的商业模式,以此来赢得不同于竞争对手的客户青睐。客户量在2015增长了超过120%,超过同行业竞争对手近70%。费用管理公司现在服务着超过20000家公司。巴雷特认为,公司的成功,很大一部分应该归功于技术决策,特别是得以依靠非常强大的数据库体系。
First Round Review 对巴雷特进行了独家专访,谈到了数据库系统和一个创业公司是怎样因此陷入危机的。并且就一些应该要避免的错误进行了解释性说明。他分享了创业公司技术和商业模式的规模化和实现成功的三个关键步骤。最后,他还分享了校正数据库体系结构的方法。
初创公司都知道,他们应该是“数据驱动”型的公司,但很少能在做出关键技术决策时知道这究竟意味着什么。“当您刚开始创业时,您没有数据,也没有客户。您所做的一切都可以简单地用一个由单一的Web服务器支持的单一数据库搞定。你会选择使用旧式机器,或者是目前流行的那款,然后还会觉得这是最好的选择了。“巴雷特说。“随着公司的发展,慢慢地,单个服务器的性能或可靠性不再适用,您开始需要多台服务器。接着,你会把一台台的服务器增加到你曾经单一的数据中心,公司的产能也会随着规模的逐渐扩大而增加。”
这就是为什么一些方法会让许多创业者落入陷阱:
到处都是松鼠。在皮克斯的一个电影《飞屋环游记》中,主人公在聊金毛猎犬道格时,话说到一半,突然停下来,大叫“松鼠!很多时候想到的不一定就是看到的。“大多数公司都会在他们最熟悉的领域来创业。这是一个安全的选择,它有效地在最开始让风险最小化。不幸的是,人们对过去熟悉,但是世界属于未来,“巴雷特说。“有胆识的公司总是退后一步,看看有什么新鲜的或者比熟悉的更好的东西。这当然是好的。但是,很多公司把“时髦”误认为是“好”,然后在他们犹豫用什么时,选择一些恰好流行但却未经检验的技术。事实上。这种做法会慢慢地将你的创业公司置于死地的。
几年前,巴雷特曾就职于一个公司。这个公司试图建立一个早期版本的Dropbox。“所有的技术是当时有的,但他们坚持不用简单的集中式系列服务器而要用那个名叫JXTA的糟糕透顶的P2P技术。我们那时候没有客户,也没有多少数据需要来存储,但我们的首席技术官偏要把整个公司赌上来用这个分布式系统,并且声称这是得以扩展到PB级数据的唯一途径,”巴雷特说。“跟很多看上去不错,综合性很强的解决方法一样,它根本不可能实现预期目标。这种技术简直是一个噩梦,之后也再没有在生产环境中使用过。公司几次调整战略,最终,在四年后一个融合新旧,新一代Dropbox的解决方案问世了。”
你不是 Google。这并不是说你将来不能或者不会成为像 Google 那样。但不要一开始就做这个假设。“当下流行的技术是给那些已经出现规模效应、有着复杂需求的成熟公司的。那些都是理想中的新技术。你作为一个新创的品牌公司,需求跟像 Google 这样的大公司相同的可能性是微乎其微的,” 巴雷特说,“像Postgres的数据库也不错,但是它们都不够酷炫。Google 用的那种有特色的数据库技术听上去更有意思。我想要像Google,所有我就要选择那种技术。”
但人们往往忽略了,Google 以他那种方式发展技术基础是因为它要运行世界上最大的搜索引擎。“搜索引擎的驱动技术是跟其他商业网站的驱动不一样的。Google 每天需要吸收大量的数据,而其中只有一小部分是变化或有趣的。也就是说,Google 基本上每天都会拷贝一份互联网数据。这意味着它能够使用数据索引的方法,非常快速地搜索和添加数据,但数据一旦添加,选择性地删除或更改就会非常缓慢。这对Google来说没有太大影响,因为这种事情他们每天都会做一遍。” 巴雷特说,“绝大多数企业都不能这么做。相反,他们需要慢慢积累更密集的数据集,包括帐户、密码和可编辑的文件,这些原始的数据你都不能只是扔掉,然后重新开始收集,它是需要时间,不断更新积累的。”
你的创业公司每天都在做网上的一份拷贝吗?如果不是,停止试图模仿Google的数据库架构。
如何明智地选择数据库体系结构
复制许多流行的或你喜欢的公司的技术基础的危险之处就在于,这些公司很可能与你的公司非常不同。他们的决定对于你来说可能是种约束。但对于他们来说需要小心翼翼的限制因素,可能成为你的亮点。这里列举几项设计数据库架构时能够减轻这种风险的方法。
拒绝被引诱,做好你的打算。人们很容易惊异于数据库的强大性能,而不考虑自己的实际需要。“当你听到一个数据库可以控制一千多台电脑和处理PB级数据的时候,不要昏头了。首先,问自己:“我可能会有多少数据需要处理?”,你是不大可能需要那么大的处理量的,” ”巴雷特说,“即使在今天,如果我们不关心的可靠性和可维护性,我们公司可能现在用的还是建立公司五年时的那套数据库服务器。人们忘记了,今天的电脑功能是如此强大却又如此廉价。你的手机处理的数据量是美国宇航局去月球上带的电脑的10000倍,甚至一个简单的服务器处理的数据量也是它的1000倍。对于一般的创业公司,几年内,单一的服务器难以处理所需数据的可能性是微乎其微的。
优先维护生产能力。“今天,最便宜的戴尔服务器有一个双核2.8ghz处理器和500gb磁盘阵列存储,价格刚刚超过700美元。升级到一个有着64GB的RAM和10TB存储的8核3.7ghz处理器版本,只需要约3200美元,花销远小于Expensify每个月在咖啡上的花费。大多数创业公司在提高自己市场上最便宜的服务器前就倒闭或者被收购了。特别是现在存储成本下降的速度远远快于大多数创业公司成长速度。即使使用EC2付费云托管,它仍然需要支付两倍的违约金。无论你的硬件是租的还是买的,机器容量永远不会成为绝大多数创业公司的一个真正的问题。维修保养才是最难的部分。如果你的单个服务器出问题了-或者你只是需要升级一下-当你重新启动它之后又会发生什么?你的整个服务就瘫痪了。总而言之,现在的电脑这么地便宜,多备几台,不是在提高生产能力,而是纯属多余。”
为安全问题钻牛角尖儿。“大多数数据库可以以两种方式访问。第一个是在数据库上做一个通用查询。另一种方法是通过存储过程来访问。诚然,所有的数据库都有安全措施,但他们也存在区别,“巴雷特说。“最流行的新数据库依赖于内置到Web服务器的代码。它的问题是,你的Web服务器十分有可能被攻破,因为他们直接连在互联网上。不怀好意者可以绕过安全措施,并不受限制地访问数据库。但如果一个存储过程在数据库内执行,网络黑客难以触及,这样能够保证在数据库层面的安全性。然而,绝大多数的创业公司-尤其是消费类公司-却选择使用不够安全的技术。这样一旦他们有了客户,在不停机的前提下进行安全改造的成本远比从一开始就做好安全工作高得多。”
初创公司在数据库安全方面还是应该保证,如果有闲置资金,最好买一个更安全的服务器。下面是应该怎么做。
早期,成长期。消费者,企业。每一家创业公司都有自己的情况,但巴雷特认为,有一个经验法则的方法,可以服务于一系列正在寻求智能化和实现目的性数据库架构的技术公司。下面是如何做:
从三个数据库开始。巴雷特认为,今天的技术让这成为可能,每一个初创公司应该在创业第一天就有三个数据中心。“三是一个神奇的数字,”他说。“一个还不够,因为它坏掉只是时间问题。可能连不上网或者主机瘫痪。不管是哪种情况出现,都是问题,一个单一的数据库是无法解决这个问题的。两个数据中心存在的问题是,你很容易受到所谓的“分裂大脑综合症”的影响,如果两个数据中心的服务器之间失去了联系,一旦两者之一完全或暂时无法访问,一切就都陷入了混乱。如果,在同一时间,他们都认为对方死机了,那么他们都认为他们是在充当主机,然后一直做着备份。在我们看来,就是他们都在消耗着相同的费用,成本会翻倍。显然这是不划算的。”
用一个时钟,你总是能够知道时间。但是如果有两个不同的时钟,你永远不会知道确切的时间,因为你不知道哪一个才是正确的。
由于一个数据中心是脆弱的,两个容易出现责任不明的问题,那就选择使用三个数据中心的服务器。“如果你有三个数据中心,这意味着在任何一时间点上,你可以失去一个完整的数据中心,还有两个剩余的。两个数据中心是足以正常运行的,“巴雷特说。“这听起来已经挺多了,但它同样可能出现问题。但是,即使问题出现了,在没有人催促逼迫的时候,正面解决问题会更有效一些。这种情况下,投资者不至于对你失望,客户也不用担心。因为前期规模已经奠定了基础。所以准备三个不同的数据中心或在AWS内准备三个不同的可用性区域吧。这一点都不贵,而且还简单,只是需要不凡的远见。”
查找和使用复制技术。为什么更多的创业公司创业时不用三个数据中心?公司创立初期建立三个数据中心意味着,在你有数据需要处理之前,-你得要先复制。每个数据中心中的每个服务器都需要不断地互相之间共享数据,这样每个服务器才能共享同一级别的信息。
“但备用或备份服务器可以很大程度上优化原始的复制技术。主机瘫痪的时候,整体都丧失了工作能力。这种故障转移过程要不是通过手动,要不就是随着请求沿途自定义脚本的过程一起被攻击。无论以哪种方式,都是全局性的问题,最终将会影响到客户,“巴雷特说。“更现代的解决方案充分考虑到复制和故障转移问题,这样,一个服务器死机也不会产生太大影响,无需手动操作,也不影响客户。此外,不同于原始的解决方案被设计在一个单一的数据中心,依赖快速而可靠的网络,新的解决方案能使优化工作在相对缓慢和不可靠的互联网连接情况下也能实现。”
问题的一部分来自,过时的关系数据库管理系统仍然处于主导地位。“想要使用MySQL,是非常困难的。因为这是一个旧的数据库,它最初是为小容量、运行速度慢的磁盘设计的。文件系统不能大于4GB。而现在,情况与那时大不相同了,“巴雷特说。“今天,所有的一切都是在固态硬盘或缓存在内存中,因此超快速。这是MySQL的难题。它还在不断优化,现在仍在被使用。所以它有所有的旧世界的包袱,但它着实不具备新世界的优势。”
有一些工具可以帮助在不同的数据中心同步服务器,但开放源代码,易于安装的工具才刚刚出现。“一些旧的解决方案与三个数据中心同步启动仍然是艰难的,这些在没有预言机那么强大的机器之前的2007年是不可能实现的。公平地说,Percona可能会奏效,但那时它刚被开发,我都没听说过,”巴雷特说。“因为我有做PtoP网络软件的背景,所以决定建立一个我们自己的解决方案。由此,产生了calledbedrock,它易于操作,并能实时复制,也不像 Oracle或MySQL那么复杂。就每一个服务器而言,只是在它的本地有一个单一的数据库,该技术将它们连接起来,并实现所有的复制功能。为了好玩,我们也会让它运行MySQL协议,它几乎可以作为一种简易替换器件。”
“如果还有其他的解决方案可供选择,Expensify计划无偿放弃这项技术。“最初,它只是一个专有的解决方案,因为我们找不到现成的。但随着时间的推移,我们意识到他强大的功能,任何人都可以用它。由于自动无缝聚类的思想,那些关心性能和可用性的人十分在意无损故障转移”巴雷特说,“但很少有人会因此来自行建立。因为其核心技术-Paxos的分布式一致性算法,很难得到正解。也正是它使得一组同等服务器能够可靠地选出一个主机,来协调分布式事务和平衡流量,并在故障发生的0毫秒之内做出反应。但我们已经花了八年的时间来让它跨过几个数量级,所以它还并不适用于很多现实世界的情况,因此,我们还在不断做出改进和准备,让它被更广泛的使用。”
决定你的数据是否需要分区。在从不同的数据中心选择三个服务器并选择一个复制技术后,还要决定是否将数据分区。分区涉及将一个数据库分解成完整的独立部分。这种选择会影响很多未来的决定。
提到分区,需要问一个问题:我想让每一位用户与其他用户共享数据还是将用户群互相分割开?
“几乎每个人开始都是“脱节的群体”,这是最简单的概念。无论你是为个人提供消费品还是为企业提供商品,用户之间的关系在开始时就已经很明显,“巴雷特说。“例如,如果你正在做企业文档存储,事情一开始就很明朗,你只需要在公司内部的员工之间共享文档。你甚至可能与企业客户签订合同,这也要求数据被物理隔离-不管如何,这样做总没坏处。”
风险是有一天你可能遇到一个意外情况,需要将以前你觉得不会有联系的几方联系起来。“想象一个法律公司为两个不同的客户工作,每一个都托管在两个不同的数据库上。突然分托的模型不适用了,因为正在使用一个数据库的公司不能调阅另一个数据库中的文件。你的技术现在阻碍了这一关键用例来提供产品支持-糟糕的是,你可能已经在此前提下通过签署企业协议巩固了这项技术。
另一种方法是提前设计一个通道,以备用户之间有朝一日共享数据,也就是从一开始就设计一个共享的数据库。“这需要你采用完全不同的技术路径,因为你不能再从硬件层面解决问题。如果你的数据库满了,你不能再为你的下一批客户买一个,你需要找到一种方法来升级整个系统-而不是单纯只为某个客户,“巴雷特说。“为所有用户保持一个单一的连续数据库的好处是,你可以消除客户之间资源分享的约束,无论是立刻还是在未来的任何时间。缺点是一个单一的巨大的数据库,比一堆小的数据库更难维护-尤其是如果你正在使用一个旧的数据库解决方案的时候。”
不是每一次的创业都能华丽地从头开始。如果你已经做了一些其他的选择-故意或不知情的-还有方法来走回正道。撞击道岔,转换方向可能不那么轻松,但火车其实还没有驶离车站。
· 选择在多个可用性区域中复制的数据库。“很多公司会说,“我已经有了一个EC2,立马就能运行我的web服务器,一个单一的RDS就是我的数据库,或者我把一些数据存储在S3里。这都是一个单一的可用性区域。“不要一开始就让自己陷入困境:与亚马逊一起构建能支持多个可用性区域或完全不同的数据中心。”
· 尝试Expensify的复制技术。“从MySQL换到Bedrock很简单:如果数据量小,你可以在深夜关掉你的服务器,把数据导出,再导入到Bedrock。您的Web服务器不会受到任何影响。因为Bedrock执行的也是MySQL协议。”
· 从存储过程开始。“问问你自己:“如果黑客袭击我的服务器,后果会有多严重?如果答案是“特别糟糕”,那么将您的验证逻辑移到数据库中的存储过程中。它会更安全,能保持更好的分层,并为最终用户提供更好的服务。”
大多数人不会觉得数据库结构很酷。但在拥有客户和他们的数据之前,充分了解也是很重要的。你如何组织,规划和保证这些数据的安全不仅会对你的技术产生作用,而且还会影响你的商业模式的可扩展性。保证在每三个不同的数据中心或可用性区域中至少有一个服务器。选择一个允许它们精确、可靠地相互通信的复制技术。检查您的用户之间的关系,以决定是否应分区您的数据。充分考虑存储的程序来保护您的数据。最大的挑战不是决定去采取这种做法,而是怎样顺利地从MySQL一类的流行数据库管理系统中转变过来。
“不要把自己的角色设定为 Google,以此来围绕数据库架构做决定。但也不要把在创业时有太多拘束,这会阻碍公司发展成为像 Google一样成熟的公司。事实上,许多初创公司在这些问题出现前,就已经失败了。你需要问问自己:你是在变得更好还是更坏?”巴雷特说。“严格的要求和机会,其实早就迫使我们做出更多关于数据库架构的思考。我们现在知道,坚实的基础不仅帮助我们按着预期的目标扩大规模,也为我们从未想过的深数据和人工智能技术提供支持。这些可能在我们第一次作出数据库架构的决定的时候就确定好了。这个系统架构像一个大桶,收纳了以任何你能想象的方式存在的数据。而另一个选择则是糟糕的。如果你没有意识到你在第一天就建立了一个监狱,将来遇到的困难可能是无法解决的。”
翻译来自:虫洞翻翻 译者ID 郭洋阳