该帖已经被评为精华帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-11-25
非关系型数据库更多的是解决海量数据时主键型查询及更新的问题。
它有个比较难解决的就是非主键的查询,比如取一用户的所有好友列表。 大数据量下我们目前解决方法是通过搜索引擎或数据库集群+缓存处理,但前者用作查询并不合适,后者mysql及pg在这块的支持还不是很好,收费的又太贵。 |
|
返回顶楼 | |
发表时间:2009-11-25
JE用的什么解决方案呢?啥时候也自己搞一套轮子来开开,呵呵
|
|
返回顶楼 | |
发表时间:2009-11-25
实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系,与你底层使用key-value,还是table还是层次数据或者网状数据,都没有关系。Codd只是说,如果一个数据库能够接受一个关系代数并且给出相关结果,那么就是关系数据库。
|
|
返回顶楼 | |
发表时间:2009-11-25
Trustno1 写道 实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系,与你底层使用key-value,还是table还是层次数据或者网状数据,都没有关系。Codd只是说,如果一个数据库能够接受一个关系代数并且给出相关结果,那么就是关系数据库。
正好想问问你,或者说大家来探讨一下: 为什么,Codd的观念,大家都没遵守呢?虽然大家都尊他为关系型数据库之父。 |
|
返回顶楼 | |
发表时间:2009-11-25
最后修改:2009-11-25
庄表伟 写道 Trustno1 写道 实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系,与你底层使用key-value,还是table还是层次数据或者网状数据,都没有关系。Codd只是说,如果一个数据库能够接受一个关系代数并且给出相关结果,那么就是关系数据库。
正好想问问你,或者说大家来探讨一下: 为什么,Codd的观念,大家都没遵守呢?虽然大家都尊他为关系型数据库之父。 性能,关系数据一大要求就是不能因为性能而改变逻辑结构。比如说一个tuple{id,year,name,salary},按照SQL的做法搞一个表吧,按照id为key.然后存啊存啊存,发现数据越大查询性能越慢,恩然后程序员说我们分表吧,一年一个表.这种情况在关系数据里是不允许的。 |
|
返回顶楼 | |
发表时间:2009-11-25
Trustno1 写道 庄表伟 写道 Trustno1 写道 实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系,与你底层使用key-value,还是table还是层次数据或者网状数据,都没有关系。Codd只是说,如果一个数据库能够接受一个关系代数并且给出相关结果,那么就是关系数据库。
正好想问问你,或者说大家来探讨一下: 为什么,Codd的观念,大家都没遵守呢?虽然大家都尊他为关系型数据库之父。 性能,关系数据一大要求就是不能因为性能而改变逻辑结构。比如说一个tuple{id,year,name,salary},按照SQL的做法搞一个表吧,按照id为key.然后存啊存啊存,发现数据越大查询性能越慢,恩然后程序员说我们分表吧,一年一个表.这种情况在关系数据里是不允许的。 如果真是这么简单的原因的话,那么Codd的不允许,岂不是一开始就错了? |
|
返回顶楼 | |
发表时间:2009-11-25
庄表伟 写道 Trustno1 写道 庄表伟 写道 Trustno1 写道 实际上从Codd的观念来说,当今的RMDB其实都不算是关系数据最多就是只是算SQLRMDB.关系数据的第一条就是,数据的关系与底层的实现是没有关系的.数据上存在关系,与你底层使用key-value,还是table还是层次数据或者网状数据,都没有关系。Codd只是说,如果一个数据库能够接受一个关系代数并且给出相关结果,那么就是关系数据库。
正好想问问你,或者说大家来探讨一下: 为什么,Codd的观念,大家都没遵守呢?虽然大家都尊他为关系型数据库之父。 性能,关系数据一大要求就是不能因为性能而改变逻辑结构。比如说一个tuple{id,year,name,salary},按照SQL的做法搞一个表吧,按照id为key.然后存啊存啊存,发现数据越大查询性能越慢,恩然后程序员说我们分表吧,一年一个表.这种情况在关系数据里是不允许的。 如果真是这么简单的原因的话,那么Codd的不允许,岂不是一开始就错了? 当年Codd针对关系数据提出了12条Rule,其中Rule 8,Rule9就是说的这个 Rule 8: Physical data independence: Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure. Rule 9: Logical data independence: Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence. |
|
返回顶楼 | |
发表时间:2009-11-25
最后修改:2009-11-25
Redis 现在已经发布了 1.02 版,从 TODO 来看,在未来的版本更新中,现有的很多缺点都将得到改进
引用 VERSION 1.1 TODO (Zsets, Integer encoding, Append only journal)
VERSION 1.2 TODO (Hash type) VERSION 1.3 TODO (Virtual memory) VERSION 1.4 TODO (Fault tollerant sharding) VERSION 1.5 TODO (Optimizations and latency) 数据库革命已经来临,大家拭目以待吧 ![]() |
|
返回顶楼 | |
发表时间:2009-11-25
在web应用的推动下,非关系数据库得到了极大的发展空间
|
|
返回顶楼 | |
发表时间:2009-11-25
最后修改:2009-11-25
数据库革命还谈不上,这些东西最多就是弥补数据库的缺点,在整个架构中,属于和数据库相互补充的这个一个角色。
当然我也想知道是否有大型网站完全不用数据库的,知道的同志出来说说。 ================================================================== 对于TT+TC, 之前做过一个简单的测试,不过是针对较大数据的,使用的是memcached协议测试的: keylength valuelength threads request/per thread get set r/s w/s read write 20b 11kb 5 10000 31.587 26.25 1612/s 1923/s 17m/s 20m/s 20b 22kb 5 10000 113.463 162.317 442 308 9m/s 6m/s 20b 33kb 5 10000 267.256 1218.055 187 41 6m/s 1m/s 20b 55kb 5 10000 274.635 2096.671 182 23 9m/s 1m/s 20b 110kb 5 10000 579.711 5921.827 86 8 9m/s <1m/s memcached客户端也换了几个,有spymemcached, dennis的xmemcached,还有我自己也写了一个nio的客户端,测试结果基本一样,区别不是很大。 11kb时的性能还是相当的好的,每秒写入的速度达到了20M, 我用bdb做local的测试,最快每秒写入可以到达35M,那么应该说来tt+tc在11kb下的写入速度收到网络方面的影响(测试方法:client和server在同一台机器上,而且client请求的是localhost) 如果要达到读写4w/s,那估计value要小于1kb才行,或者直接SSD =================================================================== 而cassandra确实不错,之前我也看了一些代码,主要是dynamic和bigtable两种理论的结合,客户端和服务器之间没有中间的层次,减少的层次上的通信,加上bigtable,确实可以提供给我们很多特性(对我来说最有用的应该是版本号)。不过目前它还在0.4版本,不知道靠不靠谱。有待验证。 |
|
返回顶楼 | |