数据密集型应用设计读书笔记第一章。现在的数据密集型应用，趋势是组件化。存储数据，以便自己或其他应用程序之后能再次找到 （数据库（database））记住开销昂贵操作的结果，加快读取速度（缓存（cache））允许用户按关键字搜索数据，或以各种方式对数据进行过滤（搜索索引（search indexes））向其他进程发送消息，进行异步处理（流处理（stream processing））定期处理累积的大批
转载
2023-12-11 10:56:54
46阅读
摘要:小心数据的爆炸性增长,不要进行不成熟的优化,但是要密切关注渐进复杂性.用户数据的算法应该能够预测所处理的数据量耗费的时间,最好不差于线性关系.如果能够证明优化必要而且非常重要,尤其在数据量逐渐增长的情况下,那么应该集中注意力改善算法的O(N)复杂性，而不是进行小型的优化。 防范可能的未来，要求我们要避免设计中含有面对更大的文件、更大的数据库、更多像素、更多窗口、更多
转载
2023-08-29 19:22:53
66阅读
可伸缩性原则
从最简单的水平来看，可伸缩性就是做更多的事情。更多的事情可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。设计软件这件事本身是复杂的，而让软件做更多的工作也有其特有的问题。这篇文章针对构建可伸缩软件系统提出了一些原则和方针。
1. 减少处理时间
增加应用所做工作数量的一个方法就是减少完成单项工作所花费的时间。举例来说，减少处理一个用户请求所需的时间意味着你能在同样长的
转载
精选
2009-11-24 14:56:51
671阅读
从最简单的水平来看，可伸缩性就是做更多的事情。更多的事情可以是响应更多的用户请求，执行更多的工作，或处理更多的数据。设计软件这件事本身是复杂的，而让软件做更多的工作也有其特有的问题。这篇文章针对构建可伸缩软件系统...
转载
2013-04-30 12:08:00
134阅读
2评论
3.2 目标客户的预测（响应、分类）模型这里的预测（响应、分类）模型包括流失预警模型、付费预测模型、续费预测模型、运营活动响应模型等。预测（响应、分类）模型是数据挖掘中最常用的一种模型类型，几乎成了数据挖掘技术应用的一个主要代名词。很多书籍介绍到数据挖掘的技术和应用，首先都会列举预测（响应、分类）模型，主要的原因可能是响应模型的核心就是响应概率，而响应概率其实就是我们在第1章中介绍的数据化运营六要
转载
2024-01-30 07:15:12
36阅读
可扩展有两个层面的含义：一是功能的可扩展性，主要是针对平台框架，是否设计并预留了足够的扩展点，后续可以很方便的增加各种功能或有第三方实现各种插件。另一种是性能的可扩展性，系统的弹性扩容能力，即随着系统用户量、并发的增加是否可实现弹性扩容，通过增加硬件设备就能提供更强的处理能力，这种一般称为可伸缩性。
转载
2019-04-24 08:59:00
425阅读
2评论
可伸缩网络服务的定义 可伸缩性（Scalability）是在当今计算机技术中经常用到的词汇。对于不同的人，可伸缩性有不同的含义。 现在，我们来定义可伸缩网络服务的含义。 可伸缩网络服务是指网络服务能随着用户数目的增长而扩展其性能，如在系统中增加服务器、内存或硬盘等；整个系统很容易被扩展，无需重新设置整个系统，无需中断服务。换句话说，系统管理员扩展系统的操作对最终用户是透明的，他们不会知道系统的改
转载
2023-07-30 07:53:27
132阅读
同步调用使得组件和组件之间紧密耦合起来，这样就使得要想伸缩应用就需要伸缩所有的组件，这不仅带来使得伸缩的成本增加，而且这种高度耦合性使得伸缩变得更加困难。因此我们需要从应用角度划分出，哪些业务操作是紧密关联的，哪些是可以异步执行的，划分出那些可以异步执行的操作，然后将其进行异步化处理（比如通过JMS，事件队列，多播消息等或者线程池等），这样划分的好处就是系统可以应对更大的访问量，消
原创
2009-12-06 19:30:00
550阅读
引言在扩展大量大型的分布式系统期间，我有机会观察（并实践）了一些最差实践。这些最差实践中的大部分在开始时都没有危害，但如果疏忽大意，它们就会对系统的发展和可伸缩性构成危害。很多文章都聚焦于最佳实践，以确保拥有一个...
转载
2013-04-29 23:35:00
106阅读
2评论
数据系统基石头 可靠性，可伸缩性，可维护性： 可靠性（Reliability）系统在困境（adversity）（硬件故障、软件故障、人为错误）中仍可正常工作（正确完成功能，并能达到期望的性能水准）。可伸缩性（Scalability）有合理的办法应对系统的增长（数据量、流量、复杂性）（参阅“可伸缩性”）可维护性（Maintainability）许多不同的人（工程师、运维）在不同的
转载
2024-01-21 10:50:48
66阅读
下面是我们认为的一些可伸缩性的最佳实践：异步；尽可能的使用异步，同步调用会导致两个服务的可用性绑在一起，意味着一个服务出问题或变慢，另一个也会受到影响，这点也是eBay一直强调的；泳道设计；错误隔离机制，避免一个失败影响全局，这种机制也有助于错误查找和代码替换；缓存；在所有层次均使用缓存，例如数据、页面、页面片段等；监测；从用户角度来看系统的性能。这包括从外部网络来对系统进行性能的监测，以及内部的
原创
2021-12-31 17:31:20
74阅读
近些年来，伴随着技术的进步，越来越多的Web应用系统需要存储、转化、处理越来越多的数据，而这必将要求工程师们掌握构建可伸缩的Web系统的能力。当我了解到大多数工程师都缺乏这种构建可伸缩Web系统的能力时，我觉得有必要写一篇与此有关的文章。一方面，目前市面上缺乏相关的材料；另一方面，那些在小公司工作的工程师们也缺乏必要的环境去学习可伸缩架构的设计方法。因此，本文致力于讲解软件架构与基础设施如何协同工
对可伸缩的TCP/IP服务器而言，最有用的扩展API也就算AcceptEx了。利用这个函数，服务器可以投递一个异步调用，该调用将接受下一个传入的客户机连接。
BOOL AcceptEx( __in SOCKET 
转载
2012-03-14 09:16:17
1757阅读
ConnectEx是一个极其必要的API，这个函数允许重叠的连续调用。
BOOL PASCAL ConnectEx( __in SOCKET s, __in 
转载
2012-03-14 10:06:11
1787阅读
转载
2012-03-14 10:07:10
543阅读
因为需要这个函数来对传递的接收调用的缓冲区内的本地及远程地址进行解码，所有这个函数是AcceptEx的辅助函数。单个缓冲区不仅容纳连接的本地及远程地址，还容纳连接上收到的任何数据。指明要接收的任何数据将始终放在缓冲区的开始部位，地址紧随其后。不过这个地址是打包形式的地址，GetAcceptExSockaddrs函数将把他们拆开放到适当的相应地址族的结构中。
void G
转载
2012-03-14 09:37:06
2085阅读
在这篇文章中，Orbitz的前架构师主管Brian Zimmer对可伸缩性的最差实践进行了论述。涵盖的主题包括金锤子、资源滥用、大泥球、依赖管理、超时、英雄模式、非自动化和监控。
文章摘录如下：
操作问题普遍的解决方案是有一个“英雄”（关键性人物），他能处理、并经常处理大部分的操作需求。在小规模环境中，当某个人有熟悉整个系统（包括保持系统
正常运行的许多细节之处）的天赋和能力时，英雄模式
原创
2008-12-19 09:50:34
582阅读
转载
2012-03-14 09:49:40
393阅读
转载
2012-03-14 09:50:56
709阅读
对可伸缩的TCP/IP服务器而言，最有用的扩展API也就算AcceptEx了。利用这个函数，服务器可以投递一个异步调用，该调用将接受下一个传入的客户机连接。
BOOL AcceptEx( __in SOCKET sListen
转载
精选
2012-12-01 22:40:10
725阅读
