13518219792
Java API 支持多个index和多个Type同时查询，但是Elasticsearch是非关系型(NoSQL)，所以不能关联查询。
成都创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：网站制作、成都网站建设、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的息县网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
关系是客观存在的自然规律，摆脱就是在修改事实模型。用NOSQL，我觉得可以理解成关系模型的变化，而不是另起炉灶。
而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。
3、High Scalability High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？
在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：
1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。
2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。
NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。
当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。
AWS推出了与SQL兼容的查询语言PartiQL，只要数据库查询引擎提供PartiQL支持，使用者就能以PartiQL单一查询关联式数据库的结构化资料，以及开放资料格式中的巢状资料或是半结构化资料，甚至还能用来查询NoSQL或是文件数据库中无固定结构（Schema-less）的资料。除了AWS自家的数据库服务，NoSQL数据库Couchbase Server也承诺将会支持PartiQL。
企业资料分散在关联式数据库、非关联式数据库以及资料湖泊中。高度结构化的资料，储存在SQL数据库或是资料仓储；无固定结构的资料则由键值储存、图形数据库（Graph Database）、分类帐数据库或是时间序列数据库等NoSQL数据库处理；而在资料湖泊中的资料，可能也有部分缺乏结构，或是可能为巢状或是多值结构。不同的资料类型适用于不同的使用案例，而每种类型的资料，可能都有自己的查询语言。
不同的资料储存对应不同的查询语言，当企业更换资料格式或是数据库引擎时，可能还需要跟着改变应用程式和查询语法，AWS提到，这对于资料的应用，特别是使用资料湖泊的灵活性与效率，有着很大的阻碍。为了统一不同类型数据库存取方法，AWS发布了查询语言PartiQL，这是个与SQL兼容的查询语言，可以用来查询以各种格式储存在各地的资料。
用户可以使用PartiQL来查询关联式数据库，像是在Redshift实作交易或是资料分析等应用，或对于Amazon S3资料湖泊的开放资料格式，同样能使用PartiQL对巢状资料与半结构化资料例如Amazon Ion格式进行查询，另外，PartiQL也可用于文件数据库等NoSQL数据库，查询无固定结构的资料。
AWS表示，PartiQL的出现，是为了满足自家查询和转换大量资料的需求，其提供严格的SQL兼容性，可与标准SQL混合使用，执行连接（Join）、过滤（Filtering）与聚合（Aggregation）操作，并以最小扩充支持巢状和半结构化资料，让开发者以简单且一致的方法，不需要更改查询语言，就能查询各种格式和服务的资料。
PartiQL具格式独立性与储存独立性，PartiQL语法和语义不依赖任何资料格式，无论使用者是要查询JSON、Parquet、ORC、CSV还是Ion等格式，查询语句的写法都相同，PartiQL的查询在综合逻辑类型系统上运作，才对应到不同底层的格式。而PartiQL也不相依于特定资料储存，因此适用于不同的底层资料储存。
虽然过去针对跨不同类型数据库查询的问题，已有不少解决方案，AWS指出，像是Postgres JSON同样也兼容于SQL，但是却无法良好地处理JSON巢状资料；而半结构化查询语言，虽然能良好处理巢状资料，但却无法与SQL语言兼容。AWS提到，PartiQL是第一个能够完全解决这些问题的查询语言。
目前AWS已在自家多项服务支持PartiQL，包括Amazon S3 Select、Amazon Glacier Select、Amazon Redshift Spectrum、Amazon QLDB，接下来几个月将会有更多的AWS服务支持PartiQL，Couchbase也公布将加入支持PartiQL的行列。现在PartiQL以Apache2.0授权许可开源，公开教学、规范以及参考实作，所有社群都能使用并参与贡献。
