Let’s start out our tutorial and explanation of why you would need a database index by going through a very simple example. Suppose that we have a database table called Employee with three columns – Employee_Name, Employee_Age, and Employee_Address. Assume that the Employee table has thousands of rows.

Now, let’s say that we want to run a query to find all the details of any employees who are named ‘Jesus’? So, we decide to run a simple query like this:

SELECT * FROM Employee  WHERE Employee_Name = 'Jesus'  

What would happen without an index on the table?

Once we run that query, what exactly goes on behind the scenes to find employees who are named Jesus? Well, the database software would literally have to look at every single row in the Employee table to see if the Employee_Name for that row is ‘Jesus’. And, because we want every row with the name ‘Jesus’ inside it, we can not just stop looking once we find just one row with the name ‘Jesus’, because there could be other rows with the name Jesus. So, every row up until the last row must be searched – which means thousands of rows in this scenario will have to be examined by the database to find the rows with the name ‘Jesus’. This is what is called a full table scan.

How a database index can help performance

You might be thinking that doing a full table scan sounds inefficient for something so simple – shouldn’t software be smarter? It’s almost like looking through the entire table with the human eye – very slow and not at all sleek. But, as you probably guessed by the title of this article, this is where indexes can help a great deal. The whole point of having an index is to speed up search queries by essentially cutting down the number of records/rows in a table that need to be examined.

What is an index?

So, what is an index? Well, an index is a data structure (most commonly a B- tree) that stores the values for a specific column in a table. An index is created on a column of atable. So, the key points to remember are that an index consists of column values from one table, and that those values are stored in a data structure. The index is a data structure – remember that.

What kind of data structure is an index?

B- trees are the most commonly used data structures for indexes. The reason B- trees are the most popular data structure for indexes is due to the fact that they are time efficient – because look-ups, deletions, and insertions can all be done in logarithmic time. And, another major reason B- trees are more commonly used is because the data that is stored inside the B- tree can be sorted. The RDBMS typically determines which data structure is actually used for an index. But, in some scenarios with certain RDBMS’s, you can actually specify which data structure you want your database to use when you create the index itself.

How does a hash table index work?

Hash tables are another data structure that you may see being used as indexes – these indexes are commonly referred to as hash indexes. The reason hash indexes are used is because hash tables are extremely efficient when it comes to just looking up values. So, queries that compare for equality to a string can retrieve values very fast if they use a hash index. For instance, the query we discussed earlier (SELECT * FROM Employee WHERE Employee_Name = ‘Jesus’) could benefit from a hash index created on the Employee_Name column. The way a hash index would work is that the column value will be the key into the hash table and the actual value mapped to that key would just be a pointer to the row data in the table. Since a hash table is basically an associative array, a typical entry would look something like “Jesus => 0×28939″, where 0×28939 is a reference to the table row where Jesus is stored in memory. Looking up a value like “Jesus” in a hash table index and getting back a reference to the row in memory is obviously a lot faster than scanning the table to find all the rows with a value of “Jesus” in the Employee_Name column.

The disadvantages of a hash index

Hash tables are not sorted data structures, and there are many types of queries which hash indexes can not even help with. For instance, suppose you want to find out all of the employees who are less than 40 years old. How could you do that with a hash table index? Well, it’s not possible because a hash table is only good for looking up key value pairs – which means queries that check for equality (like “WHERE name = ‘Jesus’”). What is implied in the key value mapping in a hash table is the concept that the keys of a hash table are not sorted or stored in any particular order. This is why hash indexes are usually not the default type of data structure used by database indexes – because they aren’t as flexible as B- trees when used as the index data structure. Also see: Binary trees versus Hash Tables.

What are some other types of indexes?

Indexes that use a R- tree data structure are commonly used to help with spatial problems. For instance, a query like “Find all of the Starbucks within 2 kilometers of me” would be the type of query that could show enhanced performance if the database table uses a R- tree index.

Another type of index is a bitmap index, which work well on columns that contain Boolean values (like true and false), but many instances of those values – basically columns with low selectivity.

How does an index improve performance?

Because an index is basically a data structure that is used to store column values, looking up those values becomes much faster. And, if an index is using the most commonly used data structure type – a B- tree – then the data structure is alsosorted. Having the column values be sorted can be a major performance enhancement – read on to find out why.

Let’s say that we create a B- tree index on the Employee_Name column This means that when we search for employees named “Jesus” using the SQL we showed earlier, then the entire Employee table does not have to be searched to find employees named “Jesus”. Instead, the database will use the index to find employees named Jesus, because the index will presumably be sorted alphabetically by the Employee’s name. And, because it is sorted, it means searching for a name is a lot faster because all names starting with a “J” will be right next to each other in the index! It’s also important to note that the index also stores pointers to the table row so that other column values can be retrieved – read on for more details on that.

What exactly is inside a database index?

So, now you know that a database index is created on a column in a table, and that the index stores the values in that specific column. But, it is important to understand that a database index does not store the values in the other columns of the same table. For example, if we create an index on the Employee_Name column, this means that the Employee_Age and Employee_Address column values are not also stored in the index. If we did just store all the other columns in the index, then it would be just like creating another copy of the entire table – which would take up way too much space and would be very inefficient.

An index also stores a pointer to the table row

So, the question is if the value that we are looking for is found in an index (like ‘Jesus’) , how does it find the other values that are in the same row (like the address of Jesus and his age)? Well, it’s quite simple – database indexes also store pointers to the corresponding rows in the table. A pointer is just a reference to a place in memory where the row data is stored on disk. So, in addition to the column value that is stored in the index, a pointer to the row in the table where that value lives is also stored in the index. This means that one of the values (or nodes) in the index for an Employee_Name could be something like (“Jesus”, 0×82829), where 0×82829 is the address on disk (the pointer) where the row data for “Jesus” is stored. Without that pointer all you would have is a single value, which would be meaningless because you would not be able to retrieve the other values in the same row – like the address and the age of an employee.

How does a database know when to use an index?

When a query like “SELECT * FROM Employee WHERE Employee_Name = ‘Jesus’ ” is run, the database will check to see if there is an index on the column(s) being queried. Assuming the Employee_Name column does have an index created on it, the database will have to decide whether it actually makes sense to use the index to find the values being searched – because there are some scenarios where it is actually less efficient to use the database index, and more efficient just to scan the entire table. Read this article to understand more about those scenarios: Selectivity in SQL.

Can you force the database to use an index on a query?

Generally, you will not tell the database when to actually use an index – that decision will be made by the database itself. Although it is worth noting that in most databases (like Oracle and MySQL), you can actually specify that you want the index to be used.

How to create an index in SQL:

Here’s what the actual SQL would look like to create an index on the Employee_Name column from our example earlier:CREATE INDEX name_index ON Employee (Employee_Name) 

How to create a multi-column index in SQL:

We could also create an index on two of the columns in the Employee table , as shown in this SQL:CREATE INDEX name_index ON Employee (Employee_Name, Employee_Age)

What is a good analogy for a database index?

A very good analogy is to think of a database index as an index in a book. If you have a book about dogs and you are looking for the section on Golden Retrievers, then why would you flip through the entire book – which is the equivalent of a full table scan in database terminology – when you can just go to the index at the back of the book, which will tell you the exact pages where you can find information on Golden Retrievers. Similarly, as a book index contains a page number, a database index contains a pointer to the row containing the value that you are searching for in your SQL.

What is the cost of having a database index?

So, what are some of the disadvantages of having a database index? Well, for one thing it takes up space – and the larger your table, the larger your index. Another performance hit with indexes is the fact that whenever you add, delete, or update rows in the corresponding table, the same operations will have to be done to your index. Remember that an index needs to contain the same up to the minute data as whatever is in the table column(s) that the index covers.

As a general rule, an index should only be created on a table if the data in the indexed column will be queried frequently.

大数据时代，数据过剩，人才短缺，越来越多的IT专业人士希望能够进入充满机遇的大数据领域，但是，到底哪些具体的大数据专业岗位和人才最为吃香呢？人力资源公司Kforce近日发布了一份报告根据IT职业薪酬水平给出了2014年最热门的十大大数据工作职位（年薪）：

一、ETL开发者（11-13万美元）
随着数据种类的不断增加，企业对数据整合专业人才的需求越来越旺盛。ETL开发者与不同的数据来源和组织打交道，从不同的源头抽取数据，转换并导入数据仓库以满足企业的需要。

ETL软件行业相对成熟，相关岗位的工作生命周期比较长，通常由内部员工和外包合同商之间通力完成。ETL人才在大数据时代炙手可热的原因之一是：在企业大数据应用的早期阶段，Hadoop只是穷人的ETL。

二、Hadoop开发者（15-17.5万美元）
Hadoop是基于Java的开源框架，随着数据集规模不断增大，而传统BI的数据处理成本过高，企业对Hadoop及相关的廉价数据处理技术如Hive、HBase、MapReduce、Pig等的需求将持续增长。如今具备Hadoop框架经验的技术人员是最抢手的大数据人才。

三、大数据可视化工具开发者（15-17.5万美元）
海量数据的分析是个大挑战，而新型数据可视化工具如Spotifre，Qlikview和Tableau可以直观高效地展示数据。过去，数据可视化属于商业智能开发者类别，但是随着Hadoop的崛起，数据可视化已经成了一项独立的专业技能和岗位。

四、数据科学家（12-14万美元）
过去也称数据架构师，数据科学家是一个全新的工种，能够将企业的数据和技术转化为企业的商业价值。数据科学家首先应当具备优秀的沟通技能，能够同时将数据分析结果解释给IT部门和业务部门领导。

总的来说，数据科学家是分析师、艺术家的合体，需要具备多种交叉科学和商业技能。

五、OLAP开发者（9.8-11.6万美元）
OLAP在线联机分析开发者，负责将数据从关系型或非关系型数据源中抽取出来建立模型，然后创建数据访问的用户界面，提供高性能的预定义查询功能。

六、数据仓库一体机专家（9.8-12.4万美元）
此类专家熟悉Teradata、Neteeza和Exadata等公司的大数据一体机。能够在这些一体机上完成数据集成、管理和性能优化等工作。

七、预测分析开发者（10-13万美元）
营销部门经常使用预测分析预测用户行为或锁定目标用户。预测分析开发者有些场景看上有有些类似数据科学家，即在企业历史数据的基础上通过假设来测试阈值并预测未来的表现。

八、信息架构师（11.4-13.5万美元）
大数据重新激发了主数据管理的热潮。充分开发利用企业数据并支持决策需要非常专业的技能。信息架构师必须了解如何定义和存档关键元素，确保以最有效的方式进行数据管理和利用。信息架构师的关键技能包括主数据管理、业务知识和数据建模等。

“大数据”是在2013年被用滥了的词汇，但实际上，由于数据量缺失、大数据清洗和分析能力不足，以及数据可视化瓶颈等问题，“大数据”一直未能迟迟落地。伴随着基础设施的发展，意味着大数据的发展又走到新的一个新的临界点。系统软件供应商Software AG的Gagan Mehra，在Venturebeat网站阐述了他对于大数据接下来发展的认识，他认为更快地数据处理、更可靠的数据质量，以及更加细分的应用市场，是大数据2.0时代的重要特征。

更快的数据处理速度

由于数据量指数型增长，使得对于数据的快速分析的需要已经变得比以往任何时候都要迫切。几乎每家大数据厂商，都想要兜售比别家处理速度更快的产品。Hadoop发布的新品Hadoop 2.0 / YARN，几乎能实时分析数据。而下一代大数据的计算牵引框架Apache Spark，它的速度比Hadoop快100倍。硅谷风险投资机构Andreessen Horowitz，已经以1400万美元的价格，领投了一家以Apache Spark为业务核心的初创企业Databricks。不久前，亚马逊也上线了实时流数据服务Kinesis，来帮助没有数据处理能力的公司解决这一问题。

许多分析供应商都已经认识到了数据处理速度的重要性，并建立了能够每秒处理TB数据的产品。传感器数据分析、物联网在工业和消费级市场快速发展的势头，驱动了这次变革。比如一家企业的传感器，能够每秒产生出数百次的事件，实时处理这些数据难度很高。特别是当实时处理的传感器数据，激增到一天5TB的时候，速度，就成了尤为关键的指标。

同时，尽管数据存储成本已经累年下降，但数据存储的费用还是不小的一笔支出。部分商家相比存储完整数据流而言，更倾向于保存过滤掉噪音的数据。

智能清洗“垃圾数据”

在本就难以计数的数据量继续以指数模型激增时，对于数据质量的强化，便摆上了许多数据供应商的议程。换句话说，在庞大数据面前，即使计算机能够高效的处理它们，但大量无用的“垃圾”数据，只会给系统带来负担，并增添存储、主机等设备成本。这就需要数据处理过程中，根据特定的规则和参数，对涌进数据流进行“清洗”和分析，并自动决策该去处理哪些数据，这一切不再需要人工去干预。

在这样的环境下，如果选择了一个坏的数据，就会像病毒一样，可能引发连续的错误决策，甚至让企业蒙受经济损失。一个例子就是利用算法去进行股票交易，以毫秒计数股票市场中，任何一点小的差错，都有可能引发无法巨大的损失。

所以，数据质量已成为服务级别协议（service level agreements）最重要的参数之一。无法屏蔽劣质的数据的供应商，会因此被列入行业的黑名单，以及面临严重的经济处罚。B2B行业为早期数据质量的入局者，他们非常重视数据的质量，来保持商业运作时的稳定性。甚至，许多企业计划为数据质量部署实时的警告系统，这些警告会被发送于负责相应问题的专员，由他们提供问题的解决方案。

机器学习是另一项需要保证数据质量的领域。机器学习系统部署在一个闭环的生态中，通过模式分析与其他的数据分析技术，细化原来的数据质量规则。而高质量的数据，能够保证机器进行正确的行为模式分析。

越来越多的基础应用

大数据带来的变革，使得每一个人都想要利用它，但技术上门槛又让许多人不得已只能充当一个看客。而应用将有助于人们去克服这一困难。在接下来的几年中，我们将会看到成千上万的解决某一垂直领域的专业应用，以应对来自各行各业的大数据挑战。

目前，已经小有成就的数据分析公司包括eHarmony、 Roambi、 Climate Corporation等等。未来，甚至许多小企业，既不用依赖特定基础设备，也不要雇佣专业的数据科学家，就能受益于对大数据分析利用。

比如，一些应用将从各种渠道，收集关联的客户数据，以更好地了解客户的需求。从而企业能够为特定的目标客户，提供特定需求的产品，更有针对性地赚到钱。当这些应用走进人们日常的吃喝玩乐、医疗保健等领域，生活也会因此而更美好。

【CNW.com.cn独家译稿】在过去三年，Hadoop生态系统已经大范围扩展，很多主要IT供应商都推出了Hadoop连接器，以增强Hadoop的顶层架构或是供应商自己使用的Hadoop发行版。鉴于Hadoop的部署率呈指数级的增长，以及其生态系统不断地深入而广泛地发展，我们很想知道Hadoop的崛起是否会导致传统数据仓库解决方案的终结呢。

我们也可以将这个问题放到一个更大的环境中去讨论：在何种程度上，大数据会改变传统数据分析的环境?

数据仓库是技术和软件套件，它能够从操作系统收集数据，并将这些数据整合，并统一到中央数据库中，然后对数据仪表盘上指标进行分析、可视化和追踪关键性能处理。

数据仓库和Hadoop之间的主要区别是：数据仓库通常部署在单个关系数据库中，而这个数据库则起到中央存储的作用。相比之下，Hadoop及其Hadoop文件系统是跨多个机器，并用来处理海量数据的，而这是任何单台机器都达不到的能力。

此外，Hadoop生态系统包括构建在Hadoop核心之上的数据仓库层/服务，而Hadoop上层服务包括SQL(Presto)、SQL-Like(Hive)和NoSQL(Hbase)类型的数据存储。相比之下，在过去的十年中，大型数据仓库转移到使用自定义多处理器设备来扩展数据量，像Netezza(被IBM收购)和Teradata所提供的数据仓库。然而，这些设备都非常昂贵，大多数中小企业都负担不起。

在这种背景下，我们很自然地要问：Hadoop是否是数据仓库的终结者?

为了回答这个问题，我们需要将数据仓库技术与数据仓库部署分开来看。Hadoop(和NoSQL数据库的出现)将预示着数据仓库设备和传统数据仓库单一数据库部署的消亡。

而在这方面就有过实例。Hadoop供应商Cloudera将其平台作为“企业数据枢纽”，这在本质上将传统数据管理解决方案的纳入了需求。ReadWrite.com在最近发表的一篇题为“为什么专有大数据技术没有希望与Hadoop竞争”的文章中也发表了类似的看法。同样地，最近一篇华尔街日报文章描述了Hadoop如何挑战甲骨文和Teradata。

Hadoop或NoSQL生态系统仍将继续发展。很多大数据环境开始选择NoSQL、SQL甚至是NewSQL数据仓库的混合方法。此外，MapReduce并行处理引擎也有变化和改进，例如Apache的Spark项目。虽然这个故事还远远没有结束，但可以说，传统的单一服务器关系型数据库或数据库设备并不是大数据或数据仓储的未来。

另一方面，数据仓库技术(包括提取—转换—和—加载、三维建模和商业智能)将会应用到新的Hadoop/NoSQL环境。此外，这些技术也将变身来支持更多的混合环境。主要原则是因为并不是所有数据都是平等的，所以IT经理们应该选择数据存储和访问机制来适应数据的使用。混合环境将包括关键价值存储、关系型数据库、图形存储、文档存储、柱状存储、XML数据库、元数据目录等等。

正如你所看到的，这并不是一个简单的问题，也不可能简单地得出一个答案。然而，一般情况下，虽然大数据在未来五年内将会改变数据仓库的部署，但它不会导致数据仓库的概念和做法过时。

对于向数据仓库投入巨资的联邦政府这意味着什么呢?

首先，当现有数据仓库的容量不够时，数据仓库将被转移到基于Hadoop、多机器或云托管的解决方案。其次，企业并不会选择“放之四海而皆准”的做法，而会将目光转向适合其企业内部数据容量的混合存储方法。（邹铮编译）

市场研究公司IDC预测，2015年大数据市场规模将从2010年的32亿美元增长到170亿美元，复合年增长率为40%。大数据是一个庞大的新的领域，其中的数据集可以增长的非常庞大，以至于使用传统的数据库管理工具也很难处理。处理这种问题所需要的新工具、框架、硬件、软件和服务是一个巨大的市场机会。随着企业用户越来越多地需要连续不断地访问数据，好的大数据工具集将以最低的成本和接近实时的速度提供可伸缩的、高性能的分析。通过分析这种数据，企业可得到更大的智能以及竞争优势。下面是Hadoop和大数据专业厂商MapR共同创始人和首席执行官约翰·施罗德（John Schroeder）对2014大数据市场的预测。

1. SQL拥有大数据的最大潜力

用于 Hadoop（分布式计算）的SQL的发展能够让商业分析师利用自己的技能和选择的SQL工具执行大数据项目。开发人员可以选择Hive、Drill和 Impala等Apache项目，以及选择Hadapt、HAWQ和Splice Machine等公司的专有技术。

2. 尽管如此 SQL还面临挑战

SQL需要数据结构。而集中的结构化数据可引起延迟并且需要人工管理。SQL还限制分析类型。过分强调SQL将延迟机构全面利用其数据价值的努力和延迟反应。

3. 身份识别是主要的数据安全问题

随着Hadoop（分布式计算）中提供的接入控制能力的猛烈攻击，机构迅速认识到线路级身份识别是必要的基础。没有充分的身份识别，任何更高级的控制都很容易被绕过，妨碍预定的安全计划。

4. 数据错误变成学习机会

2014年机构将出现许多数据错误。数据错误将表明基础的来源系统的问题吗？数据错误是在下游分析中出现偏差导致的数据提取问题吗？数据错误将表明定义差异或者缺少跨部门和业务部门的一致性吗？2014年将看到解决数据异常问题。

5. 出现可运行的Hadoop

2014年将看到Hadoop在各个行业中的生产部署显著增加。这将显示出Hadoop在运营中的实力。在那里，生产应用与分析结合在一起能够提供可以衡量的商业优势，如在客户化零售建议、诈骗检测和试验传感器数据进行规范的维护等应用中提供这些优势。

6. 更多的数据仓库将部署企业数据中心

数据中心把数据提取处理和数据从企业数据仓库卸载到Hadoop。作为一个核心的中心企业中心，数据中心要便宜10倍，能够对额外的处理或者新的应用进行更多的分析。

7. 新的以数据为中心的应用将成为强制性的

利用大数据的能力将在2014年成为竞争的武器。更多的公司将使用大数据和Hadoop准确地针对个人消费者的偏爱追逐赚钱的追加销售和交叉销售的机会，更好地缓解风险以及减少生产和开销成本。

8. 数据成为数据中心的核心

机构将从开发者过渡到大数据计划中。IT部门将越来越多地担负定义支持多种应用的数据基础设施的任务，把重点集中在部署、处理和保护一个机构的核心资产所需要的基础设施方面。

9. 搜索将成为非结构化的查询语言

2013年有大量的用于Hadoop的SQL计划。2014年将是这种非结构化查询语言成为重点的一年。把搜索集成到Hadoop将为查找重要信息的企业用户提供一种简单和直观的方法。搜索引擎还是包括推荐引擎在内的许多发现和分析应用的核心。

10. Hadoop将获得地位

Hadoop将继续取代其它IT开支，颠覆企业数据仓库和企业存储。例如，甲骨文的主要营收目标在过去的10个季度里有5个季度没有实现。Teradata在过去的5个季度有4个季度没有实现营收和利润目标。

11. Hadoop仍需要帮助才能成为主流应用

更多的机构认识到Apache Hadoop本身还没有准备好在企业应用。Apache Hadoop不是为系统管理或者灾难恢复等统一企业IT流程设计的。企业将继续推进混合的解决方案，把架构技术创新与Apache Hadoop的开源软件结合在一起。

当下，“大数据”已成为2013年最火的技术词汇之一；而在过去一年，这个市场的增速和改变也不可谓不大。同时，我们还看到了Hadoop及其生态系统的使用门槛从顶尖技术人才到数据科学家的改变。越来越多的企业拥抱大数据技术，并将其运用到生产环境中。那么，在2014年大数据的发展趋势又会如何，这里不妨看一下来自CIO的12项预测：

1. 人们不再止步于大数据的谈论 

2014年，大数据止于说的情况将发生改变，人们将致力于从中获益，所有大数据的炒作也将“烟消云散”。从Gainsight了解到，大数据本身也将成为桌面上的筹码，Gainsight在其IaaS平台中利用大数据分析被其称之为“customer success management”的服务。Gainsight认为，在2014年，每家云应用程序提供商都将会让其后端基础设施支持大数据。

2. Hadoop将成为企业的关键组件
Hadoop将普及，大数据也不会再继续止步于云服务。Alteryx认为，2014年，Hadoop的适用场景将超越批处理和存储，将成为企业数据架构中通用的核心组件，这意味着数据分析将继续成为大数据的首要用例。

3. 企业将更加钟情于用户数据
从Gainsight了解到，各个机构将对用户数据充满热情，企业将充分利用客户与其在线产品或服务交互产生的数据，并从中获取价值。为了实现这点，数据分析能力将比BI团队更受重视，为企业提供更多的价值。

4. 大数据玩转市场决策
Alteryx认为，在2014年，大数据将首次正式登陆市场营销，用于市场营销的大数据技术将在这一年扮演重要角色——影响着广告、产品推销和消费者行为，World Cup及Winter Olympics将是其最大的舞台。

5. 海量的数据将超越数据科学家的意识
lteryx认为，新型的数据分析需求将超越人力可为，有些情况下大数据技术将堪比成千上万的数据科学家。该公司预测，这将会毫无疑问的拉低数据科学家薪酬。

6. 物联网将进军网络
IEEE的专业协会认为，2014年，可识别事物将无缝的连接到信息网络，实现真正意义上的Web of Things。The Web of Things将会充分利用移动设备和传感器的监控能力，增强现实世界中的物体与Web副本之间的协同性。

The Web of Things将会生成大量与现实世界相关的数据，因而会需求智能化的解决方案在现实世界与相对应的数字世界资源之间赋予连接性、网际互连和相关性。

7. 从大数据到海量数据
数据的体积、速度和类型（volume、velocity和variety）在2014年将会继续呈指数级增长，因此需要更简单的分析工具来驾驭这些“数据洪流”。

IEEE称，“不止是3个V让大数据成了非常难以制服的老虎，数据科学家及行业所需简单工具也是个难题，许多行业尚无独立提取数据价值的能力。当前已出现的海量数据时代更需求数据管理和分析上新的范式和实践。2014年，这个领域将上演群雄争霸。”

8. R语言将取代传统SAS解决方案
Alteryx认为，基于R编程语言的分析将数据科学家“御用”模式，这种分析在2014年将成为主流，将替代传统的SAS及SPSS模式。Alteryx说道：“超过200万用户和300万的分析师都在寻找更好的解决方案，R恰逢其时。”

9. Hadoop将增加实时特性
SQL-on-Hadoop供应商Splice Machine共同创始人兼CEO Monte Zweben指出，未来1年建立在Hadoop平台上的交互式应用程序将呈爆发式增长，其中包括Web应用、移动应用和社交应用，人们可以与之进行实时的交互。

Zweben说道：“2014将带来实时大数据应用程序平台，企业将不会只能像当下一样分析历史数据，你将有能力分析5分钟，甚至是1分钟之内的数据；企业将拥有交互式应用程序，以便实时的制定决策。”

10. Hadoop将得到企业级强化
Splice Machine的Zweben说：“毋庸置疑，Hadoop是个了不起的平台，但是仍然有许多工作要做。”

他认为，在2014，你将看到Hadoop向安全、运营管理、资源管理及多站点响应方向发展。Zweben补充道：“你将看到所有的企业级需求，我认为这些将是未来主要的焦点。”

11.  2014年底，至少有一家NoSQL IPO
大数据及云环境安全解决方案Gazzang董事长兼CEO Larry Warnock预测，在2014，至少有一家Hadoop或者NoSQL供应商会IPO，这标志着大数据平台已被广泛认可。

Warnock说道：“我不会去预测哪家会IPO，但是至少会有一家Hadoop或NoSQL供应商IPO。通过Wikibon了解到，在2012年，NoSQL软件和服务创造了2.86亿美元的税收，而在2017年，这个数据被预测为18.25亿。商场被不断增长的企业需求推动，他们需要灵活、可扩展及负担得起的数据管理解决方案，为新时代的云及大数据设计。”

12. 一个新的分析堆栈将诞生
Alteryx 预测，2014年，将出现一个新的数据及分析堆栈，为数据库、分析、可视化提供新的解决方案，这将直接威胁到传统的供应商巨头，而这些供应商也会在匆忙中推出新的解决方案。

下面还是根据学习，对现在比较热门的MangoDB和Memcached以及Redis做个简单的学习：

MangoDB是(document database, 硬盘型)
a. 基于磁盘的数据库，只是缓存热点数据在内存中。
b. 文档型的非关系型数据库，
    优势是查询功能强大，可存储海量数据。
c. 可替换MySQL等关系型数据库;
    在内存足够的情况下，读写性能不错，可省去Cache这一层

Memcached和Redis是(key value store, 内存型)
a.内存型数据库，数据保存在内存中，通过TCP直接存取； 或者说是全内存Cache。
   优势是速度快，并发高，缺点是数据类型有限，查询功能不强，一般做缓存。
b. Key Value Store
c. 全内存

Memcached vs Redis
a. 都是Key Vale, Memory Cache
b. Memecahced是 multiple-thread; 适合多核CPU的应用。
    Redis是 single-thread.
    如果再多数据结构基础上支持多线程，加锁可能是个问题（待深入学习验证）。
c. Redis具有持久化机制，可以定期将内存的数据持久化到硬盘上
d. Redis支持的数据类型更多
e. Redis 具备binlog功能，将所有操作写入日志，以便redis出现故障时，可通过binlog进行恢复。
f. Redis支持Virtual Memory，可限定内存大小，当数据超出阀值，就通过类似LRU的算法将最不常用的数据保存到硬盘的页面问题中。

If you want to give your user all read permissions, you could use:

EXEC sp_addrolemember N'db_datareader', N'your-user-name'

That adds the default db_datareader role (read permission on all tables) to that user.

There's also a db_datawriter role - which gives your user all WRITE permissions (INSERT, UPDATE, DELETE) on all tables:

EXEC sp_addrolemember N'db_datawriter', N'your-user-name'

If you need to be more granular, you can use the GRANT command:

GRANT SELECT, INSERT, UPDATE ON dbo.YourTable TO YourUserName
GRANT SELECT, INSERT ON dbo.YourTable2 TO YourUserName
GRANT SELECT, DELETE ON dbo.YourTable3 TO YourUserName

and so forth - you can granularly give SELECT, INSERT, UPDATE, DELETE permission on specific tables. 

by me:

If you want to give your user permissions to execute a procedure, you could use:

GRANT EXECUTE ON OBJECT::dbo.your_procedure_name TO N'your-user-name';

below is a full step to create a user db_user, and give him permissions to execute a procedure to a table db_tableABC and a procedureproc_get_price_data; assuming the user's loginName is your_user_login_name

--add a db engine login

IF NOT EXISTS(SELECT name FROM sys.server_principals WHERE name='{your_domain\}your_user_login_name')
CREATE LOGIN [{your_domain\}your_user_login_name] WITH PASSWORD='your_user_password', DEFAULT_DATABASE = TestDB;

--add a user to current database
use TestDB;
IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name='db_user')
CREATE USER [db_user] FOR LOGIN [{your_domain\}your_user_login_name];

--grant
GRANT INSERT, UPDATE, SELECT, DELETE ON dbo.db_tableABC TO your_user;
GRANT EXECUTE ON OBJECT::dbo.proc_get_price_data TO your_user;

e.g.
assuming a user named domain123\admin1 can access a database;

IF EXISTS(SELECT name FROM sys.server_principals WHERE name = '[domain123\admin1]')
BEGIN   
   IF NOT EXISTS (SELECT * FROM sys.database_principals WHERE name = 'admin1')        
   BEGIN             
        CREATE USER [admin1] FOR LOGIN [domain123\admin1];                   
   END
   GRANT INSERT, UPDATE, SELECT, DELETE ON dbo.db_tableABC TO admin1;  
   GRANT EXECUTE ON OBJECT::dbo.GET_PRICE_DATA TO admin1;
END

Migration between MySQLs

1)      Migration between character set : utf8

Amend my.ini (2 positions)

default-character-set=latin1

=>

default-character-set=utf8

2)      Migration between character set : origin is utf8 ==> the destination is latin1

Alter destination:

• alter database [db_name] default character set utf8;
• alter table [table_name] default character set utf8;
•  alter table [table_name] change [field_name] [field_name] [filed type] varchar(45) character set utf8;
• example

users(id, user_name)

alter table users  change user_name user_name varchar(45) character set utf8;

3)      Migration between character set : origin is latin1 ==> the destination is utf8

If the origin is latin1, cannot insert Chinese Character.