3.6.1 设置SQL模式
MySQL Server中的许多操作特性可以通过设置SQL模式(SQL mode)来进行配置。模式包含了可选值，其每个值控制了查询处理的某个方面。经过恰当的设置，服务就能按指导对输入数据采取严格或宽容的处理，启用或禁用对SQL一致性有关的操作，或者提供对其它数据库更好的兼容性。这一节将讨论如何设置SQL模式。
默认情况下，SQL模式值为空值，因此没有特定的限制或一致性行为要求被启用。独立的客户端按他们自己的需要来配置SQL模式，不过也可以通过在服务启动时使用 --sql-mode项来设置默认的SQL模式。你可能在运行数据库时需要某个模式来更小心地处理无效数据或建立MySQL用户账号。例如，如果你启用TRADITIONAL模式，MySQL Server会如其它数据库一样对输入的数据进行强制约束，而不会采取宽容态度。它这种模式不会允许未设置密码的新账号被建立。你可以通过配置文件来启用TRADITIONAL SQL模式：
[mysqld]
sql-mode=TRADITIONAL
本文地址：https://www.askmac.cn/archives/mysql-configuration.html
除了通过命令行来进行MySQL参数项配置之外，你还可以将设置写入一个配置文件中来实现设置。标准的MySQL客户端程序会在启动时查找此类配置文件并使用文件中的相应设置项。通过写配置文件可以大大减少你运维工作时间，因为你不必在每次调用程序的时候通过命令来重新定义这些参数项。
默认情况下，MySQL server会在运行时使用其预编译的值作为其配置项值。如果这些默认值在实际环境中是不适合的，你可以在server运行时给予不同的运行时参数值：
--basedir参数设置告知服务正确的目录位置，否则服务无法启动。同样的，如果你并非使用安装目录下的data子目录作为你的数据存放目录的话，你就必须使用 –datadir项设置来告诉服务正确的位置。--skip-innodb项来节省内存(注意，由于现在InnoDB已成为标准配置，因此此参数在MySQL 5.7版本及其以后版本中被废用，这里仅作为例子进行说明)。你也可以设置默认存储引擎进行设置修改。--innodb_autoextend_increment, -- innodb_page_size等，这些值也可以根据你的情况进行调整。MongoDB世界2015在MongoDB 3.2版推出有趣的新功能，而对于其公司和社区的未来人们感到更加好奇
这周我在MongoDB的年度用户大会，MongoDB世界。在三月MongoDB 3.0的发布及其WiredTiger存储引擎轰动一时。现在，我们只剩下相对较小的新闻公告，以及对于公司未来及其周围的开源数据库的社区关系的更大问题。
但首先我们看这个消息。今年的头条定下了基准，说MongoDB的数据库比Couchbase和Cassandra更好（大概他们也能根据自己的基准说他们是更好的），而BI集成的东西已经可以从第三方供应商获取。
这个“大新闻”毫不奇怪是一个snoozer。毕竟，WiredTiger在四个月前刚出现。此外，MongoDB中已经有一个近乎完整的营业额管理，如果没有产品开发的牵引这是很难做到的。这就是说，有趣的新功能即将在MongoDB 3.2中出现：
本文地址：https://www.askmac.cn/archives/mongodb-how-big-data-explodes-old-databases.html
在这个新的世界，当我们需要做一些事情时，如在（相对）较短的时间内快速地建立新的大数据分析引擎，我们可以—因为有一种与生俱来的开放性和‘关注点分离’正改变着我们的技术拓扑.
有了MongoDB非模式化设计，用户能够带来多个新的大数据源，而不需要像以前一样去“准备它”。 这是关于创建一个环境，“数以千计的引擎”能够同时运用并行处理技术访问数据库…，当我们拥有正确的数据库拆分架构时，这已经成为可能。
对于这里的完整性，数据库拆分要将一个数据库分成更小的组件块， 我们称之为‘分片’（如破碎的玻璃）， 以至于我们能够将工作负荷通过一系列的分布式式服务器传播出去。你只需要知道什么时间开始分片是真确的。
介绍
我在MongoDB World 2015做的演讲“Putting the Go in MongoDB”，重点是关于MongoDB工具的重写，从C ++到Go，这在可用性以及性能方面得到了一些改进，但是这里我只简要的说两个方面的新功能，(planned for the 3.2 release) – 归档和压缩。
在本文中，我将对mongodump和mongorestore提供更详细的归档和压缩特性说明，并探索使用这些特性的可行用例。
概述
一个通常目的的归档一般由一个或多个文件组成。这样例子如磁带归档格式(tar)，其中包含按顺序组成的一个或多个文件。归档在执行进程间通信的应用程序中尤其有用，例如，你可以通过远程服务器进行目录的tarball压缩，然后通过SSH，传送到到本机上进行解压：
ssh source.server.com tar c sourceDirectory | tar x
由于归档以顺序的方式创建，接收端将能按顺序接收到发送端按顺序发来的数据。
在3.0中，我们增加了在MongoDB中并发执行备份和恢复多个集合的能力，这可以让你执行备份时，更加充分地利用磁盘I / O。 结果，写入mongodump的备份并不一定以顺序的方式接收。 同样，mongorestore同时读取还原操作集合，它的读取指令也并非是序列性的。
MongoDB3.0对WiredTiger存储引擎引入了压缩功能。在本文中，我们将观察不同选项，并举例说明这个功能如何运行。由于情况因人而异，所以我们鼓励你测试自己的数据和应用程序。
为什么需要压缩？
每个人都知道存储很便宜对吧？
但是，有可能你添加数据的速度比存储价格下降的速度来得更快，你花费在存储上的净支出实际上正在上升。你的内部成本也可能需要包括管理等因素，因此它们的价格可能会比商品市场价格高出很多。换句话说，你仍然需要寻求新的方式以减少您对存储的需求。
磁盘存储的大小是一个需要考虑的因素，当然还有其他需要考虑的。磁盘I/ O延迟是由在旋转存储上寻道时间为主导。通过降低数据的大小，用更少的磁盘寻道检索一定量的数据是必要的，这样磁盘I / O吞吐量将得到改善。对于RAM而言，一些压缩格式可以不用解压在内存中的数据。在这样的情况下，更多的数据可以放在RAM中，从而提高了性能。
“如果你光给我看代码而不让我了解数据结构，我会很迷茫。如果让我了解数据结构，我就明显不再需要经常查看你的代码了。” – 由Eric Raymond写于《The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary》，1997年
编程的基本任务是告诉计算机做某些事的方法。正因如此，许多在软件开发领域的创新是语言创新，这种创新在于使程序员能更简单有效地指示计算机的操作。
尽管计算机以二进制运行，然而我们并不会以这种方式与它们交流。每隔十年，更高级别编程语言不断出现，而程序员的自我表达能力也随之不断提高。这些创新中包括了对如何表达数据结构，以及如何表达算法的改进。
几乎所有的现代编程语言支持面向对象（OO），当我们用代码建立对象模型时，我们通常使用原始类型（整数，字符串等），数组和对象的组合。
虽然每一种语言处理细节的方式不同，嵌套对象结构的想法已经成为我们用来描述“东西”的通用语言。
我们用来持久化数据的数据结构却并没有以同样的速度发展改变。在过去30年，持久性数据的主要数据结构一直是表 – 一个由包含标量值（整数，字符串等等）列组成的行集合。这是一个关系型数据库的世界，从1980年开始流行，它的事务性，快速查询，空间使用效率，比同时代的其他数据库系统更佳，另外它还有一支强大的Oracle销售团队。
这面向对象代码建模方式和持久化数据(通过表)存储方式之间的不同，一直是困扰许多程序员的源头。数千年来人们都在改变数据形态的问题上，即在物理形式和关系形式之间转换投入了大量的努力。
一位我们曾帮助过的用户，最近又联系了我们，提出对于他们仪表系统构建NOSQL数据库的需求。
在过去的时间里，他们收集了大量重要的传感器数据，并将其存储在一个专用的Redis数据库内。 当他们为每个键收集一个值时，Redis的键值结构运作良好。然而，当一个新的错误检查需求出现，要求它们为每个数据点添加一个时间戳时，每个键要存储两个值， Redis运作就有些笨拙。这样做需要应用值域的人工分隔符或者使用两个Reids数据库，每个数据库都使用相同的键来检索与每个键相关联的独立值。
两者都是低成本或是无成本实现， 他们选择了分隔符的方法，运用 ‘::’ 作为分隔符。当然，他们知道不能像这样持续扩展键值范式， 因为新的数据记录需求出现了，但是运作良好。它几乎不需要改变任何现有的生产代码，只用足够的内存来存储附加的数据点。
他们还使用Rackspace的Redis服务，以检测他们的服务代码，同时继续为现有的数据存储写入实时数据。
他们联系到我们，让我们对他们将传感器数从276升级到8000（增加29X数据量）进行风险评估， 那时似乎已经决定向更复杂的NoSQL数据转移。
本文地址：https://www.askmac.cn/archives/nosql-real-world-mongodb-shutterfly.html
最近掀起的一波非关系数据库浪潮，也称“NoSQL”热潮，它引起了人们的热烈反映。大肆的宣传炒作下，真实情况到底如何就很难说了。人们的谈论很多，但在现实世界NoSQL到底有多牛逼？在这个系列中，我们将看到一些真实世界的NoSQL。
Shutterfly的是一种流行的，基于互联网的，照片共享和个人出版公司，管理着超过60亿图像的持久性存储，每秒的事务处理率高达10,000次操作。数据架构师Kenny Gorman接受了帮助Shutterfly的任务，选择并替换其现有的关系型数据库管理系统：Oracle的RDBMS。
最初，Shutterfly考虑过如MySQL和PostgreSQL的开源数据库。但是，在评估和重新架构应用程序的过程中，非关系型数据库似乎更符合Shutterfly的数据的需求，它有可能改善程序员的工作效率以及性能和可扩展性。“我们有过权衡，最后不得不说服自己，不太成熟的非事务性数据存储在这里也OK，” Gorman说。
本文地址：https://www.askmac.cn/archives/best-database.html
你并不需要我们告诉你现在市面上有多少种数据库系统软件。因此，当你在苦找下一个项目的参考，想要知道哪个数据库是最好的时候，那么这篇文章是一个很好的起点。
我们已经准备了一个入围名单，其中有我们的最爱- 这是一个对几个数据库的简单介绍;他们中的一些你可能听说过，一些可能没有。坐好了，祝你的研究一切顺利。
MySQL是数据库中一个家喻户晓的名字。它也有几个分支，旨在提高MySQL的某些方面，比如MariaDB或者Percona。
这是一个成熟的系统，伴随着当前的存储引擎InnoDB，它现在处理只读和以读为主的文件比之前的存储引擎MyISAM好了很多。但是，如果你开始处理巨量的数据，你也会被在InnoDB中的问题绊倒。幸运的是TokuDB可以提供一些帮助(www.askmac.cn)。
当涉及到关系数据库，PostgreSQL/Postgres也是一个很好的选择。 MySQL是比较流行的，但这主要是由于历史原因;PostgreSQL是比较容易上手的数据库。
Postgres的特别之处在于出色的可扩展性，所以如果你需要执行自定义程序，Postgres是一个不错的选择。这方面的一个例子是，它允许用户自定义函数不仅能用SQL还能用好几种语言编写。 Postgres也在NoSQL领域增加了一系列增强。通过Hstore你可以存储键值对，而无需离开Postgres。而在9.4版本中，你可以同时使用JSON和JSONB，这无疑挑战了一些NoSQL成员。这是PG在NoSQL功能上的一个突破。
TokuDB是一个MySQL，MariaDB和Percona均可用的存储引擎。在分析领域它可以替代InnoDB； TokuDB让人眼前一亮的是，它善于压缩数据。它一般比InnoDB节省了3倍的空间。 当数据集能装入内存，TokuDB的性能是和InnoDB一样的。但是，当数据变得太大，TokuDB仍能同样出色执行，而InnoDB的性能需要深入调优。
TokuDB和InnoDB之间的根本的不同在于，前者使用一个分形树数据结构，而后者使用B-树数据结构。总之，如果你的数据很大，你想要使用MySQL，你可能有兴趣考虑看看TokuDB。这些基准给了你TokuDB可以实现什么的提示(www.askmac.cn)。
MongoDB是面向文档的数据库，部分人表示对它的厌恶。但一个DBMS走红是总是有其原因的，即它的速度，灵活的架构和分片。为了实现MongoDB的优良性能，MongoDB的做法是不默认采用安全写入，在你了解它和并且它对你的应用可行的情况下，这是很好的。
开始使用MongoDB的门槛是低的，它的灵活架构让你能随时改变。随着3.0版的推出，有一些不错的性能改进，同时由于其新的存储引擎WiredTiger，也让数据库更接近ACID兼容。如果你要把它投入生产，确保你一定要做好功课，并不是所有的开发者都这么做(www.askmac.cn)。
