12.7 数据仓库课

单条数据的读写速度:

并发: 系统同时服务尽可能多的用户  系统级别架构级别 很多数据的并发“读"和”写“

eg. 双十一 很多用户在网上的记录保存下来

--跑批，减少系统硬盘读写次数  （A：分100次往硬盘里写记录   B：分10次往硬盘里写记录、每次写10条）

好处：不改变架构的基础上，

坏处：拼的数据多 ，延迟写增多，（余额在数据库里，消费了300，内存记录扣了300，但余额那里还未扣除，）

database 成为系统的瓶颈：

--很多query要到数据库执行

--application server 并发向数据库发出请求

--挑选性能更好的database server（减少数据io的开销、好的硬件、in-memeory的database 如sap的hana）

--数据库拆分成不同的固件、每个对于不同的application server（上海的数据application serverA、北京的数据在application serverB）

好处：用户知道要访问上海的数据，就去访问A，数据块小

缺点：用户可能要同时访问上海和北京的数据，

美丽说：

--长字符串、图片、视频不适合放在数据库，这些应该放入文件系统。

--适合的（结构型数据）放到数据库的放入Mysql，不适合的（非结构型数据）放到mooseFS文件系统里，Mysql里要有对应的文件路径。

缺点：

--moose FS会把index（可通过Index来查找数据以提高查找效率）都放入master里。

优点：没有index时，如果要查的数据分布在不同的slave下，client需要联系所有的slave。有index时，master可以找出存在要找数据的slave存放数据的block，这样client只需要联系部分slave的部分block。

缺点：在master干的事情越多，并行性却差。

--但是master只有一台，使用内存来维护这些index，系统会变得很慢。master机器压力很大，要是出了问题需要重建会占用很多时间。

改进：

--静态页面、少量碎片合成大文件

新问题：

--点赞越来越多、评论越来越多（这是insert语句），导致存储点赞和评论的表会越来越大、上亿条数据量的访问时间需要4-5分钟，也就是说，点一个赞，四五分钟之后才有反应。

解决：

--使用Redis存储用户的Timeline的数据、存储用户的小红心表达、存储用户和用户直接的关系

数据库或者数据仓库，都要从架构的角度去考虑响应系统时间的需求。

原始数据、业务所需分析数据

为什么选用hadoop+hana？（性能、数据量、开销、功能）

--hadoop  数据量大、性能一般、用于初步处理数据（把每天的销售清单sum一下得到总和）

--sap hana 性能更好、数据量少、用于分析初步处理过的数据（）

电信为什么选用sap hana？

--

from eBrain to Teradata：

--c++ &SQL reports

--weekly DB copy 

--历史分析汇总的结果放入database里

--