典型场景的数据库有哪些，SQLite 主要应用在哪些场景

1，SQLite 主要应用在哪些场景

一般用于对并发数量要求不高的本地查询，比如个人博客（WordPress支持SQLite3）、本地工具软件、嵌入式系统用数据库（Android）

你说呢...

SQLite 主要应用在哪些场景

2，elasticsearch mysql 哪个好

这两个所适用的领域不同，不具有可比性。ElasticSearch本质是搜索引擎，它通过建立反向索引的方式处理文档型数据，不具备通常数据库的事务、关联查询等等特性，你可以把它当作nosql来用。MySQL是典型的关系型数据库。如果你的场景是海量数据，要求水平扩展，无事务要求，那么可以用ES，否则还是要MySQL，或者根据业务需求混合使用两种。

elasticsearch mysql 哪个好

3，Hadoop 一般用在哪些业务场景

Hadoop mapreduce这个思想主要是借助了分而治之的算法思想。就是所谓的很庞大的业务逻辑能分成一个个小型任务去执行，这种类型的业务逻辑才能使用Hadoop mapreduce去解决。

1. 存储。ibm貌似才刚推出关于存储的计划。这样读写的速度更快，并且高容错，同时也可采用一般机器进行水平扩展，而不需要大型机这样的高性能机器。2. 网页索引资料库。貌似搜索领域现在运用hadoop比较多。国内估计bat都在用吧，国外的典型应该是yahoo了。3. 日志分析。类似日志分析这样的数据挖掘领域貌似也应用的较多。4. 商品推荐。amazon用来进行协同过滤的商品推荐，个性化广告的推送也应该属于此类。5. 垃圾邮件的识别与过滤。

Hadoop 一般用在哪些业务场景

4，hadoopstorm和spark的区别比较

Hadoop是磁盘级计算，进行计算时，数据在磁盘上，需要读写磁盘；Storm是内存级计算，数据直接通过网络导入内存。读写内存比读写磁盘速度快n个数量级。根据Harvard CS61课件，磁盘访问延迟约为内存访问延迟的75000倍。所以Storm更快。注释：1. 延时，指数据从产生到运算产生结果的时间，“快”应该主要指这个。2. 吞吐，指系统单位时间处理的数据量。storm的网络直传、内存计算，其时延必然比hadoop的通过hdfs传输低得多；当计算模型比较适合流式时，storm的流式处理，省去了批处理的收集数据的时间；因为storm是服务型的作业，也省去了作业调度的时延。所以从时延上来看，storm要快于hadoop。从原理角度来讲：· Hadoop M/R基于HDFS，需要切分输入数据、产生中间数据文件、排序、数据压缩、多份复制等，效率较低。· Storm 基于ZeroMQ这个高性能的消息通讯库，不持久化数据。为什么storm比hadoop快，下面举一个应用场景说一个典型的场景，几千个日志生产方产生日志文件，需要进行一些ETL操作存入一个数据库。假设利用hadoop，则需要先存入hdfs，按每一分钟切一个文件的粒度来算（这个粒度已经极端的细了，再小的话hdfs上会一堆小文件），hadoop开始计算时，1分钟已经过去了，然后再开始调度任务又花了一分钟，然后作业运行起来，假设机器特别多，几钞钟就算完了，然后写数据库假设也花了很少的时间，这样，从数据产生到最后可以使用已经过去了至少两分多钟。而流式计算则是数据产生时，则有一个程序去一直监控日志的产生，产生一行就通过一个传输系统发给流式计算系统，然后流式计算系统直接处理，处理完之后直接写入数据库，每条数据从产生到写入数据库，在资源充足时可以在毫秒级别完成。同时说一下另外一个场景：如果一个大文件的wordcount，把它放到storm上进行流式的处理，等所有已有数据处理完才让storm输出结果，这时候，你再把它和hadoop比较快慢，这时，其实比较的不是时延，而是比较的吞吐了。最主要的方面：Hadoop使用磁盘作为中间交换的介质，而storm的数据是一直在内存中流转的。两者面向的领域也不完全相同，一个是批量处理，基于任务调度的；另外一个是实时处理，基于流。以水为例，Hadoop可以看作是纯净水，一桶桶地搬；而Storm是用水管，预先接好（Topology），然后打开水龙头，水就源源不断地流出来了。

5，MongoDB和MySQL的区别

MySQL关系型数据库。在不同的引擎上有不同的存储方式。查询语句是使用传统的sql语句，拥有较为成熟的体系，成熟度很高。开源数据库的份额在不断增加，mysql的份额页在持续增长。缺点就是在海量数据处理的时候效率会显著变慢。Mongodb非关系型数据库(nosql ),属于文档型数据库。先解释一下文档的数据库，即可以存放xml、json、bson类型系那个的数据。这些数据具备自述性（self-describing），呈现分层的树状数据结构。数据结构由键值(key=>value)对组成。存储方式：虚拟内存+持久化。查询语句：是独特的Mongodb的查询方式。适合场景：事件的记录，内容管理或者博客平台等等。架构特点：可以通过副本集，以及分片来实现高可用。数据处理：数据是存储在硬盘上的，只不过需要经常读取的数据会被加载到内存中，将数据存储在物理内存中，从而达到高速读写。成熟度与广泛度：新兴数据库，成熟度较低，Nosql数据库中最为接近关系型数据库，比较完善的DB之一，适用人群不断在增长。优势：快速！在适量级的内存的Mongodb的性能是非常迅速的，它将热数据存储在物理内存中，使得热数据的读写变得十分快，高扩展！自身的Failover机制！json的存储格式！

mongodb(文档型数据库)：提供可扩展的高性能数据存储一、1、基于分布式文件存储2、高负载情况下添加更多节点，可以保证服务器性能3、将数据存储为一个文档二、比较1、稳定性2、索引，索引放在内存中，能够提升随机读写的性能。如果索引不能完全放在内存，一旦出现随机读写比较高的时候，就会频繁地进行磁盘交换，mongodb的性能就会急剧下降3、占用的空间很大，因为它属于典型空间换时间原则的类型。那么它的磁盘空间比普通数据库会浪费一些，而且到目前为止它还没有实现在线压缩功能，在mongodb中频繁的进行数据增删改时，如果记录变了，例如数据大小发生了变化，这时候容易产生一些数据碎片，出现碎片引发的结果，一个是索引会出现性能问题，另外一个就是在一定的时间后，所占空间会莫明其妙地增大，所以要定期把数据库做修复，定期重新做索引，这样会提升mongodb的稳定性和效率。在最新的版本里，它已经在实现在线压缩，估计应该在2.0版左右，应该能够实现在线压缩，可以在后台执行现在repair database的一些操作。如果那样，就解决了目前困扰我们的大问题。4、mongodb对数据间的事务关系支持比较弱5、运维不方便mongodb的优势1. 适合那些对数据库具体数据格式不明确或者数据库数据格式经常变化的需求模型，而且对开发者十分友好。2.自带一个分布式文件系统，可以很方便地部署到服务器机群上。mongodb里有一个shard的概念，就是方便为了服务器分片使用的。每增加一台shard，mongodb的插入性能也会以接近倍数的方式增长，磁盘容量也很可以很方便地扩充。3. 自带了对map-reduce运算框架的支持，这也很方便进行数据的统计。类似于group bymongodb与mysql命令对比传统的关系数据库一般由数据库（database）、表（table）、记录（record）三个层次概念组成，mongodb是由数据库（database）、集合（collection）、文档对象（document）三个层次组成。mongodb对于关系型数据库里的表，但是集合中没有列、行和关系概念，这体现了模式自由的特点