nosql

nosql引入： 1.大数据时代 3v 海量volume 多样性Variety 实时 Velocity 2.系统需求（互联网的应用----淘宝、天猫) 高并发、海量结构化非结构化数据的存储、高可扩展性、高可用性 3.传统的数据库解决方案 : 数据的切分（水平切分、垂直切分) 4.nosql---->易扩展、灵活的数据模型、高可用、大数据量（就是因为这些而生) nosql ----> not only sql 5.当下的应用应该是sql 和 nosql 一起使用案例：阿里巴巴中文站商品信息，商品信息如何存放: 商品的信息: 基本信息如名称、价格、编号等------>关系型数据库存放(mysql、Oracle) 商品描述、评价信息(文字比较多的)---->文档类的数据更适合存放在文档数据库中如Mongodb 商品图片信息----->分布式的文件系统中---->tfs、gfs、nfs、hdfs、ext3/4 其它信息: 商品有关键字----->搜索引擎当中（ISearch) 商品存在热点数据---->内存数据库(Memcached、redis) 商品和价格计算相关---->外部数据库接口（如支付宝) ... ... 总结:大型的互联网应用（海量数据、高并发访问、多样的数据种类的）的情况会采用异构的数据源问题：给开发带来很多的问题需要去解决(统一数据服务平台) 数据源改造而数据服务平台不需要大面积重构 nosql 数据模型 1.聚合模型（key/value,bson,列族) 2.图 3.案例：电子商务网站，把商品卖给消费者。存储用户信息、商品目录、订单、收货地址、账单地址、付款方式等等关系型数据库---->ER图 1:n n:1 1:1 n:n这样的关系，主外键等方式聚合模型:（bson格式) //int customers { "id":1,"name":"Martin","billingAddress":[{"city":"Chicago"}] } //int orders { "id":99,"customerId":1 "orderItems":[ { "productId":27,"price":32.45 "productName":"NoSQL Distilled" } ],"shippingAddress":[{"city":"chicago"}] "orderPayment":[ { "ccinfo":"1000-1000-1000-1000","txnId":"abelif879rft","billingAddress":{"city":"Chicago"} } ],} ======================================================================== { "customer":{ "id":1,"billingAddress":[{"city":"Chicago"}],"orders":[ { "id":99,"customerId":1,"orderItems":[ { "productId":27,"price":32.45,"productName":"NOSQL" } ],"shippingAddress":[{"city":"chicago"}] "orderPayment":[ { "ccinfo":"1000-1000-1000-1000","txnid":"abelif879rft","billingAddress":{"city":"Chicago"} } ],} ] } } nosql分类 1.key-value结构的典型的BerkeleyDB(新浪就在用) LevelDB Memcached（新浪、阿里、百度...) Redis(阿里、百度...) 2.Document文档数据库(bson格式) 典型的 Mongodb CouchDB 3.Column-Family 典型的Hbase、Cassandra(纯java的) 4.Graph(图数据库--->存放的是关系) Neo4j（纯java)、FlockDB等 CAP+BASE原理 1.在分布式数据库中CAP原理 C--->强一致性 A---->高可用性 P---->分布式容忍性在分布式的情况下3只能满足其2牺牲两外一个。 CA 传统数据库 AP 大多数网站架构的选择 CP Redis、Mongodb 注意：分布式架构的时候必须做出取舍。一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。因此牺牲一致性换取可用性，这是目前分布式数据库产品的方向 2.Base 原理 ---->AP的衍生基本可用、软事务、最终一致性（不一致窗口) （因果一致性读己之所写会话一致性）案例:ebay 竞拍(采用base) 出价竞拍:原子性不是重点，更多的是在拍卖最后的几秒钟，不要阻塞任何出价人。在显示时刻而不是在出价时刻计算出最好出价人和最高出价。所有的出价都被插入到子表中，每次显示产品，再重新取回出价。用业务逻辑解决。背后的问题就是一致性的问题。采用BASE而不是ACID。出价表和出价视图表之间不必服从ACID 使用场景一 key/value 适合存储用户信如会话、配置文件、参数购物车等等。一般都会跟ID挂钩只能通过key直接得到value,不能通过value进行查询二文档数据库日志、分析、文档（博客等) 数据库并没有固定的模式。每个文档是独立，文档间的操作就不适合了。三、列数据库日志、博客平台四、图数据库在一些关系性强的数据库中推荐引擎

相关推荐