1.11 文档数据分析基本上意味着你得是一个“万事通”。我们使用各种广泛的编程语言和工具。（在我的脑子里，我工作中使用的编程/脚本语言有PHP、JavaScript、Python、R、C、C++、Go、三种SQL方言、PL/PGSQL和Bash。）不要期望你可以预先学习所有你需要的东西。干好工作经常依赖于阅读文档。一个有良好文档的工具更有用，它使得分析师更高产并且完成高质量的工作。 PostgreSQL的文档非常优秀。它涵盖了所欲的东西，但是又不只是一个参考手册，其中有很多例子、提示、有用的建议和指南。如果你是一个高级程序员并且想要真正的深入，你可以很容易的阅读PostgreSQL的源代码，所有这些都是开放的并且可以自由获取。这个文档也很有幽默感： 第一个世纪开始于公元0001-01-01 00:00:00 ，虽然当时他们并不知道。这个定义在所有使用公历的国家使用。没有世纪编号为0的，直接从-1世纪跳到了1世纪。如果你对此不赞同的话，请写下你的抱怨到这个地址：罗马教廷圣彼得大教堂教皇收。 MS SQL服务器的文档都在MSDN上，而且很不友好、庞大、烦乱。由于微软是个大企业，而且其客户基本很保守、缺乏幽默感，因此这样的文档就很“适合商务”-即啰啰嗦嗦、令人厌烦和枯燥。它不但在开发日期算法的时候没有参考天主教的历史，而且还异常乏味，藏匿在不必要的分类以及炫耀式的官方术语之下，难以理解。试试这个：进入MS SQL服务器2012的 产品文档页面，试试能从这里获取一些有用的信息。或者阅读下面摘录的部分（我承诺，绝不是精心挑选的）： 部分report定义就是XML格式的report定义文件的一部分。在可以通过创建report定义来创建部分report，然后在这个report里选择report项，把它们做为多个部分report单独进行发布。 是不是一开始就不知道“report"是究竟是什么？ 1.12.日志记录确实有用MS SQL服务器的日志分散在几个地方-错误日志、Windows事件日志、分析器日志、代理日志和安装日志。要实现对这些日志的访问，你还需要各种级别的权限，而且还需要使用多个工具，其中一些工具是只有图形用户界面下才可以运行的。也许像Splunk这样的软件能帮助你对这些日志进行自动收集和解析。我没有试过，我也不知道别人有没有试过。有关这个问题的谷歌搜索结果得到的信息少的让人吃惊，几乎没有什么用处。 默认情况下PostgreSQL的所有日志是存储在一个地方。你可以通过更改文本文件的几个设置，让数据库记录日志记录为CSV文件（由于我们现在正在讨论的是PostgreSQL，因此这儿的CSV是正常的，而不是非正常的）。你很容易设置日志级别为任何级别：由“不记录任何日志”到“全面记录分析和调试的输出”。日志文档甚至包含CSV格式的日志文件导入的目的表的DDL语句。你还可以把日志记录到标准错误或者系统日志或者Windows事件日志里（当然，假设你正在Windows系统上运行PostgreSQL)。 日志本身即是人可阅读的，也是机器可阅读的，而且包含的数据可能是系统管理员非常关注的。谁在什么地点，什么时间登入和退出？正在执行哪一条查询语句，是由谁来执行的？他们使用了多长时间？每一次批处理里提交了多少个查询？由于数据是以非常完善的CSV格式存储的，因此在R或者PostgreSQL自身或者Python的matplotlib或者其他你喜欢的软件里，对其进行可视化和分析都非常容易。像top,iotop和iostat这些Linux应用所提供的丰富的信息远超过日志提供的信息，因此你可以非常容易、可靠地使用你可能需要的所有服务器远端测控技术。 1.13支持PostgreSQL该如何赢得这一局呢？每个人都知道大型商业公司为昂贵的旗舰企业级产品提供难以置信的技术支持，而同时免费软件则一点也没有。 当然，这都是废话。商业产品当然为支持它们的人民提供支持，因为它们花了钱的。在满足SLA条款时他们总是做到最少。在我敲这篇文章时，我知道有几个IT专家正在等待一个主要硬件供应商来帮助它们解决一个 £40,000服务器的性能问题。它们已经和供应商谈了数周时间。应供应商的要求，他们花费时间和精力来运行扩展测试和基准测试。目前，供应商的脸上混合着无能、低效和淡漠。而那个£40,000服务器正坐在那非常非常慢的运行着，它的用户每周工作70小时以试图保持进度。
每一次都发生同样的事情：最终用户混合着血、汗水、泪水、Google和熬夜将问题解决。我从未见过供应商赶来救急并将一切都搞定。 那么PostgreSQL的支持是什么样的呢？有两次我向PostgreSQL邮件列表请求帮助，在24小时内我从 Tom Lane那收到了回复。花了点时间点开链接并阅读wiki，那哥们不只是PostgreSQL的首席开发者，还是一个知名得计算机程序员。没啥说的，他的建议就是好的建议。其中一次，我问了一个关于实现跨函数调用持久内存分配的最好方法的问题，Lane用我应该学习的PostgreSQL的特性回复了我，并且给我的问题提出解决方案，另外他就我的试验性解决方案（一个C静态变量）为什么是垃圾这个问题，给我列出了一份非常好的原因清单。这种支持你是买不到的，但是你可以从热情的开源开发者社区取得支持。(⊙o⊙)哦，我有没有提到那个数据库软件，还有那些来自于广受好评的程序员的充满帮助的忠告和建议总共花费了 £0.00？ 我说的支持, 是指技术上真正解决问题的支持. 有些人(一般都是那些没有过这些产品的) 一提到技术支持合同, 想到更多的是法律方面的问题 – 他们并不关心是不是会真的获得帮助. 纯粹就是想找人臭骂几句, 发泄一下. 我在这里有讨论. (如果你真的想花钱购买技术支持, PostgreSQL 有许多提供专业技术支持的机构可以选择. 跟那些以销售商业软件为主, 提供技术支持为辅的供应商不同. 这些机构提供技术支持的质量决定了他们的生死存亡. 所以这方面没什么好担心的.) 1.14灵活的，可脚本化的数据库转储我已经谈论过可脚本化，不过数据库转储是如此重要，所以他们在本文中占有一席之地。PostgreSQL的数据库转储特别灵活，采用命令行驱动方式（使得它很容易实现自动化和脚本化）并且记录良好（与PostgreSQL其他部分一样）。这使得数据库迁移、复制和备份这三种重要和吓人的任务可控、可靠和可配置。而且，备份可以以空间压缩的格式或者纯文本的SQL来处理完整的数据，两者都是人类可读并且可执行。可以备份单个表或整个数据库集群。用户可以按他喜欢的方式去做。只需要一点点工作和小心的选择几个选项，甚至可以生成一个仅有DDL纯文本的SQL语言的PostgreSQL备份，该备份可在不同的RDBMS中执行。 而MS SQL Server的备份则是以一个专有的、无记录的、不透明的二进制格式进行。 1.15可靠性无论是 PostgreSQL 还是 MS SQL Server 都不希望发生意外，不过MS SQL Server有一个奇怪的失败模式，我遇到过不止一次：它的事物日志变的巨大并且阻止了数据库正常工作。理论上日志可以被截断或删除，但是文档中对此类动作又充满了可怕的警告。 而PostgreSQL只是坐在那里并且将工作做好。在日常使用中我从来没有遇到过一次PostgreSQL数据库意外。 1.16 易于安装和更新这个有什么关系吗？当然有。基础设施的灵活性比以往任何时候都要重要，并且这个趋势只会继续下去。多年稳坐不动的胖服务器安装的日子已经一去不复返。现在全部都是关于快速、可靠、灵活的配置和跟上尖端技术。常言道，时间就是金钱。 我装过MS SQL Server几次。我已经记不清自己到底安装PostgreSQL多少次了，很可能最少有50次了。 安装MS SQL Server非常的慢。它需要下载大量数据（现在还有谁使用物理媒介进行安装？）而且臭长，只有死板的进度条说明这货还活着。如果你没有安装正确版本的.NET或者正确的Windows服务包的话，你有可能安装失败。这些都需要你的系统管理员找一整块时间来做。 安装PostgreSQL的canonical 方法是简单至只敲一条命令（从一个Linux仓库），就像这样：
这需要花费多长时间？我只是通过在云中运行一个廉价的虚拟机，然后用上面的命令安装PostgreSQL来进行测试。只花了 16秒。这是下载和安装的全部时间。 至于更新，任何软件支持的Linux repo是非常容易从repo更新补丁。因为repo很聪明，PostgreSQL不太臃肿，下载的更新和应用，都是小而快的，并且是有效的。 我不知道怎么样容易地让MS SQL Server更新。我知道，很多在生产中的MS SQL Server在某些组织的版本还是2008 R2... 1.17.构建软件捐赠模块貌似PostgreSQL这一大堆的设置还不够，它又弄了一堆叫做构建软件捐赠模块的扩展。里面有一些函数，类型以及对服务器核心设置元素不那么重要的的实用功能的库。有模糊串匹配，快速整形数组处理，外部数据库链接，密码，UUIO生成，树形数据类型和负载的库。还有一些模块甚至什么也不做，只是为了让开发者和高级用户开发自己的扩展和功能。 当然，这些扩展安装十分琐碎。比如安装fuzzystrmatch的扩展，需要这么做：
1.18. 自由与免费PostgreSQL 既自由又免费， 这两样都很重要。 首先，PostgreSQL 是个开源软件， 在授权方面很自由。也就是说，你可以随心所欲地使用和修改它。包括发布包含或基于它的软件。 不论何时， 何地， 想怎么用就怎么用。 免费包含两个重要方面。 首先， 如果你也像我一样，在大机构中就职，花公家的钱，就会牵扯到许多繁文缛节。各种繁杂手续的拖延， 耗尽精力和激情； 抵制了创新。其次， 由于 PostgreSQL 是免费的， 许多开发人员， 实验人员，黑客，学生， 发明家， 科学家等等 (基本上都是穷书生)都在使用。慢慢地发展成为一个强大的社区。来自这群精英们的支持和贡献不断增长。 结果越做越好， 创新能力越来越强， 各种问题的解决方案也越来越多。更多的时间和精力用来解决更重要的问题。 2. 反驳让我不解的是, 大家经常无视上面的论点和论据， 用一些错误的， 奇怪的， 甚至荒唐透顶的观点来反驳 PostgreSQL 。 比如： 2.1. 不是说大牌厂商更可靠么!绝对不是。这就好比说 "没人会因为购买 IBM 而被炒鱿鱼"。 搞笑的是, 如果你谷歌下， 就会发现，排在第一的是 Wikipedia 的这篇文章， 恐惧，不确定，怀疑 。 最搞的是, 里面第一个提到的就是微软。我发誓我没动过 Wikipedia 那篇文章，我看到的时候， 它就是这么写的。 在给客户提供服务的数据分析领域(client-serving data analytics)，容不下半点差错。如果你因为搞砸了一份工作而损害了自己的名声，别指望软件供应商能帮你挽回。如果被起诉， 倒是有可能从他们那里得到一些赔偿， 前提是， 他们确实有错。 MS SQL Server 在技术上倒是没有什么错。他们不过是发布了一件垃圾产品，然后坦白的在文档里告诉你，这件产品有多烂。它运行起来就像最初设计时期望的那样。 问题是它的设计本来就很烂。不能因为你挑选数据库的时候， 不够尽职尽责， 就去控告微软。 就算你成功地让供应商背上黑锅，已经搞砸的工作和愤怒的客户， 是不可逆转的。他们才不管是不是 MS SQL Server's 错误地把 UTF-16 当成 UCS-2 处理, 导致在进行子字符串处理的时候，代理对(surrogate pair) 被截断。结果无法识别引起错误的关键字(incriminating keyword)。轻者，他们依然想要分析结果(也许还要给他们些折扣)。严重的，他们说你做的东西不能用，直接不要了。当他们的文档没有半点歉意的告诉你，你的数据可能会被悄无声息的破坏掉，而你却把全部的希望都寄托在他们的数据库上。一旦出问题， 你觉得你能怪他们吗？ 降低风险的最好办法就是把事做对。优秀的工具能帮你轻松做到这一点。优秀的工具， 我指的是 PostgreSQL 啦。 |
