我建议我调查Key/Value对数据系统来替换我一直在使用的关系数据库.
我不太了解的是如何提高查询效率.根据我的理解,您将丢弃大量有助于提高查询效率的信息,只需将结构数据库转换为一个很长的键和值列表即可？
我完全错过了这一点吗？
关系数据库的关键优势是能够关联和索引信息.大多数"NoSQL"系统不提供关系代数或优秀的查询语言.
您需要问自己的是,切换对我的预期用例有意义吗？
你有点错过了这一点.关键是,你有时候没有索引(就像你对普通关系数据库一样).即使您拥有索引,也很难将它们联系在一起,并且关系数据库的优势也很大.NoSQL解决方案具有许多新颖的结构,这使得许多用例很容易,例如Redis是一个面向数据结构的DB,非常适合用队列或pub-sub架构快速构建任何东西.MongoDB是一个自由格式的文档数据库,它将文档存储为JSON(BSON),并且在快速开发方面表现优异.BigTable解决方案的结构稍微不那么简单,但扩展了行的思想,以便拥有列族 - 每行中包含的键值对有效地排列在磁盘上.您可以使用ElasticSearch等技术在此基础上构建倒排索引.
并非所有东西都需要传统RDBMS的一致性保证或磁盘布局.NoSQL的另一个主要用例是大规模可扩展性,许多解决方案(例如BigTable - HBase/Cassandra)设计用于水平分片和扩展(使用SQL不那么容易!).特别是Cassandra是为没有SPOF而设计的.此外,面向列的数据存储区旨在通过顺序读取(并减少写入放大)来优化磁盘速度.话虽如此,除非你真的需要它,否则传统的SQL服务器通常都足够好.
有优点和缺点.就个人而言,我使用两者的混合.使用正确的工具来完成正确的工作,这可能最终成为PostgreSQL或MySQL.
您可以将基本键值系统比作制作包含两列,唯一键和值的SQL表.这很快.您无需进行任何关系或相关性或数据整理.只需找到该值并将其返回.这是一个过于简单化,NoSQL数据库确实有很多有趣的功能和应用程序,超越简单的K,V商店.
我不知道你的科学数据是否适合大多数NoSQL实现,这取决于数据.如果你看看HBase或Cassandra,它可能很适合科学家的需求(使用正确的rowkey设计 - 时间戳不能是第一个,请查看OpenTSDB).我知道许多公司通过使用随机分区器和传感器的UUID将读数汇总到每日脂肪行中,在Cassandra中存储传感器读数.每天都会围绕特定用例创建新数据库,以便答案可能会发生变化.对于特定用例,您可以以灵活性和工具为代价获得使用特定数据存储的巨大回报.
效率来自三个主要方面:
数据库的功能要少得多:没有连接的概念,也没有减少或缺少事务完整性要求.更少的功能意味着更少的工作意味着更快,至少在服务器端.
另一个设计原则是数据存储位于服务器云中,因此您的请求可能有多个响应者.这些系统还声称多服务器系统通过复制提高了容错能力.
它完全符合流行语,使用了一堆尚未完全发明的想法和描述.例如,亚马逊目前正在提供他们的服务,以便更好地了解人们如何使用它们并获得改进规范的经验.
在我看来,有人要求"我们的新数据对于我们的RDBMS来说太多了"应该有一些数据来支持这个断言,或者承认他们只是想尝试新的闪亮.NoSQL是无效的吗？可能不是.随着Java 1.0被大肆宣传,是否会让世界颠倒？可能不是.
调查新事物没有坏处,只是不要把农场押在他们身上,转而支持50年历史,完善的,易于理解的技术.
在这里,我假设您要优化一个特定查询,这只是按键查找记录.其中一个例子可能是按用户名查找userinfo记录.对于某些系统,类似的查询必须非常快,所有其他查询都不重要.
数据库性能的最大因素是读/写数据所需的I/O操作数.大多数数据库系统使用类似的数据结构(即b树),它可以在O(log(n))I/O中缓存未缓存的数据.为了提供持久的更新,必须将数据写入磁盘:大多数系统按顺序执行,这是最快的方法.
那么,Key-Value商店可以在哪里获得效率？
非标准化数据.将所有数据放在一行意味着没有连接.
低CPU开销.键值存储避免了查询处理/优化,安全检查,约束检查等的CPU成本.
使存储在进程中更容易(而不是作为单独服务运行的SQL服务器),这消除了IPC开销.
大多数RDBMS系统都建立在看起来像键值存储的东西之上,因此您可以将其视为切断中间人.
京公网安备 11010802040832号 | 京ICP备19059560号-6 