NoSQL数据库探讨之一 － 为什么要用非关系数据库？ - robbin的自言自语 - ITeye技术网站
博客分类：
随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：
1、High performance - 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。
2、Huge Storage - 对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的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应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。
3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。
因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：
Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，& ......
这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类：
一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare
高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：
1、
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github，Engine Yard。
2、
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5万次读写操作。
TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个Ruby的项目将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。
TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据库。
TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。
这个是Tim Yang做的一个
3、
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。
flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。
二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB
面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：
1、
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。
Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读写性能，我（robbin）也打算有空的时候好好测试一下。
因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。
最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。
MongoDB也有一个ruby的项目，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。
2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。
三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort
面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：
1、
Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外，twitter和都在使用Cassandra。
Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。
Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：，有非常详细的介绍。
Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。
2、
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。
从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的主要原因。
如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说NoSQL数据库领域也是博大精深的，我（robbin）也只能浅尝辄止，我（robbin）写这篇文章既是自己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。
从我（robbin）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能NoSQLDB和海量存储NoSQLDB）都是我很感兴趣的，特别是Redis，TT/TC和MongoDB这3个NoSQL数据库，因此我接下来将写三篇文章分别详细介绍这3个数据库。
浏览 143971
论坛回复 /
(77 / 99396)
非关系型还有个缺点就是表之间的关联。Join操作不能用了，于是得取出一个表里所有符合的列，再对另一个表进行多次的查询（虽然BigTable也支持IN操作，但限制数目最多20，而且内部实现是多个并发的=操作）。如果涉及到3个以上的表的话，这种操作的效率和代码量更是不可接受的。有join的需求就不要用nosql，nosql就是假定没有join的。
土问CAP什么意思？
CAP，BASE和最终一致性是NoSQL数据库存在的三大基石。CAP的意思是：
& C: Consistency 一致性
&& A: Availability 可用性(指的是快速获取数据)
& P: Tolerance of network Partition 分区容忍性(分布式)
BASE是
& Basically Availble --基本可用
& Soft-state --软状态/柔性事务。"Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
& Eventual Consistency --最终一致性。最终一致性， 也是是 ACID 的最终目的。
BASE模型反ACID模型，完全不同ACID模型，牺牲高一致性。
为什么Redis和MongoDB的读写操作差距好大哦，如果两个之间进行互补一下，是不是完美了？？
从robbin大哥文中介绍和自己了解的情况来说，redis数据在内存处理，主要解决高读写问题，MongoDB采用BSON松散结构和自己的文件系统，主要解决海量数据存储问题。
可想两者应该有差距了。
AreYouOK? 写道我在工作中也遇到很多问题，关系数据库确实有些力不从心了，但是不使用关系数据库，面对复杂的查询，没有好的解决方案。
从这篇文章的介绍看，我对MongoDB最感兴趣，期待后续。
我的需求和这里列出的Web2.0的网站需求还不太一样。我的场景是：
数据量非常巨大，写操作特别多。数据量可以说是无限的，就看系统能处理多少，如果能处理更多就要接入更多的数据（一般来说我们只接入了部分数据）。
读操作非常少，可以用每天多少次来衡量（就那么几个使用人员，他用的时候才有查询操作），但是一旦有查询操作，往往都是重量级的。
查询操作可以稍微慢点，能在5秒内出来就不错了，如果进行复杂的查询，30秒出来也算不错了。10分钟甚至1个小时才查出结果，是非常不好的，但是能出来总比不能要好。
写操作允许丢失少量数据，但是整个数据库的完整性要有保证
数据最好能够压缩存储
在某个项目里面，数据量大的时候大约每天40、50G，使用postgresql，居然也支撑了下来，但是查询非常慢。接下来的一些项目数据量会更大，可能会有这个量的100倍以上，目前没有好的办法，只能从数据源头先做过滤。
我在1年前，开始尝试进行一些探索，根据产品需求特点，使用自定义的数据格式存储。目前能够解决的问题有：
对数据进行简单的解析和压缩存储
能够对压缩的数据进行简单的查询（指定数据源、时间范围、关键字），查询较慢，但是比SQL有一个好处，就是能看见当前查询到哪个时间点了，而不是像SQL一样，等运行完了才能给用户看到
高性能的写入。目前在我的笔记本上进行简单的测试，每秒2万条的UDP包，丢包率是0.5%，在复杂的环境下性能是会下降的，但服务器的性能会更好
不幸的是，我只有很少的时间能投入到这上面，有时候几个星期都没空去弄，所以到现在还有很多要完善的地方，没有在项目里面实用。有时候我都怀疑这条路是不是走错了。
目前没有解决的问题是高性能的、对数据的复杂查询。数据可以分为2部分，原始数据和格式化后的数据，目前我这里只解决了原始数据的问题，对于格式化数据的复杂查询，还是需要类似关系数据库的功能才行。这也是我对MongoDB比较感兴趣的原因。
感觉上，你这就是一个日志统计系统，解决模型可以看现在大部分的日志统计程序
只保留必要的数据，并且汇总必要的数据，根据你可以开放的查询功能，设计你的数据结构。
就是，原始数据直接缓冲后写入文件，再以专门的分析程序进行分析，分析结果形成报表，解释查询的就是各种报表罢了。
onlytiancai 写道比如一个SNS系统，有1亿注册用户，我们可以按用户ID平均分成100组DB。
客户端通过用户ID和一个映射规则去获取它所属的DB组，然后再使用。
因为每组DB只有100w，所以能满足高性能并发读写的需求，慢的话再细分；
对于写缓存，读缓存等是应用的事，可以写应用来实现缓存。
同理，对海量数据高效率存储也可以通过优化mysql或者更细的划分DB组来达到；
每组DB都做热备以达到高可用性；
当用户又增长了100万时，增加一组DB，修改下映射规则就可以满足扩展性。
什么时候该用 nosql db呀
分库会带来太多的维护问题和辐射效应
& 上一页 1
浏览: 4488101 次
来自: 上海
浏览量：125572
像这种总结比较性的ppt文档可以多发啊
看完学习到了很多东西，感谢推荐！
直接对搜索的结果进行缓存是不是会更快一点呢
现在已经是ruby2.0了， 不知道这个的效率是怎么样的， 是 ...
很期待后面3个NOSQL数据库的的详细介绍，文章在哪搭呢？客服QQ：&&&售前咨询：
什么是网站空间和数据库空间，有什么区别，他们之前的关系是？
时间：来源：嘉一互联责任编辑：南海风筝
什么是网站空间和数据库空间，有什么区别，他们之前的关系是？
什么是网站空间：
简单地讲，就是存放网站内容的空间，我们在上网时，通过域名（网址、网站地址）就可以访问到对方的网站内容，然后看对方网站页面，文字，图片或音乐、视频，等都属于里的内容，又称为网页空间，是放页面文件的，从
专业角度讲HTML、css、php网站还有图片，音频，视频等属于存在网站空间里的内容。
什么是数据库空间：
顾名思义，是用来存储数据库的空间，那么数据库又是什么呢，在web网站中有什么作用呢？
Web数据库属于深度Web（Deep Web）的一种资源形势，通常指在互联网中以Web查询接口方式访问的数据库资源，其结构是后台采用数据库管理系统存储数据信息，对外提供包含表单的Web页面作为访问接口，查询结果也以包含数据列表
的Web页面形式返回给用户。
以上是数据库(特指web数据库)的术语理解。通俗的讲，就是一些地址和文字的储存。
从网站后台发布产品，上传的一个图片abc.jpg放在网站的根目录下upload文件夹下的img文件夹下的logo文件夹下，那么存储路径通常为/upload/img/logo/abc.jpg,这个路径就存储在数据库中，空间里的动态网页就相当于框架，他会读
取数据库里的路径，然后才能正确显示这个图片。
说到这里，很多人其实还是不明白，那么再换个方式跟大家解释，现在的多数网站都支持用网站管理后台，去更新文章或者更新产品等，这种有后台管理功能的网站就称为动态网站，这种动态网站是用程序写的，程序语言比较主流的有
asp、php、.net、java等，同时动态网站是必须有数据库的，比较主流的用于web的数据库分别有，access，sql server，mysql等，如果您的网站用的是sql server或者mysql数据库的，就要分别用到网站空间和数据库空间，如果是
access的数据库，因为属于数据量比较小，所以不需要独立的数据库空间。
如果您还是不理解，您可以直接问您的建站技术人员或直接购买模版，然后让空间商根据您的模版来给您推荐网站空间和数据库。
网站空间选购小知识：
网站空间可以由自己买台服务器来做也可以买形式的空间。购买服务器两个难点要面对。一是费用太高，这一般都是大公司或大型网站才会这样做，购买一个普通服务器要一万到几万不等，高性能的服务器要几十、几百甚至几
千万，也要24小时开机，不过现在有云服务器可以相对低成本的购买，一般在几千元左右。二是需要专业人员，服务器是需要专业的服务器维护人员配置环境和维护的。
因此，多数购买网站空间者都会选择虚拟主机形式的网站空间。
以上就是嘉一互联小编为大家讲解的网站空间和数据库空间之间的区别和关系等知识希望有助于大家选购，如果有需要购买欢迎咨询我们的在线客服！
以上是嘉一互联为您介绍的相关内容，希望对您有所帮助，如在、、、以及过程中遇到什么难题，可我们的客服，或者拨打嘉一互联技术热线咨询！电话：嘉一互联随时为您服务！
服务咨询 QQ：&&邮箱 E-mail: song_
京ICP备号-1 京公安网备
Copyright &
嘉一互联 版权所有请问ORACLE9i中的方案（Schema）和表空间（tablespace）以及数据库（database）之间的关系究竟是怎么回事啊？-Oracle/基础和管理-oracle-电脑编程网请问ORACLE9i中的方案（Schema）和表空间（tablespace）以及数据库（database）之间的关系究竟是怎么回事啊？-Oracle/基础和管理作者：佚名　和相关&&请问ORACLE9i中的方案（Schema）和表空间（tablespace）以及（database）之间的关系究竟是怎么回事啊？ 谢谢！ Best & Regards! Jack------回答---------相关资料：｜｜｜｜｜｜｜请问ORACLE9i中的方案（Schema）和表空间（tablespace）以及数据库（database）之间的关系究竟是怎么回事啊？-Oracle/基础和管理来源网络，如有侵权请告知，即处理！编程Tags：　　　　　　　　　　　　　　　　&　　　　　　　　　　　　　　　　　　　　1419人阅读
IT爱好者（16）
作者同类文章X
--表授权给另一个用户
grant&& references&& on&& ERP.customer_info&& to&&
--添加外键约束
alter table SERVICE_ORDER
& add& foreign key (CUSTOMER_ID)
& references ERP.customer_info (CUSTOMER_ID);
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：187685次
积分：2919
积分：2919
排名：第6544名
原创：100篇
评论：24条
(1)(5)(3)(1)(4)(6)(10)(3)(5)(5)(4)(7)(12)(8)(12)(10)(10)(2)(1)> Oracle用户实例数据库关系问题1，使用用户名登陆的时候登陆的是数据库还是实例2，如我使用用户名
Oracle用户实例数据库关系问题1，使用用户名登陆的时候登陆的是数据库还是实例2，如我使用用户名
people168 & &
发布时间： & &
浏览：116 & &
回复：5 & &
悬赏：0.0希赛币
Oracle 用户 实例 数据库 关系问题1，使用用户名登陆的时候登陆的是数据库还是实例& 2，如我使用用户名登陆的时候是登入哪个数据库呢 是在装Oracle时创建的那个数据库吗& 3，如何登陆另外自己创建的数据库呢& 4，使用用户名登陆时登陆的是哪个实例呢& 5，如何登陆另外的实例呢& 谢谢
1.使用用户名登陆的时候是使用实例（进程和一些内存）打开数据库(数据文件，控制文件，日志文件等)；2.Oracle安装完成后，在net configuration assistant配置连接串后，可以登录Oracle安装时的缺省用户（user），如scott,emp,也可以是你装入的3.使用sqlplus或pl/sql工具登录：conn 用户名／密码@连接串 ；4.在工具中：5.可进行用户的登录转换：conn user_other/密码@连接串。
&引用楼主 xubin1204 的帖子:1，使用用户名登陆的时候登陆的是数据库还是实例 2，如我使用用户名登陆的时候是登入哪个数据库呢 是在装Oracle时创建的那个数据库吗 3，如何登陆另外自己创建的数据库呢 4，使用用户名登陆时登陆的是哪个实例呢 5，如何登陆另外的实例呢 谢谢
peoplecwt & &
& & （0）（0）搞错了,用户是登录到实例的,例外的是 / 系统集成认证的用户.其他用户认证需要打开users表,所以需要打开数据库后再进行验证.实例负责操纵数据库,并负责和用户的交互,用户并不直接操纵数据库
pepigoo & &
& & （0）（0）
看看结构图
peopleu & &
& & （0）（0）探讨一个实例可以对应多个数据库,多个实例可以对应一个数据库,看listerner如何配置了. 登录过程是先listerner,再决定是哪一个数据库 客户端的配置在9i以后的版本,使用service_name,也就是服务器端liseterner中设置的service_name,但并非SID,所以客户端并不知道是什么数据库 服务器端配置listerner,可以多个service_name对应一个数据库,也可以配置多个listerner以配置不同的服务器或端口的监听,db和service_name可以多配,servic…
peoplewen & &
& & （0）（0）虚心接受，再回顾了一下，发现是listener可以服务于多个DB，不是实例，谢谢探讨引用:一个实例可以对应多个数据库,多个实例可以对应一个数据库,看listerner如何配置了. 登录过程是先listerner,再决定是哪一个数据库 客户端的配置在9i以后的版本,使用service_name,也就是服务器端liseterner中设置的service_name,但并非SID,所以客户端并不知道是什么数据库 服务器端配置listerner,可以多个service_name对应一个数据库,也可以配置多个listerner以配置不同的服务器或端口的监听…peoplelj & &
& & （0）（0）
本问题标题：
本问题地址：
温馨提示：本问题已经关闭，不能解答。
暂无合适的专家
&&&&&&&&&&&&&&&
希赛网 版权所有 & &&&&增值电信业务经营许可证湘B2-}