1. es可以一天存百万条数据么
es不可以一天存百万条数据。es一天最大的存储量是90万条数据，所以es不可以一天存百万条数据。es全称ElasticSearch,是一个基于Lucene的搜索服务器。
2. ElasticSearch海量数据使用简述
应用场景当中经常会遇到模糊查询或多条件匹配查询，数据量较小的情况下通过简单的数据库模糊查询是可以解决的，但是对于数据量庞大的情况，数据库模糊查询就会出现性能问题。这种情况下的一种解决方案就是根据查询内容构建反向索引，借助搜索引擎进行查询，提升查询性能。
目前使用比较多的分布式搜索引擎是ElasticSearch。那么项目中如何使用ES？如何保证ES的数据更新？下面简单做个吵磨戚描述。
Elasticsearch使用可以简单分为两个阶段。数据初始化阶段、数据更新阶段。
数据初始化阶段。数据初始化常见的方式如下：
一、通过应用程序手动将数据库中的数据，调用ES接口API插入ES索引库中。
二、同过数据迁移工具将数据初始化到ES数据库。目前常用的ES同步工具有logstash-input-jdbc、DataX。通过同步迁移工具可以全量将数据库数据初始化到ES索引库中。
数据更新阶段。数据更新阶段常见的处理方式如下：
一、通过应用服务直接调用ES更新接口。这种方式实现比较简单但是对业务侵入性比较大。
二、对于实时性要求不高的可以采用定时任务监控数据表变化然后调用ES接口实现数据更新。
三、业务应用中通过发送消息异步更新数据。
四、通过DataX同步工具定时将修改的数据同步到ES库中。
上述是ElasticSearch使用的简升陵单描述。使用的关键还是数据库与ES间的数据同游手步。能否用的好关键也是数据间的同步。
3. es查询超过10000条数据报错
{
"败巧升index"察老:{
"宽历max_result_window":2000000
}
}
4. es存储目录分析
Elasticsearch中生成的数据文件一般来说主要有三种，分别是state、index和translog。
查看ES存储目录，可发现有多个_state目录，目录下存放了以.st为后缀的文件。例如
这些st文件内容在ES源码里被称之为MetaData，缓存了诸如NodeState，ClusterState，IndexState，ShardState等信息
nodes/0/_state/:
这层目录在节点级别，该目录下的global-1.st文件存储的是MetaData中除去IndexMetaData的部分，即一些集群级别的配置和templates。node-0.st中存储的是NodeId。
nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/_state/:
这层目录在index级别，2Scrm6nuQOOxUN2ewtrNJw是IndexId，该目录下的state-2.st文件存储的是IndexMetaData。
nodes/0/indices/2Scrm6nuQOOxUN2ewtrNJw/0/_state/:
这层目录在shard级别，该目录下的state-0.st存储的是ShardStateMetaData，包含是否是primary和allocationId等信息。
可以看到，集群相关的MetaData和Index的MetaData是在不同的目录中存储的。另外，集群相关的Meta会在所有的MasterNode和DataNode上存储，而Index的Meta会在所有的MasterNode和存储了该Index数据的DataNode上存储。
5. ES数据存储可靠性和写入流程
https://www.elastic.co/guide/en/elasticsearch/guide/2.x/near-real-time.html
https://www.elastic.co/guide/en/elasticsearch/guide/2.x/merge-process.html
1、数据存储可靠性保证原理
1.1 translog机制
当一个文档写入Lucence后是存储在内存中的，即使执行了refresh操作仍然是在文件系统缓存中，如果此时服务器宕机，那么这部分数据将会丢失
当进行文档写操作时会先将文档写入Lucene，然后写入一份到translog，写入translog是落盘的
tips:如果对可靠性要求不是很高，也可以设置异步落盘，可以提高性能，由配置index.translog.rability和index.translog.sync_interval控制
tips:translog是追加写入，因此性能比较好
先写入Lucene再写入translog。原因是写入Lucene可能会失败，为了减少写入失败回滚的复杂度，因此先写入Lucene
1.2 flush操作
refresh_interval定时触发 或当translog达到index.translog.flush_threshold_size（默认512mb)，ES会触发一次flush操作：先执行refresh操作将buffer中的数据生成segment，然后调用lucene的commit方法将所有内存中的segment fsync到磁盘，最后会清空translog中的数据(6.x版本为了实现sequenceIDs，不删除translog) 。
1.3 merge操作
refresh操作会产生大量的小segment，因此产生的每个文件都会消耗文件句柄，内存，CPU 使用等各种资源。更重要的是每个查询请求都要顺序检查每个segment; segment越多检索会越慢.
ES会运行一个检测任务，在后台把近似大小的segment合并成一个新的大segment，并删除旧segment
1.4、多副本机制
ES有多副本机制（默认是1个副本），一个分片的主副分片不能分片在同一个节点上，进一步保证数据的可靠性。
2、ES写索引的流程
6. Elasticsearch 能够存储的数据量一般有多大
单独看ES能玩多大数据意义不大，具体实践中往往因为各种业务要求而无法继续增加数据量。目大的方面考虑有如下几点：
1、查询速度。ES可以支持的查询类型多种多样，单一的term匹配，复杂的historm agg，甚至父子文档模式下bool查询之后继续做文本高亮，数据量越大查询时间越长。如果只是简单的把数据写进去然后按照ID获取数据，那就尽管往里面写数据吧。
2、写入速度。数据量越大，写入速度受影响的可能性越大。业务要求1小时的数据1小时内必须写完，如果做不到就得考虑分索引或者分集群了。
3、更新速度。同上，更新比单纯的写入操作更多，先get再merge再overwrite到es。
4、其他因素。
目前我遇到的ES集群，有1.5T-2T索引量的情况下，需要支持平均查询在500ms以内的高并发高亮查询。在我们的场景下这个量级不算小了。