如果你有一张表，表内有1亿条数据，查询和更新都会很慢。对于这种情况，主要原因是出在了IO上。单单靠加索引是不行了。所以得另想办法。下面的分析比较贴近实际，如果一年前的只是备份待查,分离出来另存.如果一年前的会用到,但用得少,用分区.如果一年前的仍然要频繁使用,用分区,但要加一个磁盘.&那么就讨论一下分区吧，下面的内容来自这个博客/CareySon/category/和这个博客/sienpower/archive//2308741.html简介&&& 分区表是在SQL SERVER2005之后的版本引入的特性。这个特性允许把逻辑上的一个表在物理上分为很多部分。而对于SQL SERVER2005之前版本，所谓的分区表仅仅是分布式视图,也就是多个表做union操作.&&& 分区表在逻辑上是一个表，而物理上是多个表.这意味着从用户的角度来看，分区表和普通表是一样的。这个概念可以简单如下图所示：&&而对于SQL SERVER2005之前的版本，是没有分区这个概念的，所谓的分区仅仅是分布式视图:&&本篇文章所讲述的分区表指的是SQL SERVER2005之后引入的分区表特性.为什么要对表进行分区&&&& 在回答标题的问题之前，需要说明的是，表分区这个特性只有在企业版或者开发版中才有,还有理解表分区的概念还需要理解SQL SERVER中文件和文件组的概念.*文件，文件组/CareySon/archive//2301597.html&&&&& 对表进行分区在多种场景下都需要被用到.通常来说，使用表分区最主要是用于:&&&& 存档，比如将销售记录中1年前的数据分到一个专门存档的服务器中&&&& 便于管理，比如把一个大表分成若干个小表，则备份和恢复的时候不再需要备份整个表，可以单独备份分区&&&& 提高可用性，当一个分区跪了以后，只有一个分区不可用，其它分区不受影响&&&& 提高性能，这个往往是大多数人分区的目的，把一个表分布到不同的硬盘或其他存储介质中，会大大提升查询的速度.&分区表的步骤&&& 分区表的定义大体上分为三个步骤：&&& 定义分区函数&&& 定义分区构架&&& 定义分区表&&& 分区函数，分区构架和分区表的关系如下：分区表依赖分区构架，而分区构架又依赖分区函数.值得注意的是，分区函数并不属于具体的分区构架和分区表，他们之间的关系仅仅是使用关系.&&& 下面我们通过一个例子来看如何定义一个分区表:&&&& 假设我们需要定义的分区表结构如下:& &第一列为自增列，orderid为订单id列，SalesDate为订单日期列，也就是我们需要分区的依据.&&&& 下面我们按照上面所说的三个步骤来实现分区表.定义分区函数&&& 分区函数是用于判定数据行该属于哪个分区,通过分区函数中设置边界值来使得根据行中特定列的值来确定其分区，上面例子中，我们可以通过SalesDate的值来判定其不同的分区.假设我们想定义两个边界值(boundaryValue)进行分区,则会生成三个分区,这里我设置边界值分别为和，则前面例子中的表会根据这两个边界值分成三个区:& &在MSDN中，定义分区函数的原型如下:CREATE PARTITION FUNCTION partition_function_name ( input_parameter_type )AS RANGE [ LEFT | RIGHT ] FOR VALUES ( [ boundary_value [ ,...n ] ] ) [ ; ]&&&& 通过定义分区函数的原型，我们看出其中并没有具体涉及具体的表.因为分区函数并不和具体的表相绑定.上面原型中还可以看到Range left和right.这个参数是决定临界值本身应该归于&left&还是&right&：&下面我们根据上面的参数定义分区函数:通过系统视图，可以看见这个分区函数已经创建成功&定义分区构架&&& 定义完分区函数仅仅是知道了如何将列的值区分到了不同的分区。而每个分区的存储方式，则需要分区构架来定义.使用分区构架需要你对文件和文件组有点了解.&&& 我们先来看MSDN的分区构架的原型:CREATE PARTITION SCHEME partition_scheme_nameAS PARTITION partition_function_name[ ALL ] TO ( { file_group_name | [ PRIMARY ] } [ ,...n ] )[ ; ]&&& 从原型来看，分区构架仅仅是依赖分区函数.分区构架中负责分配每个区属于哪个文件组，而分区函数是决定如何在逻辑上分区:基于之前创建的分区函数,创建分区构架:定义分区表&&& 接下来就该创建分区表了.表在创建的时候就已经决定是否是分区表了。虽然在很多情况下都是你在发现已经表已经足够大的时候才想到要把表分区，但是分区表只能够在创建的时候指定为分区表。&为刚建立的分区表PartitionedTable加入5万条测试数据，其中SalesDate随机生成，从2001年到2010年随机分布.加入数据后，我们通过如下语句来看结果:select convert(varchar(50), ps.name) as partition_scheme,p.partition_number, convert(varchar(10), ds2.name) as filegroup, convert(varchar(19), isnull(v.value, ''), 120) as range_boundary, str(p.rows, 9) as rowsfrom sys.indexes i join sys.partition_schemes ps on i.data_space_id = ps.data_space_id join sys.destination_data_spaces ddson ps.data_space_id = dds.partition_scheme_id join sys.data_spaces ds2 on dds.data_space_id = ds2.data_space_id join sys.partitions p on dds.destination_id = p.partition_numberand p.object_id = i.object_id and p.index_id = i.index_id join sys.partition_functions pf on ps.function_id = pf.function_id LEFT JOIN sys.Partition_Range_values v on pf.function_id = v.function_idand v.boundary_id = p.partition_number - pf.boundary_value_on_right WHERE i.object_id = object_id('PartitionedTable')and i.index_id in (0, 1) order by p.partition_number&&& 可以看到我们分区的数据分布:分区表的分割&&&& 分区表的分割。相当于新建一个分区，将原有的分区需要分割的内容插入新的分区，然后删除老的分区的内容,概念如下图:&&&& 假设我新加入一个分割点：，则概念如下:通过上图我们可以看出，如果分割时，被分割的分区3内有内容需要分割到分区4，则这些数据需要被复制到分区4，并删除分区3上对应数据。&&&&&这种操作非常非常消耗IO，并且在分割的过程中锁定分区三内的内容，造成分区三的内容不可用。不仅仅如此，这个操作生成的日志内容会是被转移数据的4倍！&&&& 所以我们如果不想因为这种操作给客户带来麻烦而被老板爆菊的话&最好还是把分割点建立在未来（也就是预先建立分割点)，比如。则分区3内的内容不受任何影响。在以后2012的数据加入时，自动插入到分区4.&&&& 分割现有的分区需要两个步骤:&&&& 1.首先告诉SQL SERVER新建立的分区放到哪个文件组&&&& 2.建立新的分割点&&&& 可以通过如下语句来完成:& &如果我们的分割构架在定义的时候已经指定了NEXT USED，则直接添加分割点即可。&&&& 通过文中前面查看分区的长语句..再来看:& 新的分区已经加入！&分区的合并&&&& 分区的合并可以看作分区分割的逆操作。分区的合并需要提供分割点，这个分割点必须在现有的分割表中已经存在，否则进行合并就会报错&&&& 假设我们需要根据来合并分区,概念如下:& & 只需要使用merge参数：&&再来看分区信息:&&这里值得注意的是，假设分区3和分区4不再一个文件组，则合并后应该存在哪个文件组呢？换句话说，是由分区3合并到分区4还是由分区4合并到分区3？这个需要看我们的分区函数定义的是left还是right.如果定义的是left.则由左边的分区3合并到右边的分区4.反之，则由分区4合并到分区3:总结&&& 本文从讲解了SQL SERVER中分区表的使用方式。分区表是一个非常强大的功能。使用分区表相对传统的分区视图来说，对于减少DBA的管理工作来说，会更胜一筹！> 看看谁可以解决大数据量的搜索题目：有一个数据库其中有10亿条的记录，在其中查询一条记录需要5秒。现
看看谁可以解决大数据量的搜索题目：有一个数据库其中有10亿条的记录，在其中查询一条记录需要5秒。现
qingwuyouyang & &
发布时间： & &
浏览：359 & &
回复：4 & &
悬赏：0.0希赛币
看看谁可以解决大数据量的搜索题目：
有一个数据库其中有10亿条的记录，在其中查询一条记录需要5秒。现在有服务器10台（组成一个局域网提供服务），每个服务器有2个cpu，2G的内存。现在要求 & 将 & 对其中数据 & 90% & 的查询可以在 & 100ms & 内完成。问怎么解决？
如果要求join结果集的话。
你在建立数据的时候，按mod(key)的方法，把数据分开放在10台机器上。大概每台机器是1G左右的数据
对主键进行加速就可以达到效果，比如把1G的数据分成多个表来存放。这样在更新速度上可以得到优化。
重点不是查询，是在建数据的时候是如何建立的。合理的分配你的数据。
qingxp & &
& & （0）（0）如果不要求join结果集的话。
我对数据库不懂. 非数据库我可以做到，数据库的没有经验。
qingxin & &
& & （0）（0）假设之前是1个CPU,1G内存.
不做任何的算法改进，在现在算法的基础上将数据用比较均匀的方式分为十段，每段取出十分之一放到其中一台服务器上．理论上获得的速度提升就接近40倍．检索速度已经达到125ms. 基本上就是125 * 0.9 = 112.5已经基本达到要求．
再进行配置和算法的优化一定可以满足需求．
qingxin130 & &
& & （0）（0）也给一个处理的方案
1.数据库确实可以在在一台机器上，但是在组建的局域网的机器全部In service以后，
可以将数据分发到这些机器上，进行数据的插入(可以是保存在local的数据库，也可以使文件中)；各台服务器负责自己维护的数据.
2.具体把哪些数据记录分发到哪些机器上，将会是提高这个系统性能的关键之一。这和数据记录，查询key自身的特征有关系。需要建立，查询key，各台服务器标示(e.g.
IP/MAC)之间的映射关系，在初始化过程中，该映射读入到内存。
3.对于每一台服务器上的访问，可以使用的方法比较多。根据题目中一再强调外存文件的顺序和随机访问速度的差异，可以看出，比较倾向于直接的文件访问。这个就不谈那。想讨论一下使用文件的内存映射，可以在该服务器上建两个独立的进程，各自具有地址空间，将数据库服务器分发过来的数据保存在文件中(保存之前，用hash函数处理)，然后映射到地址空间，提高访问速度。
qingxing & &
& & （0）（0）
本问题标题：
本问题地址：
温馨提示：本问题已经关闭，不能解答。
暂无合适的专家
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&&&增值电信业务经营许可证湘B2-随着实时分析技术的发展及成本的降低，用户已经不仅仅满足于离线分析。目前我们服务的用户包括微博、微盘、云存储、弹性计算平台等十多个部门的多个产品的日志搜索分析业务，每天处理约32亿条（2TB）日志。技术架构简单介绍一下服务的技术架构：这是一个再常见不过的架构了：（1）Kafka：接收用户日志的消息队列。（2）Logstash：做日志解析，统一成JSON输出给Elasticsearch。（3）Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能。（4）Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因。努力提供更好的服务我这次分享的重点不是这种架构的优劣或为什么选择这样的架构，而是在如此的架构上如何更好地传递实时日志分析的价值。为用户做好服务也不是修改几个配置文件，调优几个程序运行参数就能搞定的。为了提供更好的服务，我们在下面三个方向做了努力：一、提升服务质量我们首先做了Elasticsearch优化，Hardware Level由于我们当时拿到机器没有选择余地，只开启了超线程；System Level的优化如关闭swap，调整max open files等；App Level的优化如Java运行环境版本的选择，ES_HEAP_SIZE的设置，修改bulk index的queue size等，另外还设置了默认的index template，目的是更改默认的shard，replica数并将string改为not_analyzed，开启doc_values以应对elasticsearch进程OOM。详细的优化内容见：/garyelephant/blog/blob/master/elasticsearch_optimization_checklist.md。随着用户数据的不断增长，index管理也成了大问题，我们需要基于大量不同的用户配置定期的create、optimize、close、delete、snapshot不同的index，在某个服务器上手工配置crontab已是不可能，而且cron是单点。于是我们开发了一个独立的Elasticsearch Index管理系统，负责以上任务的调度及执行。这个管理系统背后使用的技术是Celery，一个用Python开发的任务队列及执行系统，提供了类似crontab的定时任务配置语法，并且实现了分布式，可用性更高的架构。最近的服务升级，我们为Elasticsearch安装了HDFS Snapshot插件，可以定期将index备份到HDFS，这个功能目前主要用于备份Kibana的配置index，用以恢复用户查看或配置可视化界面时的错误操作。监控报警方面，System Level的监控报警（如硬盘满、损坏、服务器宕机）直接使用了在新浪内部提供了多年服务的sinawatch；App Level（如Elasticsearch JVM Heap Usage过高，Kibana能否正常访问，Kafka topic的consumer offset lag），我们开发了对应的监控报警脚本。User Level（如日志解析失败数量），主要通过elasticsearch python client执行query去统计或搜索。常见的报警是Logstash-filter-grok，logstash-filter-json解析日志失败会输出的JSON中添加_grokparserfailure、_jsonparsefailure，我们执行query判断解析错误的量。要说明的是，Marvel是Elasticsearch很好的监控工具和插件，但是它们是商业软件，我们没有采用。Marvel是基于Kibana做的，里面对一些重要指标（如index bulk reject number）的展示很有价值。二、增强易用性增强服务的易用性就是给用户更好的用户体验，减少用户的抱怨。ELK性能优化是一方面，但它是远远不够的，我们遇到的实际情况是，用户在其他方面抱怨更多，如下：（1）用户最先抱怨的是IP解析成地区、ISP信息一点都不准，完全没有参考意义。如对于CDN这种服务，我们解析用户IP不准，定位问题边缘节点错误，问题没法查，这是帮倒忙。原因：Logstash默认自带的IP库是国外maxmind公司的免费版本，中国的信息尤其不准。解决方案：使用我浪较新较全的IP库生成能适配maxmind geoip2 api的二进制格式IP库（maxmindDB），再开发logstash-filter-geoip2来解析IP。实测不仅IP解析准确率与公司IP库相同了，解析速度也提高了。（2）然后我们与用户都发现日志接入流程复杂，沟通困难。人做不到机器那样分毫不差，有啥说啥。接入用户日志的时候，例如常常因为用户对日志格式表达的不全面，模棱两可，导致日志解析失败，服务对接人多次重写配置。从用户提需求到用户可以看到数据可视化效果或搜到日志，需要几个小时到几天。一来二去，用户和我们都烦了，只能求变。为此，我们正在逐步实现用户数据接入的自动化，减少接入时间和沟通成本这个过程需要3个关键：A.用户配置日志格式的界面，尽可能简洁简单；B.根据用户配置自动生成logstash config、index管理需要的配置；C.自动部署配置（logstash config等），打通日志流。后来我们做了一个简单的用来协商日志格式的界面：目前我们已完成了A的一部分：用户日志格式配置界面；B的全部：开发了自动生成logstash conf的 python api；C即将开始，并且考虑使用Docker技术为我们提供一些便利。（3）部分数据可视化需求得不到满足，Kibana配置难度大。我们起初采用官方Kibana v3，用户提出的类似SQL中的多个group by，画百分比，求指定区间占比等常见需求无法满足。之后通过三斗大神(微博@argv)定制版的Kibana 3满足了一些用户需求。Kibana 4诞生后，代码几乎是对Kibana3的重写，做了大幅改进，通过Elasticsearch Aggregation的强大数据统计功能及灵活的配置从Kibana 3解放出来。近期我们将迁移到Kibana 4。三、提供新功能我们为Elasticsearch安装了国内medcl大神开发的ik中文分词插件elasticsearch-analysis-ik。之前被分词为『中』和『国』的中国，现在终于可以被当做一个完整的词汇，否则搜索『中国』、『美国』也会出现。微盘的一些离线搜索需求使用了我们的服务，也用到了中文分词，Elasticsearch的搜索天赋满足了他们的需求，减少了他们的痛苦。我们经历过的坑和坎儿（1）elasticsearch 进程JVM Heap High Usage( &90% )。很长一段时间，我们都在应对JVM Heap High Usage，他带了的问题是Old GC次数多，时间长，es节点频繁退出集群，整个集群几乎停止响应。现在我们的主要策略是开启doc_values；限制query执行时占用的JVM Heap size；analyzed string只允许做query，不允许facets或者aggs；定期close 用户不需要的index。（2） Elasticsearch Query DSL、Facets、Aggs学习困惑。有人为此开发了使用SQL执行ES Query的插件，一定程度上减轻了进入门槛。我们给出的学习他们的建议是观察Kibana的Request Body或试用Marvel的Senese插件，它有自动完成Query、Facets、Aggs的功能。另外最常用的query是query string query，最常用的aggs是Terms、Date Histogram，可以应付大部分需求。（3）logstash不工作。非官方的问题插件，及使用logstash-filter-ruby时未考虑到的异常等，导致Logstash运行时工作线程（worker thread）异常退出，Logstash僵死。我们的建议是尽可能不要在config中使用logstash-filter-ruby，尽量使用官方插件。不过我们也遇到过复杂的日志，写过250行+的config，用尽了ruby filter。当前未发现Logstash有好的成熟的监控方案，Logstash的内部状态也获取不到。我们目前通过间接的监控Kafka topic consumer是否落后或elasticsearch indexing rate来检验logstash的工作情况。（4）Kibana没有用户的概念，不同用户的数据无法隔离。多个用户共享的Kibana Dashboard，误操作或误删时常影响其他用户，保存的dashboard太多，找到特定的dashboard很困难。官方到目前为止，未在这方面做过改进。有很多非官方的改进，我们也曾经用过三斗大神定制的Kibana3，也对Kibana index做了snapshot储存到HDFS里面。（5）与用户沟通成本高。与我们的用户协商日志格式，数据可视化配置时，由于人的不确定性容易造成多次来回确定和修改，效率低下。我们毕竟是提供日志分析服务的，不给用户做日志运维，所以近期也在探索通过日志接入自动化、推荐用户提供给我们JSON格式数据，定期组织用户的Kibana培训来减少沟通成本。Q & A问：logstash连es出现timeout的情况有没?如何解决的?答：我们常见的是ES Jvm Heap Usage比较高的时候会timeout，如果是服务内存小换大内存。另外不要对analyzed的string做aggs、facets，开启doc_values。问：关于日志中异常报警的，有哪些方式？关键字过滤？答：对于日志解析失败的情况，logstash 常见的是_grokparsefailuer和_jsonparsefailure，数据写入es后，执行query查询这两个关键词的数量即可。对于报警方案，watch是官方刚出的，其实比它早的实现方案，如Yelp的elastalert。问：大数据分析平台（基于HDFS）跟kibana的展现会有很大区别吗？或者说最大的区别会在哪些方面？答：你说的区别，我理解是Hadoop与Elasticsearch的区别，一个是离线分析，以job为单位，一个是实时搜索和统计，以query为单位。这里有三个关键词：实时，搜索，统计。Hadoop是离线的，es是实时的；es本质上是一个搜引擎，可以用来做全文检索等工作，Hadoop显然于此无关。统计是Hadoop与es都能做的，我不了解Hadoop有没有像Kibana这样的数据可视化组件。问：你们的ES集群数据节点和查询节点做了分离吗？logstash是直接把数据写入查询节点还是数据节点？另外你们直接用的node模式还是transport模式呢？答：（1）还没有做分离。（2）我们还在用http protocol模式。本文来源：DockerOne关于21CTO社区是中国互联网第一技术人脉与社交平台。我们为国内最优秀的开发者提供社交、学习等产品，帮助企业快速对接开发者，包括人才招聘，项目研发，顾问咨询服务。看微信文章不过瘾，欢迎到网站看更多文章和分享。网站地址：投稿邮箱： QQ群：
（欢迎扫描下列二维码关注本微信号）　
　文章为作者独立观点，不代表微头条立场
的最新文章
导读：环境会影响一个人，但不会左右一个人。把什么责任都推到领导身上，领导也很难待见你。1领导不和我沟通，我就本文整理自知乎：有人提交了一个问题：从事互联网有几年时间，接触到的技术人员大多有以下问题：①、木讷、没礼貌；“这个网站相当简单，所有你需要做的就是完成X，Y，Z。你看起来应该是技术很好，所以，我相信，你不需要花费太多离散数学包括数理逻辑、集合论、图论和近世代数四个分支。这里我们介绍图论和互联网自动下载工具网络爬虫 (Web缘起：无线时代，网络稳定性差，应用流量敏感，APP与server之间每次HTTP请求都需要DNS解析，有没有视频时长：15分22秒编译：沪江留学小组 磐石猫这是凯文·斯拉文在TEDGloba上的一次精彩的演讲，他认为序php是一个很流行的脚本语言，现在很多公司（新浪、优酷、百度、搜狐、淘宝等等）在使用这种语言进行网站开发。“你的时间有限，所以不要为别人而活。不要被教条所限，不要活在别人的观念里。不要让别人的意见左右自己内心的声音腾讯技术大咖首次公开分享腾讯17年的技术布局、大数据、安全等核心技术，发布凝聚腾讯多年技术的腾讯云12款新品我在美国工作过、创业过，在中国工作过，创业过，在 freelancer 上发过外包接过外包，维护过开源项目，随着网络的高速发展，网络性能的持续提高成为能否在芸芸App中脱颖而出的关键。高度联结的世界意味着用户对网络体给各位的话如果您有两条路，一定要选择那条困难的。因为...还是看文章正文吧～最近，只要我想偷懒，躺在床上睡懒昨天和大家讨论了APP时代如何进行DNS速度优化，今天和各位一起讨论一下无线时代的日志上报流量优化。缘起：无稻盛和夫是世界著名的实业家，他在27岁创办了京都陶瓷株式会社（现名京瓷），52岁时又创办第二电信（目前日本仅对很多人而言，配置Nginx+PHP无外乎就是搜索一篇教程，然后拷贝粘贴。听上去似乎也没什么问题，可惜实际上他是非死不可（Facebook）的创始人，赤手空拳白手起家，掌管着2750亿美元，15亿用户、超过3500名为什么有的人条件不如你，却混得比你还好？小编觉得，条件只是成功的一个方面，也仅仅只是一个方面。小编曾经摔跤骨TokuDB·特性分析· Optimize Table本文说明一个物理升级导致的 "数据丢失"。现象在MyS导读：在中国，很多人认识孙正义是从认识马云开始的，其实这不公平。30年前，当孙正义开始创业时，其面对两个员工生活这东西，大多情况都是守恒的。如果你不劳而获了什么东西，大抵在某个时刻都会以别的形式还回去；如果你现在正在价值最大化是全世界绝大多数盈利企业的一个共同追求。销售利润率、净资产回报率、企业增长速度与价值息息相关。以提好的编程原则跟好的系统设计原则和技术实施原则有着密切的联系。下面的这些编程原则在过去的这些年里让我成为了一名来源：Spiegel全世界的知识都集中在一张数字化地图上，现实是计算机算法控制了美国股市70%的交易量，这并当你开始成为一个程序员的时候，在编程的时候很容易陷入下面所述的一些坏习惯。作为一名程序员，犯错误不可避免，这代码就是程序员的孩子，给“孩子”取个好听的名字很重要！我们在项目开发中，接触到的变量、函数、类多数都是项目自10月17日，傅盛登上颠覆式创新研习社讲台，主讲《从猎豹的经历谈颠覆式创新》，分享如何专注于纯移动、国际化、1.说话不要有攻击性，不要有杀伤力，不夸己能，不扬人恶，自然能化敌为友。2.一个常常看别人缺点的人，自己本身作为一个一年多的前端工程师，之前的前端老大离职后，自己就扛起了一些前端方面的事务。面试当然是最具挑战的事情了世界上没有一条法则说一个企业将永驻商界。相反，有一条法则是：人类所创造的所有事物的寿命都是有限的。很少有公司本文是翻译，版权归原作者所有原文地址（original source）：http://xion.io/pos10月5号，是乔帮主逝世4周年的日子。Tim Cook还发了一封邮件官僚式的缅怀了一下。当我们在缅怀乔帮主的狮子和老虎之间爆发了一场激烈的冲突，到最后，两败俱伤。狮子快要断气时，对老虎说：“如果不是你非要抢我的地盘，微信群里一程序员问：“正直的人在这个社会是不是不受待见？”然后描述了他的“正直”：“同事做得不好的地方当面指我发现了一篇很有意思的关于研究多个显示器与生产力的博客文章。去年一些开发人员，包括我自己，开始使用多个显示器来源：/post/what-i-tell-all-new-progra搜狐张朝阳最大的癖好是登山！这厮曾把5355米四姑娘山压在身下。巨人网络史玉柱史大神的特殊癖好：玩红酒！曾拿来源：《中国青年报》褚时健说，不少20多岁的年轻人跑来问我，“为啥事总做不成？”我说你们想简单了，总想找现成来源：张德芬（ID:tefenchangpublic）遇见未知的自己，活出生命无限可能如果钱和年龄都不是问题引言微博（Weibo）是一种通过关注机制分享简短实时信息的广播式社交网络平台。微博用户通过关注来订阅内容，在导读：比管理团队更为直接的命题是，如何管理自己？拿破仑、达芬奇、莫扎特这些伟人，都很善于自我管理。不过，他们1.真正的“精英程序员”不会分心于生活中的事情，如孩子和爱人。削减用于家庭琐事和交友的时间，尽量最大化编码时不管是工业界还是学术界，机器学习都是一个炙手可热的方向，但是学术界和工业界对机器学习的研究各有侧重，学术界侧人到中年，总在撕扯中前行。撕扯他们的，一边是入世的成功，一边是出世的向往。不过看着这些对比，总觉得离自己很近作者| Bruce Harpham译者| RK翔In our work oriented culture, 今天，我们要讲的重构方法为，提取方法（Extract Method）。这也是我最常用的重构方法之一。注：虽然we21cto是中国互联网界RD高端人脉与社交平台。主要会员为CTO、技术总监，技术专家，技术经理，高级研发工程师以及产品经理。本公众平台为为会员提供服务的帐号。热门文章最新文章we21cto是中国互联网界RD高端人脉与社交平台。主要会员为CTO、技术总监，技术专家，技术经理，高级研发工程师以及产品经理。本公众平台为为会员提供服务的帐号。}