ElasticSearch进阶
索引
映射
简而言之,映射即为结构(虽然说 ElasticSearch 是一个无模式的搜索引擎)。
定义方式:
1 | curl -XPUT 'localhost:9200/my_index?pretty' -H 'Content-Type: application/json' -d' |
简而言之,映射即为结构(虽然说 ElasticSearch 是一个无模式的搜索引擎)。
定义方式:
1 | curl -XPUT 'localhost:9200/my_index?pretty' -H 'Content-Type: application/json' -d' |
所谓并发的时代,其实不仅仅提现在并发友好的库、框架、语言在兴起,而是这种并发的思想,早已融入到计算机最底层中了。
『让计算机并发执行若干个运算任务』与『更充分地利用计算机处理器的效能』之间的因果关系,看起来顺理成章,实际上它们之间的关系并没有想象中的那么简单,其中一个重要的复杂性来源是绝大多数的运算任务都不可能只靠处理器『计算』就能完成,处理器至少要与内存交互,如读取运算数据、存储运算结果等,这个I/O操作是很难消除的(无法仅靠寄存器来完成所有运算任务)。
由于计算机的存储设备与处理器的运算速度有几个数量级的差距,所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(Cache)来作为内存与处理器之间的缓冲:将运算需要使用到的数据复制到缓存中,让运算能快速进行,当运算结束后再从缓存同步回内存之中,这样处理器就无须等待缓慢的内存读写了。
嫌上面文字太长了,简单说来就是:计算机计算太快了,等不及慢的主存了,加了 L3、L2、L1 以及寄存器4个高速缓存就是为了让 IO 能快点。
由此产生出了一个问题
本文承接自: Spring-源码解析-容器的功能扩展-BeanFactory功能扩展
依照前文继续分析: AbstractApplicationContext#refresh()
BeanFacotry 作为 Spring 中容器功能的基础,用于存放所有已经加载的 bean,为了保证程序上的高可扩展性,Spring 针对 BeanFactory 做了大量的扩展,比如我们熟知的 PostProcessor 等都是在这里实现的。
之前分析是建立在BeanFactory
接口以及它的实现类 XmlBeanFactory
来进行分析的, ApplicationContext
包含了 BeanFactory
的所有功能,多数情况我们都会使用 ApplicationConetxt
。其加载方式如下:
ApplicationContext ctx = new ClassPathXmlApplicationContext("beanFactory.xml");
所以我们就以 ClassPathXmlApplicationContext
来作为分析的切入点:
Restful vs Java API
需要添加依赖:
1 | <dependency> |
需要获取 client 实例:
1 | Settings settings = Settings.EMPTY; |
curl -XPOST 'localhost:9200/books/es/1' -d '{"title": "Elasticsearch Server", "published": 2013}'
返回:
{"_index":"books","_type":"es","_id":"1","_version":1,"result":"created","_shards":{"total":2,"successful":1,"failed":0},"created":true}
在经历过 AbstractAutowireCapableBeanFactory#createBean
中的 resolveBeforeInstantiation
方法后,程序有两个选择,如果创建了代理或者说重写了 InstantiationAwareBeanPostProcessor
的 postProcessBeforeInstantiation
方法并在方法 postProcessBeforeInstantiation
中改变了 bean
,则直接返回就可以了,否则需要进行常规 bean
的创建。而这常规 bean
的创建就是在 doCreateBean
中完成的。
AbstractAutowireCapableBeanFactory#doCreateBean