web嵌入应用程序_我从在嵌入式键值存储上构建3个高流量Web应用程序中学到了什么。...

web嵌入应用程序

作为一种时尚&＃xff0c;我长大了&＃xff0c;所有的Web应用程序都必须建立在正确的体系结构上&＃xff0c;通常涉及经过良好测试和稳定的sql数据库&＃xff0c;如postgres&＃xff0c;或者在某些情况下涉及nosql数据库&＃xff0c;如mongodb。 原因很简单&＃xff1a;

• 它们可以缩放&＃xff0c;缩放和缩放。 当您的应用程序在一夜之间达到最初的10亿用户时&＃xff0c;这一点非常重要。
• SQL是访问数据的最佳方法。 而且&＃xff0c;您始终需要一个复杂的消息层来访问该数据。
• 如果不使用sql&＃xff0c;将如何执行联接&＃xff1f; 您将如何构建复杂的搜索&＃xff1f; 您如何防止代码变得如此复杂以至于掉下来并杀死您的猫&＃xff1f;

• 为什么在不需要聘请经验丰富的数据库管理员来创建复杂的架构并执行非常重要和复杂的数据库维护任务的应用程序中构建应用程序。

在2015年&＃xff0c;我偶然发现了golang BoltDB数据库库 &＃xff0c;并首先用于在基本服务器端应用程序中保存状态。 然后我偶然发现了blevesearch &＃xff0c;它突然降临在我身上。 大多数数据库提供的最基本的功能是存储&＃xff0c;以及对已存储数据的灵活搜索。 使用boltdb&＃xff0c;我可以高效地存储数据&＃xff0c;并且可以使用bleve&＃xff0c;以有趣的方式搜索和访问数据。

在此基础上&＃xff0c;我仅在boltDB和blevesearch上构建并启动了Calabar Yellow Pages &＃xff0c;然后当我看到它在生产中的运行和扩展的顺利程度时&＃xff0c;我继续在badge DB&＃xff08;A上&＃xff09;构建Shop440 &＃xff08;Shopify和Aliexpress的合并&＃xff09;。比boltdb更快的替代方法&＃xff09;和blevesearch进行索引。

我学到了什么&＃xff1a;

关键价值商店快速

首先&＃xff0c;NoSQL键值存储速度快&＃xff0c;比可比的关系数据库快得多。 它的速度来自其简单性。 键值数据库使用一个主键存储数据记录。 密钥意味着记录是唯一可识别的&＃xff0c;并且可以直接访问。 除此之外&＃xff0c;由开发人员来设计访问数据的更多复杂性。

另外&＃xff0c;由于我使用的键值存储是嵌入式数据库&＃xff0c;因此我能够进行一些已建立的数据库附带的处理。 在像mongoDB这样的数据库中&＃xff0c; 大量的资源和等待时间用于序列化数据并将其通过电线传递给客户端应用程序&＃xff0c;然后由客户端对应用程序进行反序列化和解码 。 这是浪费资源&＃xff0c;尤其是当客户端和数据库在同一服务器上运行时&＃xff0c;而不是在单独的服务器上运行时&＃xff0c;它们将从HTTP通讯中受益。 嵌入式数据库消除了所有这些额外的序列化甚至tcp传输成本。

出色的可扩展性-一致性如何&＃xff1f;

其次&＃xff0c;NoSQL键值数据库也是高度可伸缩的。 这也是其简单性的功能。 与关系数据库不同&＃xff0c;NoSQL键值数据库没有义务垂直扩展。 它可以在多个机器或设备上扩展几个数量级&＃xff0c;而无需进行重大的重新设计。 在财务上&＃xff0c;这也是一个很大的优势。

但就我而言&＃xff0c;由于使用嵌入式键值存储&＃xff0c;因此大多数扩展都是垂直发生的&＃xff0c;甚至持续了很长时间。 目前&＃xff0c;即使数据库大小接近TB&＃xff0c;应用程序仍然保持强大的性能。 有了badge&＃xff0c;我想到了拥有多个multiple数据库的策略&＃xff0c;每个数据库代表一个集合。 这样&＃xff0c;如果我需要将系统扩展到单个服务器之外&＃xff0c;就可以将每个单独的数据库及其相应的程序逻辑隔离到一个单独的微服务中。 &＃xff08;我将在以后写更多有关此的内容。&＃xff09;

省时省力

扩展关系数据库解决方案通常意味着成本成比例增加。 它还需要时间和精力&＃xff08;以及服务器停机&＃xff09;来更改数据库架构。 相比之下&＃xff0c;键值数据库使价格曲线保持线性而不是指数&＃xff0c;并且设计为无需任何预定义架构即可处理数据。 某些&＃xff08;不是全部&＃xff09;键值数据库&＃xff08;如其他NoSQL数据库&＃xff09;也设计用于“ 最终一致性 ”。 这意味着数据“在某个时刻”在不同计算机上的副本之间同步&＃xff0c;但不是立即同步。

无模式行和列

嵌入式键值存储的案例

根据https://www.sqlite.org/whentouse.html

对于大多数中低流量的网站&＃xff08;也就是说&＃xff0c;大多数网站&＃xff09;&＃xff0c;SQLite可以很好地用作数据库引擎。 SQLite可以处理的网络流量取决于网站使用其数据库的程度。 一般来说&＃xff0c;任何每天点击量少于10万的网站都可以在SQLite上正常运行。 每天10万次点击是一个保守的估计&＃xff0c;而不是一个硬上限。 SQLite已被证明可以处理10倍的流量。

当然&＃xff0c;SQLite网站&＃xff08; https://www.sqlite.org/ &＃xff09;使用SQLite本身&＃xff0c;截至撰写本文&＃xff08;2015&＃xff09;时&＃xff0c;它每天处理约400K至500K HTTP请求&＃xff0c;其中约15–20&＃xff05;是动态的页面接触数据库。 每个网页的动态内容使用大约200条SQL语句 。 此设置在单个VM上运行&＃xff0c;该VM与23个虚拟机共享一个物理服务器&＃xff0c;但大多数情况下仍将平均负载保持在0.1以下。

大多数嵌入式密钥值存储区&＃xff08;例如badge&＃xff09;比sqlite的效率和性能要高得多&＃xff0c;因此这可以证明&＃xff0c;如果sqlite每天可以处理如此多的点击&＃xff0c;则嵌入式密钥值存储区还可以提供更多的功能。

此外&＃xff0c;在嵌入式语言索引值存储&＃xff08;如Blevesearch&＃xff09;和嵌入式索引引擎&＃xff08;如Blevesearch&＃xff09;和Golang等编译语言中使用 &＃xff0c;意味着您可以真正部署单个二进制文件&＃xff0c;而无需外部依赖项&＃xff0c;也不需要后期部署设置。

简而言之

嵌入式键值存储为您提供了nosql 数据库的所有优点&＃xff0c;但是缺少它的地方是在搜索中&＃xff0c;因为您只能通过其键和键的前缀来查询项目。 但是&＃xff0c;当与诸如golang中的blevesearch或elasicsearch和lucene的索引引擎配对时&＃xff0c;该配对将以非常节省资源的包为您提供功能强大的数据库&＃xff0c;具有全文搜索&＃xff0c;基于位置的搜索等功能&＃xff0c;并且可以很好地扩展。

我相信这对服务器应该比目前实际拥有更多的知名度&＃xff0c;并且在减少服务器费用方面要花很长的时间&＃xff0c;尤其是对于那些从未期望过Facebook级规模的应用程序。

翻译自: https://hackernoon.com/what-i-learnt-from-building-3-high-traffic-web-applications-on-an-embedded-key-value-store-68d47249774f

web嵌入应用程序