标签：缓存 软件系统 数据库 000 封底 GB 计算 100 请求
软件系统设计：封底计算
系统设计
系统设计是一个设计软件系统元素的过程，如组件、架构、接口、模块、数据库类型等。然后定义不同组件如何相互交互的机制。这包括数据流和数据访问。
系统设计是一个非常广泛的话题，我只是试图触及冰山一角。
一个软件 系统架构 是一个 概念模型 这定义了 结构体 , 行为 ， 和 意见 一个 系统 [ 维基 ]。架构描述是系统的正式描述和表示，以支持功能推理的方式有效地组织， 结构 ， 和 行为 系统的。
什么是信封计算的背面
粗略计算是我们在脑海中或在纸上（主要是在纸上）进行的近似计算。这些步骤都不是 100% 准确的，结果也不是。目的是比正式计算更快地达到最佳拟合或最佳匹配或大致数字。目的不是胡乱猜测，而是结果应该比猜测更准确，但不如正式计算准确。
示例：5 * 9.667
我的答案将是 45 到 50 之间的任何值。或者我会简单地选择 50。
5 * 9.667 == 5*10 = 50。尽管这个问题的确切答案是 48.335。
photo by author
什么是系统设计中的封底计算
粗略计算在系统设计中非常重要，有助于为系统选择良好的配置和技术。它有助于识别请求和响应大小、数据库大小、缓存大小、微服务计数、负载均衡器等。设计系统还需要估计网络带宽需求。
在开始任何高级和低级设计之前估计系统的规模总是一个好主意。当我们专注于数据库技术、扩展、分区、负载平衡和缓存时，这将在以后的阶段有所帮助。它还有助于提高软件系统性能。
根据我的观点，系统设计有 4 个主要领域需要进行粗略 (BOTE) 计算：
- 负载估计（又名流量估计）
- 数据库存储估计
- 缓存估计
- 带宽估计
此外，了解系统是“读取繁重还是写入繁重”有助于更好的设计和估算。让我们花几秒钟的时间讨论这个话题：
重读或重写
系统类型有助于进行良好的估计。此外，了解系统是读取繁重还是写入繁重有助于开始估计。示例：Tiny Url 是重读的，而 Web Crawler 是重写的系统。
虽然，这对选择技术和数据库类型更有帮助。它可以帮助对缓存做出一些决定。 Like Cache 对于读取 Heavy 系统而不是 Write Heavy 是高性能和有用的。
小建议：
永远记住一句话： BKMGTP
B：字节：十：10
K : 公斤 : 千 : 1000
M：兆：百万：1000 0000
G：千兆：十亿：1000 000 000
T：万亿：万亿：1000 000 000 000
P：Peta：千万亿 ： 1000 000 000 000 000k*K = M
M*K =G
G*K = T
T*K =P
1. 负载估计（又名流量估计）
负载估计有助于确定系统将要处理的请求量。它可能是 DAU——每日用户访问或每秒请求数。
它通常以每秒测量一次。并且，可以扩展到每天。
此外，了解系统是读取繁重还是写入繁重对于开始详细说明很有好处。 例子 : Tiny Url 是重读的，而 Web Crawlers 是重写的系统。
让我们做一些信封的背面：
假设系统必须读写比率= 1:100
而且，有 百万 每天写电话。
每秒新写入请求数：
1M /（24 小时 * 3600 秒）~= 12 个请求/秒
每秒读取请求数：
100 M /（24 小时 * 3600 秒）~= 120 个请求/秒
快捷方式：12 个请求/秒 * 100M = ~1200 个请求/秒。
记忆小贴士：
如果我们记得每天 100 万次请求 = ~12 次请求/每秒。然后，我们可以快速计算出每天 100M 的请求：1.2K 请求/秒。
2. 数据库存储估算
数据库存储估计非常重要，因为数据库是任何应用程序的一个组成部分。有时工程师和架构师将大部分时间花在需要构建的业务逻辑和服务上。而且，数据库选择和估计的时间也非常少。
正如我在之前的博客中提到的 开发高性能应用程序和微服务
应用程序响应时间直接取决于数据源和底层数据库响应时间。数据库选择和数据库建模非常重要。应用程序可以有 RDBMS、Key-Value 存储和/或非结构化数据（例如图像、视频）等。为了提高性能，结构化数据应存储在 RDBMS 数据库中，非结构化数据应存储在 No SQL 数据存储中像 Mongo DB 或 Cassandra。
数据库类型（RDBMS、NO-SQL、Object DB 等）应根据用例决定，我们不应试图遵循“一刀切”的做法。
数据库估计有助于回答以下问题：
- 存储 100M 写请求的内容需要多少空间？
- 存储 100 万天网页内容的空间有多大（如果我们正在设计网络爬虫）？
- 如果我们用整数索引替换每个单词怎么办？
- 512GB（存储大小）存储的机器可以容纳多少台？
- 哪个数据库最适合？等等
让我们做一些信封的背面：
假设系统必须读写比率= 1:100
而且，有 1M 每天写电话。
假设每个写请求是 1000 B = 1KB
而且，我们必须将其存储 10 年
每天的存储量 = 1M * 1KB = 1 GB（千兆字节）
每年存储 = 1GB * 365 天 = 360 GB
10 年存储 = 360 GB * 10 = 3.6 TB（TB）
会有一些存储空间用于审计、用户、安全等。假设它是 0.4 TB。
因此，10 年的总存储容量 ~3.6 +0.4 = 4 TB。
记忆小贴士：
如果我们记得每天 100 万次请求和 1 kb 端是每天 1 GB 和每年 365 GB。然后，我们可以快速计算出 XX 年的存储空间：1 GB * 365 * XX。
我们可以为识别存储设置一些基本规则或假设：
单字符 = 2 个字节。
长或双 = 8 个字节。
平均分辨率 图片 = 300 KB
良好的分辨率 图片 = 3 MB
标准 视频 对于流媒体 = 每分钟 100 MB 的视频
3.缓存估计
缓存估计是一个有趣而又令人困惑的话题。因为缓存要求没有硬定义的规则。有些应用程序根本不维护缓存，有些应用程序使用 10-30% 的数据库存储作为缓存，有些应用程序使用 20-30% 目前/经常访问 数据。正如我在之前的技术博客中所描述的那样 开发高性能应用程序微服务 ，我更喜欢 80/20 或 70/30 的数据库使用率与缓存大小的比率，即保持 20–30% 的折扣 目前/经常访问 数据提高性能。
让我们做一些信封的背面：
假设每天的存储量 = 1 GB（千兆字节）
缓存要求 = 每天总存储量的 20% = (20 * 1 GB)/100= 200 MB
你觉得上面的Cache计算正确吗？
我会说 不 - 这是不正确的。缓存是经常访问的数据/异议的临时存储。因此，应该根据每天的请求负载来计算缓存大小。以下是更好的信封背面计算：
写读比 = 1:100
每天写请求 = 100 万
每天的读取请求 = 1 亿
每个请求大小：1KB
总读取请求大小：1 亿 * 1 KB = 每天 100 GB。
缓存估计 = 20% 的读取存储（20*100 GB）/100= 20 GB。
记忆小贴士：
如果我们记得每天 1000 万个 1 kb 端的请求是每天 10 GB。然后，我们可以快速计算出 XX 年的存储空间：10 GB * .2 = 2 GB。
提示：由于缓存非常昂贵，因此良好的估算有助于更好地进行预算。
4. 带宽估算
带宽估计网络带宽。如果有助于回答诸如
- 需要什么上游和下游速度。
- 高峰期需要什么网速，
-ETC？
写读比 = 1:100
每天写请求 = 100 万
每天的读取请求 = 1 亿
每个请求大小：1KB
总读取请求大小：每天 1 亿 * 1 KB = 100 GB。
带宽（每秒）= 100 GB 每天 / (24*3600) = 1157.40741 KB/秒 = ~1 MB 每秒。
而且，写入是读取请求的 10%，因此 1 MBPS /10 = 0.01 MBPS。
由于写入请求是读取请求的 1/100，我们可以说 ~1MBPS 是该软件系统的带宽要求。
记忆小贴士：
一天中的秒数 = 24 小时 * 60 小时 * 60 秒 = 86400 = 约 100,000 秒
每天 10 GB / 100,000 秒 = 10,000,000,000 / 100,000 = 100,000 = 1 MB / 秒
如何在粗略计算中取得优势：
唯一的答案是练习练习和练习！！
所有计算均基于基本数学和转换（ 我假设我们知道软件工程和一些架构设计原则 ）。实践是学习和实施的最佳方式。作为粗略计算的一部分，在纸上犯和纠正错误比设计和实现损坏的软件系统或应用程序要好。
结论
我相信良好的估计需要大量的练习和基本的数学和转换。而且，如果我们牢记一些快速转换并不断练习，我们最终会得到良好的估计，这将导致高性能和可靠的软件产品。
感谢您的阅读。如果你喜欢这个故事，请鼓掌，喜欢，分享和关注更多这样的内容。与往常一样，如有任何问题/反馈，请联系我们。
领英： saurabh-gupta-engr _
GitHub：_ SaurabhGupta-repo
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
本文链接：https://www.qanswer.top/22156/45490708
标签：缓存,软件系统,数据库,000,封底,GB,计算,100,请求 来源： https://www.cnblogs.com/amboke/p/16664041.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。