sql如何暂时存储数据_暂时不要跳SQL船

sql如何暂时存储数据

在过去的二十年中，SQL语言一直在稳步发展。 同时，由Java客户端代码中的JDBC API引起的冗长性以及Java语言内部缺乏对一流SQL的支持，导致引入了诸如Hibernate之类的ORM，后来将其标准化为JPA和Criteria API。 但是，一些用户正在通过复杂SQL查询与数据库进行交互，无论是在性能还是在表达能力上，这种复杂性都与JPA涵盖的功能正交。 如果SQL和JPA有所不同，我们的数据交互模式将流向何方？

Topconf 2013会议的最新印象

软件会议是衡量新趋势以及未来五到十年我们行业将如何发展的新思路的绝佳指标。 在Topconf上 ，这是一个在爱沙尼亚美丽的塔林举行的有希望的新会议，很多技术讲座涉及大规模，分布式数据处理以及新兴技术和范例。 GridGain的创始人兼首席执行官Nikita Ivanov在第二天的开幕主题演讲中谈到了内存计算。 不久之后，来自Hazelcast的 Christoph Engelbert举行了一场竞争性演讲，有关异步React式编程 （一种新的新兴范式）的演讲很多，它们来自Scala的“亚文化”，旨在通过更好地共享服务器上的计算资源来进行扩展。

每当出现“向上扩展”和“向外扩展”流行语时，也会出现流行的NoSQL供应商名称，例如MongoDB或Cloudera （ Hadoop ）。 这甚至使MongoDB在2013年5月获得了12亿美元的估值 。然而，Nikita Ivanov和Christoph Engelbert都提出了一个很好的观点，即在考虑扩展时，会对我们的考虑产生更实际的影响。

放大还是缩小？ 集中还是分发？

首先，DRAM价格在过去几年中急剧下降。 尽管您10年前就不敢考虑内存数据库（当您支付大约1 USD / MB时），但许多公司现在可以负担得起将其所有在线事务数据存储到内存中（支付大约1 USD / GB）。 根据Nikita的说法，所有公司中有99％的在线数据少于9TB，这是可以负担得起的。 这允许在不实际更改软件体系结构的情况下，将大量数据从磁盘（以毫秒为单位）移出内存（以纳秒为单位）。 换句话说，可以不必使用任何新技术就可以将旧系统加速几个数量级。 对于刚刚从COBOL迁移到Java且还不愿替换关系数据模型的大型公司而言，这非常重要。 换句话说，我们实际上可能不需要新的数据存储范例。 还是我们？

另一方面，数据量仍在越来越大，人们希望分片和分发数据，使数据在物理上更接近消费者。 即使实际的计算机器可以非常快地对越来越大的内存数据进行操作，通过有线移动此类数据仍然会遭受网络延迟，程序包丢失以及各种其他性能问题的困扰。

Hazelcast实现的“新”范式是将计算移向数据，而不是将数据移向计算。 这也是OLAP数据库长期以来所做的事情。 现代RDBMS实现了复杂且具有高度表达能力的基于SQL的语言，以非常接近数据地执行存储过程。 实际上，这甚至类似于早期的共享大型机系统，例如IBM 7094 ，在该系统中，开发人员在中央计算引擎上具有时隙。 因此，这种范例并不是真正的新事物。 我们只是在经历基于可用资源和这些资源的能力的分布式计算与集中式计算的周期性振荡。 尽管NoSQL是一种分配力量，但DRAM价格下降是一种集中力量。

同时，企业Java中正在发生什么？

这些主题与Charles Humble最近对InfoQ的询问（ 如何从Java访问关系数据）有什么关系 ？ 根据他和Martin Fowler的观察 ，人们似乎普遍对ORM感到愤怒。 这些情绪中有许多是由于ORM是“泄漏抽象”这一事实造成的。 乔尔·斯波斯基（Joel Spolsky）早就已经观察到这一点 。

尽管最近在JEE 7中进行的JPA 2.1标准升级为更好地与“高级”数据库功能（例如存储过程）集成进行了一些改进，但关系数据库本身（如SQL标准）却一直在朝着无法真正表达的方向不断发展。与JPA。 使用ISO / IEC SQL：1999标准，我们可以利用分组集和（递归）公用表表达式。 使用SQL：2003 ，我们拥有非常复杂的窗口函数和MERGE语句。 使用SQL：2008 ，我们可以执行分区的JOIN。 通过SQL：2011 ，我们现在可以与时态数据库进行互操作（到目前为止，已在IBM DB2和Oracle中实现）。 这些东西都没有在Charles Humble的民意测验列出的JPA或大多数其他ORM中有任何表示形式，但jOOQ除外， jOOQ是Java中一种类型安全的内部域特定语言建模SQL（ 也在Topconf上提出 ）。

换句话说，尽管数据管理市场日新月异，但Java Enterprise社区正在慢慢过渡到其持久性API的下一个次要版本。

将来会发生什么？

我们可以说的是，在未来几年中，软件技术将发生根本性的变化。 以下是将要挑战的几个范例：

资料储存库：

RDBMS为我们提供了很好的服务，将来将继续为我们提供很好的服务。 它们基于极其复杂和扎实的理论（即关系理论），它是解决许多问题的非常合适的模型。

其他种类的数据存储继续涌现，并在非RDBMS市场中争取新的优势。 基本上有两个理由说明此类替代方案的合理性：

• 关系数据模型不足以用于高度分层或非结构化的数据。
• ACID不足以进行极端扩展，因为网络延迟使所有ACID成为分布式系统中难以解决的问题。

但是，就像老大象被教给了新花样一样 ，在集成列存储（也称为NewSQL ）时，关系数据库供应商最终也将能够集成经过验证的NoSQL功能。

语言：

近年来，命令式（和OO）编程受到功能性编程的严重挑战。 突出的挑战者是Scala，JavaScript， C＃3.0，VB 9和Java8。一个简单的解释是，功能语言使将计算逻辑更接近数据变得容易得多。 同时， 副作用是可取的 ， Simon Peyton Jones本人在讨论编程语言的未来时也证实了这一点。 与LINQ的创建者Erik Meijer一起。

另一方面，Erik Meijer的LINQ的流行证明了声明性查询语言也是与数据进行复杂交互的良好范例。 如上所述，SQL本身正在通过各种新标准进行改进。 到目前为止，Facebook已经开源了自己的基于ANSI-SQL的方言 ，该方言建立在Apache Hadoop之上。

可以说的是，这些语言范式中的任何一个都不能被其他范式所代替。

SQL无处不在

SQL在数据处理中无处不在，这使我们更接近一个重要原因，即Charles Humble发现“经典” ORM（例如Hibernate） 日益增加的不适感 。 这些工具解决了两个问题：

• CRUD的重复性
• 缓存，从而加快磁盘访问

即使使用Hibernate，智能缓存也可能非常困难，因为Hibernate在实体级别实现了许多SQL缓存功能。 由于ORM策略已与JPQL深度集成，因此只能使用Hibernate / JPA的缓存机制。 缺少本机查询，很难绕过用于缓存的基本机制。

但是，请记住内存如何变得越来越便宜？ 缓存主要有助于保持较低的磁盘访问成本。 如果不再从磁盘（毫秒）访问数据，而是从内存（纳秒）访问数据怎么办？ 当数据库已经“缓存”了内存中的所有相关数据时，我们是否仍需要复杂的二级缓存？

数据库不仅能够始终将实时的在线事务数据保留在内存中，而且已经有一段时间了，它们已经进行了一些复杂的缓存。 仅考虑Oracle的游标缓存 ， 查询结果缓存和标量子查询缓存 。

尽管JPA仍然是执行CRUD的出色工具，但是越来越多地使用以SQL为中心的替代方案，例如MyBatis或jOOQ （均为“后JPA”框架），表明确实有必要再次接近SQL。 ANSI-SQL标准正在不断发展，使各种特性标准化，这些特性来自于创新的数据库，例如Oracle，SQL Server，PostgreSQL，这些东西很难通过JCP进入下一代JPA。 JPA 2.1对存储过程提供了一些支持，但是在客户端代码中管理该支持似乎与通过简单的JDBC CallableStatements实现事物一样乏味。 此外，JPA 2.1的各种与存储过程相关的新注释都没有涵盖将用户定义的函数嵌入到SQL语句中，而这些语句由非常受欢迎的CriteriaQuery API不足以表示。 在关于jOOQ的所有会议讨论中，我一直在向观众询问他们对CriteriaQuery的满意程度。 答案始终是敌对的。

结论

时代在变。 RDBMS不断发展和拥抱新功能，在ANSI SQL中将它们标准化，从而取代了JPA2.x。 在这些变化的时代，JPA标准化似乎仅限于那些在数据存储市场上进行创新的人。 EclipseLink最近通过JPA扩展支持MongoDB的调情表明，人们对标准的把握还不确定。

但是似乎有一件事是肯定的。 我们不会很快摆脱SQL。 那么，为什么不重新开始拥抱它呢？

翻译自: https://www.infoq.com/articles/SQL-relevance-NoSQL/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1

sql如何暂时存储数据