网站建设-合理选择数据库(二)

WBOY
リリース: 2016-06-07 17:37:56
オリジナル
1135 人が閲覧しました

在上一篇文章中已经讨论过各个数据库类型的应用场景和如何合理地选择数据库,现在我们来看看一种常常被忽略的存储系统 文件系统。也许对于网站建设来说,这是一种过于简单的存储方式,大多数网站制作人员在初期编程时,访问的都是文件而不是数据库中的数据。

         在上一篇文章中已经讨论过各个数据库类型的应用场景和如何合理地选择数据库,现在我们来看看一种常常被忽略的存储系统 – 文件系统。也许对于网站建设来说,这是一种过于简单的存储方式,大多数网站制作人员在初期编程时,访问的都是文件而不是数据库中的数据。一旦我们学会了在数据库中存储和获取数据后就再也不用文件了。文件系统已经发展很久了,而且许多文件系统是专门为处理非常大量的文件和数据而设计的。这些文件系统包括Google File System(GFS),MogileFS和Ceph等。如果你的系统是一次写,多次读的,那么文件系统是个很好的选择。换句话说,如果不会发生读写冲突,也没有大量的数据库关系,并不需要用到数据库事务,那么采用文件系统才是最好的选择。

         在网站建设中现在有另一种很流行的存储策略叫NoSql,就是与基于Sql的关系型数据库而言,没有了维持关系的ACID属性。这一类存储技术通常被划分为键值存储,可扩展记录存储和文档存储。关于这种技术分类,并没有统一的标准,,很多技术可以被划分到多个种类中。

         键值存储技术包括Memcached,Tokyo Tyrant和Voldemort。这些产品中的数据都有一个键值索引存储在内存中。有些产品能够把键值写入硬盘持久化存储。有些产品会在节点间进行同步复制,而有的则进行异步复制。通过简化的数据存储模型和键值对,这类产品能够提供很高的可扩展性和性能,但在能存储什么数据方面却具有很大的限制。此外,依赖同步复制的键值数据存储仍然具有与RDBMS集群一样的限制,即节点数量和地理位置方面的限制。

         可扩展记录存储技术包括Google的BigTable和Facebook的Cassandra。这些产品采用的是可以拆分到节点的行列数据模型。可以根据主键对行进行拆分或分片,再对列进行分组,存放到不同的节点上。这种扩展方法与网站制作中数据库的X轴和Y轴扩展方法类似,前者是读取数据副本,后者是根据支持的服务来拆分。在这些产品中,行分片是自动执行的,但是列拆分则需要用户自定义,这与RDBMS的操作类似。这些NoSQL产品使用的是异步复制,最终能达到一致性。

         文档存储技术包括CouchDB,亚马逊的SimpleDB和雅虎的PNUTS。这种技术采用的数据模型虽然被称为“文档”,但其实称为多索引对象模型更确切。这些多索引对象可以聚集到多索引对象的集合中,然后可以对这些集合的多个属性进行查询。文档存储技术不支持ACID属性,相反地,它们采用的是异步复制方法,最终能使数据达到一致。这种策略对于大多数读操作远远多过写操作的网站建设项目是适用的。

         NoSQL解决方案把网站建设中的对象和实体之间的关系限制到了最少。正式因为减少了关系,所以能够把系统分发到多个节点上,在维持事务完整性和解决读写冲突的同时,实现了更大的可扩展性。可扩展性对于网站制作的前期和后期维护成本的重大影响在之前的文章中提到过。

         通常情况下,我们都需要对系统的可扩展性和灵活性进行权衡。数据实体之间的关系是进行衡量的关键,随着关系增多,灵活性会增加。灵活性增加,会使成本增加,可扩展性降低。总之,关系带来了灵活性,但降低了可扩展性。正是因为这个原因,网站建设中我们不能滥用关系数据库,而是要“因地制宜”,在有效分析网站需求和数据结构后再做定夺,使系统得到更大的扩展性。

ソース:php.cn
このウェブサイトの声明
この記事の内容はネチズンが自主的に寄稿したものであり、著作権は原著者に帰属します。このサイトは、それに相当する法的責任を負いません。盗作または侵害の疑いのあるコンテンツを見つけた場合は、admin@php.cn までご連絡ください。
最新の問題
人気のチュートリアル
詳細>
最新のダウンロード
詳細>
ウェブエフェクト
公式サイト
サイト素材
フロントエンドテンプレート